On Jan 22, 2006, at 5:58 PM, David Jencks wrote:
On Jan 20, 2006, at 1:33 PM, Dain Sundstrom wrote:
I am working on splitting the OpenEJB container into one object
for each deployed ejb and a set of share invocation processing
ejb containers. This is a refactoring of internal interfaces
well below the layer our users see.
Does this mean there will be one interceptor stack for each ejb
type, shared among all the e.g. stateless sesssion ejbs?
By default, yes. The idea is you can deploy extra invocation
processors that have different QoSes configured and then you
assign an ejb to the processor you want.
What is the advantage of this design?
I think the important important advantage for OpenEJB is that this
change aligns the 2 code with the 1 code. The other big advantage
is that it the job of a deployer is simpler because the most
complex configurations (like caches) are placed on the invocation
processors which will be defined using he generic gbean xml tags.
I can think of some disadvantages compared to our present design
but no advantages. Probably just a lack of imagination, but I'd
really appreciate discussion of architectural changes before the
code arrives.
The architectural change is to split the current EJB container
into a service for each EJB and a shared service for invocation
processing. If you want to have a discussion on this, we should
move to the openejb dev mailing list.
I thought about this several years ago in reference to another app
server and thought of 2 designs. I'm curious if you picked one or
found a third, and your reasons. I'll describe the designs in
terms of gbeans for simplicity.
1. The gbeans themselves form the interceptor stack. This means
the ejb gbean needs to have an ejb context object that it sends
down the stack with each call containing the info particular to
that ejb, such as the transaction policy settings. Since you don't
really have any idea what interceptors are present, AFAICT you
either need to code generate a context object to suit the
particular interceptors present, or use a map. A map is a bit slow
and loses type safety, whereas code generation seems awfully
complicated. I suppose it might be possible to use an Object[] and
figure out the indices for each interceptor when the ejb starts.
2. The gbeans are interceptor factories, and when the ejb starts it
uses the factories to construct its own personalized interceptor
stack. Here, each interceptor instance can hold the context
information for itself, and initializing it from a map does not
have a performance penalty. On the other hand, you get more
interceptor object instances.
Dain's on the road again, but I have seen some of the code and try
and recall what I can. From the choices, I'd say it's closer to 1
than 2. I distinctly remember a very impressive looking map
implementation that was type safe in it's understanding of methods.
IIRC it was an object array, not a true map, that gave you method ->
object indexing ability. Something of that nature.
The motivation is something I can speak a little more about as it's
basically a lot of design concepts we found useful in the past. I
think he just got sick of hearing me talk about it and decided to
give it a try :) The idea being to split the ejb specific stuff from
the stuff that is not entirely ejb specific, but likely more specific
to beans of that type. So things like pool settings, or caching
settings could just be configured generally and not over and over
again on a per-ejb basis. You can do more at a macroscopic level and
are forced to do less at a microscopic level. The bean type
information goes to the container (which could be implemented as a
stack of interceptors) and the bean specific information goes into
the ejb context object. For people who know OpenEJB 1, that would be
DeploymentInfo (bad name) and Container.
Surprisingly, it cleans up your code quite a bit to separate concerns
at that level and allows you some great config options. Say for
example, you could tweak the pool size for all the stateless session
beans running in a given container via a management console. No need
to grab each bean individually and set it's pool size. It also
allows you to easily leverage new container implementations. For
example, when we ran the ejb test suite at ApacheCon 2003 that was
basically the "nova" containers wrapped with an adapter and used in
an unmodified OpenEJB 0.9.2 distribution.
Adhering to the idea that simple things should be simple and complex
things possible, if you did want to be very specific and microscopic
in the management of a particular ejb, you just dedicate a new
container definition to that ejb (i.e. a container with one ejb). An
easy way to do that would be via another gbean declaration which you
could probably put right in the openejb-jar.xml file if you wanted.
That's where all the information lays now so it isn't entirely
different.
Anyway, that's the big picture from my eyes.
-David
