The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 322

Status: Maintenance
JCP version in use: 2.7
Java Specification Participation Agreement version in use: 2.0

Description:
The Java EE Connector Architecture 1.5 defines a standard architecture for connecting to Enterprise Information Systems. This JSR will enhance the existing specification with features requested by experts and community.

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

Team

Specification Leads

Sivakumar Thyagarajan Oracle

Expert Group

Ericsson AB IBM Oracle

Red Hat SAP SE TmaxSoft, Inc.

Updates to the Original JSR

The JSR was completed by Sun Microsystems. Oracle America, Inc. assumed the Maintenance Lead role.

Maintenance Lead: Sivakumar Thyagarajan

E-Mail Address: sivakumar.thyagarajan@oracle.com

Telephone Number: +91 80 67283773

Fax Number: +91 80 6692 7110

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Sivakumar Thyagarajan

E-Mail Address: sivakumar.thyagarajan@sun.com

Telephone Number: +91 80 6693 7050

Fax Number: +91 80 6692 7110

Specification Lead: Sivakumar Thyagarajan, Binod PG

E-Mail Address: sivakumar.thyagarajan@sun.com, binod.pg@sun.com

Telephone Number: +91 80 6693 7050, +91 80 6692 7784

Fax Number: +91 80 6692 7110,

Initial Expert Group Membership:

Supporting this JSR:

IBM
BEA
RedHat
Oracle
Ericsson AB

Section 2: Request

2.1 Please describe the proposed Specification:

Background The J2EE Connector Architecture 1.5 defines a standard architecture for connecting to heterogeneous Enterprise Information Systems (EIS) in both synchronous and asynchronous mode. It also provides a pluggability layer for JMS (Java Message Service) and JDBC (Java Database Connectivity) providers.

Proposal

The purpose of the Java EE Connector Architecture 1.6 specification is to address areas in J2EE Connector Architecture 1.5 where further support has been requested by the Connector expert group and the public. The areas this specification intend to address are the following:

Generic Inflow Context

Connector Architecture 1.5 supports transaction inflow context. The WorkManager contracts are closely tied with transaction inflow context. This feature will enhance the transaction inflow context to a more generic context to accommodate additional functionality like security. The WorkManager mechanism will be made more flexible and independent of the Inflow contracts.

General Improvements to the Connector 1.5 specification.

The existing connector 1.5 specification will be reviewed and strengthened. Following is an initial list of areas considered for this activity. Note that this list is not a final list and hence all items in this list may not be completed in the timeframe of this specification whereas some other items which are not present in the list might be taken up.

Quality of Services.
Handling Connection Failures.
Message batching.
InteractionSpec for inbound CCI.
Configuration Property Processing.
Inbound and Outbound Consistency.
Usage of TransactionSynchronizationRegistry in Resource Adapters.
ClassLoading for Standalone Resource Adapters.
Clarifying relationship with technologies like JBI and SCA.

Ease of Development

Following the common programming model for Java EE, this expert group will also consider making resource adapter development easier by defining helper classes and annotations for the Connector API wherever applicable. This simplification will be applicable for both inbound and outbound areas of the connector API.

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

This specification is targeted for 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 Java EE Connector architecture is specifically designed for the Java EE platform environment.

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 augmenting the functionality of J2EE Connector Architecture to address requests received from the Java community and the expert group for additional features.

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

See 2.5 above. The existing J2EE Connector Architecture 1.5 specification does not address the areas described in section 2.1. Vendors and developers are forced to use implementation-specific architectures or contracts, resulting in non-portable solutions.

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

The J2EE Connector Architecture is based on the technologies that are defined and standardized as part of the JavaTM EE platform environment. Specifically, the J2EE Connector Architecture leverages concepts and mechanisms defined by Java EE, Java Transaction API (JTA), JDBC and JMS specifications.

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.resource package and its subpackages.

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

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

