Советы по программированию Web-сервисов: Сервис-ориентированное моделирование и архитектура

Как определять, задавать и реализовывать сервисы для вашей SOA

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

Ali Arsanjani, Ph.D., Ведущий архитектор, SOA and Web services Center of Excellence, IBM

Доктор Ali Arsanjani является Ведущим Архитектором центра SOA and Web Services Center of Excellence в подразделении IBM Global Services. Обладает 21-летним стажем в IT-индустрии, разработке и производстве распределенных архитектур приложений для крупных систем. Область его исследований и публикаций включает в себя модели проектирования ПО, архитектуру ПО, сервис-ориентированные архитектуры, архитектуры, основанные на компонентах, а также грамматически-ориентированный дизайн объектов. Специализируется на построении динамически перенастраиваемых систем ПО. Вы можете связаться с ним по адресу arsanjan@us.ibm.com.



09.11.2004

Введение

В последнее время вокруг возможностей, предлагаемых Сервис-Ориентированными Архитектурами (Service-oriented Architectures (SOA)) и их реализаций в виде Web-сервисов было много шума и активной рекламы. Аналитики высказывали предположения, эксперты выражали свое мнение, преподаватели читали лекции на эту тему, а компании активно пытались продать то, что у них есть, как продукты SOA. Во всем этом часто упускался тот факт, что SOA вообще не является продуктом. Речь идет о заполнении пространства между бизнесом и IT при помощи набора IT-сервисов, ориентированных на бизнес, и использующих набор принципов построения, шаблонов и методов.

В издании ZDNet недавно прозвучало буквально следующее: "Гартнер предположил, что к 2008 году более 60% корпораций будет использовать SOA в качестве "руководящего принципа" при создании критически важных приложений и процессов."

К разработке и реализации SOA предъявляются огромные требования. Если архитектура SOA складывается не только из продуктов и стандартов, помогающих ее реализовать (к примеру, через Web-сервисы), то какие дополнительные элементы необходимы для ее реализации? Сервис-ориентированное моделирование требует проведения дополнительных мероприятий и наличия артефактов, которые не присутствуют в традиционном Объектно-Ориентированном Анализе и Проектировании (object-oriented analysis and design - OOAD). Статья “Elements of Service-oriented Analysis and Design” описывает некоторые причины, по которым вам необходимо нечто большее, чем OOAD. В ней также говорится, что управление бизнес-процессом или архитектурой предприятия (EA) и OOAD недостаточно соответствуют процессу проведения анализа и проектирования. В дополнение к вышесказанному, в справочнике IBM “Patterns: Service-Oriented Architecture and Web Services" раскрываются основные действия подхода сервис-ориентированного моделирования.

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

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

Все это является незначительным шагом от использования обычных "распределенных объектов". Речь идет о выгоде использования сетевых средств: к примеру, когда стороны используют комбинацию поисковых сервисов Amazon.com и Google, и совмещают их с сервисами eBay для построения собственных гибридных решений. Или, к примеру, когда агентство путешествий использует систему бронирования авиабилетов, координирует ее с информацией о ренте автомобилей и бронированием номеров в отеле, обновляет свои записи и отправляет планируемую карту маршрута в ваш органайзер. Независимо от приложения, для успешного создания SOA вам необходимы не просто хорошие инструменты и стандартны, а нечто большее. Вам необходимы некие перспективные шаги для поддержания жизненного цикла вашей SOA – методики для анализа, проектирования и реализации сервисов, потоков и компонентов. Таким образом, всем, заинтересованным в разработке корпоративного приложения, необходимо четко понимать все подробные шаги в сервис-ориентированном моделировании и архитектуре.

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


Сервис-Ориентированная Архитектура: концептуальная модель

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

Метамодель, представляющая эти отношения отображена на Рисунке 1.

Рисунок 1: Концептуальная модель архитектурного стиля SOA
Концептуальная модель архитектурного стиля SOA

Архитектурный стиль и основные принципы

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

Архитектура SOA является масштабируемой IT-архитектурой на уровне предприятия для соединения ресурсов по требованию. В архитектуре SOA ресурсы доступны для участников предприятия, линии бизнеса и т.д. (обычно путем распространения множества приложений в предприятии или между несколькими предприятиями). Она состоит из набора бизнес-ориентированных IT-сервисов, которые коллективно удовлетворяют задачам и бизнес-процессам организации. Эти сервисы можно группировать в композитные приложения и вызывать их через стандартные протоколы, как показано на Рисунке 2.

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

Рисунок 2: Атрибуты SOA
Атрибуты SOA

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

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


Контекст

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

Вначале рассмотрим то, что нам предстоит спроектировать, а именно – SOA и ее уровни. Затем мы опишем, как построить SOA, обсуждая основные действия и методики, необходимые для ее создания.

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

