> -----Original Message-----
> From: Kenneth D. Litwak [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 14, 2000 4:53 PM
> Subject: Most compelling reasons/scenarios for Entity beans?
>
>
> Im not looking to start a debate. I'm in faovr of EJbs. What I need are the
> most compelling reasons or application scenarios for using an entity bean. Fro
> my perspective, an entity bean is approrpiate if you need to change multiple
> pieces of a data in a specific "record", rather than doing a browse-kind of
> operation. I wouldn't use entity beans to do an update on all the "records" I
> needed to modify, but I owuld use it to change one speciifc row,object, etc.
> What do you think? Thanks.
>
>
> Ken
>
Just my $.02... The question you pose is similar to: "When is it better for a
musician to write a song in the key of D-Minor rather than the key of E?"
While the two keys produce different sounding music, outstanding songs
have been written in both. In most cases, the answer will be determined by
the scope of your project and its key success factors.
Session beans are appropriate for components whose "logical lifecycle"
is limited to a single client session. The logical lifecycle of an Stateless
Session Bean is one lifecycle (even though the physical lifecycle of the
bean instance may be much longer, as the server recycles it for other
clients). The logical lifecycle of a Stateful session bean may span many
EJB method calls and transactions, but are limited to the lifetime of a
single client.
This leaves us with components whose lifecycles may outlast the client
session that created them, and which may be accessed by many different
clients.
There are two common design approaches to modeling these types of
components:
1) Represent the persistent data for the components in an RDBMS and
make JDBC calls from Session Beans to maniupulate them.
2) Implement these components as Entity Beans (possibly wrapping one
or more Java classes), and use either CMP or BMP (possibly along with
an O/R mapping tool) to manage their persistent state.
Several forces influence which of these approaches makes the most sense:
* the Session Bean => JDBC approach works best when the components
represent passive objects. In other words, most or all of the component
methods are straightforward set/get functions.
* the Session Bean => Entity Bean approach gets more attractive when:
- the complexity of the entity component's business logic rises.
- the same Entity Bean components are accessed by lots of different
Session Beans, but use a common interface/implementation for each.
Let me illustrate this with a simple example. In the airline industry, a FlightLeg
represents a non-stop flight, operated by a specific airline, on a specific date,
flying between a specific origin and destination airport. For the most part, a
flight leg is mostly a passive object, acting as a container for properties such
as: scheduled/planned departure time, departure gate, scheduled/planned arrival
time, arrival gate, etc.
None of these properties have very complex business logic. For example, routine
DBMS validation constraints could be used to verify that the arrival or departure
gate code is valid for the respective airport. On the other hand, a business logic
to determine if passengers will be able to make a connection between two
FlightLegs is more complex. It may have to consider the size of the arriving
airplane and the relative locations of the connecting gates.
What's less clear is whether it is better to encapsulate this logic inside of an
Entity Bean, or encapsulate it inside of a Stateless Session Bean that forces
the client to pass in primary key handles for the "entities" involved. Personally,
I find that the latter approach gives me the most flexibility. Clients use
Stateless Session Bean API's to perform their operations, and the design
decision for whether to use straight JDBC access to a database, or delegation
to an EntityBean is transparent to them.
Regards,
Charlie Alfred
===========================================================================
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".
