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

Зачем нужна сервис-ориентированная архитектура (service-oriented architecture, SOA)? Что ждет SOA спустя два-три года? Насколько оправданы сегодня инвестиции в Web-сервисы вообще и SOA в частности? После того, как ведущие производители, включая IBM и Microsoft с ее продуктом Visual Studio Team System 2005, начали предлагать конкретные решения, построенные на базе SOA, эти вопросы постепенно становятся риторическими.

Очень своевременная архитектура, но…

Прежде всего, посмотрим, что думают по поводу SOA в ведущих аналитических агентствах.

По мнению специалистов из Giga Research, в ближайшие два-три года большинство производителей будет использовать технологию Web-сервисов в качестве расширения существующих платформ, приложений и инструментария, а также как основу для создания новых решений. Мало того, игроки ИТ-рынка будут вынуждены перестроить в соответствии с SOA свои продукты с целью оптимизации использования уже имеющихся корпоративных приложений. К 2006 году более 60% корпораций, по данным Gartner, будут рассматривать SOA как основу для построения и выполнения своих критичных бизнес-приложений. К этому же сроку более 75% крупных и средних предприятий будут иметь инструментарий SOA. Когда Web-сервисы станут повсеместным явлением, появится возможность создания гетерогенных систем, решающих бизнес-задачи путем налаживания взаимодействия между различными приложениями и технологиями. В ближайшее время, по мнению аналитиков, должен произойти переход от ИТ-инфраструктур, образованных сообществом серверов приложений, к адаптивным «фабрикам» по производству сервисов, динамично реагирующих на изменение нагрузки и условий ведения бизнеса.

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

Аналитики Butler Group подчеркивают, что SOA — это не набор Web-сервисов, а средство достижения необходимой «эластичности» ИТ-инфраструктуры. Ключевое преимущество здесь — возможность переориентации имеющейся конфигурации на решение новых задач бизнеса. Традиционная статическая инфраструктура не позволяет работать в быстро меняющихся условиях, например, один из конфликтов, который сегодня постоянно приходится разрешать предприятиям — быстрое реагирование на требования обеспечения безопасности, которому, однако, препятствует сопротивляющаяся изменениям ИТ-инфраструктура.

Безусловно, такие технологии, как CORBA, J2EE, COM/DCOM и даже Customer Information Control System, уже были ориентированы на сервисы. Однако ни CORBA, ни J2EE, по мнению аналитиков Butler Group, нельзя назвать гибкими по причине сложности определения интерфейсов. DCOM менее сложен, но, тем не менее, также требует много усилий для изменений интерфейса, а для сервис-ориентированного решения гибкий интерфейс — это наиболее важный аспект. Но и с SOA, считают в Butler Group, не все пока гладко: для успеха данной архитектуры требуется язык, принятый большинством. Долгое противостояние Microsoft с остальным софтверным миром, по мнению аналитиков, до последнего времени не позволяло говорить о действительно всеобъемлющем решении по SOA. Вместе с тем, успехи в продвижении языка описания Web-сервисов Web Services Description Language (WSDL) обнадеживают.

Гибкость и адаптивность SOA-программ основана на возможностях используемой шины и разделении интерфейсов и бизнес-логики: интерфейс варьируется в зависимости от обстановки, а логика может быть неизменна. Сегодня приложение, рассчитанное на сервисную архитектуру, зависит от конкретной шины, предлагаемой J2EE, CORBA или DCOM. Требуется же универсальная сервисная шина, независимая от интерфейсов. На данный момент в качестве решения предлагается Internet в качестве сервисной шины и интерфейсный язык WSDL. Этого уже достаточно, чтобы инициировать наступление SOA. Правда, в реальном мире все не так просто. В частности, HTTP — далеко не лучший протокол для работы с высокопроизводительными системами, однако он обладает неоспоримым преимуществом — он широко распространен. Производители, определяющие погоду в ИТ-индустрии, должны еще несколько лет поработать вместе над совершенствованием WSDL, чтобы реализовать все преимущества этого языка. WSDL основан на XML, что позволяет обеспечить обмен данными (рис. 1), однако пока еще нельзя говорить о промышленных реализациях средств работы с данными, лежащими вне XML, прежде всего, таких, как плоские файлы и таблицы реляционных баз данных.

