Richard Monson-Haefel wrote:
[SNIP]
> 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.
Or a common API, whichever.
> 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).
JNDI is a nice way to look each other up, and as you well know, JNDI is more
of API protocol than a wire protocol. How JNDI talks to it's various naming
and directory services is rather an implementation detail. JNDI would in
fact make a perfect example of an API communication interface using
downloaded stubs (hmm, gotta write that down).
> 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.
1) A bean calls a bean in a different container.
2) In completing the bean to bean call, the first container's Tx Manager
asks the other container for a reference to it's Tx Manager and receives an
API interface and/or a stub.
3) Each Tx Manager makes calls on the API interface to coordinate.
> 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.
While I do have some concerns about API communication (see other posts), it
does everything you have mentioned.
> 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.
OTS really defines a collection of interfaces (Current, Coordinator, etc)
and hidden parameters (the transaction context) and makes sure that IIOP
passes them. Wouldn't it be neater if we used the same interfaces and
considered the "how it gets from here to there" as an implementation detail
(i.e. each stub can pass it differently as long as it gets there).
> 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.
Interoperability with yourself doesn't count. Whom else does Microsoft
interoperate with?
Jeff
===========================================================================
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".