Для перенесения на SOA нам необходимы некоторые дополнительные элементы, выходящие за пределы сервисного моделирования:

  • Модели выбора и готовности. Насколько созрело ваше предприятие для перехода на архитектуру SOA и Web-сервисы? Каждый уровень готовности имеет свои требования.
  • Общая оценка. Есть ли у вас планы? Хорошо ли вы знакомы с Web-сервисами? Насколько хороша ваша архитектура? Следует ли вам идти в том же направлении? Подойдет ли вашей задаче корпоративная архитектура SOA? Решили ли вы все свои вопросы и задачи?
  • Определение стратегии и планирование. Как вы планируете осуществить переход на SOA? Какие шаги, инструменты, методики, технологии, стандарты и приготовления вам следует принять во внимание? Каков ваш план и видение, как вы собираетесь достичь цели?
  • Управление. Должен ли существующий API или возможность стать сервисом? Если нет, то что является приемлемым? Каждый сервис должен быть создан с целью принесения бизнесу некой выгоды. Как вы будете управлять этим процессом без точной стратегии?
  • Реализация лучших способов. Какие из проверенных способов реализации безопасности, производительности и соответствия стандартам обеспечения совместимости нужно изменить?

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

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


Архитектурный шаблон для SOA

Абстрактный взгляд на SOA изображает ее как частично многоуровневую архитектуру композитных (составных) сервисов, выверенных с бизнес-процессами. На Рисунке 3 отображается представление такого типа архитектуры.

Отношения между сервисами и компонентами заключаются в том, что компоненты уровня предприятия (разветвленные компоненты предприятия или бизнес-линии) реализуют сервисы и несут ответственность за обеспечение их функциональности и качества обслуживания. Потоки бизнес-процессов могут опираться на то, что я называю хореографией (объединением) раскрытых сервисов в композитные (составные) приложения. Архитектура интеграции поддерживает маршрутизацию, посредничество и трансляцию этих сервисов, компонентов и потоков с использованием корпоративной сервисной шины (Enterprise Service Bus - ESB). Развернутые сервисы должны контролироваться и управляться для обеспечения качества сервиса и строгого соблюдения не функциональных требований.

Рисунок 3: Уровни SOA
Уровни SOA

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

Вот как примерно выглядит макет документа, описывающий архитектуру SOA:

  1. Область действия <Для какой области предприятия предназначена архитектура?>
  2. Уровень операционной системы
    1. Упакованные приложения
    2. Заказные приложения
    3. Архитектурные решения
  3. Уровень корпоративных компонентов
    1. Функциональные области, поддерживаемые данными корпоративными компонентами
    2. <Какие области интересов бизнеса, задачи и процессы поддерживаются данными корпоративными компонентами>
    3. Решения по управлению
      1. <Критерий, по которому выбираются корпоративные компоненты в данной организации клиента>
    4. Архитектурные решения
  4. Уровень сервисов
    1. Классифицированное портфолио сервисов
    2. Архитектурные решения
  5. Бизнес процесс и составной уровень
    1. Бизнес-процессы, представленные как совокупность действий
    2. Архитектурные решения
      1. <Какие процессы необходимо связать в совокупность действий, а из каких создать приложение?>
  6. Уровень обеспечения доступа или презентации
    1. <Включение на этом уровне документов по Web-сервисам и SOA, если таковые существуют. К примеру, использование портлетов для вызова Web-сервисов на уровне пользовательского интерфейса и включение функциональности на данном уровне>
  7. Уровень интеграции
    1. <Включение рассмотрения использования ESB>
    2. <Как следует придерживаться требуемых соглашений об уровне услуг (SLAs) и качестве обслуживания (QoS) предоставляемого сервиса>
    3. Вопросы обеспечения безопасности и их решения
    4. Вопросы обеспечения производительности и их решения
    5. Вопросы ограничений в технологии и стандартах и их решение
    6. Контроль и управление сервисами
      1. Описание и предлагаемые решения

Теперь опишем уровни более детально и обсудим строение каждого из них.

Уровень 1: Уровень операционной системы. Состоит из существующих заказных приложений, называемых также унаследованными системами. Включает в себя существующие упакованные приложения системы управления взаимосвязями (CRM) и планирования ресурсов предприятия (ERP), а также ранние объектно-ориентированные реализации системы, а заодно и приложения для управления бизнесом. Многоуровневая архитектура SOA может помочь улучшить уже существующие системы и способствовать их интеграции с использованием сервис-ориентированных методов.

Уровень 2: Уровень корпоративных компонентов. Корпоративные компоненты несут ответственность за обеспечение функциональности и поддержание качества обслуживания (QoS) сервисов. Эти компоненты являются управляемым, регулируемым набором корпоративных средств которые расположены на уровне корпоративной или бизнес-единицы. Как средства корпоративного масштаба, они несут ответственность за обеспечение соответствия соглашениям об уровне услуг (SLA) путем применения лучших методов проектирования. Для реализации компонентов, управления рабочей нагрузкой, отказоустойчивостью и балансирования нагрузки данный уровень обычно использует такие технологии, основанные на использовании контейнеров, как серверы приложений.

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

