> 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".
