[Pipet Devel] Open DX as a loci skeleton?

[Harry Mangalam]

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.

Cheers
harry


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

-- 
Cheers,
Harry

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