Современные предприятия испытывают настоятельную потребность в предоставлении большего количества имеющихся у них информационных ресурсов пользователям, для которых эти ресурсы изначально не были предназначены. По мере того как бизнесы пытаются поддерживать новые инициативы и возможности, им требуется эффективно интегрировать и повторно использовать приложения и информационные ресурсы. Как правило, финансовые соображения диктуют предприятиям необходимость максимизировать использование существующих систем, вместо того чтобы делать обширные инвестиции в новые информационные ресурсы.
Итак, в чем же заключается проблема использования существующей информации для новых целей? Предприятия поддерживают информацию множества различных типов во многих различных системах. Часто такие системы растут скорее «органически», чем структурно, чтобы быстро реагировать на новые потребности бизнеса. Результат часто выглядит в виде набора информационных бункеров, изолированных друг от друга и внешне не имеющих друг к другу никакого отношения. Между тем, многие из этих данных связаны друг с другом, и предприятие, которое сможет объединить и использовать эти разрозненные источники данных, получит огромное преимущество.
Сервисно-ориентированная архитектура
Сервисно-ориентированная архитектура (SOA) все чаще используется для интеграции систем. SOA – это набор стратегий, практик, принципов и подходов, которые помогают представить данные и процессы как комплект программных услуг со стандартными интерфейсами и протоколами, к которым может получить доступ растущее сообщество потребителей информации. Применение стандартных протоколов XML, SOAP, языка описания веб-сервисов (WSDL), а также протокола универсального описания, поиска и взаимодействия (UDDI), позволяет публиковать, открывать и использовать сервисы технологически нейтральным стандартным образом. Этот подход имеет несколько ключевых технических преимуществ, включая следующие:
• Возможность повторного использования за счет применения сервисов, а не копирования кода
• Публикуемые интерфейсы: обеспечивается доступность сервиса, а также ясность и точность описания его интерфейса
• Формальные определения: поставщик и потребитель услуг понимают и принимают правила взаимодействия
• Обязательная абстракция: все аспекты реализации сервисов скрыты
• Значимость функций: имеющаяся функциональность представлена на таком уровне структурирования, который является подходящим и полезным для потребителя.
Если эти технические преимущества применить надлежащим образом, они могут быть переведены в реальные преимущества бизнеса, за счет придания компаниям повышенной гибкости для реагирования на изменяющиеся нужды и требования бизнеса, а также снижения сложности, риска и стоимости интеграции прикладных систем. Кроме того, они могут переходить в повышенную видимость текущих операций за счет идентификации и выделения ключевой функциональности бизнеса.
Может ли такая архитектура «навести мосты» между информационными бункерами предприятия? По понятным причинам, большинство начальных реализаций веб-сервисов сосредоточены на демонстрации многократно используемых прикладных транзакций и деловой логики – например, "Открыть счет" (“OpenAccount”) или ”Разместить заказ" (“PlaceOrder”). Но как быть с не менее важными сервисами, относящимися к перечисленным ниже задачам?
• Определение текущего статуса всех счетов клиента, включая текущие рыночные условия
• Оказание помощи в определении кода продукта по унифицированному каталогу кодов, несмотря на вероятность того, что коды продуктов управляются в нескольких системах.
Для решения этих проблем требуется сервис, который сфокусирован на данных, а не только на приложениях и бизнес-логике.
Применение SOA к данным: информационные сервисы
Информационный сервис обеспечивает нежесткую связь между источником данных и использующими эти данные потребителями. Он реализует все логические средства для предоставления доступа к источнику данных и осуществляет преобразование из форматов источника в форматы интерфейса, но не реализует логику приложения. Как и подобает всякой архитектуре, информационный сервис «отцепляет» данные от приложения, одновременно делая их обнаруживаемыми и доступными в SOA. Информационные сервисы создают подход к описанию, доступу и объединению разрозненных и традиционных источников данных в SOA. Часто информационный сервис реализуется как веб-сервис, использующий интерфейсы, совместимые со стандартами Всемирного веб-консорциума (W3C), хотя информационный сервис может также быть реализован и с применением других интерфейсов, например, SQL. Подход к созданию надежных информационных сервисов включает в себя:
• Принятие тех же стандартов, которые приняты для веб-сервисов
• Продвижение использования средств моделирования для обеспечения быстрого, рентабельного развертывания информационных сервисов
• Управление семантическими метаданными для обеспечения последовательности и создания информационных сервисов, которые могли бы в достаточной степени описывать себя
• Обеспечение управления версиями и изменениями, чтобы сделать возможным управление слоем информационных услуг SOA по мере изменений в организации.
Так как отцепление приложений от данных не является для SOA новой концепцией, вероятно, стоит описать и дифференцировать некоторые из проблем данных, обнаруживаемых в SOA при попытке достижения такого отцепления. Слой информационного доступа в SOA должен решить, по меньшей мере, следующие проблемы:
• Отображение в форматах, близких к XML: возможность отображать не-XML источники в потенциально сложном ответном документе в XML, который, как правило, мало напоминает существующие форматы источника данных
• Объединение: Часто возникающая потребность объединить несколько источников информации в единый ответный документ в формате XML
• Повторное использование: Цель повторного использования информационных сервисов должна выходить за пределы построенной вокруг XML SOA и включать в себя поддержку архитектур типа Business Intelligence (BI) – как правило, не являющихся ориентированными на XML – с тем, чтобы средства BI могли использовать ту же информацию в SQL
• Семантика: Поддержка мощной семантики и метаданных бизнеса, с тем, чтобы информационные сервисы могли быть обнаружены и дифференцированы до связывания и доступа.
Теперь рассмотрим каждую из этих информационных проблем более подробно.
Отображение данных
Представление информации в форматах XML может быть очень ценным, помогая пользователям и их приложениям лучше использовать существующие информационные ресурсы за счет функциональной совместимости данных. Документы XML, которые основаны на стандартных схемах, могут улучшить обмен информацией в сообществе пользователей или через различные интерфейсы деловых партнеров. Стандарты способствуют улучшению интеграции за счет предварительного определения общих информационных объектов и элементов их данных, таким образом, что обе стороны могли быть уверены в содержании и формате передаваемой информации. Однако содержание и формат данных в большинстве источников данных организации не соответствует этим отраслевым стандартам. Требуется подход, который включает в себя набор средств, позволяющих XML-схемам (будь то стандартным или определяемым спецификой компании) служить в качестве шаблона, в котором могли бы быть отражены структуры существующих источников данных.
Кроме того, по мере распространения интерфейсов веб-сервисов, аналогичный подход потребуется для сбора набора операций из документов WSDL, которые представляют предлагаемый договор между партнерами по обмену информацией. Если допустить, что такой договор существует и согласован, указанный «нисходящий» подход потребовал бы способности принять существующий документ WSDL и интерпретировать набор содержащихся в нем операций информационных сервисов, а также способности интерпретировать Определения схем XML (XSD), на которые указывает WSDL, с использованием форматов «запрос-ответ» в качестве «целевых» форматов, в которых должны быть отображены источники данных.
В альтернативном случае, у организаций может не быть преимущества в виде заранее существующих WSDL и XSD, которые определяют их сервисно-ориентированные структуры. Без таких предварительно определенных целевых структур, организациям нужно будет рационализировать существующие у них источники данных и определить, какие источники данных подходят для выставления в качестве набора информационных сервисов в их SOA. Этот подход требует наличия инструментов, которые могут собирать существующие информационные структуры из подвергнутых реинжинирингу схем реляционных баз данных и отображать эти существующие структуры в способы представления данных, которые в большей степени подходили бы для решения задач бизнеса. Эти инструменты также выиграли бы от возможности использовать существующие технологии, такие как средства моделирования данных, при создании шаблона для указанных бизнес-ориентированных возможностей представления. Вышеупомянутым мерам по рационализации и отображению также помогли бы инструменты, которые могли бы оказать автоматизированное содействие в сопоставлении подобных объектов и атрибутов, с использованием комбинации алгоритмов, действующих на основе имен, и алгоритмов, действующих на основе содержания.
Объединение данных
Информационным сервисам, которые выдают информацию (а не исполняют транзакцию) может потребоваться доступ к нескольким внутренним и внешним источникам для предоставления нужного набора информации. В результате, слой информационных сервисов в SOA должен будет не только абстрагировать присущие данному источнику свойства соединения и выставлять стандартизированный протокол, но и предоставлять интеграционный компонент, который объединяет запросы к нескольким источникам данных, в соответствии с определением ранее описанных отображений информации. Объединенные запросы потребуются, чтобы преодолеть несколько текущих проблем бизнеса, таких как необходимость:
• собирать информацию из нескольких различных реализаций CRM
• понимать «числа», стоящие за ежемесячной сводкой, что требует информации из лавок данных, хранилищ данных и операционных складов данных
• сочетать структурированные реляционные данные с документами клиента для получения полного "панорамного" обзора отношений с клиентами.
Информационно-ориентированные веб-сервисы будут представлять ограниченную ценность, если они будут ограничены необходимостью в отдельных сервисах для каждого физического источника данных. Если сервис не сможет соединить все существующие информационные ресурсы организации, веб-сервисы просто добавят к существующим информационным средствам еще один слой-бункер сверху.
Информационные сервисы для SOA и BI
SOAP и XML весьма перспективны в содействии преодолению географических и технологических границ, которые прежде не позволяли использовать информацию вторично. Чтобы веб-сервисы не превратились в новое поколение традиционных бункеров, реализации веб-сервисов должны взаимодействовать с другими технологиями, способствующими вторичному использованию. Повторное использование информационных сервисов распространяется не только на XML-ориентированные архитектуры, но и на BI-архитектуры, которые, в целом, являются не XML-ориентированными, а реляционно-ориентированными. Поэтому платформа информационных сервисов должна «удачно ложиться» на BI-инструменты, репозитории метаданных, а также другие компоненты традиционного стека приложения и компоненты стека SOA, такие как реестры сервисов и инструменты управления веб-сервисами.
BI-инструменты, как правило, стремятся взаимодействовать с базами данных, а это означает, что информационные сервисы должны поддерживать, помимо SOAP, Интерфейс взаимодействия с базами данных Java (JDBC) и Открытый интерфейс взаимодействия с базами данных (ODBC). Репозиториям метаданных потребуется собирать метаданные об информационных сервисах с использованием стандартов «Общая метамодель хранилища данных» (CWM) и «Средство для метаобъектов» (MOF), помимо соответствующих стандартов W3C, поддерживаемых реестрами сервисов и инструментами управления.
Информационные сервисы с расширенными метаданными
В идеальном случае, новый информационный сервис был бы опубликован в реестре сервисов, так что пользователи и приложения впоследствии обнаружили бы его существование. На следующем этапе – во время проектирования – разработчику тоже потребовался бы реестр для создания связи с базовым репозиторием, который предоставил дополнительные метаданные об этом информационном сервисе. Сочетание реестра и репозитория стало бы системой записи, с помощью которой люди и приложения могли бы обнаруживать информационные сервисы, а также руководить и управлять ими.
Помимо создания метаданных «реестр/репозиторий», улучшающих семантику этапа проектирования, связанную с информационным сервисом, для информационного сервиса также было бы крайне ценно обеспечить собственную семантику на этапе исполнения. Семантика исполнения включает в себя способность информационных сервисов предоставлять собственные самоописываемые метаданные бизнеса, как часть извлекаемого набора данных. Такие метаданные бизнеса могут предоставлять дополнительный контекст об отдельных извлекаемых элементах, или предоставлять дополнительные метаданные для содействия заданию поведения пользовательских интерфейсов. Среди некоторых примеров таких дополнительных метаданных могли бы быть короткие или длинные имена полей данных, разрешенные операторы, которые могут быть применены к элементам данных, а также минимальное, максимальное и стандартное значения для утверждения данных. Применение XML в информационном сервисе придает гибкость, позволяющую включить такие расширенные метаданные, что может быть использовано более новыми и более XML-ориентированными пользовательскими приложениями.
Управление информационными сервисами
Системы управления информационными сервисами представляют собой решение управления информацией нового типа, которое помогает разработчикам создавать и развертывать информационные сервисы, а также управлять ими. Они решают определенные выше проблемы за счет обеспечения консолидированного доступа к информации в целях достижения упрощенного взаимодействия приложений. Хотя большинство ранее использовавшихся мер в рамках SOA учитывают возможности взаимодействия приложения, систем и процессов, технологии управления информационными сервисами могут реализовывать слой базовых информационных сервисов, который предоставляет SOA последовательный доступ к разрозненным источникам данных. Если предположить, что технология управления информационными сервисами включает в себя надежные решения в области метаданных и опирающиеся на модели подходы, слой информационных сервисов, реализованный с помощью системы управления информационными сервисами, представляет собой лучшую альтернативу кодированию компонентов слоя данных в каждом сервисе.
Информационные сервисы требуют по-новому взглянуть на функциональные аспекты технологии веб-сервисов; решению этой проблемы содействует способность технологий управления информационными сервисами создавать высококачественное объединение запросов. Поскольку система управления информационными сервисами сосредоточена на выдаче данных в ответ на запросы приложения «по требованию», она хорошо подходит для обработки самых различных типов запросов, которые информационным сервисам требуется поддерживать. Будут ли эти типы запросов случайными или более жестко контролируемыми? Будет ли представляемый набор данных очень детализированным, или он будет состоять из крупных объектов данных с множеством элементов данных? Как и в случае с любой архитектурой, функционирование информационных сервисов организации имеет первостепенное значение для успешной работы SOA, поэтому архитекторам потребуется минимизировать объем данных, проходящих «через провод». Технологии управления информационными сервисами идеально подходят для применения критериев отбора и логики трансформаций к источникам данных, до того как результаты информационного сервиса будут преобразованы в XML.
Любая система управления информационными сервисами должна предусматривать практический подход к решению как краткосрочных, так и долговременных информационных проблем внутри SOA:
• В краткосрочной перспективе: Как обеспечить доступ к информации в существующих физических источниках данных, сделав это как можно быстрее и с минимальными усилиями
• В долгосрочной перспективе: Как обеспечить более высокие уровни абстрагирования данных для поддержки целей SOA и «отцепления» данных от приложения (процесс, который удачно согласуется с инициативами по управлению информацией на местном уровне и на уровне всего предприятия).
В краткосрочной перспективе, проблема заключается в том, чтобы создать механизм обмена существующей информацией в масштабах организации, независимо от физических ограничений, налагаемых технологией и структурой источника данных. Эта краткосрочная проблема имеет отношение к реальной ситуации, с которой сталкиваются большинство организаций, когда они пытаются добиться быстрого прогресса в критически важных, срочных проектах. Информационные сервисы могут решить эту проблему; кроме того, они могут создать столь необходимый слой абстрагирования, который делает возможным окончательное перемещение из существующих сред данных в новые.
Чтобы привести IT в соответствие с требованиями бизнеса, а также сделать инициативы SOA более полезными и гибкими, информационные сервисы должны стать частью стратегического плана SOA организации. В идеальном варианте, веб-сервисы должны были бы быть основаны на грубо структурированных процессах, а не на компонентах с высокой степенью детализации. Чтобы достичь такой гибкости, организациям нужен распределенный процесс разработки, при котором бизнес-аналитики артикулируют процесс, архитекторы продумывают общие сервисы, а разработчики могут без труда обнаружить, опубликовать и реализовать бизнес-сервисы. Чтобы это стало возможным, бизнес-данные в масштабах всего предприятия должны быть связаны с каждым сервисом, не будучи жестко закодированными в этом сервисе. При этом информационные сервисы, реализуемые посредством системы управления информационными сервисами, дают возможность создавать объединение информационных и прикладных сервисов, которые могут быть использованы бизнесом.
При подготовке статьи использовались публикации Роба Кардвелла