News: Enterprise Java Beans 2.1 Second Public Draft Available
The Enterprise JavaBeans 2.1 specification Second Public Draft is now available for download at http://java.sun.com/products/ejb/docs.html.
- Posted by: Dion Almaer
- Posted on: June 09 2003 09:22 EDT
Updates in the second draft:
- Adding warning about untrimmed strings in PK's
- Added info on JAX-RPC support
- Clarified that the container is not required to call ejbStore() before ejbFindByPrimaryKey() in CMP
- Clarified assignment rules for CMR fields
- Clarified EJB-QL queries using aggregate operators (SUM, MAX, MIN, etc) must be single object select methods
- Clarified EJB-QL results will have duplicates unless SELECT DISTINCT is used, or java.util.Set returned
- Clarified that the first position in an EJB-QL string is 1
EJB 2.1 includes the following new features: support for the development, deployment, and utilization of Web services; generalization of message-driven beans to support additional messaging types; enhancements to EJB QL to support aggregate and order-by operations; and a container-managed Timer Service.
- didnt we see a EJB 3.0 1st draft a week back ...... by sean decor on June 09 2003 15:09 EDT
- findByPKs by Markus Blumrich on June 10 2003 12:01 EDT
why not combine everything into ejb 3.0 draft.. by the time ejb 2.1 is out , ejb 3.0 will be in its final draft stage and by then ejb 4.0 will be in JCP review .. somebody has to control this process properly.. i dont see a point in releasing so many drafts so fast and keeping the whole market confused ..
I just see this release as the spec catching up with the leading vendors which I think should reduce rather than increase confusion. I admit that the new release needs to be sold well to the user base though so as not to look like "more things you need to deal with to build a J2EE app". .NET sells itself on simplicity (which it does have to some degree) not on functionality (where it is certainly very useful but quite a long way behind J2EE).
Expecting companies to release new patches for compliance with new EJB 2.1 release , asking companies like AT & T, motorola, , wells fargo, chase etc to just change overnight to this new spec .... and by the time they do it , there will be EJB 3.0 at the door step .. its not that simple .. i dont know if anyone thinks of big costs involved in moving from spec to spec - both for vendors and for users .. ( for general home users like us , we can install a beat version also doesnt matter much.. but not at a corporate level )
I m sure half of people out here dont understand ...
This belief that developers are expected to continually drink from the firehouse of new EJB specifications doesn't stand up to examination. Nobody's EJB 2.0 (or 1.1) applications will stop working just because EJB 2.1 has come out. And in the same way, EJB 3.0 will work alongside older versions. Also the 2.1 spec has been in development for something like 18 months and EJB 3.0 is probably 18 months away - sounds like a reasonably paced process to me.
The bottom line is that EJB is continually maturing in response to feedback and that takes time. But EJB works today - a lot of people may not like it but that's another issue (and one that EJB 3.0 is trying to address).
If you decide to use EJB make that decision on what is available today, rather than getting worked up over what may or may not be round the corner.
J2EE specifications if keep on changing like this I think the compnaies would start thinking which version to implement and whether they should go for it or not.Are'nt these people sure what they want to achieve ?I though they have roadmap 4-5 yrs down the line but it looks like a client who is never sure what his requiremnest actually are but still want a software product.
wake up guys this is no way to relase versions.Don't behave like any Tom,Dick & Harry software compnay with new versions every 6 months!!
The last time the 2.1 spec came up for discussion, there was considerable support for adding a standardized findByPKs(Collection PKs) for Entity Beans... I think it's unfortunate this has still not been added. Also - I think a paging function on finder methods would be a huge benefit... what I mean is something that allows you to return a subset of ordered results.