The Java Community Process(SM) Program - JSRs: Java Specification Requests (original) (raw)

JSRs: Java Specification Requests

JSR 67: JavaTM APIs for XML Messaging 1.0
Stage Access Start Finish Maintenance Release 4 Download page 15 Sep, 2017 Maintenance Review Ballot View results 11 Apr, 2017 24 Apr, 2017 Maintenance Draft Review 5 Download page 27 Mar, 2017 10 Apr, 2017 Maintenance Release 3 Download page 12 Apr, 2006 Maintenance Draft Review 4 Download page 14 Dec, 2005 16 Jan, 2006 Maintenance Draft Review 3 Download page 15 Sep, 2005 17 Oct, 2005 Maintenance Release 2 Download page 21 Oct, 2003 Maintenance Draft Review 2 Download page 17 Mar, 2003 21 Apr, 2003 Maintenance Release Download page 16 Apr, 2002 Maintenance Draft Review Download page 12 Mar, 2002 15 Apr, 2002 Final Release Download page 20 Dec, 2001 Final Approval Ballot View results 30 Oct, 2001 12 Nov, 2001 Proposed Final Draft Download page 25 Sep, 2001 Public Review Download page 28 Jun, 2001 28 Jul, 2001 Community Draft Ballot View results 12 Jun, 2001 18 Jun, 2001 Community Review Login page 04 May, 2001 18 Jun, 2001 CAFE 02 Jun, 2000 23 Jun, 2000 JSR Approval 27 May, 2000 02 Jun, 2000

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

Description:
JAXM provides an API for packaging and transporting business transactions using on-the-wire protocols being defined by ebXML.org, Oasis, W3C and IETF.

Expert Group Transparency:
Public Project Page
Public Communications
Issue Tracking

Specification Leads
Lukas Jungmann Oracle
Expert Group
BEA Systems: Dan Frantz BEA Systems: Jags Ramnarayanan
Cisco Systems: Krishna Sankar Electronic Data Systems (EDS): Waqar Sadiq
Hewlett-Packard: Daniel Haller Hewlett-Packard: Bill Jones
Oracle: Lukas Jungmann Oracle: Neal Wyse
SAP SE: Peter Eberlein Software AG: Prasad Yendluri
Sybase: Jean Choi Sybase: Himagiri Mukkamala
Contributors

Updates to the Original JSR

The following information has been updated from the original proposal:

2017.03.17:
The JSR changed to JCP version 2.10 as part of maintenance.

Q: Is the schedule for the JSR publicly available, current, and updated regularly?
A: The Maintenance schedule is aligned with JDK 9 schedule

Q: Can the public read and/or write to a wiki for the JSR?
A: no, there is no wiki set up

Q: Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
A: there are mailing lists: https://java.net/projects/saaj/lists

Q: Have you spoken at conferences and events about the JSR recently?
A: No

Q: Are you using open-source processes for the development of the RI and/or the TCK?
A: for RI - yes, for TCK - no, I don't think so.

Q: What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?
A: API and RI are both hosted at java.net, so its terms of use should apply

Q: What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state.
A: https://java.net/jira/browse/SAAJ/

Q: What is the mechanism for the public to provide feedback on your JSR?
A: Mailing lists: https://java.net/projects/saaj/lists

Q: Where is the publicly-accessible document archive for your Expert Group?
A: No, when there was an Expert Group, it was under JCP 2.6, so the EG communication was internal-only, I think

Q: Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?
A: yes

Q: Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR?
A: yes, twitter: https://twitter.com/jlukas

Q: Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR (please also post this to your Community tab)?
A: probably none at this point since I'd like to EOL this JSR. This should be last maintenance release for JSR-67, future development should happen within JSR-224.

2017.02.01:
The Maintenance Lead changed to Lukas Jungmann.

Specification Lead: Lukas Jungmann, Oracle

E-mail address: lukas.jungmann@oracle.com

Telephone number: +420 221 43 8543

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Participant: Sun Microsystems, Inc.

Contact Persons:

List of other Participants who endorse this JSR:

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR requests the creation of the Java API's for XML Messaging 1.0 specification (JAXM). This specification will describe Java API's designed specifically for the exchange of XML business documents such as, invoices, purchase orders, and order confirmations. This JSR will refer to such documents generically as business messages or messages for short.

The business messaging community is working to converge on a set of standard message headers and industry-specific message payloads. It is planned that this JSR will leverage work currently under way in the ebXML Transport Working Group, Oasis, W3C, IETF and potentially other relevant and open standards bodies.

This JSR does not aim to define either XML messaging standards or XML schemas for particular tasks. These networking and formatting standards belong in networking standards bodies such as Oasis or IETF. Instead this JSR aims to define standard Java APIs to allow convenient access from Java to emerging XML messaging standards, such as the emerging ebXML Transport/Packaging & Routing standard.

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

The JAXM 1.0 specification will be provided, at least initially, as a standard extension but will be incorporated into the Java 2 Enterprise Edition platform as soon as this is practical and there is sufficient demand to warrant such integration.

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

JAXM 1.0 will specify API's enabling the Java Community to develop portable applications that support emerging industry messaging standards:

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

Given the diversity of communication requirements and technologies amongst multiple trading partners, there is currently no standard way to accomplish the secure, reliable exchange of business documents. However, industry standards are emerging.

More specifically, there is currently no standard Java API facilitating the exchange of XML messages over the Web. The ability to describe a "software contract" in XML such that Java applications can exchange data (either synchronously or asynchronously) with other business applications will facilitate Web based business-to-business communication.

Although, this specification will focus exclusively on business applications written in the Java Programming language and messages described using XML (as specified by open industry standards e.g. ebXML), such applications will be capable of interoperating with all applications conforming to a common message exchange Schema.

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

The JAXM 1.0 specification will most likely specify a low-level abstract Java interface specifically targeting the transmission and reception of XML messages. The specifications will be developed by industry experts to ensure that message delivery can be accomplished by supporting a number of communications infrastructures and key networking transports including, but not limited to, HTTP(S) and SMTP.

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

javax.jaxm

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 goal is to leverage the security services of the JavaTM 2 platform, Standard Edition and Java 2 platform, Enterprise Edition where possible.

2.9 Are there any internationalization or localization issues?

The goal is to leverage the I18N services of the Java 2 platform, Standard Edition. There are no localization implications at this time.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

None.

Section 3: Contributions

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

These documents are being developed independently and are therefore at different stages of completion and can serve as a starting point for the work of the Expert Group.