The problem is that we end up with:
client --> statefull session bean --> stateless session bean --> entitity
beans --> database
Each arrow is a remote invokation, with the overhead of network latency and
the marshaling and unmarshaling of data.
May be I am missing something, but I can not see how a large system can be
implemented like that. If your application server provides optimzation
whereby co-located beans end up calling each other using local method calls,
then at least you solve the performance hit. YOu still have to deal with the
overhead of generating all these extra java files for each bean, even the
dummiest and most passive one.
Can anyboddy provide some useful insight on how to deal with this?
Philippe
-----Original Message-----
From: Dwight Rexin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 11, 1999 11:11 AM
To: [EMAIL PROTECTED]
Subject: Re: ObjectWatch issue 20, an evaluation of Roger Sessions
critiqu e of EJB1.1
I need some help on this one. Wasn't the point that Entity Beans should be
dumb so they can be stored in any resource fairly easily? Aren't the
stateless session beans in particular intended to encapsulate pure business
rules without regard for how the underlying data is actually stored? Seems
that this could be seen as an application of the OO principle of
encapsulation and loose coupling between major responsibilities. If you take
the perspective that stateful session beans are a proxy for the client and
serve as an interface between client presented user functionality, stateless
session bean provided business rules and entity bean provided long term data
it looks like a loosely coupled, divided responsibility model. Different
from tightly coupled object model designs certainly. But perhaps more robust
in the face of many changes over long periods of time. Each approach has
different strengths and weaknesses, right? Isn't designing a system
ultimately about choosing which problems you want to deal with and which you
don't? I like tightly coupled designs in theory. If I have to maintain a
system however, I'll pick the loosely coupled, divided responsibility
approach given the choice. Other people's preferences will no doubt differ.
So long as they get to maintain their systems and I get to maintain mine
we'll be fine...
Dwight
> -----Original Message-----
> From: Fajeau, Philippe [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, August 11, 1999 9:46 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ObjectWatch issue 20, an evaluation of Roger Sessions
> critiqu e of EJB1.1
>
> I would agree on the idea to merge session and entity beans. THe
> distinction
> seems does not fit very well in the OO paradigm which bundles data and
> behavior together (I have seen many postings where people basically say
> the
> entity beans are the data, and the session beans the behavior. THis make
> your entitie beans very dummy, and the session beans very functional).
> However, What about having beans that are remotely invokable and beans
> that
> are not? When developing a fairly complex model, you typically end up with
> some "passive classes", and some more active classes that can be invoked
> remotely, and act as the point of entry for the capabilities provided by
> the
> system. However, all or most of the classes (or objects) have a need for
> persistence, transaction support, and son on. Right now EJB is not very
> friendly for this type of model. Developping all the classes as beans does
> not make any sense (run time performance would be disastrous, development
> overhead), when only a small subset of your beans provide an interface to
> the outside world.
>
> Philippe
>
>
> -----Original Message-----
> From: Sridhar Kumanduri [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 10, 1999 10:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ObjectWatch issue 20, an evaluation of Roger Sessions
> critique of EJB1.1
>
>
> One of the things that comes out of the discussions is that if we
> (developers) have choice of beans , we will be confused. (Hence don't
> provide choices. Mr. Session tells us that MTS has only one for many years
> -
> the one and only one he believes is useful in the EJB spec).
>
> Even the many postings to the interest group we see are about guidelines
> (when to use stateful vs stateless and where to put Business logic) ...
> There is no one answer to all the problems but I guess new developers are
> always looking for experience documents and guidelines .. This is where I
> guess more online material is needed ..
>
> Sridhar Kumanduri
>
> ----- Original Message -----
> From: Eugene Loch <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, August 07, 1999 4:52 PM
> Subject: Re: ObjectWatch issue 20, an evaluation of Roger Sessions
> critique
> of EJB1.1
>
>
> > <soapbox>
> > At first I was infuriated while reading Sessions' article, but after
> > following this thread and thinking about it some more, I realized that
> this
> > article does reflect on a side of reality that we as EJB developers
> don't
> > see every day.
> >
> > Like many developers out there, Sessions just didn't get it. That would
> > include many Java programmers too, by my observations and unscientific
> poll
> > of attendees at JavaOne.
> >
> > Sessions represent the group of seasoned developers (OK, I'm giving him
> > the benefit of the doubt, and I'm being very generous) who had crafted
> > robust, scalable applications without the use of EJB or Java. Given the
> > lack of access to EJB we have today, the due diligence required to
> separate
> > fact from fiction, how can you fault anyone who's on the outside trying
> to
> > figure this out? IMHO the article does point out some of the confusing
> > issues a novice EJB programmer would find.
> >
> > </soapbox>
> >
> > -Eugene
> >
> >
> ==========================================================================
> =
> > 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".
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
