• 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

This JSR has been Withdrawn
Reason: Withdrawn at the request of the Specification Lead.

Updates to the Original JSR

The following changes have been made to the original proposal:

2006.08.23:

Specification Lead: John Smiljanic

E-Mail Address: john.smiljanic@oracle.com

Telephone Number: +1 512 703 4711

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Ted Farrell

E-Mail Address: ted.farrell@oracle.com

Telephone Number: +1 650 506 9812

Fax Number: +1 801 365 5378

Specification Lead: Mike DeGroot

E-Mail Address: mike.de.groot@oracle.com

Telephone Number: +1 650 506 2862

Fax Number: +1 801 365 5378

Initial Expert Group Membership:

Oracle Corporation
Sun Microsystems, Inc

Supporting this JSR:

Oracle Corporation
Sun Microsystems, Inc

Section 2: Request

2.1 Please describe the proposed Specification:

Increasingly, enterprise applications model persistent datasources as Java classes and develop Business Services[1] that query, manipulate, and persist these objects. However, developing interactive user interfaces that use Business Services to correctly manipulate the data objects requires understanding and coding against complex sets of design patterns and standards that underly the various Service technologies. This proposed specification will define a framework of classes, called Declarative Bindings, that formalize the characteristic interactions between typical UI components and values and methods available on Business Services. By using the Declarative Bindings set forth in this specificiation, any Java UI rendering technology can declaratively bind to any Business Service. Example UI components and controller technologies include: JSP JSTL tags, JSF, Struts, and Swing. Example business services include SOAP Web Services, EJB Session Beans or any Java class being used as an interface to some functionality.

When accessed by the UI components and UI controller, the metadata-driven Declarative Bindings interact with the classes that they are bound to, providing J2EE standards-compliant support for things like:

1. Binding (locating and accessing)
   1. single attribute (appropriate for input fields and other single value UI components)
   2. objects with related collection attributes (appropriate for tree controls)
   3. collections of objects (appropriate for displaying in tables)
2. Navigating
   1. current row tracking (first, next, prev, last)
   2. current range (appropriate for scrollbar pagination)
   3. coordinating related collections (appropriate for master/detail display)
   4. multiple iterators sharing same collection (appropriate for split pane)
3. Performing actions
   1. normalizing the interaction of generic insert, update and delete operations on transactional objects and collections of objects
   2. surfacing status of bound objects (to know whether the UI component needs to be re-rendered)
   3. dispatching to methods to perform custom services.
   4. validating and reporting validation exceptions.

The Declarative Binding classes provide attributes that are easily accessible to all user interface technologies that support EL or Java. Declarative Bindings manage the interaction with Business Services. They drive their behavior off metadata, which is convenient for tools vendors. One of the goals of this proposal is allow interoperability between tools products that interactively bind sophisticated interfaces to the services that provide the data.

To facilitate a common mechanism for accessing diverse Business Service technologies this specification proposes that the Declarative Bindings access the Business Services via a lightweight abstraction layer called Data Controls.

Data Controls provide supplemental metadata about the Business Service's capabilities and constraints as well as support a simple interface for normalizing typical interactions with the Service. Data Controls comprehensively describe the attributes and methods so that UI components can make intelligent assumptions about how to render the data. In addtion, the Data Control standardizes access to functionality that is typically required by data-intensive, interactive user interfaces. Examples of functionality could include how the Business Service is instantiated, navigated, invoked, sychronized, transacted or released. This JSR will not impose any requirements for the types of attributes or methods on the Data Control or any implementation requirements. Those decisions will be left to the implementor of the Data Control and revealed to the Declarative Bindings and UI via the Data Control interface.

[1] By Business Service we mean any class that publishes objects and provides methods that manipulate the objects. I.e. The actual term may vary according to the Business Service technology, SessionFacade, WebService, ApplicationModule, etc.

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

Java^TM 2 Platform, Enterprise Edition

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

This specification provides one standard way for user interfaces to access the data of the application, regardless of the implementation or specific technology used for O/R mapping or distributed object communication.

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

This area of technology is not covered by existing standards.

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

There are two parts to this technology: Declarative Bindings and Data Controls.

Declarative Bindings describe and manage the characteristic interactions between specific kinds of UI components (View and Controller layers) and the methods provided by a Business Service (Model layer).

Data Controls provide supplimental metadata about the Business Service's capabilities and constraints.as well as a simple interface for normalizing typical transactional interactions with the Service.

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

javax.datacontrol
javax.binding

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?

These will be explicitly addressed by the specification.

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

• JSR 114, and JSR 127 are complementary and may require revision though, at the moment, we are not aware of any issues.
• This JSR will keep in compliment with JSR 221 (which covers JDBC 4.0).

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

We hope to have the specification completed in time to be included in the next major revision of the Java^TM 2 Enterprise Edition platform (post 1.4).

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

Oracle will lead the specification and implementation work, with experts contributing to the API specification.

This will include email discussions, monthly phone calls and possibly a F2F meeting.

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.

The RI and TCK will be made available in stand-alone form at the time of the final release. There will most likely be earlier versions of the RI and TCK that are developed as this JSR progresses.

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

Not applicable.

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

It is Oracle's intention to create open source licenses that are as similar as possible to an "Apache"-style license. Additions or changes to this basic open source format will be limited to those terms required to comply with the JSPA, or which explain terms or limitations of the licenses granted under the JSPA. Currently intended terms are as follows:

1. Oracle will grant a royalty-free source code license to use, modify and distribute the Reference Implementation.
2. Oracle will grant a royalty-free license to use the Specification to create a compliant implementation of the Specification, which may be distributed to third parties.
3. Because of requirements in the JSPA, the Specification license will require that implementations of the Specification must (a) fully implement the specification including all of its required interfaces and functionality; (b) not modify, subset, superset or otherwise extend the Licensor Name Space (defined as the public class or interface declarations whose names begin with "java", "javax", "com.sun", or "com." or their equivalents in any subsequent naming convention adopted by Sun through the JCP), or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required by the spec; and (c) pass the TCK.
4. As part of the licenses, Oracle will grant an associated patent license under Oracle patent rights, but solely to the extent that such patent rights are essential to implement the Specification. As appropriate, Oracle may indicate in the licenses that under the JSP contributors other than Oracle may be allowed to require an additional patent license for implementations on "fair and reasonable terms" (which may include royalties).
5. Oracle may condition the license grants on the licensee's commitment to offer a license to those of the licensee's patent rights that are essential to implementing the Specification to other licensees on reasonable and non-discriminatory terms.
6. Although Oracle will place no restrictions on modifications that may be made by or license terms given to "downstream" licensees, it is Oracle's intention to clarify in the licenses, that under the JSPA, no copyright or patent licenses are granted for any non-compliant implementation made by downstream licensees, whether independent or based on the reference implementation.
7. Oracle will grant a royalty-free license to use the TCK to determine if an implementation is compliant.
8. Oracle makes no warranties with respect to the Specification, Reference Implementation, Test Suites or other distributed materials, and all liability is excluded.
9. A licensee's rights and licenses terminate in the event the licensee brings or threatens suit against Oracle or any other licensee based on a claim of infringement of intellectual property rights as a result of use of the Specification, Reference Implementation, or Test Suites.

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 "Data Control" and "Data Binding" technologies are used in Oracle 9i JDeveloper version 9.0.5. This will be shipping in preview mode in July of 2003.

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

The expert group will consider them as a starting point for ideas on defining the specification.