Dan OConnor wrote:
> Richard Monson-Haefel wrote:
>
> > The protocol negotiation and commutation can't even get started until
> > the two Tx Managers: 1) become aware that there is a need to
> > cooperate; 2) locate each other on the network; and 3) start the
> > negotiation. The point is, you absolutely must have a standard
> > protocol like IIOP in order for two Tx Managers to cooperate over the
> > network. The same is true for security managers because they have to
> > negotiate authentication.
> >
> > It seems to me that the only way this type of sever-to-server
> > interoprablity can occur is if there is a standard protocol. The API
> > solution works great for propagating the context from one stub to the
> > next, but it doesn't solve server-to-server interoperability problems.
> > The API method allows you to propagate the contexts but it doesn't
> > make systems interoperable.
>
> Why can't the API method also work for server-to-server interoperability?
> All server X needs from server Y is an interface for each negotiation (over a
> transaction, an authentication, or whatever). The bean stub could provide
> the location of the downloadable interface for its server's transaction
> manager or security service. Server X and server Y don't need a common
> protocol.
>
> What are the disadvantages of this?
>
Good question. (Maybe one of the TP Monitor / OTS people can help me out on this
one.)
The problem is, you would have to Javatize (create some level of Java
connectivity in) every subsystem of each enterprise to make them all use Java
remote interfaces. Java is a great language but lets not expect the entire world
to support it (See Microsoft). Its going to become very common for EJB servers
to front-end large and powerful Tx Managers like CICS, Encina, Tuxedo, etc. The
vendors of these systems are not going to reengineer to their products to a Java
RMI API specified by EJB. They have far to many other customers who don't use
EJB to make that a priority. If we did decide to standardize on Java
RMI-Whatever and some API, then we might as well throw in the towel and start
learning MTS because vendors won't support it. It may seem like its a Java only
world, but its not. A lot of my C++ friends would be miffed it was.
Anyway, the CORBA OTS (based on X/Open) transaction api already addresses this
need and it works across languages and platforms. Most existing Tx Monitors
support X/Open and I'm pretty sure that Tuxedo and Encina have implemented OTS.
At any rate, in the case of transaction managers a language neutral protocol is
the only real solution since we will need to support all kinds of subsystems not
just the two or three little hitters that are written in Java (which, by the way,
all support OTS). So when you think of server-to-server interoprablity don't
limit yourself to thinking in terms of Java. Fact is, companies have a
significant investment in non-Java systems and I imagine many new non-Java
systems will be introduced in the coming years.
Richard
--
Author of Enterprise JavaBeans
Published by O'Reilly & Associates
http://www.EjbNow.com
EJB FAQ
http://www.jguru.com/faq/EJB
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
