Моделирование подключенных систем, ориентированное на сервисы

Арвиндра Cеми и Бит Швеглер2006 Март № 1(4) Microsoft Architects Journal

Применение модели, ориентированной на сервисы, в процессах проектирования требует учета ее особенностей, их правильного определения и размещения на нужном уровне абстракции. Только так можно добиться соответствия этой модели бизнес-требованиям организации. В этой статье мы предлагаем трехуровневый подход к моделированию подключенных и ориентированных на сервисы систем, который обеспечивает максимальное приближение ИТ-решений к потребностям бизнеса. Мы начнем с рассмотрения старого подхода к архитектурам, ориентированным на сервисы (SOA), и покажем, почему этот подход часто оказывался безуспешным и, как правило, не давал ожидаемой отдачи от инвестиций. Далее мы обсудим преимущества размещения модели сервисов между традиционными бизнес- и технологической моделями, знакомыми большинству архитекторов, и поговорим о методологии Microsoft Motion и о сопоставлении бизнес-возможностей (business capabilities) с сервисами. Кроме того, мы покажем, как реализовать такие сопоставленные сервисы.

Моделирование, ориентированное на сервисы, занимает видное место в планах многих организаций. 

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

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

Рис. 1. Пять «столпов» подключенных систем

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

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

Пять «столпов» подключенных систем

Обмен сообщениями играет важную роль в проектировании, ориентированном на сервисы, но это лишь один из аспектов моделирования сервисов. Обмен сообщениями позволяет связать разнородные системы между собой и создать инфраструктуру, необходимую для соединения, но требуется решить и ряд других важных проблем, поэтому нужны другие «столпы», которые «подпирают» обмен сообщениями. Пять «столпов» подключенных систем показаны на рис. 1.

• Идентификация и доступ Этот «столп» связан с понятиями федеративной идентификации (единый вход через Web) и авторизации, основанной на политике. Сюда относятся управление доверительными отношениями и доступом к системе, с которой установлено соединение. Другие важные факторы, которым нужно уделить должное внимание при работе над этим «столпом», — руководства по управлению и правила соответствия.
• Данные Здесь нужно позаботиться об агрегировании сущностей и обеспечении единого согласованного представления таких бизнес-сущностей, как клиент, даже если данные о клиентах могут дублироваться в разных системах.
• Взаимодействие Этот «столп» связан с использованием сервисов людьми, например с разработкой мощного и сложного UI, поддерживающего онлайновый и автономный режимы. Сюда также относятся взаимодействия на «границах» сетей через Web, механизмы однорангового доступа и доступ с портативных устройств.
• Обмен сообщениями Обеспечивает базовую инфраструктуру взаимодействия и предоставляет безопасный и надежный механизм обмена сообщениями с поддержкой транзакций.
• Рабочий процесс Связан с выполнением бизнес-процессов и автоматизацией, внешней по отношению к сервисам. К рабочему процессу относится управление бизнес-процессами, а также другие аспекты, такие как управление взаимодействием с пользователями, специализированные процессы и обработка исключений.
  

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

Старый подход к проектированию, ориентированному на сервисы

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

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

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

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

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

Традиционное моделирование систем

В современных подходах к моделированию, как правило, применяются две модели: бизнес-модель и технологическая (рис. 2). В идеале бизнес-модель и технологическая модель должны быть согласованы и близко соответствовать друг другу, но на практике это удается обеспечить нечасто. Основная причина в том, что ИТ-отделы, обращенные внутрь, не могут достаточно тесно и эффективно сотрудничать с бизнес-подразделениями. Чтобы решить эту проблему, часто применяли модели областей сущностей (entity domain models), которые были надстройками над технологическими моделями, но такой подход работал не очень хорошо главным образом потому, что преследовал две противоположные цели — описание внутренней реализации и бизнес-функциональности. Есть основания думать, что точного соответствия технологической и бизнес-модели можно добиться лишь в редких случаях, так как слишком уж велико расхождение между подходами, на которых основаны эти модели.

Рис. 2. Традиционная модель системы

Как же добиться более точного соответствия? Для этого важны четыре ингредиента.

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

