Java News from Thursday, May 20, 2004

Oracle has posted the proposed final draft specification of Java Specification Request (JSR) 73 Data Mining API. According to the draft spec,

data mining [Mitchell1997, BL1997] includes the functional areas of classification, regression, attribute importance1, clustering, and association. These are supported by such supervised and unsupervised learning algorithms as decision trees, neural networks, Naive Bayes, Support Vector Machine, K-Means, and Apriori, on structured data. Common operations include model build, test, and apply (score). A particular implementation of this specification may not necessarily support all interfaces and services defined by JDM. However, JDM provides a mechanism for client discovery of supported interfaces and capabilities.

JDM is based on a generalized, object-oriented, data mining conceptual model leveraging emerging data mining standards such the Object Management Group’s Common Warehouse Metadata (CWM), ISO’s SQL/MM for Data Mining, and the Data Mining Group’s Predictive Model Markup Language (PMML), as appropriate

Implementation details of JDM are delegated to each vendor. A vendor may decide to implement JDM as a native API of its data mining product. Others may opt to develop a driver/adapter that mediates between a core JDM layer and multiple vendor products. The JDM specification does not prescribe a particular implementation strategy, nor does it prescribe performance or accuracy of a given capability or algorithm.

To ensure J2EE™ compatibility and eliminate duplication of effort, JDM leverages existing specifications. In particular, JDM leverages the Java Connection Architecture [JSR16] to provide communication and resource management between applications and the services that implement the JDM API. JDM also reflects aspects the Java Metadata Interface [JSR40] for the interface specification.


Sun has posted the second maintenance draft review for the Java Servlet 2.4 Specification. This just looks to incorporate various errata, mostly typos. Comments are due by June 10.


Nokia has posted an early draft review of JSR 234 Advanced Multimedia Supplements. This is a J2ME API for controlling multimedia features like cameras, videocameras, and audio playback on newer devices such as camera phones. Comments are due by May 21 (tomorrow).


Sun's has released the final draft specification of JSR 169, JDBC Optional Package for CDC/Foundation Profile. This defines an optional database connectivity package for Java 2 Micro Edition (J2ME) environments.


IBM has posted the proposed final draft specification of Java Specification Request (JSR) 95, J2EE Activity Service for Extended Transactions. Quoting from the introduction,

As the J2EE environment matures, increasingly complex business applications are placing greater demands on the container/server middleware to support more sophisticated transactional semantics than the short-lived ACID transactions provided by the Java Transaction Service (JTS). For example web service applications deployed into a J2EE environment are typically composed of loosely coupled interactions for which it may be necessary to relax the isolation characteristics of a transaction without completely sacrificing atomicity. This requires a different sort of transaction from a JTA transaction, perhaps extending over a more significant period of time and involving participants that require compensation to deliver atomicity. Many strategies are available for dealing with extended transactions, some appropriate for one type of application and some appropriate for another. But there is no single extended transaction model that will satisfy all types of application; what is required is a middleware framework that can be exploited by arbitrary, specific extended transaction models. The OMG Activity service specifies such a framework for CORBA-based middleware. This document describes the system design and interfaces for a J2EE Activity service that is the realization, within the J2EE programming model, of the OMG Activity service.

The purpose of the Activity service is to provide a middleware framework on which extended Unit of Work (UOW) models can be constructed. An extended UOW model might simply provide a means for grouping a related set of tasks that have no transactional properties or it may provide services for a long-running business activity that consists of a number of short-duration ACID transactions. The Activity service is deliberately non-prescriptive in the types of UOW models it supports. The advantage of structuring business processes as activities with looser semantics than ACID transactions, for example by modeling a business process as a series of short-duration ACID transactions within a longer lived activity, is that the business process may acquire and hold resource locks only for the duration of the ACID transaction rather than the entire duration of the long-running activity. In a widely distributed business process, perhaps involving web-based user interactions and cross-enterprise boundaries, it is neither practical nor scalable to hold resource locks for extended periods of time. A typical problem with extended UOW models is that the failure scenarios may be quite complex, potentially involving the compensation of some or all of the ACID transactions that were committed before a long-running activity failed. The responsibility for providing the appropriate recovery from such a failure may be shared between the application itself, which is the component that understands what needs to be compensated, and the extended unit of work service provider, which might provide facilities to register compensating actions.

The Activity service provides a generic middleware framework on which many types of extended transaction and other unit of work, models can be built.


Metasolv Software has posted the proposed final draft specification for JSR 142, of Operation Support Systems (OSS) Inventory API in the Java Community Process. According to the introduction:

The Inventory API reduces the cost and complexity of integrating inventory components with other OSS components and integrating inventory components between them. The API provides a solution for managing cross-component inventory relationships, which is a complex task in a typical OSS system, due to incompatible APIs and different information models.

Through the technology-independent Inventory API, client applications use the functionality of inventory systems in support of the enterprise product offering. The API allows maintaining the relationships between the enterprise product offering, underlying managed resources and technology-specific system services. Although this API is defined for the communications industry, the approach to enterprise services and their planning and packaging is relevant to other industries as well.

The API addresses inventory functions in different areas of service provider operations: Customer Relationship Management, Service Management and Resource Management. For each of these functions the API specifies J2EE-based interfaces for update and query of inventory entities, entity specifications and the associations between them. It allows retrieving metadata and allows clients to receive notifications of inventory events.

The Inventory API provides B2B integration mechanisms via the specification of XML messages, exchanged across a JMS messaging infrastructure.