At any one time there are numerous JSRs moving through the review and approval process.
The Java Community Process (JCP) an open organization of international Java developers and licensees who develop and revise Java technology specifications, reference implementations, and technology compatibility kits through a formal process.The JCP involves the use of Java Specification Request (JSR), which are formal documents that describe proposed specifications and technologies to be added to the Java platform. Formal public reviews of JSRs are conducted before the JSR becomes final and is voted on by the JCP Executive Committee. A final JSR provides a reference implementation (RI) which is a free implementation of the technology in source code form and a Technology Compatibility Kit (TCK) to verify the API specification.
Below are the lists of JCP Stages while proceeding with JSRs.
JSR Review
The Java Specification Request (JSR) is the first step in developing or revising a Java technology specification. A specification is initiated by community members and approved for development by the Executive Committee. The Java Specification Request (JSR) is the first step in developing or revising a Java technology specification.
New JSRs
New JSRs are those which have been recently submitted to the JCP.
Early Draft Review
Once a JSR is approved, a group of experts is formed to develop a first draft of the specification that anyone with an Internet connection can review.
Public Review
The JSR draft goes out for review by the public where anyone with an Internet connection can read and comment on the draft. The Expert Group uses the public feedback to further revise the document.
Proposed Final Draft
The version of the draft specification that will be used as the basis for the RI and TCK.
Final Release
The leader of the Expert Group then sees that the reference implementation and its associated Technology Compatibility Kit are completed before sending the specification to the Executive Committee for final approval.
Maintenance Review
The completed specification, reference implementation, and Technology Compatibility Kit are updated in response to ongoing requests for clarification, interpretation, enhancements, and revisions.
Withdrawn JSRs
JSRs that are withdrawn from the JCP by their Spec Leads before going to Final Release.
Rejected JSRs
JSRs that are voted down by the Executive Committee during the JSR Review, Draft Approval, or Final Approval Ballots.
Below is sample of how JSR is created for a particular version:
JSR 207: Process Definition for JavaTM
Definition of an annotated Java syntax and APIs for programming business processes in Java.
Definition of an annotated Java syntax and APIs for programming business processes in Java.
Section 1. Identification
Submitting Member: BEA Systems
Name of Contact Person:
E-Mail Address:
Telephone Number:
Fax Number:
Specification Lead:
E-Mail Address:
Telephone Number:
Fax Number:
Initial Expert Group Membership:
BEA SystemsSAP AGSun Microsystems
Supporting this JSR:
Cisco SystemsFujitsu LimitedHewlett-PackardIONANokiaSun Microsystems
Section 2: Request
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: 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.
XML Schema 1.0 http://www.w3.org/TR/xmlschema-1/
Existing J2EE specifications, e.g. JAX J2EE 1.4 http://jcp.org/en/jsr/detail?id=151
BEA WebLogic Integration(reference material will be provided to Expert Group, once it is formed) BPEL4WS http://dev2dev.bea.com/techtrack/BPEL4WS.jsp
W3C Choreography http://www.w3.org/2002/ws/chor/
OMG Meta-Data RFP http://www.omg.org/cgi-bin/doc?bei/2003-01-06
Sun's Java Business Integration JSR http://jcp.org/en/jsr/detail?id=208
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.
http://jcp.org/en/jsr/all -- This is the link where you can find all the JSRs.
No comments:
Post a Comment