Интеграция разнородных и распределенных данных не в состоянии разрешить все вопросы управления предприятием. В соответствии с процессным подходом наибольшую ценность представляют не сами по себе данные, а использование информации в тех или иных бизнес-процессах компании. В самых современных ИС принято рассматривать как «атомарную» единицу не данные в «чистом» виде, а некоторый сервис, соответствующий какому-то элементарному бизнес- процессу. В частности, такой сервис может просто выдавать какие-то данные, являясь аналогом «атомарной» единицы классических ИС.
В настоящее время при формировании информационной инфраструктуры предприятия, при проектировании и реализации КИС все чаще применяется сервис-ориентированная архитектура (Service-Oriented Architecture — SOA). Это такая архитектура ИС, в которой система строится из набора гетерогенных слабосвязанных компонентов (сервисов). SOA понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются «информационная услуга» и «композитное приложение».
Информационная услуга (сервис) — это атомарная прикладная функция автоматизированной системы, которая пригодна для использования при разработке приложений, реализующих прикладную логику автоматизируемых процессов как в самой системе, так и для использования в приложениях других автоматизированных систем.
Сервис обычно характеризуется следующими свойствами:
— возможность многократного применения;
— услуга может быть определена одним или несколькими технологически независимыми интерфейсами;
— выделенные услуги слабо связаны между собой, и каждая из них может быть вызвана посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия услуг между собой.
Композитное (составное) приложение — программное решение для конкретной прикладной проблемы, которое связывает прикладную логику процесса с источниками данных и информационных услуг, хранящихся на гетерогенном множестве базовых информационных систем. Обычно композитные приложения ассоциированы с процессами деятельности и могут объединять различные этапы процессов, представляя их пользователю через единый интерфейс.
Использование такого подхода при построении архитектуры сложных интегрированных информационных систем позволяет:
— создать систему корпоративных композитных приложений, основанных на системе корпоративных Web-сервисов;
— организовать интеграцию приложений, бизнес-процессов, с автоматизацией бизнес-процессов, включая Human Workflow;
— использовать различные транспортные протоколы и стандарты форматирования сообщений, средства обеспечения безопасности, надежной и своевременной доставки сообщений;
— существенно повысить скорость разработки прикладных приложений и снизить затраты на эти цели.
Благодаря упрощению среды управления и взаимодействия снижается потребность в кодировании новых программ; повторное использование сервисов сокращает затраты времени на разработку; рационализация унаследованных процессов помогает уменьшить общее число процессов, требующих эксклюзивных методов управления; благодаря использованию простых протоколов значительно сокращаются трудозатраты на поддержку приложений.
Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.
Упомянутая инфраструктура образует так называемую интеграционную шину (ИШ) (Enterprise Service Bus — ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.
Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. ИШ образует однородную среду информационного взаимодействия и является фундаментом для интеграции информационных систем, функционирующих в различных учреждениях и ведомствах. ИШ определяет, кем, где, каким образом и в каком порядке должны обрабатываться запросы.
Если сервис (информационный ресурс) не поддерживает эти правила, необходимо создавать промежуточный модуль-адаптер, который предоставляет системе необходимый интерфейс и обеспечивает взаимодействие с ресурсом.
Рис. 7.2. Структура построения ESB и компоненты концепции SOA
Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По данным Gartner Group, 80% ИТ-бюджета — это расходы на сопровождение систем, из них 35% — затраты на интеграцию приложений, 60% стоимости внедрения корпоративной ИС составляют расходы на интеграцию, 50% ИТ-бюджета потрачено на обеспечение интерфейсов систем. Использование SOA-архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:
— повышении скорости адаптации бизнеса к быстро меняющимся требованиям рынка (Agility);
— расширении взаимодействия гетерогенных корпоративных информационных систем при сохранении сделанных в них инвестиций;
— сокращении расходов на ИТ-системы на основе повторного использования их функциональных компонентов;
— повышении производительности труда клиентов, партнеров и сотрудников (на основе архитектуры Web 2.0).
С точки зрения бизнеса SOA можно представить как набор гибких служб и процессов, которые бизнес предлагает своим заказчикам, партнерам или внутри своей собственной организации. В данном контексте эти же службы можно по-разному комбинировать и оснащать, поддерживая изменения или развитие бизнес-требований и моделей с течением времени.
Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:
— фрагментированности и дублирования данных;
— дублирования реализаций бизнес-функций, процедур, процессов;
Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшихся прежде всего в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение информационной инфраструктуры:
— обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;
— обеспечивать реализацию различных типов интеграции:
— пользовательская интеграция (User Integration) — обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;
— интеграция приложений (Application Connectivity) — обеспечение взаимодействия приложений;
— интеграция процессов (Process Integration) — интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;
— информационная интеграция (Information Integration) — интеграция с целью обеспечения доступности информации и данных;
— интеграция новых приложений (Build to Integrate) — интеграция новых приложений и сервисов в существующие информационные системы.
— обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;
— иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки, совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения новых и миграции существующих информационных систем;
— позволять реализацию различных моделей построения информационных систем, в особенности, таких как портальные решения, grid-системы и on-demand-системы.
В настоящее время уровень развития SOA позволяет утверждать, что все указанные требования в той или иной мере выполняются.
Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:
Источник: studopedia.ru
Интеграция информационных систем предприятия
Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:
фрагментированности и дублирования данных;
дублирования реализаций бизнес-функций, процедур, процессов;
Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшихся прежде всего в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение информационной инфраструктуры:
обеспечивать преемственность инвестиций в IT, сохранить существующие информационные системы и их совместное эффективное использование для повышения ROI (финансовый коэффициент, иллюстрирующий уровень доходности или убыточности бизнеса, учитывая сумму сделанных в этот бизнес инвестиций) от IT-вложений;
обеспечивать реализацию различных типов интеграции:
пользовательская интеграция — обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем; информационный подсистема архитектура бизнес
интеграция приложений — обеспечение взаимодействия приложений;
интеграция процессов — интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;
информационная интеграция — интеграция с целью обеспечения доступности информации и данных;
интеграция новых приложений — интеграция новых приложений и сервисов в существующие информационные системы.
обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;
иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки, совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения новых и миграции существующих информационных систем;
позволять реализацию различных моделей построения информационных систем, в особенности, таких как портальные решения.
Сегодняшний уровень развития SOA позволяет утверждать, что все указанные требования в той или иной мере выполняются.
3. Реализация SOA-инфраструктуры на базе сервисной шины предприятия
Аппаратно-программную платформу, реализующую инфраструктуру КИС с SOA-архитектурой называют сервисной шины предприятия (ESB). ESB-шина образует однородную среду информационного взаимодействия внутрикорпоративных (intranet-) и внешних (extranet-) приложений и является фундаментом для их интеграции (рис. 2). Она определяет, кем, где, каким образом, и в каком порядке должны обрабатываться запросы на сервисное обслуживание времени выполнения.
Рис. 2. Общая схема ESB-шины
В верхней части схемы показаны несколько потребителей, а в нижней ‐ несколько поставщиков служб (сервисов). В реальном мире, в распределенной среде, поставщики и потребители могут располагаться где угодно по отношению шине ESB.
Уровень ESB можно сформировать на основе нескольких топологий интеграции служб в зависимости от функциональных и нефункциональных требований. Для некоторых ситуаций вполне подходит топология, состоящая всего из одной системы обмена сообщениями (рис. 3).
Рис. 3. Топология «одна шина, один сервер»
Однако при размещении нескольких таких систем, соединенных вместе (рис. 4), вы получаете ряд преимуществ. Это полезно при распределении рабочей нагрузки по нескольким серверам, чтобы обработка сообщений производилась недалеко от приложений, которые ее используют, что повышает доступность в случае системного сбоя или потери связи, обеспечивает улучшение возможностей масштабирования и размещения средств сетевой защиты и других средств ограничения сетевой активности.
Рис. 4. Топология «одна шина, несколько серверов»
ESB-шина устанавливает единые правила публикации сервисов, управления и информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление интегрированными приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.
Важные инфраструктурные службы, которые входят в ESB, выполняют передачу данных, маршрутизацию, обеспечивающую качество услуг, посреднические функции и роль шлюзов. Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. Таким образом, ESB ‐ это базовое промежуточное звено, способ связывания служб в компонентные логические наборы (рис. 4). Эти наборы отражают структуру бизнеса и предназначены для широкого распределенного использования в масштабе всего предприятия.
Шина ESB действует как логический, распределенный, транзакционный и управляющий сообщениями уровень для связывания приложений, разнотипных данных и других служб, которые распределены по вычислительной сети предприятия. Базовая роль магистрали для работы с синхронными и асинхронными сообщениями дополняется логическими возможностями трансформации и маршрутизации данных, что обеспечивает надежную передачу сообщений. ESB позволяет разработчикам вызывать и применять бизнес-функции, входящие в компоненты КИС, независимо от API (это интерфейс программирования, интерфейс создания приложений) или протокола, поскольку компоненты используются как службы, интерфейс которых имеет стандартное описание на языке Web Service Descrition Language (WSDL).
От развертывания систем на базе SOA пользователи получают следующие преимущества:
Возможность взаимодействия корпоративных приложений с широким кругом программных продуктов, реализованных на различных программно аппаратных платформах;
Упрощение и ускорение процесса разработки бизнес-приложений ‐ приложения строятся, как система взаимосвязанных компонентов и при этом используются наиболее подходящие компоненты из имеющихся на рынке;
Легкая интеграция новых функций в действующую корпоративную систему;
Возможность гибкого изменения и постоянного совершенствования бизнес-процессов предприятия;
Оптимизация процессов управления предприятием за счет упрощения процедур объединения информационных потоков и бизнес-процессов;
Поэтапное совершенствование корпоративной информационной инфраструктуры без привлечения крупных инвестиций.
Предполагается, что в будущем практически все взаимодействие приложений как в рамках одной информационной системы, так и между системами отдельных участников бизнес-процесса, будет осуществляться с использованием механизма web-cервисов, так что достаточно критическими становятся вопросы согласованной работы и управления этими сервисами. Для описания согласованной работы сервисов были предложены специальные термины – «хореография» и «оркестровка». При этом если хореография определяет взаимодействие различных участников с использованием сервисов, то оркестровка описывает взаимодействие сервисов в рамках одного бизнес-процесса, в частности, с использованием языка типа BPEL.
Этапы перехода к СОА
На предприятии переход к СОА состоит из трех этапов:
Создание сервисов. Подготовка всех существующих приложений к взаимодействию в рамках новой архитектуры и поиск или разработка недостающих сервисов.
Построение инфраструктуры сервис-ориентированной архитектуры.
Правильное использование СОА, что предполагает активную позицию предприятия в условиях меняющегося рынка.
Создание сервисов может происходить различными способами:
Написание новых сервисов с нуля. Такой подход возможен для организаций, которые либо строят новую систему, либо производят переписывание старой системы. Такой путь не является типичным
для СОА, т.к. здесь не учитывается одно из основных свойств СОА, то, что в качестве сервиса может выступать любая реализованная функциональность, при этом, совершенно не важно на каком языке или в какой среде она выполняется;
Преобразование существующих приложений в сервис-ориентированные. Такой подход применим к системам, построенным по модульному принципу. При этом подходе в организации поменяется только структура взаимодействия, и это будет лишь частичная реализация сервис-ориентированной архитектуры;
Дополнение существующих приложений оболочкой, которая позволит работать с этими приложениями как с веб-сервисами. Этот подход является наилучшим для сохранения инвестиций вложенных в информационные технологии до перехода на СОА. Реализация такого подхода может проходить разными способами: написание дополнительных оболочек к приложения; изменение приложений;
Осуществление поиска готовых сервисов. Сервис может быть уже доступен. Все больше и больше коробочных приложений предоставляют интерфейсы взаимодействия с ними, как с веб-сервисами. Большинство систем уровня предприятия (ERP, CRM) предоставляют программные интерфейсы приложений (API) для веб-сервисов;
Использование поставщиков сервисов. Данный подход возможен в случае необходимости не специфического для организации сервиса.
Результат первого шага реализации СОА, должен поменять архитектуру взаимодействия существующих приложений, при которой появляется средний слой.
Построение инфраструктуры СОА
Инфраструктура сервис-ориентированной архитектуры является инструментом управления, безопасности, масштабируемости как системы в целом, так и для каждого отдельного сервиса, подключенного к инфраструктуре. На рис. 5 схематично представлено взаимодействие систем и приложений предприятия без инфраструктуры (рис. 5а) и с ней (рис. 5б).
На рис. 5 под «кружочками» понимаются точки интеграции приложений, через которые идет взаимодействие систем между собой. На рис. 5а показаны взаимодействия приложений и систем без СОА, что требует использование специфических связей при каждом взаимодействии, т.е. для того, что бы связать n систем между собой нам необходимо n*(n-1) односторонних специфических связей. Очевидно, что
Источник: www.studsell.com
