On Fri, 2006-09-08 at 10:27 -0500, OKeeffe, Michael K wrote:
> Kevin,
>
> Hopefully I didn't get anything incorrect in this post, there are no
> naming service issues with EJBs and CORBA (orbd)? It seems simpler,
> in 3.0, if anything, to me...
>
> -Mike
>
> http://www.javalobby.org/forums/thread.jspa?messageID=92039511�
Thanks, your post is basically correct. I do have a few comments:
* As Ken Saks has explained in this thread (the discussion with
Gili (cowwoc)), there is no interop requirement for EJB 3 in the
spec, since that is covered by EJB 2.x. That said, an EJB 3
implementation uses the basic RMI-IIOP protocol (and possibly
others like RMI-JRMP or T3) and the usual CosNaming INS
standard. I am not an export on EJB3, so I'll leave any further
discussion on this topic to Ken Saks, who is heavily involved
with both the EJB3 spec and the Sun implementation.
* Much (but not quite all) of dynamic RMI-IIOP is in the JDK 5
ORB. We build both the JDK and the GlassFish/App Server ORBs
from the same code base, but due to the long lead times for the
JDK, the JDK ORB is usually at least 1 year behind where we are
in the app server. Unfortunately, we have not been able to find
time to sync up the latest ORB version with the JDK 6 codebase,
so JDK 6 has basically the same ORB as in JDK 5 (with a few
additional bug fixes).
* We've had an NIO-based transport in the ORB since the JDK 1.4
days. There is a team at Sun working on enhancing Jean-Francois'
work in Grizzly so that a new version of the core Grizzly
transport can be used from the ORB (as well as a number of other
projects). Jean-Francois will probably blogging more about the
changes coming to Grizzly soon (his blog is at
http://weblogs.java.net/blog/jfarcand/ ).
* The code gen improvements are already done. Starting from the
EJB 3 business "POJO" interface, we dynamically generate the
remote interface, a bridge class that adapts the business
interface to the remote interface, and the RMI-IIOP stub at
runtime (no static compiler anywhere) using either BCEL
(currently for the RMI-IIOP stubs) or a library (codegen) built
on top of ASM. Of course, this is one of the problems with
standalone access to an EJB 3 object: you don't even normally
have the remote interface available at the client end. Using the
appserv-rt.jar for the app client solves this problem, but as
others have discussed in this thread, that's a rather large (16
MB) jar file, and this can be too much to deploy widely (I
wonder just what examples people have in mind for deploying
remote access to EJBs? e.g. how many clients, what
bandwidth/memory limitations in the clients?) I have discussed
this with some other GlassFIsh engineers, and I think there is
agreement within the GlassFish project that we should
investigate creating a light-weight client side jar file that
applications can use for remote EJB 3 access.
* At what level to handle failover and load balancing (FOLB) is an
interesting discussion. If everything is stateless, it probably
makes sense to simply handle this at the TCP/IP level. That's
certainly what a lot of customers do for handling HTTP traffic,
and it scales very well. It's harder to do this for IIOP, but
not impossible: we have in fact done some special support for
one particular customer in this area. Basically, we need to:
* Support the use of IIOP without connection caching, so
that each TCP connection is used for a single GIOP
request and response (much like HTTP 1.0). This allows
an external load balancing appliance to make a load
balancing decision on each incoming request.
* Support an ORB configuration that listens on one
particular port (or ports), while creating IORs that
contain the address of the load balancer.
It turns out that both of these changes can be accomplished
through our proprietary ORB SPI, without changing any of the ORB
code. We do plan to investigate better packaging and
productization for IIOP HW FOLB at some point, but limited
resources prevent us from addressing this in AS 9.1/GlassFish
v2.
SW FOLB is a different story. It's already fully supported in
AS 9/GlassFish. There are some things that we can do with SW
FOLB that can't readily be done with a HW load balancer. This
mainly revolves around stateful requests. One of the features
in this area is session stickiness: when a session fails over to
a new node in a cluster, we make sure that all requests to all
objects in the session failover together to the same (new) node
when a node fails. Eventually we may be able to take advantage
of application-level information to improve load balancing
performance (but today we just use a simple round-robin load
balancer on new initial naming context creation).
AS 9 also supports dynamic cluster membership changes: you can
add or remove nodes to a cluster while it is under full load,
and we will seamlessly update all of the remote EJB references
without causing any visible failures to the applications. This
works with all types of EJBs.
Ken.