В нашем общем профессиональном языке есть такое понятие, как «описание бизнес-архитектуры» («exposing the business architecture»). Поскольку бизнес-возможности в одной отрасли во многом схожи или даже идентичны, сотрудники ИТ- и бизнес-подразделений могут получить информацию о бизнес-архитектуре с помощью стандартного набора вопросов и определить требования. Даже люди, не являющиеся экспертами в бизнесе, могут, используя стандартный набор вопросов, вести плодотворное обсуждение бизнес-требований и собирать важную информацию о метриках, производительности, зрелости инфраструктуры, возможностях взаимодействия, управлении и совместимости. К тому же, поскольку сотрудники бизнес-подразделений отвечают на вопросы архитектора, тот помогает им четко описать свои (возможно, еще не систематизированные) представления о бизнесе.

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

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

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

Новый подход к проектированию, ориентированному на сервисы

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

Рис. 3. Трехуровневая модель архитектуры, ориентированной на сервисы

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

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

Табл. 1. Четыре принципа: требования и особенности моделей

Требования	Бизнес-модель	Модель сервисов	Технологическая модель
Границы	Четко разграниченные функциональные возможности (карта возможностей в бизнес-архитектуре)	Интерфейсы сервисов для внешнего использования (определение конечной точки сервиса)	Реализация явных границ сервиса (конкретная конечная точка сервиса)
Автономия	Возможность внутреннего выполнения и аутсорсинга (определения возможностей — базовых, производственных и внешней среды)	Взаимозаменяемые, слабо сопряженные сервисы (проектировочные решения — территориальные, временные, технические и производственные)	Независимость реализаций (независимость реализаций данных и поведения)
Контракт	Описания задач и процессов (логические единицы обработки и определения рабочих процессов)	Определения данных, интерфейсов и управления (сообщения и данные XSD, WSDL и протоколы взаимодействия сервисов)	Реализации общих данных, интерфейсов и управления (WSDL, XSD и BPEL)
Политика	Управление, определения SLE и SLA (требования, пожелания, ожидания и соглашения)	SLA, доступные извне (определения совместимости «я могу», «мне нужно», «я предпочитаю»)	Несвязанные друг с другом производственные задачи [пересекающиеся задачи (защита, надежность, транзакции), WSI-Profile]

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

Разработка, ориентированная на сервисы, основана на четырех фундаментальных принципах, введенных группой разработки Windows Communication Foundation (WCF) (ранее Indigo) в Microsoft. Ее сотрудники сформулировали эти принципы главным образом для того, чтобы описать, как с помощью программной модели WCF создавать Web-сервисы с высоким уровнем детализации, т. е. эти принципы в большей степени связаны с технологической моделью, чем с двумя другими. Однако они могут иметь важное значение в трехуровневой модели, если рассматривать их как принципы бизнес-сервисов, применимые к уровню сервисов и бизнес-уровню.

Четыре принципа SOA

Что представляют собой эти четыре принципа?

Существуют явные границы, сервисы автономны, они используют общие схему и контракт, но не класс, и совместимость сервисов определяется на основе политики. Рассмотрим их подробнее.

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

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

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

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

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

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

Определение моделей

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

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

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

Уровни сервиса Чтобы обеспечить согласованность и совместимость моделей, введено понятие уровней сервиса (обслуживания). На уровне бизнес-модели ожидаемый уровень сервиса определяется с помощью SLE, являющихся ожиданиями с точки зрения бизнеса. В дальнейшем, когда вы разрабатываете программную систему, предоставляющую сервис, SLE преобразуется в SLA (соглашение об уровне сервиса). На уровне технологической модели SLA оказывают влияние на хостинг сервиса и на то, как осуществляется управление сервисом.

Например, если ваши бизнес-ожидания или соглашения об уровне сервиса очень высоки, вас не устроит, если хостом для вашего сервиса будет однопроцессорный сервер, не поддерживающий избыточность. Ожидания и соглашения определяют требования к доступности, надежности, безопасности и управляемости вашего решения. Аналогично, если система является критически важной для бизнеса, к возможностям управления, которые должно поддерживать ваше решение, предъявляются дополнительные требования. Как представляются уровни сервиса в каждой из трех моделей, показано на рис. 4.

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

