По материалам http://www.olapreports.com

Вступление в бой JOLAP...

Как мы уже писали, 21 августа была анонсирована новая, основанная на Java, коллективная OLAP API инициатива "JOLAP". Основной разработчик - Hyperion Solutions. Другими членами группы, определяющей предложенный API, являются: IBM, Internetivity, Nokia, Oracle, Painted Word, SAS Institute и Unisys. За исключением Hyperion, лишь Oracle и SAS Institute имеют свои сервера OLAP. JOLAP был описан группой как "чистый Java API для среды J2EE(tm), поддерживающий и эксплуатирующий данные и метаданные в независимости от конкретных OLAP-поставщиков". Business Objects был первым, и пока что единственным, поставщиком внешних инструментальных средств, пообещавшим поддержку инициативе. Удивительно, но ни Comshare, ни AlphaBlox внешне не проявили никакого интереса к ней, несмотря на то, что оба имеют Java Web клиентов для Essbase.

Прошлые попытки создать коллективный OLAP API оказались неудачными, поскольку компании были более заинтересованы в конкуренции, чем в сотрудничестве. Самым лучшим намерением этих компаний было создание спецификации с наименьшим общим знаменателем, хотя даже это оказалось слишком амбициозным. В отличие от Microsoft OLE DB для OLAP и мертвого MDAPI OLAP Council, JOLAP должен был стать более чем просто API запросов, планировалась поддержка в создании, хранении, доступе и эксплуатации данных и метаданных на серверах OLAP и многомерных базах данных. Это довольно амбициозная цель, достигнуть которой будет значительно труднее, чем сделать просто общий API запросов. На самом же деле, она скорее всего недостижима.

Тем не менее, имея общего мощного врага в лице Microsoft, эта новая небольшая группа, с явным лидером, имеет больше шансов на некоторый успех, чем OLAP Council, чьи усилия никогда не воспринимались всерьез даже его собственными членами. Пожалуй это последний шанс для группы "анти-Microsoft" создать единый OLAP API, неподконтрольный Microsoft. Кроме этого, эти компании действительно заинтересованы в создании Java API, поскольку даже те компании, которые поддерживают Microsoft OLE DB для OLAP (напр., SAS Institute and Internetivity), хорошо знают, что Microsoft не заинтересован в выпуске Java версии. Тем не менее, планируемый новый OLAP API все же столкнется с большими проблемами, ибо Microsoft, имея по крайней мере трехлетний опыт в этой области, предлагает богатый многомерный язык запросов MDX.

Поставщики внешних инструментальных средств, поддерживающие стандарт Microsoft, не имеют пока серьезных оснований для включения в свои продукты поддержки JOLAP, разве только если он не станет основным API для широко используемого OLAP сервера, такого как Essbase, или для Oracle9i OLAP Services (для которого еще пока рано говорить о его популярности). JOLAP должен не только работать со многими, отличающимися друг от друга, серверами OLAP, использующими разные внутренние многомерные модели данных - он должен предложить нечто большее, чем продукты, использующие исконный API, нечто, что либо невозможно создать, либо для этого потребуется значительное время.

В противоположность этому проект, руководимый Hyperion, может стать новым Essbase API, что по крайней мере является реально достижимой целью. При этом гарантирована поддержка теми производителями внешних инструментальных средств, которые уже работают с Essbase.

... и гибель OLAP Council API

Никто так и не внедрил MDAPI 2.0, так что управление видоизмененным OLAP Council с помощью MDAPI 2.0 очевидно невозможно; более того, уровень его приемлимости для пользователей существенно понизился, по сравнению с первой версией его промышленного стандарта OLAP API.

26 Января 1998 года OLAP Council наконец-то опубликовал долгожданную, проведенную Oracle, "только для чтения" спецификацию MDAPI 2.0. Пересмотренный API в виде пакета библиотек Java и COM объектов доступен через языки программирования, такие как C++ и JAVA, а также через средства разработки приложений, как Visual Basic и Java Script. Ключевой особенностью (в отличие от OLE DB для OLAP API) является MDAPI поддержка разнородных сред: серверов Windows NT, любых клиентов Windows, Unix, OS/2, Macintosh и любых виртуальных машин Java. Он также допускает клиент-серверное взаимодействие через любой клиентский стандарт, такой как DCOM, CORBA, Java, и т.д.

Когда в начале 1995 был сформирован OLAP Council, одной из наиболее важной и наиболее желаемой его целью было создание промышленного стандарта API. К сожалению, его первая попытка создать даже предварительный вариант API слишком сильно затянулась, но в конце концов, в сентябре 1996 года была выпущена спецификации 0.5. Однако, она была в основном проигнорирована, Gentia был пожалуй единственным производителем сервера, использующего данную спецификацию API. Удивительно, но хотя спецификация 1.0 так и не была создана, в начале 1998 года Council выпустил версию 2.0. Скорее всего это была реакция на успешную инициативу Microsoft OLAP API.

В течении 1997 года количество членов, участвующих в проекте OLAP Council, сократилось с 18 до 12 компаний (хотя в пресс релизе неправильно указывается 13), а когда их число уменьшилось до девяти, Council был преобразован в Analytical Solutions Forum (ASF). Тем не менее ожидалось, что спецификация 2.0 получит большую поддержку, чем первая попытка, поскольку Oracle сообщил о планах ее использования в качестве основного API для Express. NCR в начале также сообщил об аналогичных планах для Teradata OLAP, однако познее отказался от них. В итоге данный API, вероятно был бы принят, но благодаря инициативе Oracle, а не потому, что это является технологией OLAP Council.

Кроме Oracle, являющимся лидером этой инициативы, следующие OLAP поставщики публично поддержали анонсирование API: Cognos, Infospace (теперь Viador), MSA,
NCR, Application Consulting Group, Pilot Software и Platinum Technology (хотя никто из них этого действительно не осуществил). Кроме этого короткого списка поставщиков OLAP, еще два консультанта с интересами OLAP - Price Waterhouse и Dimensional Systems (который внес большой вклад в создание MDAPI) - и два союзника Oracle, не имеющих очевидных связей с OLAP: Netscape и Sun - также выразили свою поддержку. Намного больше настоящих и бывших членов старого OLAP Council публично заявляли о поддержке OLE DB для OLAP, а не какой-либо версии OLAP Council MDAPI.

Таким образом, нет никакого шанса для реальной поддержки MDAPI за пределами лагеря Oracle, и даже Oracle отказался от этих неудачных попыток. Oracle осуществляет новый "OLAPI" со своим собственным API; вероятно, никто из других поставщиков серверов OLAP не будет его использовать, и лишь несколько поставщиков клиентских средств захотят им воспользоваться.