I've been listening to this debate with great interest. I like Rickard's idea
of API propagation, but there are some issues that give me pause before jumping
on the API band wagon. If we are debating interoperability then, IMO, the API
vs. Protocol fails to address the real issue.
Interoperability is all about servers cooperating to complete a common task.
The only way servers can do this is if they agree on standard protocols or
rules of engagement (peaceful engagement). In other words, how do two servers
in different domains cooperate? This problem is critical to the success of EJB
in the long run.
A hypothetical scenario illustrates the point (you can ignore this paragraph if
you already understand the issue): If a bean in CompanX's system enlists the
services of a bean in CompanyZ's system, how do you propagate the transaction
and security information? Transferring some kind of data that represents the
transaction context is easily. You can use a protocol or the API method. The
hard part is getting the transaction manager and security system used by
CompanyX to cooperate with the transaction manager and security system used by
CompanyZ. How do they communicate?
In order for the Tx Managers to cooperate they have to agree on a internet
protocol, that way they can talk to perform a two phase commit. There are two
ways this protocol agreement can be established, either everyone conforms to
one protocol or you support several protocols and choose one that is commonly
supported at run time. Unfortunately, this second option doesn't' work well
because you have to start communicating somehow and that requires a common
protocol (Catch22).
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.
The second issue in this debate is the transaction and security contexts
themselves. OTS specifies a transaction context that allows two OTS Tx
Managers to cooperate in a distributed transaction. Problem solved IMO. The
security context problem has not been solved. It's complicated, and as I
understand it, will need some work.
Central to this debate is interoperability. The only way we will get
interoperability is to agree on one protocol and a standard transaction and
security context. If we agree on a server-to-server protocol and standard
transaction and security contexts then we have interoperability.
Whether we use an API approach or protocol to propagate contexts between stubs
is not central to the real debate. The real debate is whether IIOP should be
the standard for interoperability between servers. Obviously we have to
decide whether we want to use an API a protocol to transfer the context, but
the real issues we should be talking about are server-to-server
interoperability.
Without server-to-server interoperability, EJB's future is debatable. The
biggest competitor with EJB is MTS (COM+). MTS has the advantage of a
homogenous platform. One vendor, Microsoft, provides everything (tx manager
and security system) so MTS has interoperability automatically, EJB doesn't.
Thanks,
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".
