[Chris Raber]
> Any reasonable scale projects that have been successful with CORBA,
> have treated remote objects as with a coarse grained "service"
orientation.
Say that we have a model business model to represent parties and
relationships between them similar to the accountability pattern
[Fowler]. Then you extend that with the Role object pattern (Riehle+) or
the Extension object (Gamma) so that you can see a party as "investor"
if that party has an investment relationship with party Q, a manager if
that party is also the manager of dept D of company C, etc. There are
quite a few more issues in the model but that may give an idea of its
size. There are also accounts, contacts, etc. but it is not an
accounting model.
We use a single entity bean (EB) to represent that fairly big but
strongly cohesive graph of objects (suggestions welcome). EB is not used
by any client and is the only "component" of the system that knows about
the DB (glad it is an OODBMS). The client access the "services" through
session beans. Let's suppose that we do not need to keep state in the
server so they are all stateless. Now the question is how many session
beans should we have?
1) just one (course grained service orientation as stated by Chris Raber
above ???)
2) one per service (a service is just a method: quite a lot of beans
with this approach)
3) all the range between those extremes.
I am wondering about the purely technical reasons here trying to think
what happens under the cover. Let's suppose that each service can be
satisfied by calling methods in the entity bean only and not on other
session beans or even the one that is serving the request. Is it more
efficient in this case to go for course grain (option 1)? If we should
go for option 3, should we tried to make it closer to option 1, 2,
depends (on what?)?
I would expect EB being quite close to the object model and the session
beans being more closed to the client needs. Different session beans may
be used to match different kinds of clients needs. If we need to keep
state in the server (stateful session bean), this is even more clear. I
can see issues here if we try to do something like option 2 above
because we may need a lot of communication between session beans if for
example a complex service requires several subservices, some of which
are provided by session beans ("self" in option 1, another one in option
2) and others by EB. Any comments/patterns?
Javier
===========================================================================
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".
