>The collections of lightweight summary objects we are discussing are
>serialized and sent to the client requesting them, they do not remain on
the
>server as any kind of state. They contain the information that the actor
>uses to identify a particular entity that they would like to work with,
>typically.
Why create a session object for the above if there is no client specific
state to keep? Just to host the methods? EJB already provides an entity home
object that manages the associated entity universe. The point is that these
type of summary or "collective" methods (that, again, are *not* client
dependent) should be part of the entity home. BTW, you don't have to
separate class static behavior into another class when writing java classes.
>They also contain the PK of the entity bean that they represent.
Summary info of entities represents a specific member of the same entities?
>These objects are not domain objects, but are designed to contain the
>information needed by a particular actor in a particular use-case, and
>therefore belong in the application model layer.
Which objects? If they represent (or depend on) a specific client then
absolutely yes. Otherwise, I just cannot see how summary info about the top
10 stocks of the stock universe would need to be modeled by session beans
unique to specific clients/actors.
>If there are collections
>of domain objects that need to be provided to the client (as there most
>certainly are, including the examples you gave), then these collections
>should be made available through the interface of the relevant entity bean.
Do you mean "getInfoAboutTop10" should be part of the Security entity bean's
remote interface (as opposed to the home interface)?
Imre Kifor
Valto Systems
===========================================================================
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".
