Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 220: Enterprise JavaBeansTM 3.0

Stage Access Start Finish
Maintenance Draft Review Download page 14 Nov, 2007 17 Dec, 2007
Final Release Download page 11 May, 2006  
Final Approval Ballot View results 18 Apr, 2006 01 May, 2006
Proposed Final Draft Download page 21 Dec, 2005  
Public Review Ballot View results 09 Aug, 2005 15 Aug, 2005
Public Review Download page 27 Jun, 2005 15 Aug, 2005
Early Draft Review 2 Download page 08 Feb, 2005 10 Mar, 2005
Early Draft Review Download page 30 Jun, 2004 30 Jul, 2004
Expert Group Formation   10 Jun, 2003 24 Mar, 2004
JSR Review Ballot View results 27 May, 2003 09 Jun, 2003
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0


Description:
The purpose of Enterprise JavaBeans (EJB) 3.0 is to improve the EJB architecture by reducing its complexity from the developer's point of view.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
Star Spec Lead Linda DeMichiel Oracle
  Mike Keith Oracle
Expert Group
  Apache Software Foundation Baier, Oliver BEA Systems
  Behforooz, Reza Bernard, Emmanuel Borland Software Corporation
  Crawford, Scott E.piphany, Inc. Google Inc.
  IBM Ihns, Oliver Infospace
  Nokia Corporation Novell, Inc. Oracle
  Pramati Technologies Progress Software RedHat
  Reinshagen, Dirk Rosenberger, Carl SAP AG
  SAS Institute Inc. SeeBeyond Technology Corp. Shah, Suneet
  Siemens AG SolarMetric Inc. Sun Microsystems, Inc.
  Sybase TIBCO Software Inc. TmaxSoft, Inc.
  Versant Corporation Xcalia

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Original summary: The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based business applications.

The purpose of Enterprise JavaBeans (EJB) 3.0 is to improve the EJB architecture by reducing its complexity from the developer's point of view.

Section 1. Identification

Submitting Member: Sun Microsystems, Inc

Name of Contact Person: Linda DeMichiel

E-Mail Address: linda.demichiel@sun.com

Telephone Number: +1 408 276 7057

Fax Number: +1 408 276 7191


Specification Lead: Linda DeMichiel

E-Mail Address: linda.demichiel@sun.com

Telephone Number: +1 408 276 7057

Fax Number: +1 408 276 7191


Initial Expert Group Membership:

* TBD

Supporting this JSR:

* BEA
* Borland
* Fujitsu
* Fujitsu-Siemens
* IBM
* IONA
* Macromedia
* Oracle
* Persistence Software
* Pramati
* SAP
* Sun Microsystems
* Sybase



Section 2: Request

2.1 Please describe the proposed Specification:

The EJB architecture is a component architecture for the development and deployment of component-based business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure.

The purpose of EJB 3.0 is to improve the EJB architecture by reducing its complexity from the EJB developer's point of view.

It is expected that metadata attribute annotations will play a large role in this simplification. The scope of the JSR is not limited to simplification through the use of metadata, however. It will consider a variety of other features that can promote ease-of-use. It will also examine how existing requirements on the developer can be reduced.

Aspects that should be considered in this work include, but are not limited to, the following:

    * Definition of the Java metadata attributes that can be used to annotate EJB applications. Such metadata will be also be targeted at reducing or eliminating the need for the bean developer to provide an EJB deployment descriptor. Use of metadata will further enable the generation of component and home interfaces for an EJB component from the enterprise bean class itself.
    * Specification of programmatic defaults, including for metadata, to reduce the need for the developer to specify common, expected behaviors and requirements on the EJB container.
    * Definition of utility classes to reduce the number of interfaces and/or callback methods that the bean developer must implement.
    * Encapsulation of environmental dependencies and JNDI access through more convenient utility classes and/or factory patterns.
    * Simplification of the stateless session bean type or the introduction of a simplified EJB component that more closely resembles a plain Java class.
    * Enhancements to container-managed persistence and EJB QL to provide greater usability and to facilitate the development of frameworks based on container-managed persistence.
    * Reduction of the requirements for usage of checked exceptions.
    * Enhancements to facilitate performance optimizations by EJB container vendors.
    * Requests for other enhancements to the EJB architecture to be considered by the Expert Group
.

The goal of the EJB 3.0 Expert Group will be to investigate these directions and to identify and pursue others through which the EJB 3.0 architecture can be simplified and enhanced from the application developer's point of view.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

JavaTM 2 Platform, Enterprise Edition (J2EE) 1.5.

2.3 What need of the Java community will be addressed by the proposed specification?

EJB 3.0 will address the need of the Java community for ease-of-development features targeted at J2EE developers. It is intended that EJB 3.0 make the Enterprise JavaBeans technology accessible to a wider range of J2EE developers.

2.4 Why isn't this need met by existing specifications?

Developers need a standard way to more quickly build and deploy EJB applications.

2.5 Please give a short description of the underlying technology or technologies:

See 2.1 and 3.2.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.ejb

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

No

2.9 Are there any internationalization or localization issues?

No

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No. Developers may continue to freely rely on the existing EJB APIs.

2.11 Please describe the anticipated schedule for the development of this specification.

The following dates are preliminary:

* Expert Group Formation: July 2003BR> * Community Review: February 2004
* Public Review: June 2004
* Final Release: This will occur at the time of the J2EE 1.5 Final Release.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed.

2.13 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Sun will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) as part of J2EE 1.5.

2.14 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

In line with the Java Community Process version 2.5, the following is a summary of Sun's anticipated principal license terms and conditions for the JSR , Enterprise JavaBeans (EJB), version 3.0.

The Reference Implementation (RI) is expected to be included in J2EE, and to be licensed along with the J2EE Reference Implementation.

The EJB TCK is expected to be an integral part of the J2EE CTS, and will be available only through a J2EE CTS license. Compatibility with the specification is tested using the entire J2EE CTS. Licensing of the J2EE RI source code is not required for the licensing of the CTS.

The J2EE 1.5 licensing terms are expected to be very similar to those for J2EE 1.4.

Per the requirements of JCP 2.5, the J2EE CTS is expected to be licensed at no charge and without support under Sun's Compatibility Testing Scholarship Program, described at http://java.sun.com/scholarship/.





Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

3.2 Explanation of how these items might be used as a starting point for the work.

The EJB 2.1 architecture specification will be used as a starting point for this work. It is anticipated that the contributions of JSR-175 (A Metadata Facility for the Java Programming Language) will be one of the key technologies enabling this work. EJB 3.0 will use the facilities defined by JSR-175 to define metadata attributes that can be used to annotate EJB applications. These attributes will be used to simplify (both in quality and quantity) the code written by application developers. The goal of JSR-181 is to define metadata to enable the easy definition of Java Web Services in a J2EE container. EJB 3.0 will plan to leverage the results of JSR-181 for the definition of web service endpoints and the utilization of web services by EJB clients.



Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

No additional information.