Actually, the problem is stronger than wire-protocol versioning. If
the the component running on a second server is moved to a new
EJB server, and thereby changes wire protocols completely (a
more likely scenario than a wire-protocol version change) client
stubs would need to be redistributed if they are referenced from the
classpath.
A wire protocol solution would make this redistribution
unnecessary. But again, so would stub downloading.
-Dan
On 22 Mar 00, at 14:52, Rickard �berg wrote:
> > I am following this thread for a long time --- I had one question --- Dont u
> > think that when u are using a protocol based apporach u gain more
> > portability as compared to API based apporach --- if u use an API based
> > approach like what u are saying keep the class files of the other vendors
> > server in ur classpath -- hey desent that mean that ur components are using
> > the other vendors class files directly and loosing their portability ---
> > what happens if the 2nd server changes???
> > This solution is only feasible if there is a standard interface defined for
> > the communication and the servers communicate through that interface ...
>
> Excellent! At last a good argument pro-wire, and agains an API solution.
> More like this, please.
>
> Now, to adress your concern, you should first keep in mind that there is
> no difference between updating a particular vendors wire-protocol, and
> updating IIOP. An IIOP-based solution would have the same problem. If
> IIOP was updated as a protocol, all the server communicating with it
> would have to be updated. The only difference here is that if container
> A talks to B and C through IIOP, and A and B upgrades to a newer version
> of IIOP, then A would have to use some kind of versioning system to be
> able to talk to the older version of IIOP that C uses. Is this built-in
> in IIOP? In any case, a custom wire-protocol could also use versioning.
> Anything you can do with IIOP you can do, theoretically, with any
> protocol X.
>
> Same problem as with custom wire protocols, only with custom
> wire-protocols A doesn't have to know about these things: if the beans
> in A wants to talk to B and C, then it is up to the administrator of A
> to make sure that the B and C protocol-classes are up to date. The
> vendor of A doesn't have to do anything.
>
> R U with me? In short, IIOP has the same problem, only worse. This isn't
> really related to IIOP as such, but rather to single-protocol solutions
> in general. Again, Jini solves this through dynamic classloading of
> protocol-implementations, and I see no reason why it couldn't work in a
> J2EE context. Actually, Jini takes special care to be able to allow
> clients to talk to different servers using different versions of the
> same protocol.
>
> Nevertheless, this was a very good attempt at an argument against an
> API-based solution (the only one so far IMO).
>
> /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".
>
===========================================================================
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".
