|
Maybe
I *don't* understand what you mean by Container ... I understand a Container to
be a fairly heavy object that provides some a namespace, possibly some
allocated/pooled resources, some state management and so forth. A Container
cannot make location assumptions about the other Container (it may be remote).
So my concept of overhead comes from what I think happens moving between these
disjoint spaces:
1. the
target has to be found in that other namespace (this may not be a
difference)
2.
some context has to be marshaled and moved (such as transactional state,
security context, session/resource tracking info, etc)
3.
some resources need to be allocated in that target Container if they are of a
type that isn't immediately transferable from one Container to the
other
4. the
thread in the originating Container has to be stalled and another thread
launched in the target container, with attachment of the various context info
and local enrollment of the various resources
5.
reply context info has to be marshaled, transfered, unmarshalled. Resources
released from target Container, returned, re-enrolled in originating Container.
Coordination with transaction manager, other resource managers may be
required.
If a
bean-bean call is inside the same Container, the (it seems to me) the same
thread might be used, thus avoiding a lot of context activity; the resources
used (such as a DB Connection) might be reused easily (and are already
enrolled in the transaction, if there is one), a priori knowledge about related
EJBs might be used to control activation sequences, and so
forth.
Is this view of
inter-Container calls sensible? Or are you thinking we'll have some
extra-Container context object that we hold onto at the EJB Server base and just
move the one object between Containers, then use that object to enlist all the
resources, be the SessionSynch for callbacks, etc? Would that object have the
actual thread used for execution, then?
Wayne
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
termWe 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.
|
