On Sun, 28 Jan 2001, you wrote:
> Hi Ed,
>
> Thanks for your reply. I have some comments, below, and would very much
> appreciate further comments from you.. Also, would be happy to hear from
> others on this subject. Apologies to the list for this thread in JBoss
> instead of on EJB-INTEREST, but it was already started here.
's alright, it's interesting....
[snip]
> > > the extra overhead of two remote calls to pass the request through the
> > > session bean to the entity bean, and
> >
> >The session bean is on the server. Only one remote call. And as the session
> >bean is performing larger "lumps" of work one remote call to a session bean
> >can do more work. So actually this leads to fewer remote calls.
>
> Yes, true...I was actually thinking of the extra serialization overhead of
> passing requests/responses between session and entity beans, but I believe
> that can be eliminated with a JBoss option. Only downside to this, I
> guess, is that the semantics of EJB are not strictly adhered to, and this
> feature is probably not portable to all (most?) other EJB containers.
Depends... it'll always _run_ on other EJB servers, and I think any such worth
it's salt should be able to optimize these calls (MHO, you understand).
[sinp]
> EJB and distributed business apps are a new software architecture for me
> and I'm having a little trouble making the leap from concept (which seems
> reasonable enough) to real-world example. For example, if I have a website
> that allows customers to register themselves, creating a Customer entity in
> the process, why would this require business rules. Why can't the client
> (servlet) just invoke the CustomerEJB::create() method to get the job done.
> What would you imagine the biz rules doing in this case?
Making sure that the user had a valid email address, for instance. This seems
an ideal thing for a session bean to do. When it receives a request to add a
new user, it sends an email to the address given, and then waits until it gets
a reply before it calls create() on the CustomerEJB (or until some timeout
occurs).
[snip]
> I'm curious about how you organize your session beans, in general. Do you
> use a session bean per entity that contains all the accessor methods
> (including business rules) for the associated entity? What about
> operations on multiple entity beans? Do you use session beans that are
> functionally organized, and lump all the methods for a functional area in a
> bean? This approach would seem to make the session beans very fluid, and
> the entity beans more stable. Since business process tends to change more
> rapidly than the underlying data structure for most companies, this
> approach seems to match well with the way most requirements will evolve
> over time.
>
> Comments?
Personally, I'm toying with making a session bean generate an HTML interface,
and having a 'dumb' servlet which just passes through the servlet parameters to
the bean and gets the HTML back to return to the client. This obviously won't
work in the case of a Swing client, but it seems to work OK for web apps.
Tom
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
