JSRs: Java Specification Requests
JSR 227: A Standard Data Binding & Data Access Facility for J2EETM
This JSR has been Withdrawn
The following changes have been made to the original proposal:
Specification Lead: John Smiljanic
E-Mail Address: john.smiljanic
Telephone Number: +1 512 703 4711
Fax Number: -
Section 1. Identification
Submitting Member: Oracle
Name of Contact Person: Ted Farrell
E-Mail Address: firstname.lastname@example.org
Telephone Number: +1 650 506 9812
Fax Number: +1 801 365 5378
Specification Lead: Mike DeGroot
E-Mail Address: email@example.com
Telephone Number: +1 650 506 2862
Fax Number: +1 801 365 5378
Initial Expert Group Membership:
Supporting this JSR:
Section 2: Request
2.1 Please describe the proposed Specification:
Increasingly, enterprise applications model persistent datasources as Java classes and develop Business Services 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:
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.
 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.)
JavaTM 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.)
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
2.8 Are there any security issues that cannot be addressed by the current security model?
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?
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 JavaTM 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).
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:
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.