2.1 Please describe the proposed Specification:
The specification will define metadata, interfaces, and a runtime model that enable business processes to be easily and rapidly implemented using the Java language and deployed in J2EETM containers. Process Definition for Java will provide a functional foundation upon which J2EE programmers can implement business processes. This foundation will support tasks commonly encountered when programming business processes, for example parallel execution and asynchronous messaging, while leveraging the programming constructs of Java. As such, the foundation can also be used to build Java implementations of business process initiatives such as BPEL4WS, WSCI, and W3C Choreography.
Process Definition for Java will build on Java Language Metadata technology (JSR-175) to provide an easy to use syntax for describing a business process at the source code level for the J2EE platform. Metadata will bind data and tasks within the process definition to variables, classes, and tasks in the source code. The metadata will be amenable to manipulation by tools.
The specification is intended to provide a set of programming interfaces for advanced business process programming and access to data manipulated directly by the business process.
The specification will be based on the J2EE 1.4 platform in order to avoid reinventing existing XML and web services standards required in business processes.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
J2EE 1.4
2.3 What need of the Java community will be addressed by the proposed specification?
Although Java developers can author business processes using existing J2EE APIs, the process is slow, tedious and yields code that is hard to revise and maintain over time. A new standard is required to enable Java developers to rapidly and easily build and deploy complex business processes.
Java needs to maintain its lead as the most competitive platform for corporate application development. As business process-style programming becomes more commonplace, it is very important to the Java community that Java applications programmers have a common model for writing and running business processes under J2EE.
The goal of the specification is to provide a mechanism built on top of the existing J2EE APIs, including the core J2EE web services APIs and the Java Language Metadata technology (JSR-175), that supports the requirements of business process programming in an easy to use, simple syntax.
The JSR aims to address the common needs of business process programming: asynchronous and synchronous messaging using XML and web services, message routing with correlation, parallel execution of tasks, exception processing, and compensation.
2.4 Why isn't this need met by existing specifications?
J2EE provides APIs that can be used to develop business processes. But due to lack of specific support for asynchronous conversations, request/response sequences, and message correlation, workflows written using the current J2EE APIs are tedious and time consuming to develop, difficult to modify and maintain, and hard to deploy.
2.5 Please give a short description of the underlying technology or technologies:
Java Language Metadata (JSR 175) provides a standard model for annotating Java code, of which Process Definition for Java will be one application.
Javadoc is a standard syntax for structured comments introduced in the first version of the Java Language Specification.
J2EE provides existing technologies for messaging, state management, and communication; the Process Definition for Java specification will rely on these technologies.
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
javax.process.*
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?
No.
2.9 Are there any internationalization or localization issues?
No.
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.
March 31, 2003: Expert Group FormedSeptember 30, 2003: Release Community DraftNovember 30, 2003: Release Public Review DraftMarch 31, 2004: Final Release
The schedule above is dependent upon the timely completion of JSR-175.
2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.
Once this JSR is approved, invitations to participate in the Expert Group will be sent to known parties in the business process industry in addition to the standard notification sent to Java Community members. A baseline specification will be created by a process of analyzing and comparing existing proprietary APIs, and this will be developed iteratively by the Expert Group using email and telephone conferencing as the primary mechanisms.
Occasional face-to-face meetings will also be held, roughly quarterly after the initial face-to-face.
2.13 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.
BEA will deliver a standalone reference implementation (RI) and Technology Compatibility Kit (TCK) for Java Process Definition.
2.14 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.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
BEA will license the specification, RI and TCK to all interested parties on a royalty free basis.
Section 3: Contributions3.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 purpose of this specification is to leverage the first standard above, Java Language Metadata (JSR 175), to provide a standard that simplifies development of the commonly required functionality for implementing business processes. Process Definition for Java will utilize the metadata syntax of JSR 175. Since JSR 175 is scheduled for completion with J2SE 1.5, Process Definition for Java may use a pre-processor on the JSR-175 syntax for J2EE 1.4 implementations.
In investigating deployment models for Process Definition for Java, the expert group will determine the extent to which this specification should refer and relate to JSR-088.
The existing XML Schema standard is referenced because it will describe the structure of messages passed between participants in a business process.
Existing implementations such as item 5 above achieve several goals of this JSR and will provide a starting point for the specification.
Items 6-10 above reference cross-platform business process initiatives. This specification anticipates that these initiatives would be implemented on the Java platform using Process Definition for Java. Sun's Java Business Integration JSR will define SPIs that provide a business integration environment. An implementation of Process Definition for Java could use the JBI SPIs.
