Your point about non-Java systems is well taken. Of course we
can't assume that every system in the enterprise is Java-based,
and I agree with you that any solution assuming an all-Java
environment is doomed to fail. I also agree with you that we can't
expect every non-Java system to provide a Java interface.
The original scope of the problem we are discussing was quite
limited--interoperability between J2EE servers. In this case, the
J2EE server would act as a proxy to those non-Java solutions. For
example, something like the following could happen:
1. Bean/Server X calls Bean/Server Y within a transaction.
2. Bean/Server Y updates a non-Java transactional resource.
3. Server X contacts Server Y using its published transactional RMI
API.
4. Server Y forwards that commit/rollback notification to its
managed resource (using that resource's published API, e.g.
JDBC).
So the non-Java resource doesn't need to publish or write to a Java
RMI API specified by EJB. Only a J2EE server does. The J2EE
server provides the downloadable interface for the server's
transaction manager or security service. This can be a facade to
anything you want.
However, interoperability between J2EE servers and other services
(other non-Java application servers/ CORBA objects/ anything else)
is a different matter, and one I have thought little about. From a
bean's point of view, these are all just resources. Would this
matter be addressed in the Connector API? It sounds like
mediating between a J2EE server's authentications/transactions
and a non-Java service is the kind of thing a "Connector API" might
do. What about from the point of view of one of these non-Java
things calling a bean? Well, probably if you're doing this, you're
using a CORBA-based server anyway, so IIOP would be available.
Anyway, thanks for a great couple of posts. They've made me
clearer on some of the issues in this thread.
-Dan
On 22 Mar 00, at 15:29, Richard Monson-Haefel wrote:
>
>
> 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".
