The proposed final draft of the EJB 2.1 specification is available for review. The EJB 2.1 specification extends the existing EJB 2.0 specification with new features, including support for JAXM message-driven beans, enhancements to EJB QL to support aggregate and other operations, support for linking of messaging destinations, support for web services usages within EJB, and a container-managed timer service.

Read the EJB 2.1 Specification Proposed Final Draft.

Check out JSR 153: Enterprise JavaBeans 2.1 Specification.

I think the timer stuff could be a lot better. I'd have prefered to see:

A java:comp name rather than overloading the EJBContext interface. Applications would look up the TimerService at java:comp/j2ee/TimerService or something. I'm worried that this sets a precedent for this sort of mixing concepts moving forward.

Timers invoking MDBs or a WSDL endpoint.

A timer without a standard calendar function isn't so useful for enterprises. Most enterprises need to specify things like 4 business days. More complex requirements (seem in financial applications) would be like special calendars based on multiple variables like the "last Thursday which isn't a bank holiday in august common to japan and the US". I think this sort of calendar function is sorely needed by the spec.

The timer is not invoked using the credentials of the creator of the timer. This is a security problem as now the timer must be executed in the context of a 'standard' principal specified using RUN_AS or system. Who initiated the alarm has been lost. I'd prefer to see the timer only doing what the creator was allowed to do rather than something completely seperate security wise.

Billy
(work for IBM but my views are my own)

<quote>
"The timer is not invoked using the credentials of the creator of the timer. This is a security problem as now the timer must be executed in the context of a 'standard' principal specified using RUN_AS or system. Who initiated the alarm has been lost."
</quote>

This reminds me of the design problem in windows: unprivileged processes can send messages to privileged processes. For example, a simple program operating with user permissions can send a WM_TIMER message to a system process and the system process will greenly call the callback.

Holger

I'm extremely disappointed that Sun didn't include support for "findByPrimaryKeyCollection()" for Entity Bean home interfaces. I don't think the expert group even reads EJB-Interest anymore, even though it's the official place for such feedback, and many people have requested this feature. home.findbyPrimaryKeyCollection(list) gives the developer direct access to the bulk loading aspects of the container. This is useful for batch operations and for situations where EJB-QL can't express a query but SQL can (SQL returning PKs to the home.findByPrimaryKeyCollection()). As far as I'm concerned, this is proof the community feedback process is broken. Sun never even commented on the measure.

<Doug>
I'm extremely disappointed that Sun didn't include support
for "findByPrimaryKeyCollection()" for Entity Bean home
interfaces.
</Doug>
I think the have included a "findByPrimaryKeys" feature:
you can now include a parameter in a EJB QL finder, so
it is possible to have a "findByPrimaryKeyCollection()"!

Bye,

Jürgen

<Jürgen>
I think the have included a "findByPrimaryKeys" feature:
you can now include a parameter in a EJB QL finder, so
it is possible to have a "findByPrimaryKeyCollection()"!
</Jürgen>

Sadly, no. The parameters in the EJB-QL finders can't be collections. Specifically, the IN keyword takes literals or parameters representing individual literals. Additionally, the MEMBER OF keyword doesn't take collection valued parameters. The best subsitute we have at present is to pass in 10 keys at a time, each one as a seperate parameter to the finder. There's no support for generalized collections as parameters.

Sun knows this too. They've just choosen to ignore the community feedback on the matter, leaving Entity Beans crippled due to lack of an alternative query approach when EJB-QL breaks down. You're stuck loading individual entity beans one by one from the database, destroying performance. EJB-QL is very limited at present, as you can't do queries like "find all orders where all lineitems have shipped" (but you can do find all orders where at least one lineitem has shipped). That's just one example. There are many things that EJB-QL can't do.

While I can understand Sun not tackling the general EJB-QL improvement issue, I can't understand why the expert group ignored community feedback regarding a findByPrimaryKeyCollection(), which is a trivial, yet powerful change to the spec. I doubt the expert group even reads EJB-Interest anymore. What's the point of public review if there's nobody to even respond to it.

Without a workable query language or an alternative (like findByPrimaryKeyCollection()), entity beans are proving severly limited and inffective. We all hoped EJB 2.0/2.1 would fixs the major problems with entity beans. But it looks like we'll have to wait until EJB 3.0 now. Meanwhile, .NET races ahead...

Doug

<Doug>
Sadly, no. The parameters in the EJB-QL finders can't be collections
</Doug>
Oh! I didn't notice that, that's really a show stopper.
I can't imagine a real high-througput / low latency application
without a working "IN" clause or something like findByPrimaryKeyCollection().

From my experience, the performance of a use case is (rougly ;-))
directly proportinal to the number of round-trips to the DB Server,
and latency kills you...

Ed Roman, (in the second edition of his book), discusses the introduction of a new role called persistent manager. this will make sure that every persistent manager works with every application server. is this being considered in 2.1?

Also, are any more Collection types being added to the available return types for representing container-managed relationships? right now, i think only java.util.Collection and java.util.Set types are supported.