The Java Community Process(SM) Program - JSRs: Java Specification Requests (original) (raw)

• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs

• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

JSRs: Java Specification Requests

JSR 19: Enterprise JavaBeansTM 2.0

Status: Maintenance
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

Description:
The Enterprise JavaBeansTM 2.0 specification extends the architecture with integration with JMS, improved support for entity bean persistence, a portable query language for finder methods, and support for server interoperability.

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

Specification Leads
	Linda Demichiel	Oracle
Expert Group
	BEA Systems	Fujitsu Limited
	Hewlett-Packard	Oracle
	Siemens AG	Sun Microsystems, Inc.
	TIBCO Software Inc.

Original Java Specification Request (JSR)

Identification | Request | Contributions

Original Summary: The Enterprise JavaBeans 2.0 specification extends the EJBTM architecture with new features including the integration with the JavaTM Message Service; improved support for entity bean persistence and relationships; a query language for finder methods; additional home interface methods; and support for server interoperability.

Section 1: Identification

Submitting Participant:

Linda DeMichiel
Java Software, Sun Microsystems, Inc.
901 San Antonio Rd, MS UCUP02-201, Palo Alto, CA 94303

Phone: +1 408 863 3194
Email: linda.demichiel@eng.sun.com

Projected expert group will include experts from:

• application server vendors and container providers
• enterprise tool vendors
• message-oriented middleware product vendors
• enterprise application vendors

Most of the partners involved in previous Enterprise JavaBeansTM specifications have expressed strong interest in participating in the expert group for the Enterprise JavaBeans 2.0 specification.

Section 2: Request

This JSR is to develop the Enterprise JavaBeans 2.0 specification.

2.1 Target Java platform

The Enterprise JavaBeans 2.0 specification is targeted for the JavaTM 2 Platform, Enterprise Edition.

2.2 Need of the Java Community that this work addresses

The Enterprise JavaBeans architecture is a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification.

The purpose of the Enterprise JavaBeans 2.0 specification is to address a number of open areas in the Enterprise JavaBeans 1.1 specification where further support has been requested by the Enterprise JavaBeans partners and the public. The areas we intend to address include, but are not limited to, the following:

• Integration of Enterprise JavaBeans with the Java Message ServiceTM(JMS).
  JMS is an API for accessing enterprise messaging systems from Java programs. JMS integration is needed to allow Enterprise JavaBeans to be invoked asynchronously from clients, to allow them to interoperate with legacy systems that use JMS for integration, to support use of disconnected clients with Enterprise JavaBeans, and to allow use of Enterprise JavaBeans within publish/subscribe configurations.
• Improved Support for Persistence for Entity Beans.
  The EJB specification does not currently define the architecture for data access objects or strategies. Currently two forms of persistence are supported: bean-managed and container-managed. Bean-managed persistence gives the bean developer a high degree of flexibility in customizing the data access components that are used. Container-managed persistence frees the developer from having to code the data access calls and allows the bean class to be independent from the data source in which the entity is stored. In the case of entity beans with container-managed persistence, container providers rely on tools to generate the persistent storage access layer at bean deployment time. For bean-managed persistence, the EJB specification assumes that the data access calls are either coded directly into the enterprise bean class or are encapsulated in a data access component that is part of the entity bean. However, if the data access calls are coded directly into the bean class, it may be difficult to adapt the component to work with a database that has a different schema. In the case where encapsulated data access components are used, we expect these data access components to be generated by tools, and thus not the same for all tools.
  In order to better support the use of tools to generate data access components for either bean-managed or container-managed persistence, we need to investigate to what extent it is possible to define a standard way for the bean provider to describe the complex internal structure of the bean in order to insure that a bean that is developed on one Enterprise JavaBeans server (with a particular set of tools) can be portably deployed in a different server environment, with a different persistent storage facility, with a different set of tools, and a different database. In addition, in the case of container-managed persistence, a standard interface between the container and the persistent storage mechanism would enable tools to operate across the containers of multiple vendors.
• Support for Relationships among Enterprise JavaBeans.
  In the Enterprise JavaBeans 1.1 specification, the management of 1-1, 1-n, and m-n associations among enterprise beans and the management of relationships between enterprise beans and their dependent objects are left to the bean provider. We would like to define a means to capture the information about such relationships that are known to the bean developer so that this information can be made available at deployment time and also at run time.
• Support for Inheritance and Subclassing of Enterprise JavaBeans.
  The Enterprise JavaBeans specification does not currently provide for the subclassing of components. We plan to investigate adding support for this in EJB 2.0.
