I wrote:
> > Sounds pretty bleak, doesn't it? I think it shows the relative
> > immaturity of the EJB/J2EE architecture. Clearly the ability to
> > use parallelism (threads), I/O, etc. are useful. What's needed
> > are container-friendly ways to access them. This stuff just
> > isn't specified yet.
Joel Crisp replied:
> You need to look at the intention of the EJB spec. It is supposed to be
> easy for the container vendors to implement and to support basic business
> logic. Most of these features are not requirements for blasting data from
> databases to web pages - one prime application area for EJBs. People who
> are doing more complicated things (me included) are moving into grey
> areas of the spec. The solution is to use the spec to cover the parts
> of your application to which it is applicable (basic Entity beans and
> session beans) and to implement any additional complexity outside the
> bean container. This way your sophisticated support services may be
> written _as services_ by sophisticated programmers, and the business beans
> may be written by more business focussed authors - people who should not
> need to know about the more eldrich parts of the application.
My comment came off a lot more harsh than I intended. In the
context of the messages with Ron, where he was expressing a lot of
frustration with the EJB restrictions, it was intended as being
sympathetic with his frustrations. I should have included a smiley
in there somewhere, because I wasn't trying to bash EJB/J2EE.
I agree that EJB does a fine job of handling the more common
enterprise scenarios. I also agree that there are ways to handle
more complex scenarios using techniques like RMI or other classes
implemented outside the EJB context. I also think that things will
get even better as the spec matures to include other facilities for
handling more complex scenarios (e.g., connectors). We can help
this process by identifying those scenarios that aren't well
supported and encouraging the development of facilities that can
be used to solve them.
In the meantime, I'm hoping that through all these discussions we
can develop a set of best practices, or tips and tricks, or whatever,
to handle the complex scenarios. I see that happening every day.
Paul
===========================================================================
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".