> 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.
If you're talking about server-interop, then no, IIOP doesn't matter. In
fact, here's a copy of a letter on the subject that I sent to the EJB2.0
Expert Group. (very long)
---------------------------------
Introduction:
Up until now the EJB specification and its various implementations have
been maturing rapidly. From day one it has been the intent of the
specification
to allow different servers to work together in order to implement some
specific application. Herein I will describe the background and
requirements, and will show reasons why we, the EJBoss-group, does not
believe that making RMI/IIOP mandatory, as a means of providing server
interoperability, is a good idea.
Background:
We want beans residing on different servers to be able to call each
other. This is trivial in the sense that a bean should always be able to
acquire a stub to the bean it wants to talk to in the same way as any
client would do. What is non-trivial is the ability to support proper
security and transaction context propagation. Hence, this problem must
be addressed by the EJB specification in order to allow this kind of
cooperation between beans residing in different servers, potentially
provided by different vendors. In the case of one-vendor scenarios this
may be implemented in any way the vendor chooses, as it is transparent
to the client and bean developers. In the case of multi-vendor scenarios
we must define how this is supposed to work. Whenever the word
"interoperability" is mentioned hereafter, the semantics is "how to
allow beans in EJB-containers from multiple vendors to call each other
while maintaining call context information such as transaction and
security".
Specifically, "interoperability" does not imply the possibility for
CORBA-clients (such as C++-clients) to call beans in a server. This is
a separate problem, whose solution may or may not be the same as the
solution for the "interoperability" problem defined above.
Possible solutions:
The solution that is mentioned in EJB1.1, and which is most likely
discussed by the EJB2.0 expert group, is the use of RMI/IIOP as a means
of providing interoperability as defined above. The general idea is to
define the wire protocol as a way to support interoperability. The
background of IIOP comes from a need to support clients on multiple
platforms written in multiple languages to call a server-object. As
noted above this problem is a superset of the server-to-server
interoperability problem.
Another solution would be to introduce API's which the bean-stubs could
use to extract this information from during a method-call. Specifically,
when a stub is called from a client, which may or may not be a bean, the
stub could extract the context information from the environment using
some specific API (which would have to be defined in the EJB
specification), and it may then forward this along with the method
invocation information to the server where the bean is finally invoked.
This is a more high-level approach which only relies on the client being
in Java, which is true in case of any bean residing in a EJB-container,
regardless of how the container is implemented (a C++-implementation
such as WLE or Jaguar would be possible; the bean still uses a
Java-environment to execute). It may be noted here that the API for
extracting security information is already defined in the JAAS
specification, so the only addition would be a similar API for
transaction context extraction.
Why RMI/IIOP is a bad idea:
There are several flaws with using RMI/IIOP as a way to solve the
interoperability problem.
* RMI/IIOP has technical and historical problems in the sense that
context propagation is not fully defined yet in that particular
technology, or the subset specification IIOP which it relies upon.
* RMI/IIOP makes it much harder to get into the EJB business as it is a
rather complex API to support in addition to EJB. Since the multi-vendor
argument is important for J2EE this should not be ignored. It is not
desirable to have only a few big vendors, since they will only cover a
piece of the target market. By making it possible for smaller vendors to
compete the J2EE market is essentially being made larger, and considered
as viable in more types of projects.
* RMI/IIOP limits the containers quality of service since it is too
low-level. In general, the more high-level approach is used to solve any
particular problem, the more freedom is gained in how to implement the
defined contracts. Specifically, if RMI/IIOP is mandated, it would make
it impossible to use a more optimized wire protocol, it would make it
impossible to add custom logic into the stubs (such as load-balancing
and
fault-tolerance functionality), and, in the case of EJBoss, it makes it
impossible to create these stubs at runtime. EJBoss uses the high-end
functionality provided in JDK1.3 to provide EJB developers with a
super-simple, super-fast deployment facility. The reasons are speed (we
can deploy a bean in under a second), administration simplification (no
generated stub distribution), architecture simplicity (no physical
EJB-objects), and transparent quality of service implementation (our
stubs contain many proxy-features only possible with our custom
wire-protocol).
* It increases the complexity for the bean and client developers, since
it is necessary to use the PortableRemoteObject interface narrowing API.
One of the basic goals of EJB, and any high-level distributed
application API, is to reduce the complexity of the application. Hence,
any solution that increases the complexity for the application should be
avoided as much as possible. Our ability to add features transparently
greatly increases the productivity of the application developer, and
also increases the possible complexity of the application.
Why API-based context extraction is a good idea:
* Allows custom wire protocols, which in the end allows for higher
quality of service.
* Simple to define. JAAS already has the security context extraction
part covered.
* IIOP based servers may still be supported. If a particular vendor
needs to support CORBA-clients, this is no problem. IIOP is just a wire
protocol as anything else.
* Reduces complexity for client- and bean-developers since
PortableRemoteObject is not required.
Summary:
It is the firm belief of the EJBoss-group that mandating RMI/IIOP is a
bad solution all by itself, and also because of the availability of
better solutions.
Should RMI/IIOP be a mandatory part of EJB2.0 we have no intent of
supporting it. It would severely impact our ability to provide our
users with a good EJB solution, which is something that we are not
prepared to do.
We do realize that we only represent a fairly small group of developers
(currently about 400), but we have every intent of making this group
much larger, and also to provide an implementation that is used widely
by a diverse range of developers.
It is our hope that you listen to these arguments against RMI/IIOP and
for an API-based solution, in part because we want to say "we are EJB2.0
compliant", in part because we believe it is the technically right
way to go, and last, but not least, because we believe that on a
conceptual
level it is the right way to go because of the reduced complexity of
EJB.
---------------------------------
That is the opinion of the EJBoss group, and a couple more EJB vendors
(which I won't name here). IIOP is necessary if you want to support
CORBA-clients (i.e. C++-clients et al), but not if you want to do
server-interop.
/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".
