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

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

technorati tags: soa

Как я упомянул в предыдущем посте, 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

Предметное обсуждение SOA началось и по-русски. Сколько ни пишут журналы на эту тему, дискуссии никак не получается. И только с появлением ITBlogs.ru наметилась радующая тенденция.

Внести ясность, которой пока так не хватает в обсуждении этой темы, попытался Влад Боркус. Как он правильно заметил, большая часть рассуждений на ITBlogs (и не только), так или иначе связанных с SOA, фокусировалась на Web-сервисах. С этим мнением я согласен, но добавлю, что "фундаметальный изъян" выходит за обозначенные рамки. Одно то, что мы только и придумываем, как сущности какие согласовать, да в какие системы их так воткнуть внедрить, чтобы целостность была гарантирована и т. п., уводит нас немного в сторону от предмета обсуждения (хотя способы и даже стандарты протоколов синхронизации состояния бизнес-процессов и соответствующих систем существуют). Чтобы к дискуссии о возможном техническом оснащении SOA подойти с общим ее пониманием, целесообразно рассмотреть сервисную ориентацию несколько шире.

Много раньше я порассуждал о разнице в моделировании объектов и сервисов, столкнувшись с несовершенством моделей программирования сервисов на самых популярных платформах. С их подходом действительно можно быстро наладить базовый Web-сервисный RPC, особенно не задумываясь об архитектуре целого решения, корректности интерфейсов, да и о сервисной ориентации вообще. IMHO это крайне странный подход, если осуществляется в рамках SOA, поскольку потребность в SOA возникает совершенно с других позиций, и первые шаги должны быть осуществлены именно в сфере проектирования.

Необходимо определиться с принципами выделения сервисов, с их функциональными границами, максимально привязывая их к границам соответствующих бизнес-единиц. Я предпочитаю думать о провайдере сервиса не как о системе (CRM, ERP и т.п.), а как о соответствующей этому сервису бизнес-единице (произвольно малой или большой). Именно она предоставляет сервис, потенциально реализованный при помощи некой системы или совокупности систем.

Делая провайдером не систему, а бизнес, задача согласования информационной архитектуры выводится на тот уровень, на котором она теоретически решаема -- на уровень бизнеса. Мы уже говорили о том, что семантика идентичных сущностей в разных системах то и дело оказывается несогласуемой и, как следствие, информационное взаимодействие затрудняется. Согласование семантики сущностей, как и бизнес-процессов в целом, является делом бизнеса, а не IT, и ошибка, соответственно никак не в технологиях. <update>SOA позволяет корректно вернуть эту задачу бизнесу и получить результат, допускающий техническую реализацию. Сервисная ориентация способствует конструктивному участию IT в оптимизации бизнес-процессов и получении результата, допускающего техническую реализацию.</update> Сервис (в этом контексте его еще называют "бизнес-сервис") является той самой промежуточной конструкцией соответствия (alignment'а) бизнеса и IT.

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

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

Такой двойственный характер информационного обмена в SOA служит постоянным источником противоречий, устранить которые можно только установив границы, помимо функциональных, между асинхронными бизнес-взаимодействиями верхних уровней и преимущественно синхронными сопутствующими IT-взаимодействиями более низких уровней. Лишь на самом низком уровне SOA мы приходим к т. н. "мелкозернистым" (fine-grained) сервисам, которые через RPC-вызовы включаются в бизнес-процессы для хранения и передачи состояния между ними (т.е. для осуществления учетной функции). Основная же область рассмотрения SOA лежит выше.

technorati tags: soa