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".