• Query Syntax for Entity Bean Finder Methods
  The Enterprise JavaBeans 1.1 specification assumes that finder methods for entity beans with container-managed persistence are generated using the container provider's tools. The names and signatures of such methods alone, however, do not specify sufficient information to generate the implementation of finder methods other than ejbFindByPrimaryKey. The bean provider must therefore communicate a description of such methods in a manner specific to the container and its associated tools, thus hampering bean portability. In order to support the definition of portable finder methods, we would like to define a format for specifying the query criteria or the selection predicates that are to be used by the finder method implementations.
• Support for Additional Methods in the Home Interface
  There is currently no means for the bean provider to add methods to provide behavior that is independent of the existence of individual bean instances (other than create and finder methods on the Home interface). We plan to investigate adding support for the bean provider to define additional methods on the Home interface, for example, bulk update operations.
• Mechanisms for Container Extensions
  Interceptors are methods, typically supplied by a systems programmer at the customer site, that the container invokes through a standard interface at well-defined points (and within a well-defined security and transaction context) during the bean invocation protocol. We plan to introduce an interceptor mechanism to provide a portable means for specializing the behavior of the container for specific operational environments, thus reducing the need for specialized containers.
• EJB Server Network Interoperability Protocol
  In order to support network interoperability among CORBA-based EJB server implementations from multiple vendors, it is necessary to complete the mapping of EJB via RMI/IIOP by specifying support for interoperable security and naming.

2.3 Explanation of why the need isn't met by existing specifications

As discussed above, these areas are largely unspecified in Enterprise JavaBeans 1.1. Consequently, Enterprise JavaBeans server vendors and tool vendors that offer support in these areas must necessarily do so using vendor-specific architectures. This in turn means that beans that are written to make use of the functionalities supported by such architectures are not portable to the products of other vendors and/or are dependent upon the tools that were used at bean development time being available at bean deployment time.

2.4 Specification to be developed and how it addresses the need

This extension and revision to the Enterprise JavaBeans 1.1 specification is intended to address these needs in the ways described above.

2.5 Detailed description of the underlying technology or technologies

A detailed description of the Enterprise JavaBeans Version 1.1 functionality can be found in the Enterprise JavaBeans Specification, http://java.sun.com/products/ejb/index.html

2.6 Proposed package name for API Specification

The existing javax.ejb package will be used.

2.7 Security implications

The Enterprise JavaBeans 1.1 architecture specification addresses mechanisms and policies required for secure usage of enterprise beans. The Enterprise JavaBeans 2.0 specification will be consistent with those mechanisms and policies and with those of the Java 2 Platform, Enterprise Edition, as the latter evolves.

2.8 Internationalization implications

The Enterprise JavaBeans architecture uses the I18N support in the Java 2 Platform, Standard Edition.

2.9 Localization implications

None

2.10 Risk assessment (impact of work on target platform, impact if work not carried out, difficulties in carrying out RI and/or CTS)

• The Enterprise JavaBeans 2.0 architecture is targeted to be released as an important feature of the next major release of the Java 2 Platform, Enterprise Edition. It will require that a reference implementation and compatibility test suite be developed as a part of that platform.
• In the absence of this specification, it is highly likely that Enterprise JavaBeans container providers will develop container-specific mechanisms to support integration with JMS, container-managed persistence of entity beans, query syntaxes, and specialized containers. This will in turn result in a proliferation of beans that are not portable across vendors' products. 2.11 Existing specifications that might be rendered obsolete or deprecated by this work

Our goal is to maintain compatibility with previous specifications. We currently see no reason why this will not be possible.

2.12 Existing specifications that might need revisions as a result of this work

No such need can be identified at this time.

Section 3: Contributions

3.1 List of relevant existing documents:

• Enterprise JavaBeans architecture specification - http://java.sun.com/products/ejb/index.html
• Java Message Service specification - http://java.sun.com/products/jms/index.html
• JavaTM Transaction API specification - http://java.sun.com/products/jta/index.html
• Enterprise JavaBeans to CORBA Mapping - http://java.sun.com/products/ejb/docs10.html
• Java 2 Platform Enterprise Edition Specification
• JSR-000016 J2EETM Connector Specification -http://java.sun.com/aboutJava/communityprocess/jsr/jsr_016_connect.html

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

The Enterprise JavaBeans 1.1 architecture specification will be used as the basis for this work.