Clyde Oldham wrote:
> Same thing has been bothering me as I am about
> to embark on fairly large EJB based project.
>
> IMO this is one of the major questions which
> needs to be addressed by the EJB dev community.
> There are many OO systems that have domain object
> models as a conerstone of their design. Most of
> these models involve complex inheritence and
> association relationships. Polymorphic behaviour
> is important in this modeling.
>
> I have been following this discussion group and
> I am yet to come across a suggestion of a
> reasonable pattern for implementing DOM's in an
> EJB based environment. Most threads where this
> is discussed end up in a debate around the evils
> of inheritence as opposed to delegation.
>
> This to me is missing the point. The issue is:
> we have inheritence in OO analysis, design, and
> implementation. It is a powerful tool when used
> correctly. The Java environment itself relies
> heavily on it and encourages it use in the
> programming model, and yet to my knowledge there
> is no clear and simple way for using it with EJB's.
>
> DOM's usually reflect:
> - "entity" (Jacobson) type objects involved in the
> problem domain.
> - These entity objects have state.
> - The state needs to persist beyond the lifecycle
> of one process
> - There are generalizations and specializations of
> entities.
> - They are involved in units of work (transactions)
> Entity EJB's seem to be the perfect answer at an
> implementation level for dealing with these
> requirements.
I believe the consensus on this list would disagree with you. Entity beans
are not the runtime construct to use for every DOM object because the EJB
model is a distributed component model not an object model. Among several
significant problems, inter-EB method calls are far too inefficient to be
used for method in vocations on fine-grained objects.
> Echoing Michael's question: What then are
> strategies/patterns for implementing domain
> objects to entity EJbeans?
Here's a proposed "strategy" in outline:
1. take your DOM
2. overlay it with "components", Components are coarse-grained,
independently deployable, distributable locales for application code and
will correspont to EJBs when we come to write the actual code. Plan for
where the components are to execute (client or server). Components can
overlap (so that function is deployed multiple places). Component will not
always enclose complete DOM objects. (so that some logic for an object can
be placed on the client, and other logic for the same object on the
server). Make sure that you are happy with where function is executed from
a security perspective. I would expect DOM relationships such as
inheritance to remain within a component - in other words no inheritance
between components.
3. look at use cases to define transaction boundaries. Preferably these
should coincide with component boundaries to avoid explicit transaction
management appearing in the code.
4. look at use cases and where necessary reduce the frequency of flows
between components by creating tailored message objects ("buckets").
5. look at how to persist the instance data of a component. There is a
trade-off between instantiating all state data initially which could slow
dowm some usecases, and constantly faulting to fetch data that has not yet
been instantiated which could slow down other use cases.
6. Use what you did in steps 2-5 to create a separate DOM for each
component that includes the "technical" objects such as buckets. Perhaps we
should call this the "Technical Object Model", TOM.
6. Write/generate the code to the EJB runtime environment for each
component from its DOM.
Hope this helps...
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
