Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0 - Коллектив авторов

Адаптеры для унаследованных приложений иногда называют «обертками», а саму технологию – «обертыванием»[209]. Такие адаптеры могут разрабатываться на заказ для передачи информации из/в приложение или для доступа к его функциональности.

10.3.7. SOA

Данный раздел содержит более техническое описание SOA.

10.3.7.1. Что такое SOA

Сервис-ориентированная архитектура (SOA) представляет собой гибкий набор принципов проектирования, используемых при разработке и интеграции приложений. В соответствии с этим подходом приложения разрабатываются в виде сервисов, к которым можно обращаться по сети. Обращения на чтение или запись проходят через адаптеры EAI, которые преобразуют их в вызовы функций внутри приложений, реализованных на традиционных языках программирования. Таким образом, обращение на чтение или запись может быть реализовано однократно с применением единого формата SOA, а затем использовано многократно (обычно с помощью ESB) различными приложениями без трудоемкого программирования. Тем не менее, даже несмотря на упрощение, которое достигается благодаря использованию SOA, EAI и ESB, интеграция по-прежнему остается непростой задачей.

Результатом является библиотека сервисов – слабо связанных программных модулей, вызываемых по мере надобности. Помимо этого, SOA предусматривает уведомление потребителей сервисов об их доступности.

10.3.7.2. Основы SOA

Сервис-ориентированная архитектура (SOA) представляет собой подход к организации взаимодействия между разнородными компьютерными системами, в частности к получению и предоставлению данных.

Ниже рассматриваются некоторые ключевые термины и понятия, знание которых поможет BPM-профессионалу со стороны бизнеса разговаривать с IТ-специалистами. Ключевые понятия SOA: сервис, интерфейс, протокол, поставщик, потребитель, запрос, ответ[210].

Сервисом называется программный модуль, включающий одну или несколько логически связанных функций (в случае веб-сервиса они называются методами), например получение суммы остатка на банковском счете и распоряжение на перевод денежных средств со счета. В рамках SOA система, предоставляющая свои ресурсы для внешнего мира, называется поставщиком сервиса, а система, обращающаяся к ресурсам другой системы, – потребителем сервиса.

Взаимодействие между поставщиком и потребителем обычно осуществляется через веб-сервисы (хотя теоретически ставить знак равенства между SOA и веб-сервисами неправильно, так как SOA может реализовываться и другими способами).

Вызов веб-сервиса реализуется следующим образом: программный код на стороне потребителя сервиса «упаковывает» входные данные (например, номер счета) в XML-документ и соединяется по сети с потребителем сервиса. Это делается примерно так же, как интернет-браузер соединяется с веб-сайтом, и с использованием схожих механизмов – в частности, потребитель задает адрес поставщика сервиса в Интернете или во внутренней сети предприятия. Получив запрос, программный код поставщика сервиса его «распаковывает», извлекая данные, и выполняет действия, заказанные потребителем. Результат (например, сумма остатка по счету) снова упаковывается в XML и также по сети отправляется обратно поставщику – опять-таки примерно так же, как веб-сайт отправляет веб-страницу браузеру. Обычно вызов веб-сервиса осуществляется по тому же протоколу HTTP, по которому браузер обращается к веб-сайту, но в принципе могут использоваться и другие протоколы, в частности электронная почта.

Относительную независимость (так называемую слабую связанность) поставщика и потребителя обеспечивает то, что им не требуется знать о способе обработки на другой стороне. Все, что нужно для вызова сервиса, – это спецификация его интерфейса, представляющего собой своего рода «контракт», которому стороны обязаны следовать в ходе взаимодействия.

В случае веб-сервиса для спецификации интерфейса используется специальный язык описания веб-сервисов (WSDL)[211]. Спецификация WSDL содержит адрес поставщика сервиса в Интернете, перечень функций (методов), формат запроса и ответа и поддерживаемые поставщиком протоколы. Этой информации потребителю сервиса достаточно, чтобы вызвать поставщика и получить от него требуемый результат.