Реализация Вам нужна возможность подробно описывать, как вы собираетесь реализовывать свои модели и выражать их. В бизнес-модели требуется отразить существующие на предприятии бизнес-процессы, которые вы идентифицировали. Далее, чтобы описать бизнес-процессы в модели сервисов, понадобится механизм управления. Затем, когда вы займетесь реализацией управления, потребуется некая технология реализации рабочего процесса или механизм управления. Так, на платформе Microsoft можно применять сервисы управления, поддерживаемые Microsoft BizTalk Server (рис. 4). Говоря об управлении (orchestration), мы подразумеваем автоматизированные рабочие процессы, но возможна и такая реализация технологической модели, в которой не исключен ручной труд. Это становится понятным при определении бизнес-модели.

Рис. 4. Представление бизнес-функций (1), моделирование уровней сервиса (2) и реализация моделей на разных уровнях абстракции (3)

Создание бизнес-модели

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

Сопоставление возможностей

Методология Motion помогает выделять и документировать структурную и ориентированную на процессы информацию вместе с индивидуальными возможностями.

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

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

Разработка моделей возможностей

Модель возможностей — вложенная иерархия бизнес-возможностей, которая позволяет моделировать бизнес как структурированную сеть возможностей (в противоположность физически интегрированной сети). Модель бизнес-возможностей — схема, которая описывает сеть возможностей, используемых бизнесом. Базовая инфраструктура, применяемая при конструировании модели возможностей на разных уровнях абстракции, показана на рис. 5.

Рис. 5. Базовая инфраструктура для конструирования модели возможностей

Вы можете рассматривать бизнес на разных уровнях абстракции. На уровне 1 находятся базовые возможности, общие для большинства организаций независимо от отрасли. Возможности уровней 2, 3 и выше обеспечивают дополнительную детализацию бизнес-возможностей. Прежде чем подробно обсуждать каждый уровень, заметим, что не обязательно разбивать все возможности на части, относящиеся к одному уровню: можно сфокусироваться на рассмотрении возможностей, наиболее значимых для предметной области.

Базовые возможности уровня 1

Изучив предприятия различных отраслей, Microsoft определила верхний уровень абстракции. Для предприятий в большинстве отраслей характерны пять общих основополагающих возможностей, связанных с их работой и внешней средой; их называют базовыми (рис. 6). Это разработка продукции и услуг, создание спроса, доставка продукции и услуг, планирование бизнеса и управление им, а также коллективная работа (collaboration). Коллективная работа — это фактически процесс, который управляет другими бизнес-возможностями и координирует их. Он может выполняться вручную или автоматически, но обязательно должен управлять другими возможностями.

Пять общих базовых возможностей большинства предприятий — это разработка продукции и услуг, создание спроса, доставка продукции и услуг, планирование бизнеса и управление им, а также коллективная работа. Помимо этого, к базовым возможностям относятся производственные (operational capabilities) (т. е. доступные в рамках предприятия) и возможности внешней среды (environmental capabilities), предоставляемые людьми и организациями, находящимися за пределами предприятия. Это могут быть клиенты, партнеры, провайдеры сервисов и контролирующие органы. Они играют важную роль, поскольку могут влиять на то, как вы ведете свой бизнес.

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

Группы возможностей уровня 2

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

В следующем примере мы начинаем с базовой возможности 3 (доставка продукции и услуг) и демонстрируем иерархию возможностей на уровнях 3…n:

3. Доставка продукции и услуг

3.1 Предоставление услуг

3.2 Детальное планирование

3.3 Снабжение

3.3.1 Заключение контрактов с поставщиками

3.3.2 Закупки

3.3.2.1 Запрос ресурсов

3.3.2.2 Получение/приобретение ресурсов

3.3.2.3 Управление отношениями с поставщиками

3.3.3 Получение средств производства

3.4 Производство продукции

3.5 Логистика

Заметьте: возможности всегда помечаются как относящиеся к определенной родительской группе. Группа возможностей часто является важным начальным уровнем для анализа, поскольку на этом уровне можно сначала ввести абстрактные понятия ожидаемого уровня сервиса, препятствий и ограничений, а затем конкретизировать их.

Бизнес-возможности уровня 3

Далее группы возможностей разбиваются на бизнес-возможности (business capabilities). Сопоставляя модель возможностей (например, как на рис. 6) отдельным бизнес-возможностям, вы в конечном счете получаете вложенную иерархию таких возможностей. Возможности, располагающиеся на уровне 3 и ниже, — это структурные элементы, из которых строится модель.

Рис. 6. Базовые возможности, общие для большинства предприятий

