Даниил Фейгин: мысли вслух

Как я упомянул в предыдущем посте, SOA следует модели бизнеса, его архитектуре. Если ценность объектной ориентации основывается на том, что объекты могут представлять реальные предметы, то ценность сервисной ориентации основана на том, что сервисы могут представлять то, чем занимаются компании. Таким образом сервисная ориентация сближает бизнес и его IT-отражение (бизнес -> сервисы -> технологии; "->" означает глагол drive(s)).

Анатолий Тенцер справедливо обратил внимание на потребности бизнеса, определяющие в нашем деле. Бизнес же, по крайней мере тот, который в классификации вендоров относится к enterprise, по природе своей децентрализован. В противном случае он парализован. При этом он имеет тенденцию развиваться, если не сказать больше. Управляемость IT, к сожалению, обычно обратно пропорциональна как степени децентрализации, так и скорости изменений. Как же SOA, по определению децентрализованная, учитывает эти требования и сглаживает противоречия?

Короткий ответ: слабая связанность. Ее реализация может основываться на сочетании различных средств и методов.

1. Контракты. Понятие контракта в SOA трактуется несколько шире, чем обычно (например, в CORBA контракт, как правило, исчерпывается IDL -- техническим описанием интерфейса объекта), играя более значимую, если не определяющую роль (контрактно-ориентированная архитектура?). Контракт определяет условия предоставления и потребления сервисов, включая функциональные, технические (не только протокол, но и, например, способ авторизации, QoS) и прочие (стоимость, гарантии) параметры и служит основой соглашения между потребителем и провайдером сервиса на всех этапах его жизненного цикла. Не даром одно из распространенных определений провайдера и потребителя сервисов базируется на том, кто из них контракт предоставляет (провайдер), а кто принимает (потребитель).

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

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

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

3. Динамическое связывание. Опираясь на стабильность контракта потребитель может находить необходимые экземпляры сервисов во время исполнения. Это означает, что система устойчива к изменениям не только в адресации доступных сервисов (переезд на другой сервер), но и в их составе, который может измениться за время эксплуатации. Например, могут появиться новые партнеры, или ответственность за предоставление требуемой бизнес-функции может перейти к другому провайдеру, в том числе внешнему, прозрачно для пользователей этих функций.

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

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

Тем не менее, реестр выполняет очень важную функцию в рамках регулирования (governance) SOA, вне зависимости от того, используется он в runtime или нет.

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

Здесь мы вынужденно опускаемся на технологический уровень, поскольку возможность такая для инструментально поддерживаемых прикладных протоколов приобрела распространение лишь с появлением XML в паре с XML schema (душещипательные истории про хаки с расширением IDL-описаний, работающих только для конкретного ORB, пускай даже по стандартному IIOP, не принимаются, т.к. ни стандартными ни поддерживаемыми не являются) и протоколов на его основе. Описание же интерфейса на базе XML schema может содержать абсолютно стандартные wildcard-компоненты, прекрасно используемые валидаторами и в разной степени поддерживаемые всевозможными инструментальными средствами и платформами. Вкупе с определенными подходами, можно реализовать довольно гибкую схему, не ломающую при добавлении новых элементов ни промежуточные звенья, ни какую-либу из взаимодействующих сторон.

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

В качестве примера приведу SOAP, основанный на этом принципе. Все протоколы из серии WS-* являются именно такими расширениями заголовка SOAP-конверта, XML-схема которого содержит wildcard и атрибут булевского типа mustUnderstand, определенный для элементов-расширений. Если расширение с mustUnderstand="true" приходит SOAP-обработчику, не понимающему данный заголовок, то он может корректно сообщить об этом отправителю сообщения, отказавшись от обработки. Если же mustUnderstand="false", то расширение можно игнорировать без опасности утраты критической информации.

5. Перестраивание. Расширяемость -- хорошо, но недостаточно. По хорошему, интерфейс всегда должен быть максимально полным, да и основных проблем управления изменениями расширяемость не решает. Поэтому, рано или поздно, интерфейс приходится менять, адаптировать к измененным бизнес-требованиям. Какие процедуры при этом запускаются каждая компания (в лице ответственного IT-менеджера) сама определяет для своей организации, в зависимости от множества факторов, не последний из которых -- баланс логичности/интуитивности в стиле принятия решений. Для более стабильных организаций характерна бо́льшая регламентация процесса изменений, для более гибких -- меньшая. Каждый регулирует свои изменения подстать себе, руководствуясь -- чем же еще? -- требованиями бизнеса.

Сто́ит отметить, что далеко не все нынешные инструментальные средства помогают в достижении слабой связанности. Они, например, имеют тенденцию по описанию интерфейса генерировать клиентский код так, что тому при инициализации известен адрес и свойства сервиса на момент генерации этого кода. О каком слабом связывании может идти речь? Для его обеспечения приходится добавлять собственный слой обнаружения и инициализации, вполне генерируемый тем самым инструментальным средством либо же упаковываемый в используемый технологический стэк (платформу).

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

Но ни один продукт в принципе не может "сделать SOA", архитектуру нельзя купить в коробке. Продукты -- только средства, причем довольно далекие от архитектуры. Чтобы их эффективно применять (или осознанно не применять), полезно сначала представить себе желаемый результат, отталкиваясь не от конкретных продуктов, а от необходимых свойств архитектуры.

technorati tags: soa