Oh, I am not suggesting you only have one coarse grained service
object to talk to the server with. You probably have several/many, and the
services
they offer (i.e. remote methods exposed) are grouped together by
related functionality.
Divide and conquer. You might want to sue one of the components
separately from the others some day!
-Chris.
> -----Original Message-----
> From: Javier Deniz [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, May 06, 1999 1:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Seduction by perceived ease of use,was RE: Granularity
> of EJBObj ects
>
> [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".
===========================================================================
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".
