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?
-Dan
>
>
> Thanks,
>
> Richard
===========================================================================
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".
