Three JSR’s have been approved in their final ballots, thereby becoming endorsed Java standards. These deal with Java Wireless Architecture, the Generic Connection Framework for J2ME and the Information Module Profile meant for embedded networked devices without graphical display capabilities.
A new JSR dealing with standardizing the semantics of binding, accessing, navigating and manipulating data objects within a data source has been proposed for J2EE.
Enterprise applications typically model persistent datasources as Java classes and develop various homegrown libraries that query, manipulate, and persist these objects. Implementing these libraries often requires understanding and coding against complex sets of design patterns and standards and specific knowledge of the datasource being used. The proposed specification will define a framework of classes, called Declarative Bindings, that formalize the characteristic interactions between typical UI components such as JSP JSTL tags, Swing, Struts etc. and values and methods available on service libraries such as SOAP Web Services, EJB Session Beans or any Java class being used as an interface to some functionality.
Declarative Bindings completely decouple the user interface from the data portions of the application. In the nomenclature of MVC application architectures, this specification standardizes metadata and behavior for binding to elements of the Model from both the View and the Controller.
To facilitate a common mechanism for accessing diverse 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 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 addition, 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, synchronized, transacted or released.
This JSR has been approved for development along the guidelines of the JCP.
Two JSR’s were approved for further development under the guidelines of the JCP. These JSR’s were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee)
XQuery 1.0 is a query language being developed by the W3C XML Query Language Work Group, which defines a syntax for querying XML documents. XQuery is designed to be flexible enough to query a broad spectrum of XML information sources, including both databases and documents. This specification will define a set of interfaces and classes that enable an application to submit XQuery compliant queries to an XML data source and process the results of these queries.
This specification will define an optional package API for rendering scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format. The API is targeted for J2ME platform, with primary emphasis on MIDP. The main use cases for this API are map visualization, scalable icons, and other advanced graphics applications. The API is targeted at CLDC class devices that typically have very little processing power and memory, and no hardware support for 2D graphics or floating point arithmetic. The API shall allow utilization of native 2D graphics features of the device when applicable. The API will have the ability to load and render external 2D vector images, stored in the W3C SVG Tiny format and the capability to render 2D images that are scalable to different display resolutions and aspect ratios.
The Community Draft Specification is the specification developed in collaboration by members of the expert group for the JSR. Community Review specifications covering the Java Platform Profiling, Management and Monitoring technologies have been made available for review.
Platform profiling is the ability to extract usage statistics of a running JVM. Metrics include memory usage, CPU usage, object references etc. There is an experimental interface – the Java Virtual Machine Profiling Interface (JVMPI) that suffers from a number of design flaws, scalability issues, sizeable overhead and imprecise profiling. The new profiling architecture intends to non-compatibly supercede JVMPI but provide similar yet enhanced functionality. These APIs will allow inter-operability of profiling and advanced garbage collection technologies. The APIs will allow reliable implementation on the widest range of virtual machines, part of which will be achieved by grouping functionality into optional sets. Queries for which optional capabilities are supported will be provided. The APIs will be targeted to provide a Java programming language model of execution, however, some aspects of the virtual machine, native and operating system models may be directly provided or provided via an extension mechanism. The APIs will accommodate implementations which can dynamically enable and disable profiling; and thus will allow implementations which have negligible performance impact when profiling is disabled. While profiling in the application development phase will be the primary goal of this specification, the design objectives for low performance overhead and data perturbation will also support profiling in the deployment phase.
The Community review closes on 28th July 2003. JCP members may access the Community review at http://java.sun.com/aboutJava/communityprocess/participant/jsr163/index.html.
These APIs will provide Java applications, system management tools and RAS-related tools with the ability to monitor the health of the Java virtual machine as well as manage certain run-time controls such as class loading, memory and garbage collection statistics, thread statistics, object references and state, operating system and platform information. It will also provide control for JIT compilation, thread creation, garbage collector operation and heap allocation. It will support JMX invocation and it’s feature set and implementation will be developed to in synergy with the new platform profiling architecture.
The Community review closes on 28th July 2003. JCP members may access the Community review at http://java.sun.com/aboutJava/communityprocess/participant/jsr174/index.html.
Community Draft Approvals
The Community Draft Specification is the specification developed in collaboration by members of the expert group for the JSR. The following community draft specifications were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee)
The intent of this JSR is to define a collection of APIs that provide security services to J2ME enabled devices. It will provide security mechanisms to support a wide variety of application-based services, such as access to corporate network, mobile commerce, and digital rights management. These services rely on the existence of a “Security Element” in the device for storage and execution of sensitive data and operations. This Security Element will provide secure storage to protect sensitive data, secure execution (such as cryptographic operations to support payment protocols, data integrity, and data confidentiality) and the ability to customize and enable secure features provided by the device. The most commonly implemented Security Element currently is a Smart card, which is widely deployed in wireless phones. This specification provides an access model that enables applications running on J2ME enabled devices to communicate with a smart card inserted in the device. This access model intends to provide a flexible mechanism to allow service and equipment providers to define secure operations.
The JAIN (Java Advanced Intelligent Network) API’s are a set of libraries that enable the rapid development of Next Generation telecom products and services on the Java platform. The JAIN APIs bring service portability, convergence, and secure network access to telephony and data networks. Java Coordination and Transaction (JCAT) includes (but is not limited to) the facilities required for applications to be invoked and return results before, during or after calls; to process call parameters or subscriber-supplied information; and to engage in further call processing and control. The JCAT JSR will extend another JAIN API called Java Call Control (JCC) which provides the facilities required for observing, initiating, answering, processing and manipulating calls, where a call is understood to include (but is not necessarily limited to) a multimedia, multiparty session over the underlying integrated (PSTN, packet and/or wireless) network. JCAT will extend JCC with concepts to model and control terminal capabilities. This enriches JCC’s state transitions models by giving more control over its processing.
Public Review Specifications
Java Database Connectivity (JDBC) specifies a Rowset interface which allows programmatic access to manipulate and view tabular data stored within a database. However, JDBC does not specify any proposed implementations which is what this JSR intends to provide, a guideline for implementations of the Rowset interface.
The Public review closes on 26th July 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr114/index.html.
This JSR deals with supporting long running, distributed and complex transactions. The resulting API’s will provide a unified and modular interface to group multiple, distributed executions into a single logical transaction. This work is based on a submission to the Object Management Group (OMG) suggesting addendums to its Object Transaction Service specification.
The Public review closes on 8th August 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr95/index.html.
Portlets are web components much like Servlets specifically designed to be aggregated in the context of a composite page. Usually, many Portlets are invoked to in the single request of a Portal page. Each Portlet produces a fragment of a page that it s combined with the fragments of other Portlets, composed within the Portal page. The Portlet specification will define the different components for Portal Computing, their interaction, lifecycle and semantics. These components will comprise -but they will not be restricted to-: Portlets, Deployment descriptor, Portlet APIs. In addition, APIs for vendor extensions, APIs for security, user customization and layout management will be considered. The Portlet specification will be based on the Servlet specification. It is envisioned that the developer API will be similar to the Servlet API.
The Public review closes on 16th August 2003. You may access the public review at http://jcp.org/aboutJava/communityprocess/review/jsr168/index.html.
JSR Final Ballot Approvals
The final specifications were approved were approved via ballot voting by the Executive Committee members. (http://jcp.org/en/participation/committee). At this stage, the complete final specification is available for download along with documentation and reference implementations of the specification.
This is an umbrella JSR that covers the use and relation of various other JSR’s relating to the wireless industry. In particular, this JSR describes and overall architecture of how the various proposed wireless API technologies work together to form a complete handset solution for the wireless services industry. This JSR was updated with a list of other JSR’s under the umbrella of this JSR and provides a reference to the Java Wireless Architecture Roadmap This also links to an Open letter from the Expert group describing the status and future of this JSR.
You may download the final specification from http://jcp.org/aboutJava/communityprocess/first/jsr185/index.html.
This JSR will define a J2ME profile targeting embedded networked devices that wish to support a Java runtime environment similar to the Mobile Information Device Profile (MIDP) version 1.0, but that do not provide the graphical display capabilities required by MIDP 1.0. The Information Module Profile (IMP) will be a strict subset of MIDP 1.0, where the APIs relating to GUI functionality (the LCDUI) are simply removed. Functionality not already present in MIDP 1.0 is not anticipated or desired.
You may download the final specification from http://jcp.org/aboutJava/communityprocess/first/jsr195/index.html.
In order to support a generic mechanism of creating “connections” from small devices to other devices, networks or storage systems the Java Micro edition Platform (J2ME) defines a “Generic Connection Framework” (JSR-46). This generic framework provides runtime protocol binding and an abstraction to creating connections hiding all the protocol, transport and network specific details from the application programmer. The Java Standard Platform (J2SE) support connections through a number of libraries and classes within the java.io and java.net package namespaces. This JSR intends to provide the Generic Connection Framework as implemented in J2ME to J2SE. This will allow complete and seamless portability of applications written from J2ME to J2SE.
You may download the final specification from http://jcp.org/aboutJava/communityprocess/first/jsr197/index.html.
What do you think of the JCP? What do you think of the current JSRs? Do you have any suggestions for this column? Feel free to write to me at [email protected].