Бизнес-возможности можно разбивать на более узкие бизнес-возможности, например, когда требуется более точно определить атрибуты. При анализе можно создать для одних бизнес-возможностей много уровней детализации (уровень 4 и ниже) и агрегировать другие бизнес-возможности на уровне 3. Как мы уже говорили, не обязательно приводить все возможности к одному уровню. В равной мере не обязательно моделировать весь свой бизнес. Вы можете выбрать области бизнеса таким образом, чтобы модель отвечала текущим бизнес-целям и требованиям проекта.

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

Вот некоторые основные атрибуты, необходимые, чтобы охарактеризовать каждую возможность.

• Кто ею владеет?
• Кто является заказчиком?
• Что имеется на входе и выходе?
• Каковы механизмы обработки исключений и уведомления об исключениях?
• Каковы требования к производительности (прежние, настоящие и будущие)?
• Оказывает ли производительность, связанная с данной возможностью, прямое влияние на производительность, связанную с родительской возможностью?
• Отделом?
• Всей организацией?
• Почему возможность именно такова?
• Причина в сотрудниках?
• Производственном процессе?
• ИТ?
• В сочетании этих факторов?
• Является ли эта возможность причиной, по которой клиенты, партнеры или поставщики работают с вашей организацией?

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

Бизнес-возможности можно разбивать на более узкие бизнес-возможности, например, когда требуется более точно определить атрибуты.

Сопоставление бизнес-возможностей сервисам

Одно из ключевых преимуществ подхода с моделированием возможностей в том, что он позволяет выявить постоянные элементы вашего бизнеса, на основе которых моделируется архитектура, и предоставляет критически важный уровень, точно соответствующий определению сервисов в архитектуре ваших подключенных систем. Можно определить границы между сервисами, например на уровне групп, и описать каждую возможность контрактом. Затем можно создать сервисы, выражающие эти контракты, и обеспечить управление возможностями, основанное на контрактах сервисов.

Рис. 7. Характеристики контракта, определяемые в модели сервисов

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

Методология Motion

Microsoft разработала Motion для построения карт возможностей — простую методологию, ориентированную на проекты. Motion — это методология организации, измерения и оценки бизнес-возможностей. Она основана на четырех элементах: средствах и мерах (measures), методологии описания (prescriptive methodology), методике сопоставления бизнес-возможностей и модели заявленных патентов, находящихся на рассмотрении (patent-pending model).

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

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

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

Ключ к пониманию того, почему Motion занимает особое место, — определение сопоставления возможностей и его отличий от сопоставления процессов. Ядро методологии Motion — архитектура возможностей, а не процессов. Сначала вы абстрагируетесь от процессов (и даже игнорируете их) и анализируете не процессы, а бизнес-возможности, тем самым формируя более постоянное представление о бизнесе, что особенно полезно с точки зрения контроля версий. В дальнейшем возможности становятся «строительными кирпичиками» процессов.

Главное преимущество единообразного и подробного документирования всех возможностей в том, что оно дает четкое представление об уровне сервиса, ожидаемом бизнесом от каждой бизнес-возможности.

Методология Motion выходит за рамки текущих подходов, многие из которых не поддерживают быстрые изменения, свойственные современному бизнесу. В отличие от них она разрабатывалась как методология проектирования бизнес-архитектур, способная решать текущие и будущие проблемы, с которыми сталкиваются предприятия, непрерывно взаимодействующие друг с другом.

В методологии Motion определено около 80 атрибутов, применяемых при документировании возможностей. Некоторые атрибуты перечислялись выше, когда речь шла о третьем уровне бизнес-возможностей.

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

Как работает Motion?

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

1. Определение контекста проекта Сначала документируются цели проекта, генерируется карта базовых возможностей, затем цели проекта сопоставляются карте базовых возможностей.

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

3. Создание архитектуры бизнеса На этом этапе происходит детализация, необходимая для создания архитектуры бизнеса.

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

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

Создание модели сервисов

Возникает вопрос: как преобразовать имеющуюся бизнес-модель в модель сервисов, которую вы в конечном итоге реализуете? Прежде чем рассмотреть подход, позволяющий это сделать, обсудим, какие элементы нужно определить для создания модели сервисов. (Еще раз вернитесь к табл. 1, чтобы вспомнить контекст.) Ключевые характеристики контракта, получаемые в результате анализа и проектирования, ориентированного на сервисы, и описываемые моделью сервисов, показаны на рис. 7. Заметьте: в модели сервисов нужно описывать только абстрактные характеристики (независимые от технологии). Транспорт и конечные точки определяются в технологической модели.

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

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

Чтобы выявить и документировать в модели сервисов описанные выше элементы, принципиально новые методики анализа не нужны. Вместо этого можно воспользоваться существующими методиками, например традиционным объектно-ориентированным анализом и проектированием (object-oriented analysis and design, OOAD). Однако его следует применить на другом уровне абстракции, поскольку нужно ориентироваться на сервисы, а не на объекты.

Создание моделей сервисов при использовании проектирования и анализа, ориентированного на сервисы (service-oriented analysis and design, SOAD), не требует принципиально новых методологий и подходов. Можно применить существующие методики, особенно те, которые имеют отношение к UML и традиционному OOAD. Но акценты нужно сместить. Вы должны отойти от образа мышления, при котором взаимодействие между объектами рассматривается как вызовы методов в стиле RPC, и перейти на взаимодействие между сервисами, основанное на обмене сообщениями. Тогда можно взять традиционный OOAD, основанный на UML, и применить его на бизнес-уровне, чтобы создать модель сервисов. Главное отличие SOAD от OOAD в том, что в SOAD процессы и сущности четко отделены друг от друга, чтобы сервисы не были связаны между собой. Отделенные сервисы более гибки и отражают реалии современного бизнеса.

Например, посмотрим, как применить традиционные UML-модели к анализу и проектированию, ориентированному на сервисы.

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

• Модель коллективной работы (collaboration model) дает хорошее представление о процессе, охватывающем задачи и операции. Это полезно при составлении требований к управлению.

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

• Компонентная модель, формируемая на ранних этапах, помогает сосредоточиться на функциональных проблемах и должна учитывать организационную структуру, владельцев и функции возможностей (сервисов). В ней содержится важная с точки зрения бизнеса информация о доступности, надежности и масштабируемости; эта модель полезна для определения SLE и SLA. Таким образом, применяя подход SOAD на практике, вы можете извлечь всю информацию, необходимую для построения модели сервисов: контракты и соглашения об уровне сервиса, основанные на ожидаемых уровнях сервиса, для каждой бизнес-возможности, а также требования к управлению сервисами. После создания детальной модели сервисов, построенной на основе бизнес-модели и близко ей соответствующей, самое время сопоставить модель сервисов технологической модели, которая определяет, как реализуется, размещается и развертывается каждый сервис.

Создание технологической модели

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

Технологическая модель включает следующие элементы.

Интерфейс сервиса Задает, как принимаются документы и сообщения. Он позволяет указать, какие транспорты будут использоваться независимо от реализации. Контракт сервиса может реализовываться более чем одним интерфейсом сервиса, но каждый интерфейс сервиса осуществляет только одну привязку, например SOAP поверх HTTP. При необходимости можно описать несколько интерфейсов сервиса, использующих разные транспорты. Так, можно связать один и тот же интерфейс и с транспортом Web-сервисов, и с транспортом очередей сообщений Windows. Каждый транспорт предоставляет свои возможности во взаимодействии и поддержке транзакций, равно как и налагает свои ограничения. В частности, очереди сообщений не поддерживают напрямую шаблон «запрос-ответ». Для поддержки взаимодействия и соответствия сервиса спецификации Web Services Interoperability Basic Profile (WS-I BP) версии 1.x сервис должен предоставлять хотя бы один интерфейс.

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

Хост сервиса Хост сервиса или реализации предоставляет конечную точку для интерфейсов сервиса. Выбирайте хост, исходя из требований SLA. Например, если бизнес-операции должны выполняться в режиме 24x7, нужно очень тщательно выбирать хост; при этом часто требуется применение технологий поддержки очередей, таких как Microsoft Message Queue или SQL Server Service Broker. В технологической модели хосты определяют стоимость решения. В бизнес-модели важны ожидаемые уровни сервиса. Сопоставляя хост соглашениям об уровне сервиса, задаваемым моделью сервисов, и в конечном счете уровню сервиса, ожидаемому бизнесом, можно рассчитать и обосновать стоимость данного хоста. Дополнительное преимущество перехода от изолированных приложений (silo-based applications) к сервисам заключается в том, что, если у вас имеется бизнес-возможность, требующая работы в режиме 24x7, можно перенести сервис для нее на хост, обеспечивающий достаточную производительность и избыточность. А для других возможностей — использовать менее дорогостоящие хосты. При применении изолированных приложений приходится выбирать один хост для всего приложения.

Управление сервисами Чтобы выполнять соглашение об уровне сервиса и принимать соответствующие меры, если его не удается соблюсти, предусматривайте средства мониторинга сервиса и управления им. Следует вести мониторинг интерфейсов, реализаций и хостов сервисов, например с помощью Windows Management Instrumentation (WMI). Для наблюдения за сервисами и управления ими можно применять Microsoft Operations Manager (MOM), а для поддержки изменений и управления конфигурацией в «пограничной» экосистеме сервиса — Microsoft Systems Management Server (SMS). Выбранный вами механизм управления (orchestration engine) также должен поддерживать мониторинг, как, например, BizTalk Server, содержащий средства Business Activity Monitoring (BAM). В будущем центральную роль в управлении ресурсами независимо от платформы хостинга и управления будет играть WS-Management.

Механизм управления Требования к управлению следует определять в модели сервисов так, чтобы они не зависели от платформы, но в конечном счете вам придется использовать определенный механизм управления. В технологической модели идентифицируется целевая платформа, например Microsoft BizTalk Server.

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

Современные подходы к созданию сервисов

Как, выяснив набор основных характеристик сервиса, определить их в коде и как структурировать этот код в Visual Studio 2005? Ключевой момент, который нужно учитывать, — необходимость разделения данных, сообщений, интерфейсов, внутренних элементов реализации и привязки к транспортам. На рис. 8 показан подход к сопоставлению решений и проектов Visual Studio 2005 с характеристиками сервисов. Заметьте: поля подстановки «xx» на рис. 8 представляют пространства имен, названия которых соответствуют имени сервиса, например OrderService.

Рекомендуется использовать для каждого сервиса один файл решения Visual Studio 2005, являющийся контейнером для нескольких проектов, показанных на рис. 8.

Вот эти проекты:

• xx.Data — содержит определения схемы данных, передаваемых по сети и получаемых из сущностей модели сервисов. Кроме того, содержит CLR-представление (common language runtime) этой схемы;

• xx.Messages — хранит определения входящих и исходящих сообщений, используемых при взаимодействии с сервисом. Сообщение представляется элементом схемы, содержащим элементы контракта для данных;

• xx.Interfaces — содержит определения интерфейсов;

• xx.ES и xx.WS — содержат конечные точки транспорта для интерфейсов. В данном примере xx.ES — проект, предоставляющий транспорт En ter-prise Services, а xx.WS — транспорт Web-сервисов;

• xx.Adapters и xx.Internals — содержат реализацию сервиса.

Адаптер, определенный в проекте xx.Adapters, обеспечивает уровень абстракции между интерфейсом и его внутренней реализацией. Адаптер анализирует поступающее сообщение и передает полученные данные о сущностях коду внутренней реализации. Кроме того, адаптер обертывает данные, выводимые реализацией, ответным сообщением. Заметьте: при таком подходе реализации ничего не известно о сообщениях, передаваемых через интерфейс, что позволяет изменять инфраструктуру обмена сообщениями, не влияя на внутреннюю реализацию сервиса. Конечная точка, показанная на рис. 8, относится только к развертыванию и зависит от выбранной вами привязки к транспорту. Например, при использовании транспорта Web-сервисов можно развернуть сервис на Web-сервере Internet Information Services (IIS), на котором выполняется ASP.NET.

Адаптер Ключевой компонент, позволяющий отделить реализацию от обмена сообщениями. Кроме того, это удобное место для преобразования сообщений (если в нем есть необходимость). Так, в адаптере можно преобразовать внешнее представление идентификатора клиента (например, 10 символов) во внутреннее (скажем, 12 цифр). Создавая новый адаптер для каждой версии своего сервиса, вы обеспечите такой контроль версий сервиса, при котором не оказывается влияние на реализации ранее опубликованных интерфейсов сервиса.