Рис. 1. Использование XML в SOA

Среди основных преимуществ SOA аналитики Gartner выделяют модульность, позволяющую строить гибкие и актуальные решения для бизнеса, а также возможность повторного использования программ — лучших «строительных блоков», из которых по запросу можно строить необходимые бизнесу приложения, способные работать в новом контексте. Однако, за преимуществами не следует забывать и о рисках, связанных с SOA.

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

Деятельность провайдеров основана на идее передачи на аутсорсинг процессов, в которые конкретный пользователь не может добавить ничего своего. В этом случае, получая от провайдера услуги, пользователь ожидает, что их цена будет ниже, чем стоимость их изготовления собственными силами — SOA позволяет создавать операционное окружение, оперируя терминами выгоды. Еще «на заре» интереса к Web-сервисам большое внимание уделялось реестру (репозиторию), содержащему исчерпывающую информацию по службам и снабженному средствами поиска. Однако, до сих пор еще нет единого мнения по перечню требований к этому реестру. Неясно, как для построения бизнес-приложения выбрать лучший сервис, позволяющий выполнить сформулированные для бизнеса конкретные соглашения по уровню обслуживания (service level agreement, SLA). Понятия «лучший» и «выгодный» применительно к сервисам остаются весьма размытыми; не всегда очевиден, скажем, выбор по таким критериям, как скорость доступа, цена аренды сервиса и его доступность.

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

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

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

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

Конструктор SOA-приложений

Одним из средств конструирования и разработки программ, предлагаемых Microsoft, будет система Visual Studio 2005, в реализациях Whidbey и Orcas которой будут расширенные средства для конструирования SOA-приложений.

Сервис-ориентированный конструктор Whidbey призван помочь архитекторам систем и разработчикам при создании SOA-приложений и их размещении в реестре. Помощь эта реализуется по трем направлениям: содействие в конструировании и конфигурировании сервисов и проектировании программ их реализации; поддержка при описании инфраструктуры центров данных (ограничения, логическая топология, политики работы с приложениями); сопровождение сертификации каждого приложения, подготовленного для размещения в реестре. Один из ключевых механизмов реализации такой помощи — предоставление соответствующих шаблонов. Примечательно, что в концепции Microsoft, Web-сервис рассматривается как адаптивный компьютерный элемент, способный через протоколы взаимодействовать с другими элементами и приложениями.

Конструирование операций и процесса выполнения

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

Инициатива Microsoft Dynamic Systems Initiative (DSI) направлена на сокращение цикла «проектирование-разработка-кодирование» за счет предоставления архитектору приложений специального инструментария. В основе DSI лежит модель определений — System Definition Model (SDM), позволяющая в унифицированном виде описывать среду работы приложения: хост, сеть и уровни аппаратных устройств. Сам процесс проектирования должен быть более точным, но достигать этого требуется без введения дополнительных уровней и концепций, без усложнения процесса. SDM-модель содержит метаданные, используемые на всех стадиях жизни SOA-приложения и позволяющие синхронизировать процесс проектирования и кодирования.

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

Рис. 2. Состав SOA-конструктора
  • Конструктор распределенного сервиса - Distributed Service Designer (DSD). Визуальное представление различных сервисов и компонентов SOA-приложения. Конструктор представляет собой планшет для проектирования сервисов, создания компонентов и визуализации автоматически формируемого кода программы. С помощью DSD архитектор на этапе проектирования сервиса определяет потоки его взаимодействия с другими сервисами, моделирует параметры для будущих приложений и экспериментирует с их структурой.
  • Конструктор логики системной архитектуры - Logical Systems Architecture Designer (LSAD). Визуализация и описание логической структуры репозитория сервисов, включая параметры развертывания приложений и ограничения. Конструктор используется для формирования диаграмм, описывающих логическую структуру репозитория: порядок взаимодействия хостов; топология элементов центра данных (Web-серверы, серверы баз данных, зоны безопасности, входящие и выходящие потоки, точки обработки информации); описание деталей конфигурации (например, протоколы взаимодействия и параметры безопасности); ограничения и спецификации приложения. Архитектор инфраструктуры может использовать LSAD для определения ограничений на параметры приложений, согласуя их с возможностями центра данных. Имеется возможность использовать уже готовые диаграммы, предлагаемые Microsoft.
  • Конструктор подсистем - Subsystem Designer (SSD). Конфигурирование компонентов, определенных в DSD с целью их объединения в готовую к развертыванию логическую подсистему. С помощью SSD архитектор может, например, задать порядок доступа нескольких пользователей к одному сервису.
  • Конструктор хостовых подсистем - Subsystem Hosting Designer (SHD). используется для виртуального развертывания подсистем. SHD получает на входе данные от SSD и LSAD и формирует единую связку сервисов. Конструктор устанавливает требования к коммуникациям приложения, следит за их обоснованностью, контролирует совместимость между программными компонентами и логическими хостами в точном соответствии со спецификациями LSAD.

Результатом работы конструктора из Whidbey может быть код для Web-приложений ASP.NET.

Интегратор Indigo

Востребованность SOA-решений неизбежно приведет к тому, что поддержка этой архитектуры станет частью платформы, что, в частности, уже подтверждается фактом включения в перспективную операционную систему от Microsoft (она разрабатывается под кодовым названием Longhorn) нового компонента Indigo, объединяющего в себе функциональность COM+, MSMQ и Web Services/Web Services Enhancements. Коммуникационные сервисы в Longhorn предназначены для того, чтобы скрыть от пользователя сложности налаживания взаимодействия между приложениями (межсетевые экраны, диапазон адресов, особенности маршрутизации, аутентификация и авторизация, разнообразие протоколов и форматов представления данных и т.п.), освободив его время для разработки прикладного функционала. Indigo — это система обмена сообщениями, обеспечивающая безопасное, гибкое и многопотоковое взаимодействие гетерогенных систем.

Коммуникационный сервис Indigo поддерживает два основных типа взаимодействия: модель stateless, при которой сообщение доставляется с некоторой вероятностью, и модель stateful, предусматривающую создание коммуникационного сеанса между двумя сервисами. Первая модель применяется в современных Web-сервисах для работы с некритичной информацией. Вторая модель призвана через Internet гарантированно и в срок доставить требуемое приложению сообщение. Мало того, имеется возможность поддерживать долговременные взаимодействия, предусматривающие восстановление даже в случае сбоев в работе приложений. Для защиты приложения от случайных проблем при связи между узлами в Indigo предусмотрены средства автоматического обнаружения сбоев и восстановления. Предоставляется гарантия доставки сообщений приложению, которое подтверждается либо сообщением об успешном завершении, либо информацией о невозможности выполнить доставку. Стабильность процесса передачи сообщений необходима для освобождения приложений от решения проблем, связанных нарушением работы узлов. Это достигается за счет сохранения в памяти всей информации о сообщениях, включая все данные по диалогу, что позволяет в случае необходимости восстановить коммуникационный сеанс.

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

Архитектура Indigo

Indigo имеет многослойную архитектуру. Пользователь взаимодействует с верхним, сервисным слоем, оперируя терминами метод, событие и запрос. Сервисный слой преобразует эти абстракции в сообщения для нижних процедурных слоев, с которых через некоторое время возвращаются результаты. Порядок перемещения сообщений определяется протоколом SOAP, а сами сообщения представляют собой XML-тексты иерархической структуры, задаваемой в слое XML Infoset. Доставка сообщений осуществляется на транспортном уровне, на котором определены абстрактные классы и интерфейсы, способные работать с любым коммуникационным протоколом, таким как TCP или HTTP.

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

Приложения Indigo

Indigo инфраструктура позволяет создавать различные приложения, от простейших типа телеконференций с двумя участниками, общающихся через корпоративную сеть, до сложных масштабируемых Web-сервисов, обслуживающих миллионы пользователей. В первом случае приложение может представлять собой Web-сервис на базе XML, построенный на ASP.NET со страницей .asmx; этот тип приложений получил название Indigo Web Service Applications. Во втором, более сложном случае, предусматривающем двусторонние преобразования объектов и использование кэширования для удаленных классов .NET, речь идет о Indigo RemoteObject Service Application.

Indigo Web Service Applications. За счет поддержки SOAP 1.1 и 1.2, а также спецификаций WSDL 1.1, Web-сервисы на базе Indigo взаимодействуют со сервисами, установленными не только на платформах от Microsoft. Приложения данного класса обладают следующими возможностями:

  • безопасное взаимодействие через произвольное количество межсетевых экранов, работа со средствами обеспечения безопасности, надежности и обработки транзакций от третьих поставщиков;
  • участие в распределенных транзакциях;
  • поддержка двустороннего общения;
  • гарантированная доставка сообщений;
  • масштабирование за счет поддержки работы с репозиториями Web-сервисов;
  • предоставление разработчикам возможности построения приложений .NET Framework без обязательного знания XML или особенностей SOAP.

Indigo RemoteObject Service Applications. Приложения данного типа аналогичны приложениям для .NET но с расширенными функциями. Клиентам предоставляется возможность взаимодействия с объектами на сервере, инициации диалога, работы с метаданными для удаленных классов. Однако в удаленных объектах .NET нет механизмов аутентификации и шифрования, у них нет возможности автоматической активации сервера, кроме этого, нельзя передать транзакцию путем вызова удаленного метода. Напротив, приложения Indigo RemoteObject имеют встроенный механизм Indigo SOAP, позволяющий поддерживать все необходимые функции обеспечения безопасности (аутентификация, шифрование, автоматическая активация и т.п.). Дополнительно имеется возможность удаленного взаимодействия и использования асинхронных методов обработки.

Часто требуется ограничить доступ к приложениям Indigo только заранее определенному кругу пользователей; для этого используется специальный сервис идентификации клиентов. Кроме этого, Indigo предоставляет сервис по аутентификации, предусмотренный в Windows, сертификацию X.509 и аутентификацию по имени пользователя и паролю. В Indigo поддерживаются алгоритмы симметричного и асимметричного шифрования, можно также использовать цифровую подпись.

Шина передачи сообщения автоматически настраивает процесс передачи в соответствии с политиками, указанными в спецификации WS-SecurityPolicy. Например, если сообщение передается клиенту и используется стандартная конфигурация, то клиент-получатель будет автоматически извещен о необходимых параметрах защиты. Во многих случаях требуется специфицировать параметры безопасности только на стороне сервера, что также поддерживает Indigo. Конфигурация параметров безопасности может быть описана в специальном файле, либо включена в код.

SOA — в жизнь

Развитие Internet вызвало необходимость организации взаимодействия между приложениями без посредства человека, однако подход к разработке таких приложений отличается от традиционных методов создания программного обеспечения. Например, разработчику приходится учитывать массу дополнительных факторов: особенности преодоления защиты межсетевых экранов, маршрутизация сообщений, авторизация, работа с разными протоколами и т.п. Архитектура, ориентированная на сервисы, определяет порядок работы приложений, распределенных по Сети, а ряд ведущих игроков ИТ-рынка уже предложили свои реализации SOA. Недавно компания Microsoft обнародовала планы по системе Visual Studio 2005 Team System, которая, наряду с решениями от IBM (например, IBM Rational Rose XDE), позволит говорить о существенных изменениях на рынке CASE-средств.

Исторически, продукты Microsoft были «кодо-ориентированы» и не очень хорошо предназначены для создания адаптивных архитектур. До недавнего времени с этим можно было мириться: наличие у пользователя команды разработчиков позволяло относительно быстро реагировать на запросы бизнеса. Однако движение в сторону адаптивных систем исключают частое вмешательство человека в жизненный цикл аппаратно-программной системы. Сегодня, пока компания еще работает над интеграцией в Visual Studio .NET средств, направленных на удовлетворение потребностей разработчиков, архитекторов и тестировщиков, преждевременно говорить о появлении на рынке продуктов, полностью отвечающих требованиям SOA, подразумевающей «фабричную» стратегию разработки приложений. Однако наличие реальных внутрикорпоративных реализаций SOA-приложений и определенный успех в стандартизации WSDL вселяет оптимизм в будущее архитектур, ориентированных на сервисы.

Задачи для конструктора

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

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

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

  • Архитектор системы использует LSAD для фиксации метаданных о центре данных, а затем информирует членов рабочей группы. Если такой центр уже имеется, то LSAD используется для определения существующей конфигурации и передачи этой информации разработчикам. Если центра еще нет, LSAD применяется для описания требований к его работе по поддержке приложения. Все это позволяет избежать конфликтов, почти неизбежных при выполнении проектов в условиях ограниченных ресурсов.
  • Архитектор работает с DSD, задавая параметры приложения и формируя оптимальный пакет спецификаций, который передается разработчикам. С помощью конструктора команда разработчиков может сразу сгенерировать прототип реализации Web-службы и по заданным спецификациям получить проекты Visual Studio. Следует отметить, что архитектор на всем протяжении проекта снабжает всех членов команды спецификациями приложения, что полностью снимает проблему организации взаимодействия.
  • Актуальность диаграмм и кода обеспечивается их взаимной синхронизацией - любые изменения сделанные через интерфейс в коде автоматически отражаются на диаграммах и наоборот.

Сбои при развертывании приложения. Интенсивное тестирование приложения может показать, что проект выполнен в соответствии со спецификациями, однако, до момента развертывания приложения в центре данных нельзя быть уверенным в успехе: невозможно заранее смоделировать реальные условия эксплуатации приложения. Например, развертывание приложения может оказаться неудачным в случае отсутствия в центре данных требуемого окружения. К моменту передачи приложения в центр данных в распоряжении архитектора будет SHD, позволяющий на основе имеющейся информации представить карту логического расположения компонентов приложения. Здесь архитектор может одновременно задать параметры приложения и атрибуты хоста, добавить ограничения по взаимовлиянию параметров и отследить корректность отражения параметров в приложении. Картина структуры приложения позволяет архитектору убедиться в правильности учета разработчиком всех имеющихся ограничений еще до момента развертывания приложения в центре данных. В SHD предусмотрена обратная связь — сообщение о появлении ошибок позволяет разработчику исправить возникшие неточности еще до момента реального использования приложения.

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

Поддержка приложений. Часто поддержкой кода занимаются не его разработчики и в общем случае достаточно трудно быстро разобраться в структуре программ и понять логику взаимодействия различных кусков приложения. Это положение иногда усугубляется отсутствием документации и актуальных диаграмм потоков данных. Сама природа SOA-приложений изначально ориентирована на устранение таких недоразумений: в любое решение Visual Studio Whidbey могут быть включены диаграммы распределения сервисных потоков, что обеспечивает прозрачность процесса взаимодействия Web-сервисов.

На сайте msdn.microsoft.com/longhorn/archive/ default.aspx?pull=/library/en-us/dnintlong/html/longhornch06.asp представлен пример, неплохо иллюстрирующий порядок разработки приложений с использованием SOA-решений от Microsoft.