Hi all,
I have extracted the following posting from the Inprise Appserver Newgroup
(I hope this is OK jkw). I think everbody who is considering buying a server
or throwing out their current one read this. I know this might cause alot of
heated discussions but I think it is time we got to the truth about this
interop thing. I have had enough of the wild claims, somethings verging on
outright lies by ejb server vendors. I think it is hard enough building
distributed systems without these kind of issues not being resolved. My
reading of the spec was that ejb would provide us both portable beans and
interoperability between beans residing in different containers. Can some
inform me that this is not the case because of some vendors not updating
their architectures or because of my reading being incorrect.
============================================================================
=================
Why IIOP matters
Eyal,
Consider a deployment including the following:
a) WebLogic Server 5.0
b) IAS4 (or any other server supporting full IIOP)
c) Client program
Let's say that the client (c) wants to access EJBs in both servers (a) and
(b).If you use WebLogic's proprietary RMI protocol (T3), then your client
(c) can only access (a), not (b), since our product does not support the T3
protocol. If you use WebLogic's client-side IIOP protocol, then your
client(c) can access (a) or (b). However, if (c) starts a transaction, this
transaction will not be propagated to (a), but will be to (b), since
WebLogic does not provide full JTS support, meaning IIOP based transaction
propagation, as per: <http://java.sun.com/products/jts/index.html>
Furthermore, since WebLogic only provides client-side IIOP support, beans
deployed in (a) cannot communicate withbeans deployed in (b), and vice
versa. All of these interoperability limitations go away ifyou use two
products which provide full support for IIOP.This means using IIOP not only
for client-to-server interoperability (which WebLogic supports, partially),
but also for server-to-server interoperability (which WebLogic does not
support at all). With full IIOP based products, (c) can call (a) and (b),
either within the scope of a transaction or not.
I find it curious that the EJB specification recommends using IIOP in
exactly the opposite way. The spec. recommends using IIOP for intra-server
interoperability, since this is where you need to get different vendors to
agree how to communicate, and a standard protocol is very much needed. For
the case of client to server communication, the EJB spec does not currently
recommend a particular protocol, since you can always use the particular
vendor's client-stubs to get the the objects. With WebLogic, they support
IIOP only for clients. Curious...
-jkw
============================================================================
===
Eyal,
To the best of my knowledge, the following application servers provide full
support for IIOP:
GemStone, IAS4, Oracle, Persistence, etc.
The following provide only client support for IIOP:
WebLogic Server 5.0 (still in Beta), iPlanet (not yet in Beta)
The following do not support IIOP at all:
WebLogic Server 4.5.1 (current WebLogic release)So to answer your
question:
Users of WLS 4.5.1 are completely isolated, in terms of interoperability.
Users of WLS 5.0 or iPlanet can only use (non-transactional) IIOP clients,
but have no interoperability among different servers.Users of: GemStone,
IAS4, Oracle, Persistence, etc. can do whatever they want, in terms of
interoperability. Sorry for the "etc.", but I believe there are quite a few
other vendors who are building EJB solutions using full IIOP. I just don't
know the whole list.
-jkw
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
