Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 345: Enterprise JavaBeansTM 3.2

Updates to the original JSR

The following information has been updated since the original proposal on the dates shown:

2014.07.30:

The Maintenance Lead has changed from Marina Vatkina to Linda DeMichiel.

Maintenance Lead Member: Oracle America, Inc.

Maintenance Lead: Linda Demichiel

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

Telephone Number: 1 408 276 7057

Fax Number: -

2013.03.05:

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

2012.04.06:

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

Apr 2011 Expert Group formed
Q3 2011 Early Draft
Q3 2012 Public Review
Q4 2012 Proposed Final Draft
Q1 2013 Final Release

2012.02.02:
The JSR moved to JCP 2.8. Public feedback and archives of Expert Group communications are available here: http://java.net/projects/ejb-spec/lists. The public Issue Tracker is here: http://java.net/jira/browse/EJB_SPEC.


Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle Corporation

Name of Contact Person: Linda DeMichiel

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

Telephone Number: +1 408 276 7057

Fax Number: +1 408 276 4185


Specification Leads: Linda DeMichiel, Marina Vatkina

E-Mail Address: linda.demichiel@oracle.com, marina.vatkina@oracle.com

Telephone Number: +1 408 276 7057, +1 408 276 5637

Fax Number: +1 408 276 4185


Initial Expert Group Membership:

TBD

Supporting this JSR:

Adam Bien
David Blevins
Caucho
Antonio Goncalves
OW2
RedHat
TmaxSoft



Section 2: Request

2.1 Please describe the proposed Specification:

Enterprise JavaBeans (EJB) is an 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 Enterprise JavaBeans 3.0 specification was focused on bringing ease-of-use to the EJB API. The Enterprise JavaBeans 3.1 specification further simplified the EJB architecture from the developer's point of view, while also adding significant new functionality in response to the needs of the community.

The goal of Enterprise JavaBeans 3.2 is to consolidate these advances and to continue to simplify the EJB architecture as well as to provide support for the Java EE platform-wide goal of further enabling cloud computing. The scope of EJB 3.2 is intended to be relatively constrained in focusing on these goals.

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

  • Further enablement for use in the cloud. EJB 3.2 will consider enhancements to the EJB architecture to enable the Platform as a Service (PaaS) model for applications using the EJB architecture in accordance with the directions of the Java EE 7 Platform JSR. This will include an investigation for the support of multiple tenants.
  • Investigation of the potential factorization of the EJB technology to enable use of container services that it currently provides by other component technologies of the Java EE platform. The separate "Interceptors" document is an example of such factorization as was achieved by EJB 3.1. It is expected that the EJB 3.2 Expert Group will investigate the area of container-managed transactions as the first target area for further factorization.
  • Alignment and integration with the simplifications and enhancements made by related JSRs within the Java EE 7 Platform umbrella (e.g., CDI, JMS, Bean Validation, ...)
  • Further use of annotations to simplify the EJB programming model.
  • Specifying as optional earlier EJB technology designated as "proposed optional" in the Java EE 6 Platform specification: namely, EJB 1.x and 2.x entity beans and the required support for web service invocations via JAX-RPC. An implementation is permitted but not required to support such optional features.
The goal of the EJB 3.2 Expert Group will be to investigate these directions, and to identify and pursue aspects for enhancement of the overall programming model and facilities of the Enterprise JavaBeans API. It is expected that additional areas of work may be driven by proposals by the members of the EJB 3.2 Expert Group.

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

The target platform is Java EE.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The Enterprise JavaBeans 3.2 architecture is expected to be included as a required part of the Java Platform, Enterprise Edition version 7. Aligning the timeline of this JSR with that of Java EE 7 may therefore impact the scope of the Enterprise JavaBeans 3.2 release. Features that may not be able to be addressed in Enterprise JavaBeans 3.2 due to time constraints may become candidates for a future release.

2.4 Should this JSR be voted on by both Executive Committees?

No. It should be voted on by the Java SE / EE Executive Committee only.

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

The goal of the proposed specification is to address the needs of the Java community by further simplifying Enterprise JavaBeans from the perspective of the developer and aligning it to meet the evolving needs of the Java EE 7 Platform.

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

See above.

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

See above. A detailed description of the EJB technology can be found in the EJB 3.1 specification, http://jcp.org/en/jsr/summary?id=318.

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

The API Specification will continue to use the javax.ejb, javax.ejb.embeddable, and javax.ejb.spi packages.

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

No.

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

No.

2.11 Are there any internationalization or localization issues?

No.

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

No.

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

Apr 2011 Expert Group formed
Q3 2011 Early Draft
Q1 2012 Public Review
Q3 2012 Final Release

Note that this section of the JSR has been updated since this original proposal.

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

The primary means of communication will be email and conference calls. Face-to-face meetings will be scheduled if needed.

2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate.

  • The public can read the names of the people on the Expert Group.

    Yes. This information will be available in all spec drafts and on the Update page of the JSR.

  • The Expert Group business is regularly reported on a publicly readable alias.

    We intend this to be the case.

  • The schedule for the JSR is publicly available, it's current, and I update it regularly.

    This will be available on the JSR Update page.

  • The public can read/write to a wiki for my JSR.

    We plan to use a public mailing list for comments.

  • I read and respond to posts on the discussion board for my JSR on jcp.org.

    We plan to use a public mailing list for such discussion. We expect the jcp.org discussion board to also be available for such use.

  • There is an issue-tracker for my JSR that the public can read.

    The issue-tracker for the Java EE 7 reference implementation, of which the EJB 3.2 implementation is a part, will be available to the public. Open issues in the specification drafts will be flagged on those drafts.

  • I have spoken at conferences and events about my JSR recently.

    At JavaOne.

  • I am using open-source processes for the development of the RI and/or TCK.

    The EJB 3.2 RI will be developed as part of the open source GlassFish application server. See http://glassfish.java.net.

  • The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR.

    This will be the case.

2.16 Please describe how the RI and TCK will be 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.

Oracle Corporation will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) as part of Java EE 7.

2.17 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.18 Please provide the full text of the licenses that will apply to your Final Release Specification, Reference Implementation and Technology Compatibility Kit, or provide links to the same.


Note that this information has been updated since this original proposal.

Specification license
RI license
TCK license





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.

Enterprise JavaBeans specification, http://jcp.org/en/jsr/detail?id=318

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

The Enterprise JavaBeans API as defined by JSR-318 will be the starting point for this work.

Experience with existing implementations and vendor extensions to the Enterprise JavaBeans architecture as defined by JSR-318 will be considered when evaluating new functionality.