Journal influence
Bookmark
Next issue
Abstract:
Аннотация:
Authors: () - , () - | |
Ключевое слово: |
|
Page views: 14423 |
Print version Full issue in PDF (1.54Mb) |
MicroStrategy как средство аналитики: возможности расширения При построении хранилища данных одно из важнейших решений, которое нужно принять компании, – выбор инструментального средства Business Intelligence (BI). Среди главных факторов влияющих на этот выбор, можно выделить необходимость минимизации затрат на развертывание BI приложений и сокращение эксплуатационных расходов. Успешное решение этой задачи зависит от возможностей интеграции инструментального средства BI в корпоративную информационную среду (КИС). В результате можно выделить следующие требования к инструменту BI: · возможность организации работы через открытые каналы связи; · доступ к средствам BI из MS Office; · гибкие программные интерфейсы; · возможность построения портальных решений. От качества этих средств зависят такие параметры внедрения решения, как сложность, сроки, а следовательно, и стоимость всего решения. Рассмотрим решение на базе платформы MicroStrategy 7i – одного из лидеров на рынке BI и, что очень важно, одного из технологических лидеров в этой области. Ядром платформы является OLAP сервер Intelligence Server (IS), выполняющий в реальном времени преобразования запросов пользователей в SQL запросы к реляционной базе данных. Традиционно для работы с отчетами производитель предлагает три способа: · 32-битный клиент MicroStrategy Desktop. Это наиболее мощный клиент, дающий следующие возможности: создание, изменение и выполнение отчетов, а также создание и изменение слоя метаданных – описание объектов и сущностей предметной области в терминах платформы, настройка сервера IS. · Web-клиент. Функциональность, предоставляемая им: создание, изменение и выполнение отчетов. Для работы не требуется никакого ActiveX плагина или каких-то специальных сред. Все что нужно – браузер с поддержкой DHTML. Серверная часть существует в двух вариантах: для Microsoft IIS 5 и для Java2 Enterprise Edition (J2EE) серверов приложений. · Целевая рассылка отчетов клиентам по e-mail, sms и печать отчетов, для чего используется специальный компонент платформы – MicroStrategy NarrowCast Server, сервер рассылки. Функциональность сервера не ограничена только рассылкой отчетов. Существует возможность рассылки любых документов office, xml, html, txt. Поддерживается рассылка по расписанию, по некоторому событию, групповые настраиваемые рассылки. Стандартные средства расширения функциональности и их проблемы Для расширения возможностей в старых версиях платформы доступны два API: COM API, дающий доступ ко всем возможностям сервера аналитики, и Web API, дающий возможности дизайна и выполнения отчетов, но требующий от программиста владения технологиями J2EE. Недостатки COM: сложность реализации приложений, устаревший бинарный протокол RPC, работающий через TCP/IP сокеты, отсутствие именования через URL и контроля безопасности на уровне исполнения ActiveX компонент. Необходим был удобный API, позволяющий соединяться с Intelligence Server, используя каналы публичных сетей, безопасный и простой в использовании. И такой API был создан, но о нем чуть ниже, сейчас же рассмотрим применение COM API на примере проекта, осуществляемого специалистами компании S&T (http://www.snt.com.ru) в одном из крупных коммерческих банков. Изначально задача стояла так: заказчик предоставил шаблоны отчетов в формате MS Excel, и необходимо было реализовать отчеты в максимально близкой форме. В процессе анализа шаблонов выяснилось, что ввиду того, что в отчетах заказчика использовалась зачастую разнородная информация, отчеты представлялось возможным реализовать только в виде сборки из нескольких подотчетов. В MicroStrategy есть такая возможность. Но затем нужно будет этот HTML как-то размещать в Excel. Поэтому для реализации этой части проекта были выбраны COM API и язык VBA. Со стороны конечного пользователя нужно только открыть файл Excel и запустить нужный макрос. Такой подход решил задачу, поставленную заказчиком, но в ходе реализации проекта мы столкнулись с рядом проблем и ограничений, накладываемых именно технологией COM. Отметим следующие. · Задача COM API в платформе MicroStrategy – предоставить программисту все возможности платформы. Оборотная сторона этой медали – сложность API. Даже очень простые действия требуют большого количества кода, а в сложных манипуляциях с отчетами размер макроса легко вырастает за тысячу строк кода, причем для каждого отчета нужен свой, во многом уникальный макрос. · Посредством VBA невозможно выполнять отчеты в асинхронном режиме, что означает, что приложение на время выполнения отчета перестает отвечать. То есть, например, невозможно запустить два экземпляра Excel на одной машине, если в одном из них уже выполняется отчет. · При ограничении протокола RPC невозможно работать через VPN. Итак, хотя решение было найдено, не признать необходимость существования еще одного API нельзя. В рамках конкретного проекта от него не потребовалась бы и трети тех возможностей, что дает COM API, а устранение недостатков связанных со сложностью разработки сократило бы время реализации проекта и упростило бы сопровождение. Может быть, оптимальным в данном случае был бы Web API. Конечно, появилась бы возможность использовать публичные сети, но сложность разработки в конечном счете возросла бы, так как необходимо было бы, кроме клиентской части, реализовывать еще и серверную часть на базе сервера приложений Java 2 Enterprise Edition, что тоже не прибавило бы проекту скорости разработки и простоты реализации. В декабре 2003 года компания MicroStrategy выпустила новую версию своей платформы: MicroStrategy 7.5. Этот релиз ознаменован двумя нововведениями, одно из которых – MicroStrategy Report Services, средство создания отчетов полиграфического качества в формате PDF. Вторая новинка в платформе MicroStrategy 7i – MicroStra tegy Web Services, по сути и есть тот самый API, речь о котором шла выше. Фактически новый API представляет собой еще один слой для WebAPI, реализующий доступ к возможностям IS посредством технологии XML Web Services. Ядро технологии XML Web Services включает 4 стандарта: XML – описание данных; WSDL – описание сервиса; SOAP – описание формата передачи; UDDI – реестр веб-сервисов. Рассмотрим их подробнее: XML (eXtensible Markup Language): язык XML очень удобен для описания любых данных, а в WS используется еще одна выгодная черта: XML-документы – это текстовые документы, которые можно легко передавать в публичных сетях с помощью протокола HTTP. В веб-сервисах используется ряд стандартов и технологий семейства XML, наиболее важные из них: XML v1.0, XML schema, XML namespaces, XML Information Set, XPath, XSLT, DOM, SAX. WSDL (Web Services Description Language): как следует из названия, язык описания веб-сервисов – это формат XML-схем, определяющий структуру описания интерфейсов веб-сервисов. WSDL-интерфейс – это XML-формат, описывающий состав веб-сервиса. По уровню абстракции его можно разбить на три основные составляющие: 1) определение типов данных: здесь определяются структура и содержание сообщений, используемых веб-сервисом; 2) абстрактные операции: задаются операции, которые должны быть выполнены с содержанием сообщения; 3) привязка сервиса: определяется сетевой транспорт, который должен доставить сообщение. Для описания типов данных в WSDL используются XML-схемы, но их, например, можно заменить на IDL (Interface Definition Language) или CORBA. Как любая XML-технология WSDL – язык расширяемый, что дает ему еще большую гибкость. Например, можно расширить WSDL чтобы в качестве транспорта использовать традиционный DCOM. SOAP (Simple Object Access Protocol): XML-способ определить, какая информация и как передается и как передается. После того как мы определили с помощью XML данные и абстрактно описали с помощью WSDL службу, необходимую для обеспечения обработки данных и собственно соединения, мы должны указать, каким способом сообщение будет доставлено с одного узла на другой, что и позволяет стандарт SOAP. Для этого весь XML-документ или его часть преобразуется в SOAP-сообщение, состоящее из конверта (Envelope), определяющего конец и начало сообщения, тела сообщения (Body), содержащего XML-данные, и дополнительную информацию (информация о кодировках, вложения, определения дополнительных атрибутов и пр.). На обмене SOAP-сообщениями строится независимый абстрактный протокол связи, обеспечивающий коммуникацию двух и более серверов. UDDI (Universal Distribution, Discovery, and Integration): публикация и поиск веб-сервисов. После того как мы определили, какие данные передаем, как их обрабатываем и как передаем, встает задача поиска веб-сервиса в сети, эту задачу и решает реестр UDDI. Он регистрирует и публикует определения веб-сервисов и выступает их каталогом, использующим SOAP для регистрации и поиска информации. Взаимодействие приложений происходит следующим образом (рис.1). Сначала поставщик веб-сервиса генерирует WSDL-описание своих сервисов (1) и регистрирует их в UDDI хранилище (2). Затем SOAP-процессор клиентского приложения отправляет в UDDI хранилище запрос (3) на получение WSDL схемы веб-сервиса (4). Затем по полученному описанию SOAP-процессор клиента генерирует сообщение (5) и посылает его при помощи определенного транспорта поставщику веб-сервиса (6). Сервер поставщика расшиф- ровывает сообщение, выполняет операцию, генерирует ответ и посылает его клиентскому приложению. Итак, веб-сервисы являются универсальным связывающим средством для приложений решающих различные задачи и функционирующих на различных платформах. Технологии, рассмотренные выше, составляют лишь ядро этого подхода. Для того чтобы быть реально востребованными, веб-сервисам необходимо обладать рядом дополнительных характеристик, функций и сервисов. Если не все, то большее из этого веб-сервисам способны дать дополнительные технологии, в настоящее время активно развивающиеся. Основную и самую важную часть дополнительных технологий представляют технологии безопасности для веб-сервисов. Наиболее отработанный подход – использование технологии HTTPS для транспорта SOAP-сообщений, но в данный момент этого стандарта недостаточно, так как HTTPS является протоколом туннелирования обычного HTTP в защищенное с помощью протокола SSL/TLS сетевое соединение. То есть между обменивающимися сообщениями компьютерами в сети всегда должно быть установлено соединение. К сожалению, такое не всегда возможно, к тому же, защищая содержимое сообщения, HTTPS защищает и все служебные данные в этом сообщении, что иногда избыточно. Поэтому компании Microsoft и IBM предложили, а также реализовали в своих продуктах язык лицензионного соглашения о веб-сервисах (WS-License) и безопасности веб-сервисов (WS-Security), работающие совместно. WS-License определяет форматы и порядок шифрования маркеров доступа для WS-Security, применяемых ради обеспечения конфиденциальности и целостности сообщений. Лицензионные соглашения, которыми оперирует WS-Security, представляют собой особый тип мандата, включающего набор определенных утверждений, подтвержденный полномочиями, например закрытым или открытым ключом. Действительными лицензионными соглашениями считаются сертификаты X.509 и мандаты Kerberos. Кроме проблем безопасности, решаются задачи и в других аспектах технологии веб-сервисов, таких как: управление потоком процесса (управление потоком выпонения нескольких параллельно работающих веб-сервисов), транзакции (координирование многочисленных веб-сервисов), обмен сообщениями (настройка путей прохождения сообщений и их надежной маршрутизации). Коротко рассмотрим промышленные системы, воплощающие технологию XML Web Services. Существующие реализации веб-сервисов можно разделить на 6 категорий. 1. .Net Framework компании Microsoft. MS Windows – самая популярная операционная система для настольных компьютеров, поэтому большое число разработчиков используют технологии этой компании при реализации проектов распределенных систем. В платформе .Net каждая программа потенциально является веб-сервисом, а все транспорты могут использовать XML. 2. Серверы приложений Java 2 Enterprise Edition. J2EE-сообщество во главе с компаниями Sun Microsytems и IBM использует сервлеты, классы и EJB-компоненты как веб-сервисы, что сделало XML-интеграцию частью описания сервера приложений. 3. Брокеры интеграции. Производители связующего ПО используют веб-сервисы для связывания приложений и B2B (business-to-business) интеграции. 4. Производители СУБД. Используют веб-сервисы как средство доступа к таблицам баз данных и хранимым процедурам СУБД. 5. ERP, CRM, BI и пр. Разработчики этих продуктов используют веб-сервисы для интеграции своих пакетов с другими программными системами. 6. Платформы веб-сервисов. Самостоятельные, независимые продукты. Пример применения Вернемся к платформе BI MicroStrategy 7i и рассмотрим два нововведения, появившиеся в версии 7.5. 1. MicroStrategy Web Services. Этот компонент представляет собой API на базе технологии веб-сервисов для доступа к возможностям сервера приложений MicroStrategy Intelligence Server. Разработчики не стали создавать еще один Web API, сложный в освоении и использовании; на базе технологии Microsoft.Net была разработана библиотека, являющаяся промежуточным звеном между веб-сервисом, работающим на платформе Microsoft, и собственным Web API, который, в свою очередь, использует COM API для доступа к IS. Набор действий, который новый API предлагает пользователю, явно беднее, чем COM API или даже Web API: это авторизация пользователя, просмотр дерева проектов, выполнение отчетов и документов в синхронном или асинхронном режиме, выполнение отчетов с запросами к пользователю (prompts). Функциональность, чаще всего необходимая при интеграции отчетности в существующие приложения. Другой стороной урезанной функциональности является простота API: теперь для выполнения отчета программисту не нужно заполнять десятки полей в различных структу- рах. На рисунке 2 показано, как происходит взаимодействие: сначала клиентское приложение обращается к веб-сервису (1), работающему на сервере Micsrosoft Internet Information Server, затем веб-сервис осуществляет вызов необходимых методов из Web API (2); Web API посредством COM API получает доступ к серверу MicroStrategy (3) и, например, запускает отчет на выполнение. Тогда сервер MicroStrategy генерирует SQL-запрос к базе данных, выполняет его (4), интерпретирует результат, и цепочка повторяется в обратную сторону. В проекте, описанном в начале статьи, существовало 3 основных проблемы, связанных с использованием COM API. Представим, как можно реализовать этот проект в рамках новой технологии.: а) очевидно, снимается вопрос о протоколе взаимодействия – протокол HTTP позволяет использовать любые каналы связи, в том числе и со стойким шифрованием; б) так же решается вопрос об асинхронном выполнении отчетов – в новом API запустить отчеты на выполнение в таком режиме так же просто, как и в синхронном; в) и, наконец, проблемы со сложностью API для использования тоже нет, так как урезанная функциональность положительно сказалась на простоте использования и скорости разработки. Особо нужно отметить, что задача интеграции средства BI в приложения Microsoft Office – это не частная задача одного проекта, поэтому в новой версии продукта компания MicroStrategy предложила на суд пользователей новое клиентское приложение, построенное на новой технологии XML Web Services. 2. MicroStrategy Office. Новый компонент платформы MicroStrategy, предназначенный для выполнения отчетов из приложений Microsoft Office и сохранения результатов в документах Word, Excel, PowerPoint. MicroStrategy Office представляет собой модуль, загружаемый при запуске приложений Office и отображаемый кнопкой на панели инструментов. При настройке нового приложения для работы нужно знать URL веб-сервиса MicroStrategy Web Services. При нажатии на кнопку приложение связывается с сервером, происходит авторизация, после чего пользователь может начинать работу. Выполнив отчет, пользователь может работать с ним как с частью документа, например, сделать график в Excel. Есть также возможность обновления отчетов, то есть выполнения отчета и подстановка новых результатов в документ. Есть возможность запускать на выполнение или обновление сразу несколько отчетов. Итак, с внедрением в систему корпоративной отчетности и аналитики MicroStrategy технологии Web Services были существенно расширены возможности по интеграции этой платформы Business Intelligence в корпоративные информационные среды. Среди новых возможностей необходимо отметить: · возможность использовать публичные каналы передачи данных для построения распределенных систем; · новые компоненты интеграции с Microsoft Office; · новый XML Web Services API, с возможностью использования из наиболее популярных платформ J2EE и .NET; · API для интеграции с портальными решениями. Список литературы 1. Newcomer E.,2002, Understanding Web Services: XML, WSDL, SOAP and UDDI. Addison-Wesley 2. SOAP Version 1.2 W3C Recommendation 24 June 2003 3. Web Services Description Language (WSDL) Version 2.0 W3C Working Draft 10 November 2003 4. MicroStrategy University 2003, Web Universal Customiza tion. |
Permanent link: http://swsys.ru/index.php?id=592&lang=en&page=article |
Print version Full issue in PDF (1.54Mb) |
The article was published in issue no. № 2, 2004 |
Perhaps, you might be interested in the following articles of similar topics: