Сервис-ориентированная архитектура (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Т-специалистами.