Контроль версий Здесь необходимо провести различие между контролем версий абстрактного или конкретного контракта и контролем версий внутренней реализации. Ключевая архитектурная цель — обеспечить независимый контроль версий этих двух элементов. Контракт состоит из данных, сообщений, интерфейса и конечных точек. Можно контролировать версии каждого из этих элементов независимо друг от друга, если вы спроектировали сервис так, чтобы каждый составляющий элемент относился к единственной версии элемента, в состав которого он входит. Например, контракт, описывающий сообщения, в состав которого входит контракт, описывающий данные, должен ссылаться лишь на одну версию контракта для данных. Это условие должно выполняться и для представления контракта средствами XSD/ WSDL, и для CLR-представления.

Чтобы осуществлять контроль версий контрактов для данных и сообщений, используйте политику управления версиями XML-данных и расширения. Можно контролировать версии интерфейсов, создавая новый интерфейс, производный от предыдущего интерфейса (для CLR), но сопоставленный новому типу WSDL-порта.

Шесть этапов разработки сервисов

В настоящее время, чтобы реализовать описанные выше принципы в проектах для Visual Studio 2005 и получить сервисы, основанные на этом подходе, нужно пройти следующие шесть этапов.

1. Разработать контракт для данных и сообщений.
2. Спроектировать контракт сервиса.
3. Создать адаптеры.
4. Реализовать внутренний уровень сервисов.
5. Связать этот внутренний уровень с адаптерами.
6. Создать транспортные интерфейсы.
   

Этап 1

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

Для создания своих схем данных и классов данных можно использовать два подхода. При первом подходе сначала создается схема: вы формируете XSD-схему и автоматически генерируете классы данных утилитой вроде Xsd.exe или XsdObjectGen.exe. Если вам больше нравится подход, при котором сначала создается код, можете определить свои классы данных на C# или Visual Basic, а затем с помощью Xsd.exe создать эквивалентную XSD-схему. В следующем примере показан контракт для данных.

