Re: CORBA Extensible Transport Framework
Duncan Grisby <[email protected]> Wed, 09 Nov 2005 10:56:11 +0000
| Newsgroups | gmane.comp.corba.omniorb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Friday 4 November, "J rgen" Weber wrote: > JacORB has an implementation of the CORBA Extensible > Transport Framework ETF, see Chap. 18 of JacORB 2.2 > Programming Guide > (http://www.jacorb.org/releases/2.2/ProgrammingGuide.pdf.gz) > > A collegue of mine wrote a JMS based implementation of > this forJacORB, which was quite easy. > > Are there plans to include ETF into Omniorb, too? Is > somebody allready writing this? There are no plans to support ETF in omniORB. The specification is rather lacking, in that it doesn't address all the things required by a decent transport. In particular, it doesn't have any notion of allowing a thread to block on multiple connections (equivalent to select() or poll() with TCP). It also has a very inefficient design with even the "zero copy" interfaces involving lots of data copying. omniORB has a pluggable transport framework, and it's relatively easy to add new transports on top of a stream protocol. Look at the transports in the src/lib/omniORB/orbcore/tcp, unix and ssl directories. The ssl transport is a good example since it lives in a separate library that initialises itself as it is loaded. > There are still some conservative banks who do not > allow IP networking traffic between sites, but do use > IBM's MQSeries. That's odd, considering MQSeries sends its messages over IP... > So a possibility would be to use MQSeries as technical > transport for the ORB, the server would listen on a > queue. Am I right in thinking MQSeries is purely message based? If so, you'd have to dress it up to look like a stream protocol to be able to run GIOP over it. Cheers, Duncan. -- -- Duncan Grisby -- -- [email protected] -- -- http://www.grisby.org --