Hi William,
Excelent letter, hopefully it will make people understand
what is good and what is not.
Do you happen to know how IAS implements security ?
As far as I've seen this has not been released yet. Have
you used security issues in your projects, how ?
Best Regards,
eyal.
> 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 fe
w
> other vendors who are building EJB solutions using full IIOP. I just
don't
> know the whole list.
> -jkw
===========================================================================
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".
