Printed: Nov 22, 2024
From: http://jcp.org/en/jsr/detail?id=69
|
| Specification Leads | |||
| John D. Poole | Hyperion Solutions Corporation | ||
 |
|||
| Expert Group | |||
| Hyperion Solutions Corporation | IBM | Kamatkar, Sudhir | |
| Kelly, Michael | Nokia Corporation | Oracle | |
| SAS Institute Inc. | Suconic, Clebert Rezende | Sun Microsystems, Inc. | |
| Unisys | |||
This JSR has been Withdrawn
Reason: Withdrawn at the request of the Specification Lead.
Original Java Specification Request (JSR)
(Updated June 20, 2000)
Identification | Request | Contributions
Section 1. Identification
Submitting Participant: Hyperion Solutions Corporation
Name of Contact Person: John D. Poole
E-Mail Address: john_poole@hyperion.com
Telephone Number: +1 203 703 4359
Fax Number: +1 203 329 6729
List of other Participants who endorse this JSR:
Daniel T. Chang
IBM Corporation
555 Bailey Avenue, D164, San Jose, CA 95141
phone: +1 408 463 2319
e-mail: dtchang@us.ibm.com
Gregory Dorman
Oracle Corporation
5th Ave, Waltham, MA 02451
phone: +1 781 768 5600
e-mail: gdorman@us.oracle.com
(endorsement added 2000.06.20)
Sridhar Iyengar
Unisys Corporation
25725 Jeronimo Ave, Mission Viejo, CA 92691
phone: +1 949 380 5692
e-mail: sridhar.iyengar2@unisys.com
(endorsement added 2000.06.20)
Projected expert group will include experts from:
Section 2: Request
The JOLAP specification will address the need for a pure Java API that supports the creation, storage, access and maintenance of data and metadata in OLAP servers and multidimensional databases (referred to generically as "OLAP systems" throughout the rest of this document).
JOLAP is targeted for the JavaTM 2 Platform, Enterprise Edition (J2EETM).
The Java community needs a standard way to create, store, access and maintain data and metadata in OLAP systems serving J2EE-compliant application servers. Currently, there is no widely-agreed upon, standard API for doing this. By using JOLAP, implementors of OLAP systems can expose a single, standard API that will be understood by a wide variety of client applications and components running on the J2EE Platform. Similarly, OLAP clients can be coded against a single API that is independent of the underlying data resource (e.g., native multidimensional database versus relational star-schema). The ultimate goal of JOLAP is to provide for OLAP systems what JDBC did for relational databases.
Currently, no existing Java platform specification provides a standard API for OLAP systems. Existing APIs are generally vendor-proprietary. The only standard that comes close is the OLAP Council's MD-API, but this is a query-only interface that does not support database updates and, being an earlier standard, is not J2EE compatible.
JOLAP will be based on a highly-generalized, object-oriented, OLAP conceptual model. This model will support three conceptual areas that are generally of key interest to users of OLAP systems: Metadata, Data, and Query. Metadata and Data provide interfaces supporting OLAP metadata and data manipulation, respectively. Query defines interfaces supporting general OLAP queries (both metadata and data) and management and manipulation of result sets. The object model provides a core layer of services and interfaces that are available to all clients. Clients consistently see the same interfaces and semantics and are coded to these interfaces. A particular deployment of the object model may not necessarily support all interfaces and services defined by JOLAP. However, JOLAP will provide mechanisms for client discovery of supported interfaces, capabilities, and constraints.
It is up to each vendor to decide how to implement JOLAP. Some vendors might decide to implement JOLAP as the native API of their product. Others may opt to develop a driver/adapter that mediates between a core JOLAP layer and multiple vendor products. The JOLAP specification does not prescribe any particular implementation strategy.
To ensure J2EE compatibility and eliminate duplication of effort, JOLAP will leverage existing specifications. In particular, JOLAP will rely on the Java Connection Architecture (JSR-000016) to provide resource management, transaction management, security, and record mapping and result set management. JOLAP will also leverage the forthcoming Java Metadata Interface (JSR-000040) for core metadata management (i.e., JOLAP metadata interfaces will most likely extend core JMI interfaces to represent OLAP metadata concepts, such as dimension and hierarchy).
The following are proposed as JOLAP standard extension packages:
javax.olapJOLAP has no specific operating system or hardware dependencies.
JOLAP will exploit the existing security mechanisms of both J2EE (JSR-000016 in particular) and those of the underlying OLAP systems.
JOLAP uses the I18N support in the JavaTM 2 Platform, Standard Edition (J2SE)
There are no existing specifications or specification requests pending that would be rendered obsolete by the JOLAP specification. There are no existing specifications that would require revision as a result of JOLAP.
Section 3: Contributions
The following specifications serve (in part) as design references for JOLAP:
CWM Specification, Volume 1 (ad/2000-01-01)
CWM Specification, Volume 2 (ad/2000-01-02)
CWM Specification, Volume 1, Chapter 10, Multidimensional, and Chapter 13, OLAP, provide a sense of the overall structure of the metadata that the metadata-oriented interfaces of JOLAP will support.
CWM Specification, Volume 1, Chapter 19, Compatibility with Other Standards, discusses (in part) how the Multidimensional and OLAP metamodels of CWM relate to the OLAP Council's MD-API.
CWM Specification, Volume 2, Section 2.9, Multidimensional.idl, and Section 2.12, Olap.idl, provide a general idea of how the metadata-oriented interfaces of JOLAP might be structured (once again, generally extending the appropriate JSR-000040 interfaces).
The OLAP Council's MD-API provides a sense of the general type of OLAP data models that JOLAP would manage. This includes metadata, data, query and result set structures and database/server connections.
The CWM specification is dependent upon the MOF, UML and XMI specifications.
The above sources generally serve (in part) as design references for JOLAP.
Section 4: Additional Information
The availability of a J2EE-compliant OLAP API will provide great benefit to both vendors and users of tools and applications in the areas of business intelligence/business analytics, OLAP systems, and data warehousing. It will provide a standard API for creating, storing, accessing, and managing all metadata and data related to OLAP systems, and greatly simplify client logic by providing a common OLAP interface. Clients coded to these interfaces will be capable of connecting to a diverse set of OLAP systems provided by different vendors. Similarly, OLAP systems supporting JOLAP will be capable of offering their services to a wide range of clients that can immediately connect to them without re-coding or using adapters.
Furthermore, JOLAP's close alignment with JSR-000040 and the CWM Multidimensional and OLAP metamodels means that it directly supports the constuction and deployment of data warehousing and business intelligence applications, tools, and platforms based on OMG open standards for metadata and system specification (i.e., MOF, UML, XMI, CWM) and the forthcoming Java metadata standard (JSR-000040).
