• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Specification Leads
	Kimmo Loytana	North Sixty-One Ltd
	Pia Niemela	Nokia Corporation
	Jens Paetzold	Oracle
Expert Group
	Apache Software Foundation	Laukkanen, Mikko	Nokia Corporation
	North Sixty-One Ltd	Oracle	Research In Motion, LTD (RIM)
	Sharp Corporation	Slominski, Aleksander	Sun Microsystems, Inc.

Updates to the Original JSR

The following has been updated from the original request:

2012.08.22: The following section has been updated.

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

TCK:
- Available free of charge to qualified not-for-profit organizations and individuals in accordance with the JSPA, solely for developing and testing their own implementations and not allowing to test any third party or commercial for-profit implementations.
- The TCK is licensed, in line with the MSA licensing principles, with a flat fee of USD 50 000 for a license term of 3 years. This includes all maintenance updates and releases, if any. The license will be worldwide, non-exclusive and will be granted on an AS IS basis without any warranties or indemnities given and with the exclusion of all indirect and consequential damages. Major new releases, from new follower JSR, are subject to a separate license fee.
- The license grant will be for a term of not less than three (3) years.
- A license allowing licensees to test implementations on behalf of third parties as a free or for-fee commercial service under certain conditions shall be available. This right may result in a higher license fee.

2012.08.21: North Sixty-One has become the co-Maintenance Lead.

Maintenance Lead: Kimmo Löytänä

E-Mail Address: jsr279@northsixtyone.com

Telephone Number: -

Fax Number: -

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Nokia Corporation/Sun Microsystems, Inc

Name of Contact Person: Steve Lewontin / Ellen Siegel

E-Mail Address: steve.lewontin@nokia.com/ellen.siegel@sun.com

Telephone Number: +1 781 993 3648/ +1 650 585 9510

Fax Number: +1 781 993 1933 / +1 650 585 9510

Specification Lead: Steve Lewontin / Ellen Siegel

E-Mail Address: steve.lewontin@nokia.com/ellen.siegel@sun.com

Telephone Number: +1 781 993 3648/ +1 650 585 9510

Fax Number: +1 781 993 1933 / +1 650 585 9510

Initial Expert Group Membership:

Nokia
Sun Microsystems

Supporting this JSR:

Ericsson
Nokia
Sun Microsystems

Section 2: Request

2.1 Please describe the proposed Specification:

This JSR proposes a general-purpose high-level Service Connection API for Java^TM ME for mobile devices. The API is intended to support writing mobile clients for identity-based Web services, service-oriented architectures (SOA), and other similar network service application models involving service discovery, authentication and identity. Existing Web services APIs tend to focus on support for low-level protocols, such as SOAP and Web Services Security. However, high-value Web services for mobile devices may be quite complex, requiring identity- based discovery and authentication, multiple service providers, and invocation of device-hosted services. These may require extensive protocol exchanges, complex state machines and other logic. To provide portability and interoperability such applications need to be based on frameworks that specify how multiple protocols and services can work together in a standard way. An example of such a standard framework that is currently being deployed is the Liberty Identity Based Web Services Framework (IDWSF), specified by the Liberty Alliance. Other frameworks with similar goals are also being specified and deployed, including for example the not yet standardized WS* specification suite or UPnP. The supported model is general enough that it could also be extended to non-Web services frameworks.

While it is theoretically possible to write such a framework-based application using only low-level Web services protocol APIs, the programming required would be very complex and would require implementing high-level protocols and other logic already well-specified by the framework. It makes much more sense to provide developers with a standard API to wrap framework behavior so that they can concentrate on service and application specific logic only.

The proposed JSR will specify a high-level Service Connection API for Java^TM ME that supports a simple GCF-like model for application interaction with services. The API will also cover the configuration needed to bootstrap interaction with service frameworks.

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

Java^TM ME

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This JSR is defined to be compatible with CLDC/MIDP and should be easily implemented in CDC-based platforms as well.

2.4 Should this JSR be voted on by both Executive Committees?

No

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

High-value Web service applications may require complex interactions with identity and discovery services, composition of multiple services, callbacks to device-hosted services, and other complex logic. Frameworks that specify such protocols and behavior - such as the Liberty IDWSF - are now being deployed. Java developers need an API to create applications for such services. Such an API will hide all of the complexity of the service framework and allow applications to concentrate on service-specific and application-specific logic. Java developers also need an API that allows them to interact with services in a flexible way, including access to raw XML messages so that the application can carry arbitrary processing of large documents based on complex XML schemas.

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

