[omniORB-dev] CORBA Extensible Transport Framework

[Duncan Grisby]

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         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --