[Javier]
> 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.
[Brian]
> What's more clear?
I was just thinking of the stateful bean holding the model in the
model-view-controler architecture. In that case, it seems that the
session bean is closer to the "client's needs" for that particular kind
of client than a stateless session bean which provide "common" services.
By "common", I mean they are more or less appropriate to many different
(kinds of) clients.
In my previous email, I was interested in trying to find out about the
(different) granularity of both
1) the session beans that make the interface to the client
2) entity beans that hides a complex graph of business objects (stored
in OODBMS)
It's been suggested in our company that we should have one stateless
session bean per service. For example, one of them would be used to find
parties playing role R (e.g. investors), another one to find parties
using party ids, yet another one to find relationships between parties
according to criteria X and still another for criteria Y, etc. We may
have something like 40 services in the model described in my previous
email and the list increases when our business expert re-thinks about
it. We can think about the managebility of such granularity but we
didn't know about efficiency issues. I can think of
1) if you have one session bean, you can specify you want a max of 50
in the pool. If you have 5, you can say 10 of each and hope for the
best.
2) If our app has 20 loosely coupled modules (e.g parties,
accounting), we would have 20 or 100 types of session beans depending on
having 1 or 5 per module/entity bean. Does it make a difference?
2) If N different types of session beans need to talk to one single
type of entity bean, does the number of resources used depend on N?
3) Anything else?
Of course our application has more than just a party model like the one
I have discribed so we will have more than one session bean and more
than one entity bean anyway. From your answers/discussions (Thanks
Chris!) and other readings, my conclusion is that for every cohesive
graph of business objects in our systems, there should be
1) one entity bean hiding the graph
2) several session beans (but not one per service???) that make the
interface between the clients and that single entity bean.
If you have implemented that already, you may have followed a criteria
like
* an entity bean should not hide a graph of more than, say, 100
classes
* for each entity bean, I would expect 5-20 session beans with about
5-10 services per bean but never 100 session beans each one with 1
service or never 1 session bean with 100 services, etc.
If you have done CORBA development, you may have an idea of how it
should be in EJB as well or you may have read something about it
(where?). Comments are very welcome indeed. Because I have read many
useful comments in this and other forums, I have an idea but it would be
still better if I knew issues about EJB implementations like GemStone,
Weblogic, Versant container etc. I just would like to learn as much as
possible from the experts.
Thank you very much indeed for being there,
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".
