|
Wayne,
You ask about the ability to optimize intra-container calls.
As long as things are in the same JVM, there should not be any overhead.
What do you have in mind when you say that there is an "overhead in
the container-boundary crossing"?
I think we are missing something...
Maybe you are assuming things about containers that you didn't express.
alex
Wayne Stidolph wrote:
Good
point... I certainly agree that containers should be built as a composition
of components (service providers) - we're trying to get there with the
Enhydra MultiServer Services by offering a plug-in/service framework so
you can split services off from the Container (the services are managed
independently, protected from client replacement or unauthorized use, and
found via the name system). But, I think that doesn't relate to whether
the Container we build this way is itself typed vs non-typed.
Here
is how I understand your thought, with a concrete example: we would have
a BMPContainer, a CMPContainer, a StatefulSessionContainer, a StatelessSessionContainer.
(Do we further segment according to transaction management attributes supported?)
And each Container hosts multiple bean Homes of that type, and each Home
would manage multiple instance of that class.
So,
I have my Doctor/Nurse/"visit and pay" example. The Doctor and Nurse are
both CMP/CMT entity beans (let's assume Doctors have a relationship with
Client, and Nurses have relationships with ExamRooms). The HospitalVisit
is a CMT stateful session bean, which manages a patient visit using a visit(ClientPK
Client) method - this method gets the ExamRoom, notifies verifies availability
of the Doctor and Nurse and books time in their schedules, then makes sure
the billable event is entered into the payroll system. The payroll system
uses a PayableEvent stateless session bean (CMT, Required) to enter data
into the payroll database (the args to PayableEvent.add() is an array of
Employee references and amounts).
So
I need three Containers to handle the visit, right? (1) A CMPContainer
instance, hosting both DoctorHome and NurseHome; (2) a StatefulSessionContainer
hosting the HospitalVisitHome; and (3) a StatelessSessionContainer hosting
the PayableEventHome. All 3 Containers connect to and use the same DB Manager,
the same TransactionManager, the same LifecycleManager? (And I assume the
CMPContainer has some plug-in interface for third-party OR mapping tools.)
A
couple questions, just playing "devil's advocate" for a bit:
Splitting
apart the Container family from Lifecycle is going to require definition
of a public interface; I like this a lot, but is it going to be feasible
for us to come up with a Lifecycle interface that fits all the Container
types?
Am
I going to be able to optimize inter-Container calls (RMI-style) as easily
as intra-Container calls?
Will
the overhead in Container-boundary crossing hurt performance and provide
additional deadlock possibilities as each Container gathers up Resources
independently? (From a performance viewpoint, consider, for example, the
attachment of security context information ... it can be put into a ThreadLocal
and left there as long as the Thread is traversing Remotes/Beans in the
same Container ... well, as long as we assume the Container is not spread
over multiple JVMs ... but if a call travels between Containers, won't
we have to do Thread allocation/dispatch all over again?)
Where
do I put Container Managed Associations (a later-growth issue, expected
in EJB 2) to control the mapping between Client/Doctor, between Nurse/ExamRoom?
(Assume the Client bean defines an abstract method, getMyDoctor(), that
the Container intercepts and implements in generated code.)
When
we get to container-managed relationships, will we have to accept a restriction
that a relationship can not span persistence types?
How do the disparate
Containers do deadlock detection? One of the classic distributed deadlock
detectors? (Requires some extra messaging between Containers.)
Gotta
run,
Wayne
Stidolph
Lutris
Technologies
Just a small contribution to this discussion...
The problem of optimizing a server with respect to locality (either
in space or in time) is a major issue. There may be a lot of tradeoffs
for answering this problem. This argues for a framework that should by
highly flexible where containers should be seen as special components built
themselves using more basic components. Though the points raised here are
pertinent, the architectural answer is probably not the good one to guarantee
the framework for evolution or extensibility. The important point here
is thinking of building the framework itself out of components, not only
applications. Indeed, plugins are a possible implementation of this approach.
The example concerning the exploitation of reference locality can be
solved using basic typed containers. The solution merely consists in having
these containers share the managers that deal with the different technical
aspects (database connections, activation/passivation system, etc).
Thus we argue for a component-based design of the framework where containers
should be built by composing different pieces, and especially basic typed
containers, which would mainly implement a particular life-cycle for example.
Anyway, with this approach, basic containers should not constraint to support
a single EJB, which would contradict the openess property of the proposed
design.
Pascal.
Wayne Stidolph wrote:
Very
interesting topic! You raise three related questions:1. Should Containers
be typed?1. Should Containers be specific to a bean type?2. Should we support
multiple EJB in a single Container? My
quick thoughts - Let
me raise the issues of: i)
efficient exploitation of locality of reference today, andii) bean-to-bean
relationship management by the Container in the future.We want the platofrm
to be highly efficient at running business applications. I think that requires
we architect planning to exploit the natural tendency of business apps
to have enduring relationships between types of objects, as well as changing
relationships between instances of types. Business applications using components
will tend to use the components in groups - one often-recommended architecture
for business apps is using a Session Bean to provide beahvior in front
of Entity Beans, for example; or often a particular application provides
explicit concepts of a particular relationship between entities (which
may not explicity exist in the data store that houses the entities).For
exploiting locality of reference (sharing database connections, optimizing
inter-bean calls, activating and passivating groups involved in the same
transaction, buylk-capture of the state of a session, etc) we need
to host the multiple beans into the same container. So for efficiency I
argue for un-typed Containers that host multiple beans, today. (And yes,
this moves us to the difficult concept of the Application. We don't do
our customers any favor by ignoring it, though, and we miss out on some
important optimizations.)Then there is the idea of container-management
of explicit applications-level relationship between beans. For example,
a particular Doctor bean wants access to her Nurse beans, over and over
- there is an explicit relationship between Doctors and Nurses, in the
context of the HospitalBusiness application (but maybe that relationship
doesn't exist in the Payroll application.) The link between Doctor and
Nurse may changes over time... in a relational model, the relationship
is often stored in an association table. In the EJB model we would have
to require a Session Bean or maybe specialized code in the Doctor Beans
schema and have to do some specific complex find to get to her Nurses ...
seems to embed the relationship into the code, and even if we accept that
maintenance problem then we can't predict the activation requirements on
Nurses based on the invocations on Doctors. So, I think we're going to
see that relationship made explicit as a deployment description ("this
Doctor has a relationship to multiple EJB of type Nurse, with a relationship
name of 'myNurses' " so the Doctor will ask the container for an enumeration
of "myNurses.") This argues for the multiple-type multiple-bean Container
style. Now,
how should we get CMP behavior or whatever into the Container? Composition
by plug-in, not inheritence. Eventually, there will be a standard EJB CMP
definition for plugins, so lets' get started in that direction.Wayne
Containers Discussion
Current status:
-
The current specification for EJB (1.1) does not
architect the interface between the EJBContainer and Server. The focus
of a Container Provider is on the development of a scalable, secure, transaction-enabled
container that is integrated with an EJBServer. For CMP entity beans, the
container is responsible for persistence of the Entity Beans installed
in the container. Containers must be managed and monitored at runtime
via tools provided by the Container Provider. In particular nothing is
said about the strategy to be followed: is there a unique container or
multiple containers? in a given container are there EJBs of a single type?
May be several types of EJB installed in the same container?...
-
In JOnAS 1.6 there is a unique container in which
are installed several EJBs which are specified in the jonas.properties
files at EJBServer launching time and it is possible at run time to install
others deployed EJB via the ADMServer tool (AdmServer -a).
-
In the JOnAS 2.0 pre-version there is an EJBContainerManager
that is started in the EJBServer; for the moment the EJBContainerManager
creates a unique instance of a Container object in which all the EJBs needed
are installed.
-
In the SUN J2EE reference implementation there
is a ContainerFactory that is able to create four types of container (for
stateless session, stateful session, BMP entity and CMP entity) in each
instance of container is installed only one EJB.
Open questions:
-
Do we provide Generic EJB Containers or Specific
EJB Containers?
-
a Generic typed EJB Container provides the common
fonctionalities for all containers of a given type. An example of common
fonctionality is the Life Cycle. For example we may define a generic EJB
Container for stateless session bean; it is in this sort of container that
the pool of stateless session bean would be implemented. In a generic container
for CMP Entity bean would be implemented the life cycle for entity bean
with the handling of activation/passivation of instances.
-
A Specific type EJB Container would be containers
that inherit from generic containers but that realise services for the
component in a specific way (for example a specific container for CMP entity
beans in which persistence service is provided by JORM or cocobase etc...)
-
Another point of view may be : there are no typed
containers (it is the case for the moment) but a container is where all
the components of an application are installed, there are several containers
at a given time one by application running. This may facilitate the unloading
of beans and corresponding classes for an application. The problem is that
it introduces a concept of Application.
In the previous points we are talking of EJB containers,
but this notion is generalized in the J2EE specification: A typical
J2EE product will provide a container for each application component type:
application client container, applet container, web component conatiner,
and enterprise bean container.
So must we consider that we have this sort
of hierarchy :
-
Container
-
ClientContainer (QUESTION : will this sort of
container exist in the Enhydra J2EE server? who is working on it?)
-
AppletContainer
-
WebContainer (QUESTION : is there a current specification
of this sort of container in the Enhydra J2EE server?)
-
EJBContainer
-
StatelessSessionContainer
-
StatefulSessionContainer
-
BMPEntityBeanContainer
-
CMPEntityBeanContainer
-
JORMEntityBeanContainer
-
CocoBaseEntityBeanContainer
all these containers using the same set of services
Naming, Transaction, Connection Pool, Security, Logging, Timer etc...
in the JOnAS 2.0 version these services has
been repackaged in order to be reused in other containers than EJB Containers
The first axis of discussion is are the
containers typed or not .I think that typed containers are closer to
spirit of J2EE specification. Moreover,it will allow contributions to be
brought on specific optimizations and mechanisms for each type of beans.
It seems the second axis may be: Is there a
container by deployed EJB or may several EJB of the same type be installed
in a container?
The short term and long term
We have to precise what it is needed to be done
for the short term for the first version of Enhydra J2EE server, in terms
of architecture redefinition, in order to facilitate migration of current
containers to new ones that we will need at a more long term and to facilitate
external contributions.
|
