Ian,
I agree with your high level process outline.
In addition what folks need is more guidance on #2 (i.e. "overlay the DOM
with 'components'"). We (EJB Industry) have not given the community good
guidelines/hueristics for overlaying domain object models with components,
and the treatment of "dependent objects" or non-bean child objects of a
component covered thinly in the specification.
Here are some off the cuff hueristics for organizing domain objects into
components:
- Objects that share the same life cycle (creation, updating,
destruction...) belong together in a component. For example Order and
OrderLineItem belong together since they have the same life cycle. Product
(referenced from OrderLineItem) does not share the same life cycle, so it is
not part of the Order component.
- Parent to child aggregation hierarchies or owning relationships belong in
the same component. For example Order owns OrderLineItem so they belong
together in the same component. On the other hand OrderLineItem does not own
Produt, so they are in seperate components.
I would be interested to hear other's suggestions for design guidelines
here.
Regards,
-Chris.
----------------------------------------------------------------------
Chris Raber, Director Professional Services, GemStone Systems Inc.
100 West Big Beaver, Suite 200, Troy, MI 48084
phone: (248)-680-6691, fax: (248)-680-6689,
email: [EMAIL PROTECTED]
web: http://www.gemstone.com/
----------------------------------------------------------------------
> -----Original Message-----
> From: Ian McCallion [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, July 12, 1999 11:40 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Entity bean granularity
>
> 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".
===========================================================================
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".