Сервисы SOA являются слабосвязанными в том смысле, что и поставщик, и потребитель сервиса могут работать независимо, быть размещены на разных серверах и реализованы на разных языка программирования.

10.3.7.3. Принципы SOA

SOA – это выбираемая компанией стратегия доступа и предоставления данных, а не просто тактика или техника интеграции корпоративных приложений. Это принципиальное различие. Переход к SOA в силу масштабности и глубины изменений, которые он вызывает, следует увязывать со стратегическими целями, задачами и эффектом, достигаемым на уровне корпоративной архитектуры.

Сегодня нет единого мнения о том, что в точности означает следование SOA, или о том, как отличить «SOA-решение» от «не SOA-решения». В то же время существует согласие относительно преимуществ SOA, таких как гибкость, адаптируемость, масштабируемость, повторное использование и т. д. Помимо этих существенных преимуществ, переход к SOA дает побочный эффект в виде устранения барьеров между бизнесом и IТ, между разными бизнес-подразделениями и между разными IТ-специалистами.

Существует множество международных стандартов, которые большинство производителей ПО, консультантов и пресса ассоциируют с SOA. Основной стандарт – язык XML[212], опубликованный W3C[213]. XML определяет формат данных, передаваемых между системами в рамках SOA. Стандарт XML Schema, также опубликованный W3C, описывает структуру и семантику XML-документа.

Примечание: термин «XML-документ» относится ко всему, что кодируется с помощью XML, например бизнес-письмо, заказ на покупку, обмен сообщениями между сторонами, схема базы данных.

Всего же существует свыше 30 относящихся к SOA стандартов, опубликованных W3C, OASIS (Organization for the Advancement of Structured Information Standards), ISO (International Organization for Standardization), OMG (Object Management Group) и другими организациями: WSDL, WS-Policy, WS-Security, WS-Reliable Messaging, BPEL (Business Process Execution Language), BPMN (Business Process Model and Notation), JSON (Java Script Object Notation) и т. д.

То, какие стандарты или какие части стандартов компания выбирает для собственной реализации SOA, определяет то, как она будет использовать SOA, и то, каким из множества преимуществ SOA она отдает предпочтение. SOA, таким образом, не является универсальной, подходящей всем и всюду реализующейся одинаково стратегией.

Для успешной реализации SOA необходимо определить цели, назначение и внутренние стандарты. Начинать следует с определения желаемого результата: какие из преимуществ SOA являются приоритетными. Под эти цели выбираются стандарты, методы, техники и концепции и разрабатывается совместный план действий бизнеса и IТ, в соответствии с которым будет реализовываться стратегия SOA и в котором будет определена роль каждого участника. Но даже при наличии ясного видения, стратегии и плана реализация потребует финансирования и постоянного надзора за тем, что внедрение нового подхода движется в правильном направлении.

Компании следует определить и задокументировать то, какие ресурсы будут предоставляться в рамках SOA – например, процессы, сообщения, объекты данных, хранилища данных, правила, события и т. п.

Также следует рассмотреть и явно задокументировать следующее.

• Все ли предоставляемые ресурсы являются внутренними по отношению к организации, или же они могут включать данные бизнес-партнеров и клиентов.

• Как будет осуществляться контроль за изменениями.

• Работы по переводу программной среды на формат SOA.

• Возможности технологической платформы в части поддержки SOA.

• Новые требования к хранению данных.

В силу гибкости SOA и принятого в нем подхода к предоставлению ресурсов критически важным становится всеобъемлющее и эффективное регулирование. Недостаточно эффективное регулирование является самой распространенной причиной провала инициатив по переходу на SOA.

Основным вопросом регулирования SOA является управление жизненным циклом сервиса от концепции через спецификацию, разработку, тестирование, внедрение и ежедневную эксплуатацию до вывода из эксплуатации. Сюда входит контроль за изменениями в части того, как:

• взаимодействуют подразделения;

• принимаются решения и назначается ответственность;

• меняется процесс;

• проверяются процедуры;

• применяются способы и методы.