 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 220: Enterprise JavaBeansTM 3.0
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
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 Telephone Number: +1 408 276 7057 Fax Number: +1 408 276 7191 Specification Lead: Linda DeMichiel E-Mail Address: linda.demichiel Telephone Number: +1 408 276 7057 Fax Number: +1 408 276 7191 Initial Expert Group Membership: * TBD Supporting this JSR: * BEA 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:
* 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 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
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.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. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