namespace DataContracts {

[Serializable]

[XmlType("Order", Namespace="urn.

contoso.data/order")]

public partial class Order

{

[XMlElement("Customer")] public Customer customerField; [XMlElement("Items")] public OrderItemsList ordersItemsField;

}

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

Рис. 8. Сопоставление характеристик сервиса проектам Visual Studio 2005

PlaceOrder содержит Order в своей полезной информации.

namespace MessageContracts { using System.Xml; using System.Xml.Serialization; using DataContracts; [Serializable] [XmlType(Namespace="urn.contoso.

msgs/orderservice")] [XmlRoot(Namespace="urn.contoso.

msgs/orderservice"] public class PlaceOrder { [XmlElement("Order")] public Order order; } }

Этап 2

На этом этапе определяют абстрактный контракт сервиса — с помощью подхода, при котором сначала создается WSDL-описание, или определяя интерфейсы на C# или Visual Basic. Ваши интерфейсы определяют, какие сообщения принимают ваши сервисы и, возможно, какие сообщения они возвращают. Чтобы сгенерировать интерфейс по WSDL-описанию, запустите Wsdl.exe с ключом /si: Wsdl.exe xx.wsdl /si

Заметьте, что это работает только в Mic ro soft .NET Framework 2.0.

В следующем примере определен интерфейс для сервиса, работающего с заказами. Интерфейс содержит единственный метод PlaceOrder, который принимает сообщение PlaceOrder и возвращает сообщение

OrderTracking. namespace Interfaces {

using MessageContracts;

public interface IOrderService { OrderTracking

PlaceOrder(PlaceOrder placeOrderMsg); } }

В данном случае используется интерфейс «запрос-ответ», поэтому время обработки сообщения (время между получением запроса и отправкой ответа) не должно превышать примерно секунды. Если гарантировать это нельзя, примените другой шаблон обмена сообщениями, скажем, дуплексный обмен, при котором два сообщения, отправляемые в каждом направлении, согласовываются и таким образом реализуется логический шаблон «запрос-ответ».

Чтобы сгенерировать WSDL для приведенного выше интерфейса, можно создать ASMX-файл Web-сервиса, а затем вызвать Web-сервис с параметром ?WSDL, например http://localhost/OrderService/OrderService.asmx?wsdl. Тогда Web-сервис сгенерирует и возвратит WSDL-описание.

Этап 3

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

В следующем коде приведен пример адаптера.

namespace Adapters {

using MessageContracts;

using ServiceInterfaces;

public class OSA : IOrderService {

public virtual TrackingOrder PlaceOrder(PlaceOrder PlaceOrderMsg) { // Вызов внутренней реализации ... } } }

Заметьте, что адаптер всегда находится внутри вызывающего процесса, а идентификация процесса зависит от того, какой хост вы выбрали. Если хостом для внутренней реализации служит IIS, экземпляр внутренней реализации сервиса создается ASMX-интерфейсом (находящимся на «границе»). Если хостом для внутренней реализации служит Enterprise Services, но вызовы поступают через Web-сервис ASMX, то ASMX-ин-терфейс делегирует вызов интерфейсу Enterprise Services, который создает экземпляр адаптера и передает ему сообщение. Поскольку все транспорты реализуют один и тот же интерфейс, вызовы можно передавать по цепочке.

Этап 4

На этом этапе создается внутренняя реализация сервиса. Существует только одна реализация независимо от того, сколько транспортов вы используете. В следующем фрагменте кода показан каркас реализации сервиса, обрабатывающего заказы.

namespace BusinessLogic {

public class OSI

{ public static string AcceptOrder

(DataContracts.Order order) {

// Обработка данных заказа ...

return "XYZ"; }

} }

Обратите внимание: внутренней реализации ничего не известно о формате сообщений. Ей известен лишь контракт для данных. В рассматриваемом примере данные передаются в единственном объекте Order. Если вы хотите полностью исключить зависимость от формата данных, передаваемых по сети, внутренняя реализация вообще не должна иметь доступа к контракту для данных. Тогда адаптер сопоставляет внешний контракт для данных внутренним типам данных.

Этап 5

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

namespace Adapters {

using MessageContracts;

using ServiceInterfaces;

public class OSA : IOrderService { public virtual TrackingOrder PlaceOrder(PlaceOrder PlaceOrderMsg) { TrackingOrder to = new

TrackingOrder(); to.TrackingId = BusinessLogic. OSI.AcceptOrder( PlaceOrderMsg.Order); return to; } } }

Этап 6

На этом этапе абстрактные интерфейсы сервисов, определенные на этапе 2, привязываются к определенному транспорту. Следующий фрагмент кода демонстрирует привязку интерфейса IOr der Service, определенного на этапе 2, к транспорту Web-сервисов.

namespace Endpoints.WS {

using System;

using System.Diagnostics;

using System.Web.Services;

using System.ComponentModel;

using System.Web.Services. Protocols;

using System.Web.Services. Description;

using System.Xml.Serialization;

using MessageContracts;

using ServiceInterfaces;

using Adapters;

[WebService(Namespace="urn. contoso.interfaces/ orderservice")] public class OrderService : System.Web.Services. WebService, IOrderService { [WebMethod] [SoapDocumentMethod (ParameterStyle= SoapParameterStyle.Bare)]

public TrackingOrder PlaceOrder(PlaceOrder PlaceOrderMsg) {

IOrderService adapter = new

OSA(); return adapter.PlaceOrder (PlaceOrderMsg); } } }

Средства автоматизации проектирования и разработки

Применяя шестиэтапный процесс, рассмотренный выше, можно разработать сервисы, удовлетворяющие всем требованиям и принципам, о которых говорилось ранее. Однако, поскольку все элементы, используемые в этом процессе, можно описать метаданными, есть возможность автоматизировать крупные этапы генерации сервиса. Для этого можно воспользоваться инструментальными средствами, подобными Guidance Automation Toolkit (GAT). Средства автоматизированного проектирования и разработки процессов особенно полезны в следующих случаях:

• при преобразовании между семантически идентичными элементами XML и CLR, например XSD и классами CLR;
• при преобразовании между типами портов WSDL и интерфейсами CLR;
• при генерации адаптеров по описаниям интерфейсов;
• при генерации конечных точек по описаниям интерфейсов.
  

Заключение

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

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

Подключенные системы — примеры реализации данной трехуровневой модели, которые соответствуют четырем принципам проектирования, ориентированного на сервисы. Для более полной их реализации можно воспользоваться пятью «столпами» технологий платформы Microsoft. Вспомните вопросы, которые мы задавали в начале статьи.

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

Проектирование Web-сервисов на основе SOA — лишь одна из реализаций данной модели. Это качественная и обоснованная модель, дающая ответ на все эти вопросы.