Name of Contact Person: Tony Storey

E-Mail Address: tony_storey@uk.ibm.com

Telephone Number: +44 1962 815358

Fax Number: +44 1962 817961

Specification Lead: Ian Robinson

E-Mail Address: ian_robinson@uk.ibm.com

Telephone Number: +44 1962 818626

Fax Number: +44 1962 817961

Initial Expert Group Membership:

IBM

IBM has a list of candidate expert member companies some of which have already expressed a wish to participate.

Section 2: Request

2.1 Please describe the proposed Specification:

A framework that supports a large variety of Extended Transaction models.

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

Java 2? platform, Enterprise Edition

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

An increasingly large number of distributed applications are constructed by composing existing applications. The resulting applications can be very complex in structure, and with complex relationships between their constituent applications. Furthermore, the execution of such an application may take a long time to complete, and may contain long periods of inactivity, often due to the constituent applications requiring user interactions.

In a distributed environment, it is inevitable that long running applications will require support for fault-tolerance, because machines may fail or services may be moved or withdrawn. If an application is structured as some composition of transactions, then when executed, the application is frequently required to possess some or all of the ACID properties of the individual transactions. However, currently the application programmer has to build application specific mechanisms to do this (such as creating mechanisms for saving application state, creating ad-hoc locking mechanisms, creating mechanisms for compensating transactions and so forth).

Therefore, functionality is required for supporting flexible ways of composing an application using transactions, with the support for enabling the application to possess some or all ACID properties. Such support should include facilities for supporting business rules, programming rules, and data usage patterns. Long-running applications and activities can be structured as many independent, short-duration top-level transactions, to form a logical long-running transaction.

This structuring allows an activity to acquire and use resources for only the required duration rather than the entire duration of this long-running transactional activity. In the event of failures, to obtain reliable execution semantics for the entire long-running transaction may require compensation transactions which can perform forward or backward recovery. A transactional workflow system can be used to provide scripting facilities for expressing the composition of these transactions with specific compensation activities where required.

This JSR addresses the above problems with current transaction structuring mechanisms by providing a low-level architecture for Workflow Engines, Component Management Middleware, an EJB^TM Container and other systems to use to create advanced transaction implementations.

Similar text will be found in the introduction to the OMG's Activity Service specification that was voted for adoption in October 2000. This document can be found on the OMG document server

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

The JTA and JTS specifications are suitable for individual transactions with ACID properties. However, as stated above, higher level functionality is required for supporting flexible ways of composing an application using transactions, with the support for enabling the application to possess some or all ACID properties. Such support should include facilities for supporting business rules, programming rules, and data usage patterns. Long-running applications and activities can be structured as many independent, short-duration top-level transactions, to form a logical long-running transaction.

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

The J2EE^TM Activity Service for Extended Transactions is based upon the technologies that are defined and standardized as part of the Java 2? platform, Enterprise Edition. Specifically, the Activity Service leverages concepts and mechanisms defined by Java Transaction API (JTA), Enterprise JavaBeans^TM (EJB^TM) and JDBC^TM specifications.

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

Not yet decided. But please see section 3.2 below.

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?

The Activity Service is based on the security architecture defined as part of Java 2? platform, Standard Edition and Java 2? platform, Enterprise Edition.

2.9 Are there any internationalization or localization issues?

No localization issues; where internationalization is concerned, the Activity Service use the I18N support in the Java 2? platform, Standard Edition.

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.

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

Currently planned to be available 3Q2001

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.

• The OMG's Activity Service specification http://cgi.omg.org/cgi-bin/doc?orbos/2000-06-19 on the OMG document server.
• Since an EJB^TM Container may wish to deploy the Activity Service, the Enterprise JavaBeans^TM specification is especially relevant
• Java^TM Transaction API specification - http://java.sun.com/products/jta/index.html
• JDBC^TM 2.0 standard extension API - http://java.sun.com/products/jdbc/jdbcse2.html

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

The OMG's Activity Service specification http://cgi.omg.org/cgi-bin/doc?orbos/2000-06-19 should be read first. IBM will shortly (planned for December 2000) have a specification of all the Java packages and interfaces for consideration.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

None at this time.