- 7 октября 2000 г.
Войны за OLAP API
В этом номере Журнала мы предлагаем читателям обзор интерфейсов OLAP. Как и
во многих других областях компьютерных технологий, здесь существует жестокая
конкурентная борьба. Однако, возможно, вы удивитесь, узнав, что основных лагеря
здесь только два - первым, естественно, командует фирма Microsoft, а второй,
как ни странно, объединяет IBM и Oracle, включая наряду с ними и менее
конкурирующие друг с другом фирмы - Hyperion, SAS Institute, Nokia, Painted
World, Internetivity и Unisys.
Первая статья рубрики даст представление о "театре военных действий" OLAP
API, его победителях и побежденных.
Объявлено о начале работ по созданию JOLAP
21 Августа 2000 г. было объявлено о том, что начаты работы по созданию JOLAP - OLAP API-решения, основанного на языке Java и рассчитанного на множество поставщиков. В группу по разработке данной спецификации под руководством Hyperion Solutions вошли семь компаний: IBM, Internetivity, Nokia, Oracle, Painted World, SAS Institute и Unisys. Помимо самой компании Hyperion, собственные OLAP-сервера сегодня имеют только Oracle и SAS Institute. JOLAP описывается группой как "Pure Java API для среды J2EEд, поддерживающий создание и обслуживание OLAP-данных и OLAP-метаданных независимо от их компании-поставщика". Первым и на данный момент единственным пообещавшим поддержать эту инициативу среди прочих поставщиков внешних интерфейсов, стала компания Business Objects. Удивительно, но ни Comshare ни AlphaBlox не проявили никакого заметного интереса к этому, несмотря на то, что у обоих существуют основанные на языке Java web-клиенты к Essbase.
Предыдущие попытки создания OLAP API, рассчитанного на множество поставщиков, предпринимались тогда, когда компании больше были заинтересованы в конкуренции, чем в сотрудничестве. В лучшем случае они собирались разработать спецификацию, представляющую собой некий наименьший общий знаменатель, хотя и это оказалось для них слишком сложной задачей. В отличие от OLE DB for OLAP фирмы Microsoft и "покойного" OLAP Council MDAPI, планируется не ограничивать возможности JOLAP функциями API запросов, поскольку планируется, что он будет поддерживать создание, хранение, доступ и обслуживание данных и метаданных в OLAP-серверах и многомерных базах данных. И это достаточно серьезная амбиция, реализовать которую будет значительно труднее, нежели разработать обычный API запросов. Нет, в самом деле, весьма велика вероятность того, что эта задача неосуществима.
Однако перед лицом общего сильного врага - Microsoft - эта недавно созданная маленькая группа с конкретным лидером может иметь больше шансов на успех на некотором скромном уровне, чем было у OLAP Council, чьи усилия никогда не принимались всерьез даже его собственными участниками - и, возможно, это последний шанс анти-майкрософтовской группы выступить с собственным OLAP API, не подконтрольным Microsoft. К тому же эти компании действительно заинтересованы в создании API, основанного на языке Java, поскольку даже те компании, которые одновременно поддерживают и Microsoft OLE DB for OLAP (например, SAS Institute и Internetivity), знают, что Microsoft не питает интереса к созданию его Java-версии.
Тем не менее, планируемый новый OLAP API все равно столкнется с невероятно трудной борьбой, учитывая, что у Microsoft было три года форы, чтобы предложить очень богатый язык многомерных запросов - MDX. Нет никаких предпосылок к тому, то JOLAP будет содержать что-то подобное. У поставщиков инструментов внешних интерфейсов выбор невелик - фактически он ограничен стандартом Micorosft, и поэтому они могут счесть целесообразным существенно поддержать JOLAP, Если только он не станет исключительно API для одного широко-используемого OLAP-сервера, наподобие Essbase или нового Oracle9i OLAP Services (который еще далек от воплощения и популярность которого непредсказуема). Но JOLAP не только должен работать с каждым из множества различных OLAP-серверов - которые даже не имеют общей внутренней модели данных - он должен предложить богатую функциональность, сравнимую с собственным API каждого продукта, и достижение такой цели может занять много времени или даже просто окончиться ничем. Однако поскольку руководителем группы является компания Hyperion, есть вероятность того, что заявленная спецификация станет просто еще одним Essbase API, что является более реальной перспективой и возможно будет поддержано теми поставщиками инструментов внешних интерфейсов, которые уже работают с Essbase.
История неудач - различные API группы OLAP Council
Поскольку абсолютно никто не пожелал внедрять у себя MDAPI 2.0, ныне распавшийся OLAP Council, похоже, в этом случае добился невозможного: уровень признания оказался ниже, чем у его первой версии некогда желанного отраслевого стандарта OLAP API.
26 января 1998 г. OLAP Council в конце концов опубликовал свою долгожданную спецификацию MDAPI 2.0 под управлением Oracle в формате только для чтения. Исправленный API был собран из библиотек Java и COM-объектов и доступен как для языков программирования низкого уровня наподобие Си++ и JAVA, так и для инструментов разработки приложений - таких, как Visual Basic и Java Script. Одним из ключевых моментов является то, что, в отличие от Microsoft OLE DB for OLAP, MDAPI поддерживает гетерогенные вычислительные среды: серверы Windows NT, любых Windows-клиентов, Unix, OS/2, Macintosh и любую Виртуальную Машину Java. Кроме того, он инициирует взаимодействие клиента и сервера с помощью потребительского стандарта - такого, как DCOM, CORBA, Java и др.
На момент образования OLAP Council в начале 1995 г. создание стандартного для отрасли API было одной из важнейших и наиболее приветствуемых его задач. К сожалению, первая его попытка создания еще чернового варианта стандарта API слишком затянулась. Наконец, в сентябре 1996 г. была опубликована спецификация 0.5. Но ее практически проигнорировали, поскольку единственным поставщиком серверов, собирающимся ее реализовать, была компания Gentia. Странно, что OLAP Coucil в начале 1998 г. опубликовал версию 2.0, хотя никакой спецификации 1.0 никогда не выпускалось. Вероятно, это было реакцией на успех инициативы Microsoft OLAP API.
В течение 1997 г. число членов OLAP Council упало с 18-ти до 12-ти компаний (хотя пресс-релизы и заявляли о 13-ти), и опустилось до 9-ти прежде, чем 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, чем когда либо выражавшее поддержку каких-либо версий MDAPI, публично поддержали OLE DB for OLAP фирмы Microsoft. В целом, у MDAPI практически нет никаких шансов заполучить поддержку где-либо вне лагеря Oracle, и даже Oracle отступил от неудавшегося детища, собираясь реализовать новый собственный новый API "OLAPI". Никто из других поставщиков OLAP не будет его использовать и только немногие из поставщиков клиентских средств предполагают принять его.
Автор: Найджел Пендс