Francois Staes wrote:
> It's clear that it is not feasible to expose these methods to client
> applications as this would require many calls to be made from the
> client application to the EJB server to retrieve a customer's name,
> address, etc..
>
> Hence, it is proposed quite often to use a session bean to hide the
> entity bean to the client application. The client application then talks
> to the session bean, and the session bean talks to the entity bean.
>
> Although I understand the advantages of this approach quite clearly
> (especially when having clients that only need to access some of
> the attributes of the entity bean, and as a logical place for
> implementing business logic rules), I don't see very well how it solves
> the communication problem mentioned above. .......
If the session bean and entity bean are in the server process or in a
server cloud (in the case of a clustered architecture), you stand to
benefit quite a bit by not exposing the entity bean to the
client. This is of course assuming the obvious rule that you don't use
the session bean to merely delegate each method to some entity
bean. The session bean should do some, preferably a lot, of
aggregation of *data*.
Look at the session bean as a representative of the client on the
server, instead of as a public wrapper for the entity bean. So, if
the UI displays a list of customer names and addresses, you could
(should) have a method on the session bean that returns an array
of customer related data, either formatted as a ResultSet or an
array of "CustomerInfo" objects .. your choice. The UI should
not dwell on the structure of the object model.
> ..... One could allow the client
> application to retrieve customer information from the session bean
> in two ways:
>
> - Implement a large number of methods in the session bean to retrieve a
> specified customer's name, address, etc.
> (and having the same excessive communication problem as explained
> before);
>
> - Implement one (or a few) methods in the session bean, and have these
> methods work in a CustomerData object (something that
> holds information on a customer and that can be sent to the client
> application and back using serialization).
I don't see why these options are exclusive to each other.
> When implementing the second solution there obviously is a strong
> relationship between this CustomerData object and the original
> entity bean.
Sure. But doesn't *have* to be. If I change the Customer object
tomorrow, should the UI know about it? What if the UI changes
tomorrow? Say, for every customer you want to get a list of their
outstanding payments and for this information you have to go to the
billing system. Should the UI know how many systems have been touched?
The information in your CustomerData object is merely a bunch of
things that are of interest to that screen; it does not necessarily
tie back to one corresponding object in the server.
Another reason for using a session bean is as an intermediate stage is
that it gives you a convenient place to remember the versions or
timestamps of entity beans, in case you wish to implement an
optimistic concurrency scheme.
Finally, having a session and entity bean in the same cloud can
dramatically improve performance. For example, within an app server
such as ours, an intra server call doesn't go through the RMI stack,
an inter-server call gets a fair amount of wire-level optimizations
that are not always available to client-server communication, security
contexts are cached and load balancing algorithms tend to cluster all
object access within a transaction in the same server as much as
possible.
Cheers. Hope this helps.
-Sriram
________________________________________________________________________
Principal Engineer BEA/WebLogic, San Francisco www.weblogic.com
===========================================================================
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".
