I beg to differ and I specifically pulled that one paragraph from your
excellent argument.
Your argument supports, in my opinion, why IIOP should not be the only
protocol. However, your argument assumes an environment that is very
favorable to RMI, not very favorable to IIOP: who gets to publish the
smart stubs in a distributed system? why would company A allow stubs
coming from company B's server? how does that play with SOAP and similar
interoperability standards that do not use stubs?
The IIOP approach involves propagating the context on the wire, which in
theory allows any two servers to communicate without cross domains by
publishing their stubs. The API between an ORB and EJB is very well
defined (JTS). The RMI approach can either adopt a propagation context,
which allows stubs from server A to use beans in server B, or favor an
API which means server B must push stubs to server A. The SOAP approach
does transaction propagation over the wire, so is my understanding of
DCOM.
I can forsee other possibilities include intra-VM, or other forms of
protocol where a generic approach like propagation would work. It is
then up to each protocol to define in what way, and these protocols tend
to do so outside the J2EE space (is any J2EE vendor involved in the
evolution of SOAP?), and an implementation can always default to use
smart stubs when it makes sense. Why not. If WebLogic works better than
way, just do that.
Since the APIs required to connect all these pieces, whether RMI, ORB,
SOAP, are well defined, and from hands on experience JTA interoperates
very well with OTS, JAAS interoperates very well with HTTP and IIOP and
IPSec, I do not see any problem.
The only issue I see is the total lack of specification for the security
context, and that one is defined to work exteremly well with RMI, I do
not see how it will buy us an IIOP, SOAP, IPSec or other form of
interoperability. I understand that a lot of effort went into the JAAS
design to assure such flexibility.
arkin
> To address the requirements, we've proposed that agents for one another's
> J2EE containers are hosted in each J2EE container (the host). These
> agents (container proxies) are extensions of the concepts of
> application deployment and assembly already present in J2EE. The agent
> could be deployed as JAR files or as an alternative possibly even as
> Java Standard Extensions.
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
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".
