The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 9

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1: Identification

Submitting Participant:

William Connor, Phd.
Sun Microsystems, Inc.

e-mail: william.connor@central.sun.com
voice: +1 303 448 0048 (extension 117)

Section 2: Request

Specification Overview

The purpose of the Federated Management Architecture (FMA) is to specify a storage management platform that will allow vendors to construct storage management applications from standard and custom components. Currently, management application developers must write different applications and components for each proprietary management platform. The FMA extends the write once/run anywhere to management applications and components. The specifications will include the architecture, design, and the interfaces of an object model and a component model to support interoperability between vendor implementations. Both the object and component models are intended to run in desktop, server, and embedded JVMs.

The object model is an extension of the Java^TM object model to support classes of distributed objects important to storage management. The intent is to provide full distributed object-oriented support in a management environment. This may include the ability to operate through firewalls, provide lookup services, as specified by the expert group. While an object model is not strictly necessary to support a component model, it does provide for a more harmonious architecture when the component model itself is object oriented.

The purpose of the component models is to support the construction of applications from components. To define the interrelationships between components, the specification addresses how the components are deployed and assembled. The expert group is to define a component model suitable for building management applications that are highly available and often autonomous. These components live largely in management servers, shared or private, rather than in management clients. Thus, the architecture is three tiered and similar in many respects to the architecture of many application servers.

Our initial impression is that the component model could follow the general form of either Enterprise JavaBeans^TM or CORBA Components, but simplified and otherwise modified for storage management. Most of the component concepts such as connectivity, activation, and deployment are useful, but their specifications will be different to suit management applications. In particular, requirements such as scalability, flexibility, and availability are quite different for management applications than for the business applications. A management server must be simple enough so that it does not require substantial management itself. There is also a need to accommodate technologies, such as the CIM, which are specific to management or storage compared to application servers.

The FMA specifies the component model for the second or logic tier of a three tiered management application. The FMA expects not to specify the third (or "agent") tier. The Common Information Model (CIM) effort currently in progress is a likely source of standards in this area. The FMA also does not specify the first (or "client") tier, including any user interface, of a management application. Additional expert groups may use the core technology in creating standards for these other tiers.

Underlying Technologies

The object and component models are based on Java technologies including the JDK and any useful extensions, such as Jini, as decided by the expert group. In addition to Java technologies, the specification is expected to allow for managing storage devices that are modeled using the Common Information Model (CIM), and exported over a protocol as yet undefined by SNIA. In addition to the CIM, the expert group may choose to adopt other non-Java technologies at their discretion.

Proposed Package Name

We propose a package root of javax.sxi.core for the FMA.

Platform Dependencies

None.

Security

As a distributed object technology, the FMA must provide significant security features. Our intent is to build on the security work of the JDK and the Java Authentication Service.

Internationalization and Localization

FMA technologies are intended to be fully internationalized and provide a standard means of supporting internationalization and localization for components that are FMA compatible.

Risk Assessment

FMA is strongly dependent on the evolution of Java security to support remote principal based security.

Relationships to Existing Specifications

Java Management Extensions (JMX) The current JMX effort is to provide Java APIs to support the creation of management agents in Java. The agent technologies under consideration for support include SNMP and the CIM. To the extent that JMX supports the CIM, JMX is an interesting and complementary technology to FMA. If JMX does satisfactorily not support the CIM, FMA will do so as it requires a Java API to the CIM.

Enterprise JavaBeans (EJB) EJB specifies a component model for enterprise business applications. FMA specifies a component model for storage management. While component models all have certain characteristics, component models are specific to the class of application that they support. Management applications are different than business applications; therefore, the FMA component model is complimentary to EJB.

Impact on Existing Specification

None.

Section 3: Contributions

Sun has developed and acquired a number of technologies that may be useful to the expert group. These technologies include a distributed object model for building management applications, Java support for the CIM, and a number of services commonly needed by management applications. Sun has also done early work on specifying a component model suitable for management applications. It is our intent to contribute as much code and expertise as possible to the effort, but the expert groups should not feel compelled to use or accommodate these contributions except as they see fit.

Sun will also provide an implementation team dedicated to the core expert group for the purposes of writing those portions of the specification that will be expressed in Java code. This includes interfaces and so called "replaceable" classes, as well as an initial reference implementation of the object and component model specifications. The purpose of the reference implementation is to prove that the specification may indeed be implemented and is useful. Our intent is to have the implementation team track the specification closely in an effort to minimize the delay between finishing the specification and providing a reference implementation for early use as well as providing early feedback to the core expert group.