Hi
Paul Hodgetts wrote:
>
> Ron Yust wrote:
>
> > Wow! No static methods/data, no file i/o, no threads, no sockets, no native
> > code. Sounds like EJB is an unruly teenager about to take the family car
> > out on a date. Geeesh, just neuter the EJB application! I may end up
> > sticking with my trusty old RMI server.
Let me know how long it takes to put the security and transaction management in.. ;-)
>
> 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.
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.
>
> However, from my experience, we can actually get away with doing
> many of the prohibited things *if* we can understand the reasons
> they are prohibited and how we can safely work around them. I
This is not guarenteed to be forward compatible. Stick to the spec,
and in areas of conflict, do it my way ;-)
> posted some thread issues that can be worked around earlier, and
> I just posted some static issues. But unfortunately, these
> work arounds are not to spec and often depend on the specific
> container implementation, so they are at risk for rework in the
> future as things get more specified and mature.
>
> An alternative approach is to know what the future J2EE specs
> will add (like connectors), and build our own version of them
> for now with an easy migration later. But this requires either
> access to internal Sun resources or a crystal ball.
Or access to a mailing list with SUN personel on.. ;-)
>
> Life on the bleeding edge...
>
> 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".
Joel Crisp, Senior Java Architect, SUN PS Java Center UK
===========================================================================
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".
