Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 95: J2EETM Activity Service for Extended Transactions

Stage Access Start Finish
Final Release Download page 11 May, 2006  
Final Approval Ballot View results 14 Mar, 2006 27 Mar, 2006
Proposed Final Draft Download page 25 Mar, 2004  
Public Review Download page 23 Jun, 2003 07 Aug, 2003
Community Draft Ballot View results 14 Jan, 2003 21 Jan, 2003
Community Review Login page 06 Dec, 2002 21 Jan, 2003
Expert Group Formation   05 Dec, 2000 19 Aug, 2002
JSR Review Ballot View results 21 Nov, 2000 04 Dec, 2000
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
The Activity Service supports flexible ways of composing an application using transactions, and can enable the application to possess some or all ACID properties.

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

Specification Leads
  Ian Robinson IBM
Expert Group
  Autodesk, Inc. Bank of America IBM
  Intalio, Inc. Netscape Communications Novell, Inc.
  Pramati Technologies Progress Software RedHat

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: IBM

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 EJBTM 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 J2EETM 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 JavaBeansTM (EJBTM) and JDBCTM 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.

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.