Rickard �berg wrote:
>
> > 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.
Sorry, but this is false. The OMG's GIOP specification (of which,
IIOP is the TCP mapping) defines how contexts are propagated. The
OMG's OTS specification defines how transaction contexts are
propagated (using the underlying GIOP mechanism). The only real
issue is that there is no agreement as to how the Security
Principal is propagated, since this is a currently a Java-ism.
This is not a complex issue: it basically involves reserving a
GIOP context identifier (a 32-bit number) and then specifying the
GIOP format of the data (which might simply be a string, which
would allow security to be interoperable with C++ and other
languages supporting IIOP). Let's move forward and define the
identifier and the Security Principal format, and be done with it!
There is nothing broken in IIOP: security context propagation has
simply not been standardized yet.
> * 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.
Sun provides a free implementation of IIOP with the JDK. Vendors are
free to use this implementation, or to build their own implementation
and/or partner with a vendor that provides one. The goal of the EJB
specification is NOT to make building containers easy, but to provide
the server technology customers want.
> * 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).
Wrong again. As you say, IIOP is simply a wire-protocol. You CAN optimize
the wire protocol (we do this), you CAN add customer logic into stubs
(we do this for fault-tolerance and load-balancing, for example), you
CAN implement stubs dynamically at runtime (see the DSI/DII portion of the
CORBA specification for details).
Your other claims all hinge on the fact that one can't dynamically implement
stubs/skeletons with IIOP, which is untrue. Dynamic client and server
support has existed in the CORBA specification since day one.
> * 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.
Our Beta product automatically handled the narrowing for you. Our users
complained about this feature, and asked that we not automatically narrow
objects, so as to comply with the EJB specification. Thus, it is possible
to avoid requiring the PRO.narrow when running on IIOP. However, our
product currently requires the narrow because the EJB specification
currently requires it. If the spec chooses to remove the limitation, we
could do likewise (over IIOP, no less).
> Why API-based context extraction is a good idea:
> * Allows custom wire protocols, which in the end allows for higher
> quality of service.
Show me a feature you cannot implement over IIOP and I will show you an
uninspired engineer. Sorry, but IIOP does not restrict functionality,
it simply increases interoperability.
> * Simple to define. JAAS already has the security context extraction
> part covered.
This might be useful in defining the contents of the security context.
However, this context should be propagated with IIOP. See above.
> * 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.
Agreed.
> * Reduces complexity for client- and bean-developers since
> PortableRemoteObject is not required.
Sorry, but the PRO.narrow is not required when running on IIOP, as
noted previously. However, IMO, it is still useful, because it
indicates to users that the object they are using is a little more
heavy weight than a local Java object. This is similar, in my
opinion, to the requirement that all methods throw RemoteException.
Yes, it is annoying overhead, and makes my code more verbose, but
it keeps me in mind of the fact that EJB objects are not local (or
may not be local). But I could honestly go either way, if people
think the PRO.narrow is so complicated!
> 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".
===========================================================================
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".
