Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 69: Java OLAP Interface (JOLAP)

Stage Access Start Finish
Withdrawn   16 Apr, 2012  
Final Approval Ballot View results 15 Jun, 2004 28 Jun, 2004
Proposed Final Draft Download page 11 Sep, 2003  
Public Review 2 Download page 23 Jul, 2002 22 Aug, 2002
Public Review Download page 19 Jun, 2002 19 Jul, 2002
Community Draft Ballot View results 08 Jan, 2002 14 Jan, 2002
Community Review Login page 15 Nov, 2001 14 Jan, 2002
CAFE   03 Jun, 2000 23 Jun, 2000
JSR Approval   27 May, 2000 02 Jun, 2000
Status: Withdrawn
Reason: Withdrawn at the request of the Specification Lead.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
JOLAP is a pure Java API for the J2EETM environment that supports the creation and maintenance of OLAP data and metadata, in a vendor-independent manner.

Please direct comments on this JSR to the Spec Lead(s)
Team

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:

  • OLAP and multidimensional database system and tool vendors
  • Business intelligence/analytics application vendors
  • Data warehousing system and tool vendors


Section 2: Request

2.1 Please describe the proposed Specification:

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).

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

JOLAP is targeted for the JavaTM 2 Platform, Enterprise Edition (J2EETM).

2.3 What need of the Java community will be addressed by the proposed specification?

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.

2.4 Why isn't this need met by existing specifications?

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.

2.5 Please give a short description of the underlying technology or technologies:

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).

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

The following are proposed as JOLAP standard extension packages:

javax.olap
javax.olap.metadata
javax.olap.data
javax.olap.query

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

JOLAP has no specific operating system or hardware dependencies.

2.8 Are there any security issues that cannot be addressed by the current security model?

JOLAP will exploit the existing security mechanisms of both J2EE (JSR-000016 in particular) and those of the underlying OLAP systems.

2.9 Are there any internationalization or localization issues?

JOLAP uses the I18N support in the JavaTM 2 Platform, Standard Edition (J2SE)

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

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

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 following specifications serve (in part) as design references for JOLAP:

  • Common Warehouse Metamodel (CWM) http://cgi.omg.org/techprocess/faxvotes/CWMI_RFP.html

    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).



  • OLAP Council Multidimensional API http://www.olapcouncil.org/research/apily.htm

    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.



  • OMG MOF, UML and XMI Specifications http://cgi.omg.org/techprocess/meetings/schedule/tech2a.html#mod (reference added 2000.06.20)

    The CWM specification is dependent upon the MOF, UML and XMI specifications.

  • 3.2 Explanation of how these items might be used as a starting point for the work.

    The above sources generally serve (in part) as design references for JOLAP.



    Section 4: Additional Information

    4.1 This section contains any additional information that the submitting Participant wishes to include in the JSR.

    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).