[Pipet Devel] Open DX as a loci skeleton?

Harry Mangalam mangalam at home.com
Mon Feb 14 13:07:07 EST 2000

This just arrived via the DX list:  It seems to indicate that CORBA, and
even real time functionality may not be that hard to add to DX..  Basically
you write an "CORBA-input" module and a "CORBA ouput" module and that takes
care of the CORBA comms.  DX's internal Data Flow model handles the
analysis internally.


gabra at us.ibm.com wrote:
> While there is no built-in CORBA interface for DX, there are hooks in DX to
> support asynchronous input.  The trick in DX is that modules generally are
> scheduled for execution when their input has changed.  Typically, this
> input consists of data arrving on the
> inputs of the modules - the wires connecting a module to its precursors.
> In the case of asynchronous input, what you do is to create a module that
> has two functions.  One, a "watcher" procedure,  keeps an eye on an input
> stream, and kicks DX to let it know that input has arrived.  The other is
> the module itself, which actually reads the input  when it runs, creates a
> DX data object from the input, and  passes it on down the network.
> In the samples, you'll find a prototype in outboard/watchsocket.c.   This
> sample module (as you might guess) watches for data input arriving on a
> socket.   It opens the socket, and then registers the fd along with the
> "worker" procedure, to the list of fds that DX watches.  When input arrives
> on that fd, DX calls the worker procedure, which in turn calls
> DXReadyToRun, passing in the module's identifier.  This indicates that
> input has changed on that module, and next time DX executes (immediately,
> if DX is in ExecuteOnChange mode) the module will execute.  The module then
> reads the input off the socket, creates an object, and passes it out.
> This scenario can be generalized easily.  Your module spawns a thread that
> blocks waiting for input in whatever manner is appropriate for the
> communications medium you are using.  When input arrives, your thread
> releases and calls DXReadyToRun, just as in the sample.
> I hope this makes sense.
> Greg
> GENE <genepaul at flash.net>@opendx.watson.ibm.com on 02/12/2000 02:18:04 PM
> Please respond to opendx-users at opendx.watson.ibm.com
> Sent by:  owner-opendx-users at opendx.watson.ibm.com
> To:   opendx-users at opendx.watson.ibm.com
> cc:
> Subject:  Re: [opendx-users] Dx and CORBA
> Harry Mangalam wrote:
> ...
> > Second, is there a way for DX servers to communicate via CORBA to make
> data
> > resources, analyses, and requirements known?  It seems that this would be
> > generally useful.   I'm trying to use it as the basis of distributed
> > processing of gene expression data and since a lot of our other services
> > are CORBA-based, it would be of interest to us to hear if others have
> tried
> > it or if the DX-gurus could suggest an approach to do this.
> ...
> Let me add two cents more, and ask if there is an existing real-time
> interface
> capability in opendx which would support a streaming data source, such as
> radar observation reports, continuously being reported?  Secondly, if the
> notion
> of continuously updating a visualization from real-time data is not
> anethema
> to
> the opendx data model, where in the opendx hierarchy of modules, etc. would
> one look to begin to fashion a "real-time"  CORBA IDL-defined interface?
> Pardon me if this is more suitable material for the dev group - just trying
> to
> latch onto the Mangalam theme above.
> Gene Montgomery


Harry J Mangalam -- (949) 856 2847 -- mangalam at home.com

More information about the Pipet-Devel mailing list