2.11 Are there any internationalization or localization issues?

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. This is an update to JSR 112: J2EETM Connectors Architecture 1.5

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

We hope to deliver the final specification, reference implementation, and TCK in the Q4 of 2008. A rough estimate of the schedule would be

December 2007 Expert group formed
April 2008 Expert draft
May 2008 Early Draft review
August 2008 Public Review
October 2008 Proposed Final Draft
Q4 2008 Final release (aligned with Java EE 6 dates)

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. We will solicit feedback from the community. See section 2.15 for the transparency measures we will use.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The Expert Group will publish early drafts for review by the community at convenient points during the development of the specification. The Expert Group will solicit feedback from the community via public fora(e.g., public presentations, blogs, and other online postings).

2.16 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). The RI will be made available as part of the Java EE 6 RI. The TCK will be delivered both standalone and as part of the Java EE 6 TCK.

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 a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Pursuant to Section 2.2.1 of the Java Community Process version 2.6, the following is a summary of Sun's anticipated principal license terms and conditions for the JSR, Java EE Connector Architecture 1.6.

The Java EE Connector Architecture 1.6 Technology Compatibility Kit (TCK) will be available both as a standalone TCK and included as part of the Java EE 6 Compatibility Test Suite (CTS). The Java EE Connector Architecture 1.6 Reference Implementation (RI) will be available as part of the Java EE 6 RI.

The TCK license does not limit how a compatible implementation of the specification can be used or distributed, e.g., by limiting the hardware devices or operating environments that can be supported.

Non-Commercial Use

As required by the Java Specification Participation Agreement (JSPA), the Java EE Connector Architecture 1.6 TCK will be licensed at no charge without support to qualified not-for-profit entities. Such qualification will be verified by the Compatibility Testing Scholarship Program. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to: http://java.sun.com/scholarship/.

The RI will be available at no cost under an open source license as part of the Java EE 6 RI.

Commercial Use

Covers all use that doesn't fall under "Non-Commercial Use" above.

Java EE Connector Architecture 1.6 TCK Java Licensee Engineering (JLE) support, available for a fee not to exceed 50ドルk, is required for commercial use for each Marketed Product* which implements the Java EE Connector Architecture 1.6 specification. TCK JLE support includes access, updates and upgrades to the TCK at no additional charge.

Java EE Connector Architecture 1.6 RI and TCK JLE and marketing support will be made available at no extra charge to Java EE licensees under their Java EE business terms.

The RI will also be made available at no cost under an open source license for commercial use as part of the Java EE 6 RI.

For purposes of these terms:

Marketed Product is intended to describe a licensee's product that has its own differentiation and marketing collateral. It may comprise one price list entry, or in some cases multiple entries (for example, to account for different localizations or delivery packaging). By way of example, in terms of Sun's product line we wouldn't consider Sun's Java Application Server to be a Marketed Product, but Sun's Java Application Server Platform Edition, Standard Edition, and Enterprise Edition are 3 Marketed Products. Sun's Java Studio Enterprise is a fourth Marketed Product.

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.

J2EE Connector Architecture 1.5 Specification (JSR 112) http://jcp.org/en/jsr/detail?id=112

Java Platform, Enterprise Edition Specification Version 5 http://jcp.org/en/jsr/detail?id=244

Java Transaction API, Version 1.0.1 http://java.sun.com/products/jta

JDBC Specification, Version 4.0 http://java.sun.com/products/jdbc

Java Message Service, Version 1.0.2 http://java.sun.com/products/jms

A Metadata Facility for the JavaTM Programming Language (JSR 175) http://jcp.org/en/jsr/detail?id=175

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

This specification extends the J2EE Connector Architecture 1.5 Specification. This specification leverages concepts and mechanisms defined in Java EE, JTA, JDBC and JMS specifications. This specification might use the facilities defined by JSR-175 to define metadata attributes to artifacts in the Connector API.

Section 4: Additional Information (Optional)