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

Взаимодействие с внешним миром

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

Проблема взаимного исключения

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

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

Интерфейс с пользователем

Еще одна область, о которой часто забывают проектировщики – удобство пользователей, доля которых в выполнении операций может доходить до 100% в SOA-системах с широким участием человека в выполняемых операциях. Именно принцип SOA позволяет клиентским приложениям абстрагироваться от того, как выполняется операция сервиса. Поэтому потенциально за каждым сервисом может находиться человек и удобство его работы нельзя игнорировать.

Этап разработки

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

Этап внедрения

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