I have been rounding the Jonas' transaction-group mailing list in order
to get some hints from other people doing the same. Answering a question
that I had posted about Jeremy-Jonas integration, Kathleen Milsted politely
wrote the following:
>Dear Carlos,
>I can give you some info about how Jeremie and JOnAS fit together
>from the Jeremie point of view. However, I can't help with jBoss,
>nor with details of SUN's implementation of rmi-iiop.
>First, Jonathan is a framework of components, the idea being
>that you can build your own ORB (which we use as a generic term for
>a distributed object platform). Jeremie is an RMI-like ORB built
>from Jonathan components. It is RMI-like in the sense that it
>offers an RMI-like programming style (remote interfaces, java
>serialization, etc.) to application developers. However, Jeremie
>uses CORBA IIOP at the network layer as a transport protocol.
>So, Jeremie is in fact a mixture of RMI at the top and CORBA at
>the bottom.
>The link between JOnAS and Jeremie is actually quite simple,
>and basically focuses on how the transaction service context
>is propagated. First, JOnAS remote objects are exported to Jeremie
>(in a similar way to how they are exported to straight RMI).
>However, in the case of Jeremie, when a remote method call is
>invoked, IIOP will be used to transport the call, whereas in
>the case of straight RMI, Sun's RMI-specific protocol JRMP is used.
>Now, when used with a transaction service, Jeremie's marshalling of
>a remote method call is accompanied by a request to a registered
>transaction service (in this case the JOnAS transaction service) to
>see whether a transaction context must also be transported (in an
>IIOP service context field) with the method call. On the receiving
>side, Jeremie unmarshalling includes reading the transaction context
>from the IIOP message and passing it to a registered transaction
>service on that side.
>On the other hand, with pure RMI, no service context fields exist
>in the JRMP protocol to transport a transaction context (or any other
>kind of context). So, JOnAS on top of RMI transports the transaction
>context as an explicit extra parameter in remote method calls.
>However, with rmi-iiop, the way to transport the transaction service
>context should be as for Jeremie and JOnAS.
Although Jonathan seems REALLY interesting software (and I couldn't take
enough time to read about it in detail) and gives a lot of possibilities by
virtue of its openness, I remain thinking that a pure corba orb (using rmi
built on top of it where needed) is a more prudent strategy (no problem
using Jonathan as an orb while not depending on its opennes, although
Jonathan isn't the best orb choice due to the fact that it isn't a very
complete orb). I could give the following reasons to justify this:
1) There are several java orbs implemented already and (hopefully) there
will be more in the near future.
2) Building rmi-iiop on top of an orb isn't hard work and there are some
implementations of this already.
3) The way to integrate a transaction service with an arbitrary corba orb is
standard (and is defined by the portability interfaces given in the ots spec
which a jts must support).
4) The orb-application (or orb-application_server) interfaces are well
defined.
5) Some current orb implementations come with oms transaction service
implementations.
6) Most orbs offer another services (persistence, events, security) which
are pertinent to ejb containers implementations.
7) The corba component model is a more robust ground for a ejb container
implementation and the way to align with it (not necessarily now and
possibly never!) is building it on top of a corba (2.3 or 3? we surely need
a POA) orb.
I think the more important point here is the glue between the core orb,
the services and rmi-iiop. The way to integrate a ots with an orb and to
build rmi-iiop as a layer over an orb should be well defined by now (or at
least easy to encapsulate in a thin layer). I'm sure that the integration
with some of the other services is currently more orb implementation
dependant but the offer of orbs with proprietary services should be enough.
IMHO another kind of solution would be very a little shortsighted.
Carlos.
