Right, and another argument would be in the case of federation of servers, where you wouldnt know at build time to which list of servers you would be talking to.
How would all such servers co-exist in an API based solution?
I checked the "End of Protocols" article. It seems to grab my attention when he mentioned that Jini doesnt require it to be "All Java". But then in details he mentions a JVM has to exist in each application!! I think that is not a viable alternative though theoretically possible.
Atul.
> -----Original Message-----
> From: Bhattacharyya, Ana [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 22, 2000 10:36 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
>
>
> Hi
> I got what u are trying to say -- all that dynamic class loading is
> excellent but still my concern remains ----
> Lets take an example ---
> My application needs to talk to a Database server -- say
> oracle. Now Oracle
> gives me an OracleHandler to communicate to it. Now in all my
> application
> classfiles I have added that Oracle access code using
> OracleHandler class.
> Now what happens when oracle goes off and Informix comes
> in!!!! they have an
> InformixHandler --- but I have to change my code for that!!! But if an
> interface is already defined which is implemented by both the
> OracleHandler
> and the InformixHandler --- then I can just talk to that
> interface and would
> not bother what implementation it is using underneath. So if
> such a standard
> interface is defined then only API solution will be succesful.
>
> But in case of protocols --- IIOP is a standard one which
> everyone has to
> follow and support --- then the protocol solution also should
> work ---- but
> IIOP has a long history of servers being non compatible and
> everyone doing
> their custom stuff which makes the application unportable ---
> on the other
> hand API solution has a better track record in that respect.
>
> cheers
> Anamitra
>
> -----Original Message-----
> From: Rickard �berg [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 22, 2000 8:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Does IIOP Matter !!! READ THIS !!!!!!!!!!!
>
>
> > 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".
>
