About JCP
Get Involved
Community Resources
Community News
FAQ
Contact Us
|
|
|
|
| Stage |
Access |
Start |
Finish |
| Maintenance Draft Review |
Download page |
20 Feb, 2002 |
25 Mar, 2002 |
| Final Release |
Download page |
24 Sep, 2001 |
|
| Final Approval Ballot |
View results |
21 Aug, 2001 |
04 Sep, 2001 |
| Proposed Final Draft 2 |
Download page |
26 Apr, 2001 |
|
| Proposed Final Draft |
Download page |
25 Oct, 2000 |
|
| Public Review 2 |
Download page |
12 Sep, 2000 |
12 Oct, 2000 |
| Public Review |
Download page |
09 Jun, 2000 |
06 Jul, 2000 |
| Participant Review |
Login page |
26 Apr, 2000 |
26 May, 2000 |
| CAFE |
|
26 Jun, 1999 |
16 Jul, 1999 |
| JSR Approval |
|
25 Jun, 1999 |
|
|
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)
|
 |
Linda Demichiel |
Oracle |
 |
|
| |
BEA Systems |
Fujitsu Limited |
Gemstone Systems, Inc. |
| |
Hewlett-Packard |
Oracle |
Persistence Software Inc. |
| |
Siemens AG |
Sun Microsystems, Inc. |
Sybase |
| |
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:
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.
|
