> It seems to me that there are actually two parallel issue being debated in this
> thread. One is whether all container vendors should support a common wire
> protocol so that containers can freely inter-operate. The second is whether
> RMI/IIOP is a good protocol for a common wire protocol because of it's network
> and API characteristics.
No, these are not the threads, IMHO. The issues are, as I explained in
my first reply to this thread, as follows:
We want interop between servers. How do we do that?
a) Choose a wire-protocol
b) Choose an API-solution
That's the first issue. In my mind b) is much better, as motivated in
earlier post. I have yet to see any good reasons against this line of
thinking.
The second is, if we, for some reason, decide on a), what protocols
would be possible? The general concensus seems to be that IIOP is the
only possibility, although IIOP does not support interoperability fully
as there is no support for security context propagation.
> On the first I feel very strongly that containers should be able to
> inter-operate at spec levels. That is, a client shouldn't need to know the
> vendor of the container. It doesn't matter if the client is an Applet,
> application, Servlet, JSP, EJB or a daemon process. The whole thrust of a
> component standard is to permit developer's to write business logic, and permit
> the deployer to select the container that offers the features that best meet the
> situation. So, any vendor-specific extensions should in my mind be limited to
> information read from deployment descriptors, and acted upon by the container.
>
> If I have an EJB client that accesses beans, and if I have to re-write the
> client just because I've moved the bean from one container to another, then I
> think that one of those container vendors has violated the EJB design goals
> (Caveat: If I decide to make use of proprietary features that require client
> code, all bets are off).
>
> Similarly, if I need to change code in a bean class because I've moved the bean
> from one container to another, then a spec violation has occurred. This one is
> probably even more important if a market in third-party EJBs is ever going to
> develop,
Absolutely. However, this requirement..
> The conclusion I derive from this argument is that if there isn't a common wire
> protocol, I can't freely move beans around from one container to another,
.. does not lead to this conclusion. Choosing a wire protocol is one
option of several, and not a good one at that.
For a good description of this general problem, please see this new Jini
article on JDC:
http://developer.java.sun.com/developer/technicalArticles/jini/protocols.html
Jini has solved this by following the API-option. EJB should do the
same.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
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".