The current mobile Web services API (JSR 172), provides only low-level Web-services protocol support. In order to write a framework-based Web service application using this API, the developer would need to supply all of the complex framework logic and higher-level protocols. Also, JSR 172 is strongly focused on application interaction via an RPC-style interface implemented by tool-generated stubs. However applications that deal with large documents and complex service schemas need to access the raw XML for application-specific parsing and other processing.

The Ad-Hoc Networking API proposal (JSR 259) has some goals in common with this one - simplified discovery and connection over heterogeneous networks - but focuses on peer-to-peer communication, whereas this JSR focuses on web services and service-oriented client-server architectures.

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

Service API:
The API model would define a new service connection type, for example by extending the Generic Connection Framework (GCF). Applications would ask the API for a connection to a service, based on a service URL. The underlying framework implementation would then handle all of the protocol exchanges, state, and other logic required to create a connection to the service. The application would use the returned service connection to exchange service-specific messages with the service.

This model provides several important benefits:

- The high-level service API encapsulates all of the service framework logic so that applications only need to deal with service-specific logic and messages. - Services can be deployed in multiple frameworks. Because the service API encapsulates framework specifics, application code does not need to be rewritten for different frameworks. Binding to a specific framework can be controlled by configuration data and could be determined at runtime. - The API is not specifically Web-service oriented: rather it is adaptable to any service framework, based on any underlying protocols, for discovery, authentication, identity-based service invocation. For example, the proposed API could serve as an interface to UPnP.

Configuration:
The JSR would also specify mechanisms for configuration of the device with the bootstrapping data required to interact with specific services and service frameworks, such as discovery and identity providers, keys, etc.

Application Service Interaction:
The proposed JSR assumes that services are based on service-specific messages (typically specified by a service-specific XML schema, WSDL, or some other interface specification) and that applications exchange such messages with the service according to application specific logic. The JSR would not impose any specific model on how applications handle such messages.

Service Framework Support:
The proposed JSR is intended to support multiple service frameworks. One protocol framework binding that would be possible is to the Liberty Identity Web Services Framework (IDWSF). One natural model for implementing this JSR is a generic plug-in architecture for frameworks, but the JSR will not specify the interfaces between frameworks and such a plug-in API implementation.

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

javax.serviceconnection

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

None

2.10 Are there any security issues that cannot be addressed by the current security model?

None

2.11 Are there any internationalization or localization issues?

None

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

None

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

January 2006: Early Draft Review
April 2006: Public Review
June 2006: Proposed Final Draft
August 2006: Final Approval Ballot

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

Mainly email communications with occasional teleconferences/video conferences are used. Face-to-face meetings, which will be tele/videoconferenced, are arranged as needed and as appropriate.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The transparency plan has two components:
a) JSR community page is used to provide the community with regular updates of the draft specifications and information about the current topics and issues of the Expert Group.
b) An observer alias is maintained for the JCP members outside of the Expert Group. Periodic milestone draft specifications and status are published to this list. The Expert Group may also use the list to request feedback on key issues facing the group.

2.16 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.

Both RI and TCK will be delivered as stand-alone packages.

2.17 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.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion.
We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately.
For the TCK we will charge a single one-time fee of max US $50,000 and an annual maintenance fee, max US $20,000 for a term of four years. The TCK will include both the binary environment and the source code for the test suite. The maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to an additional single one-time fee. Using the TCK for testing of implementations on behalf of third parties will be allowed, though, be subject to a higher fee, which is capped at the sum of license fees due in accordance with license fees as described above in this section, if the third parties would have directly licensed the TCK from Nokia. For the RI in source code form we will charge a one-time access fee, and an annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to specification changes, and when made generally available by the specification lead. The binary license is free of charge.

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 Generic Connection Framework is specified in CLDC and MIDP and separately in JSR 197. The current device Web services API is specified by JSR 172 (J2ME Web Services). This includes a subset of JAXRPC as well as XML parsing specifications. Other Web services JSRs target J2SE and J2EE platforms. These include JSR 101 (JAX RPC 1.0) and JSR 224 (JAX RPC 2.0); JSR 183 (Web Services Message Security); JSR 181 (Web Services Metadata); and JSR 921 (Enterprise Web Services). Other specifications that may be relevant are the JAXP specifications (JSR 5 and JSR 206) and the XML Security APIs, including JSR 104, JSR 105, and JSR 106.
Relevant non-JCP specifications include the Liberty IDWSF specification suite, the OASIS Web services specifications, and the not yet standardized WS* specifications.

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

The API will be modeled on the GCF. The approach is orthogonal to other Web services and XML specifications, but it may make use of components provided by other specifications, including:
- WSDL to Java binding as described in JSR 172
- XML digital signature API as described by JSR 105
- XML SAX parsing subset as described in JSR 172 (or new XML Parsing for J2ME JSR)

Section 4: Additional Information (Optional)

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

N/A