Уровень 4: Уровень объединения (хореографии) бизнес процессов. В этом уровне определяется способы объединения сервисов, определенных в Уровне 3. Сервисы связаны в поток путем группировки (хореографии) и, следовательно, они действуют совместно как отдельное приложение. Подобные приложения поддерживают особые ситуации и бизнес-процессы. Здесь для проектирования потоков приложения могут использоваться такие визуальные инструменты компоновки, как IBM® WebSphere® Business Integration Modeler или Websphere Application Developer Integration Edition.

Уровень 5: Уровень доступа или презентации. Несмотря на то, что этот уровень обычно упускается при обсуждении SOA, постепенно он становится все более значимым. Здесь он изображен по причине возрастающей конвергенция стандартов, таких как Web Services for Remote Portlets Version 2.0 и других технологий, стремящихся вывести Web-сервисы на уровень интерфейса приложения или презентации. Этот уровень можно представить как уровень, который необходимо принять во внимание в последующих разработках. Важно также обратить внимание на то, что SOA отделяет пользовательский интерфейс от компонентов, и в качестве альтернативы вам может потребоваться обеспечение сквозного решения между каналом доступа и сервисом или набором сервисов.

Уровень 6: Интеграция (ESB). Этот уровень допускает интеграцию сервисов путем представления проверенного набора таких возможностей, как интеллектуальная маршрутизация, посредничество протоколов и других механизмов преобразований, обычно описанных как ESB (см. Ссылки). Язык описания Web-сервисов (WSDL) определяет связь, которая заключает в себе местонахождение предоставляемого сервиса. С другой стороны, ESB для интеграции обеспечивает механизм, независимый от местонахождения.

Уровень 7: Качество обслуживания (QoS). Этот уровень предоставляет возможности для мониторинга, управления и поддержки таких аспектов качества обслуживания, как обеспечение безопасности, производительности и доступности. Он является фоновым процессом, использующим механизмы запросов и ответов, и инструменты, контролирующие общее состояние приложений SOA. Сюда включены все важные стандартные реализации WS-Management и других значимых протоколов и стандартов, реализующих качество обслуживания для SOA.


Как подойти к сервисно-ориентированному моделированию и архитектуре

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

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

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

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

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

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


Сервис-ориентированное моделирование: анализ и проектирование сервисов

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

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

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

Рисунок 4: Мероприятия по обеспечению сервис-ориентированного моделирования
Мероприятия по обеспечению сервис-ориентированного моделирования

На Рисунке 4 представлены мероприятия, обычно проводимые со стороны потребителя и поставщика. Обратите внимание, что мероприятия поставщика является расширенным набором мероприятий потребителя. К примеру, поставщик также как и потребитель будет вовлечен в идентификацию сервиса, его категоризацию и т.д. Во многих случаях, разграничение ролей происходит по причине того, что поставщики сами определяют необходимые для них сервисы (обычно путем их поиска). После того, как потребитель будет уверен в соответствии спецификаций искомого сервиса со спецификацией сервиса, предоставляемого поставщиком, он может вызвать необходимый сервис. Поставщику, в данном случае, необходимо опубликовать сервисы, которые он желает поддерживать, как с позиций функциональности, так и с позиций обеспечения требуемого качества обслуживания (QoS). Это неявно выраженное соглашение между поставщиком и потребителем могло бы сформироваться в явно выраженные условия соглашений об уровне услуг (SLA), установленные или электронным способом или путем подписания юридических документов.

Мероприятия, описанные выше, можно отобразить в виде потоков в сервис-ориентированном моделировании и архитектурном методе, как это показано на Рисунке 5.

Рисунок 5: Метод сервис-ориентированного моделирования и архитектуры
Метод сервис-ориентированного моделирования и архитектуры

Процесс сервис-ориентированного моделирования и построения архитектуры состоит из трех основных шагов: идентификации, спецификации и реализации сервисов, компонентов и потоков (обычно путем объединения сервисов).

Идентификация сервиса

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

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

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

Классификация или категоризация сервиса

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

Анализ подсистемы

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

Спецификация компонента

В этом важном мероприятии определяются следующие детали компонента, реализующего сервисы:

  • Данные
  • Правила
  • Сервисы
  • Настраиваемый профиль
  • Вариации

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

Размещение сервиса

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

  • Медиаторами
  • Фасадами
  • Объектами Rule
  • Настраиваемыми профилями
  • Фэктори

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

Реализация сервиса

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

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

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


Заключение

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

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

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

Благодарности

Автор выражает глубокую признательность в помощи при написании статьи своим уважаемым коллегам и друзьям: Luba Cherbakov, Kerrie Holley, George Galambos, Sugandh Mehta, David Janson, Shankar Kalyana, Ed Calunzinski, Abdul Allam, Peter Holm, Krishnan Ramachandran, Jenny Ang, Jonathan Adams, Sunil Dube, Ralph Wiest, Olaf Zimmerman, Emily Plachy, Kathy Yglesias-Reece, David Mott.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=SOA и web-сервисы
ArticleID=96339
ArticleTitle=Советы по программированию Web-сервисов: Сервис-ориентированное моделирование и архитектура
publish-date=11092004