Paul Hodgetts wrote:
>
>
> Business objects (or data) as represented by entity beans, are
> usually used across multiple applications, at least if we want
> some level of reuse in an enterprise architecture.
>
> For a given application, we would usually represent its required
> functionality as a set of use cases for the application. These
> use cases will define the business logic required to support that
> application. If we're creating an enterprise architecture to
> support a suite of applications, we'll have a set of use cases for
> each application.
>
> I would caution against migrating use case business logic into an
> entity bean, unless that business logic is intrinsic to the entity
> and common to *all* applications. This type of common business
> logic would be logic that is *only* related to the maintenance and
> access of the entity data apart from the entity's use in any use
> case. Examples would include the usual update/retrieve logic and
> data validation logic.
>
This is an excellent design goal. However, migrating the application
specific logic into session beans is not the only solution. Another
common approach is to model some of the application-specific logic
into role objects, that may be implemented as entity beans.
An example of this is a FlightLeg in an Airline domain. A Flight Leg
has certain extrinsic properties that are invariant across all uses: the
airline that operates it, origin airport, flight number, flight date, etc.
A Flight Leg also has many application-specific properties. For example,
from a reservations viewpoint, you have the set of passenger reservations
and seating assignments. From a flight control viewpoint, you have
the flight plan, aircraft assignment, fuel plan, planned departure and
arrival times, etc. From a flight operations viewpoint, you have crew
assignments, airport gate assignments, food and beverage catering, etc.
The application-invariant parts of a Flight Leg are its intrinsic attributes
and behaviors. The application-specific parts are extrinsic, ones that
emerge out of its participation in a specific context.
I would certainly recommend separating out the extrinsic properties
from the intrinsic ones (and from each other), as Paul does. However,
I'd also be inclined to model each of the application-specific objects
as Entity Beans, not Session Beans.
In my view, the line between Entity and Session beans has more to do
with lifecycle (Entity Beans typically have longer lives) and purpose
(Session beans have more of a functional-orientation, ala the Gof4
Strategy pattern).
Just my $.02
Charlie Alfred
Foliage Software Systems, Inc
===========================================================================
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".
