Модель программирования SOA для реализации Web-сервисов, Часть 1: Введение в модель программирования SOA

Модель программирования IBM® для сервис-ориентированной архитектуры (SOA) позволяет программистам, не обладающими особыми навыками в IT-сфере создавать и повторно использовать IT-средства. Модель включает в себя типы компонентов, схемы соединений, шаблоны, адаптеры приложений, единое представление данных и Enterprise Service Bus (ESB). Эта первая статья из серии статей о модели программирования IBM SOA. В ней также рассказывается о том, что необходимо для выбора, разработки и размещения приложений и рекомендуются различные элементы модели программирования. Содержимое статьи подразумевает что разработчики, решившие воспользоваться данной моделью, обладают различными навыками и выполняют разные роли.

Дональд Фергюсон (Donald F. Ferguson), Ведущий архитектор, IBM Fellow and Software Group, IBM

Дональд Фергюсон (Donald F. Ferguson), доктор философии, является одним 55 действительных членов IBM, занимающих самый высокий технический пост в инженерном сообществе IBM, состоящем из 200 000 профессионалов. Дональд является ведущим архитектором и техническим лидером семейства продуктов IBM Software Group, которое включает в себя Lotus®, Rational®, WebSphere, DB2 и Tivoli®. Он возглавляет SWG Architecture Board, объединяющую ведущих архитекторов продукта SWG. Его последние работы были связаны с Web-сервисами, управлением бизнес-процессами, клиентскими платформами, платформами аутсорсинга/хостинга, Grid-сервисами и разработкой приложений для WebSphere. Дональд был ведущим архитектором семейства продуктов WebSphere от начала их разработки до перехода на пост ведущего архитектора SWG в 2003 году. Связаться с Дональдом можно по адресу: dff@us.ibm.com.



Mарша Стоктон (Marcia Stockton), Старший член технического совета, Software Group Programming Model Workgroup, IBM

Марша Стоктон (Marcia L. Stockton) является ведущим штатным техническим сотрудником и главным изобретателем в IBM Software Group в Research Triangle Park, шт.Северная Каролина (проживает в Калифорнии). Она является также старшим членом IEEE. Марша возглавляет рабочую группу Software Group Architecture Board's Programming Model Workgroup, где управляет инициативами горизонтальной интеграции и занимается продвижением упрощения программной модели между продуктами Lotus, Rational, WebSphere, DB2 и Tivoli. Является автором 73-х запатентованных в США разработок в областях сетевого обеспечения, Web, безопасности, защиты информации, мультимедиа, беспроводной связи, проникающих устройств, идентификации радиочастот. До недавнего времени возглавляла работы по определению архитектуры для управления идентичностями для распределенного программирования краевого сервера. Вступила в IBM в 1988 году после пяти лет разработки сетевого программного обеспечения. В 1975 году получила степень Бакалавра гуманитарных наук в Суортморском колледже. Связаться с ней можно по адресу: mls@us.ibm.com.



14.06.2005

Серия статей о модели программирования SOA

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


Введение

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

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

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


Возможности модели программирования SOA

Начнем с выделения некоторых основных возможностей модели программирования SOA.

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

Модели программирования SOA требованием является единый принцип создания и получения доступа к бизнес-логике. Для простоты потребляемости сервис должен скрывать различия в технологиях реализации и быть на более высоком уровне абстракции, чем существующие программные конструкции, такие как Enterprise Java™Beans (EJBs). Считается, что сервисы могут быть реализованы при помощи компонентов, собранных в модули, которые в свою очередь могут быть собраны в решения. Компоненты раскрывают сервисы, которые могут быть вызваны с использованием адресуемых интерфейсов. Для описания интерфейсов можно использовать WSDL (Web Services Description Language - язык описания Web-сервисов), Java или другие языки. Такой стиль реализации может иметь неразрешенные ссылки для требуемых сервисов, которые перед выполнением будут удовлетворены путем связывания компонентов воедино.

Кроме всего прочего программная модель представляет хорошо структурированные типы компонентов для общих видов артефактов, которые разработчики производят и размещают в решения. В качестве примеров можно привести "Plain old Java objects" (POJO), процессы Business Process Execution Language (BPEL), SQL-сервисы, Adaptive Business Objects, программы CICS® получающие доступ через адаптеры ресурсов Java Connector Architecture (J2C), приложения, использующие интерфейс программирования бизнеса SAP, Java 2 Enterprise Edition (J2EE) сессионные компоненты без состояния и приложения MQSeries®.

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

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

Еще одна метафора программирования - business state machine, которую может создать бизнес-аналитик при помощи графических инструментов, выполняется при помощи механизма процесса хореографии. State machine может предоставлять такие бизнес-артефакты, как заказ на поставку, страховое требование и т.д. Эти артефакты проходят через несколько четко оформленных состояний, отвечающих определенным событиям «жизненного цикла».

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

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

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


Концепция модели программирования

Модель программирования является центральной в IBM SOA, и в продуктах IBM вообще. Она определяет концепции и абстракции, которые создают и используют разработчики. Продукты рабочего цикла, такие как WebSphere® Application Server, DB2® и CICS, выполняют или содержат артефакты (искусственно созданные элементы) программной модели. Инструменты разработчика поддерживают моделирование и реализацию артефактов модели программирования, их сборку в приложения (решения) и размещение в рабочие циклы. И, наконец, продукты управления системой, агенты и инструментальные средства поддерживают администрирование рабочих циклов и артефактов модели программирования, которые они содержат.

Что такое модель программирования? Общепринятого определения не существует, однако мы определим этот термин следующим образом:

  • Набор сущностей, с которыми работают программисты. Под сущностями подразумеваются разнообразные артефакты модели программирования: HTML-файлы, хранимые в БД процедуры, Java-классы, XSD-схемы, C-структуры, определяющие MQSeries-сообщения и так далее.
  • Набор ролей, которые группируют разработчиков и членов административного сообщества, имеющих сходные навыки и знания. Подобная классификация разработчиков позволяет производить инструменты, соответствующие ролям, что позволяет не программистам реализовывать сервисы и собирать из них решения. Бизнес-аналитик определяет бизнес-процессы, а маркетолог определяет правила, классифицирующие пользователей и вычисляющие скидку на продукты – вот иллюстрация новых типов разработчиков. Каждая роль содержит:
    • Навыки, которыми обладает роль. К примеру, разработчик пользовательского интерфейса создает интерфейсы, представляющие функциональные артефакты приложения или решения. Такая роль подразумевает знание разрабатываемого приложения и его бизнес-целей для полного понимания пользователей приложений и их задач. Необходимо также быть экспертом в нескольких методах проектирования пользовательских интерфейсов, а также быть способным создавать простые в использовании пользовательские интерфейсы, выбирая для каждой задачи ее правильный тип.
    • Используемые сущности и интерфейсы приложения, с которыми взаимодействуют роли (потребляют или производят). К примеру, дизайнеры динамических страниц (роль) создают JSP-страницы и используют EJB-компоненты (сущности), которые упаковывают существующие источники информации и приложения.
    • Инструменты, используемые ролью. К примеру, инструментом Web-разработчика будет WYSIWYG-редактор для написания динамических страниц, в котором имеются инструменты для создания HTML и JSP тегов и осуществления контроля над EJB-компонентами.

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

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


Архитектура продукта

Рисунок 1. Архитектура продукта
Архитектура продукта

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

В основе лежит ESB, осуществляющий соединение между сервисами. ESB является многопротокольным, поддерживает двухточечный стиль связи, а также стиль публикация-подписка. Кроме того, он поддерживает посреднические сервисы, обрабатывающие сообщения “на лету”. IBM WebSphere MQ, IBM WebSphere MQ Integrator Broker и WebSphere поддерживают Web-сервисы, а JMS находятся в первой категории.

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

Таблица 1. Контейнеры, содержащие различные компоненты и типы сервисов
Тип компонента/сервисаКонтейнер
Программы транзакций написанные на COBOL, PL/1 и других языкахCICS или IMS (Information Management System – система обработки транзакций предприятия). Для доступа к сервисам программисты могут использовать соединения SOAP/HTTP, WebSphere MQ и J2EE J2C.
Хореография бизнес-процессаWebSphere Business Integration Server Foundation. Этот контейнер поддерживает процессы долговечного потока, реализующего интерфейсы Web-сервиса и вызывающего операции в других Web-сервисах. Он также поддерживает долготекущие транзакции бизнес-деятельности.
Адаптеры приложений – обеспечивающие фасад SOA/Web-сервиса для существующих приложений и системКонтейнер адаптера приложения предоставленный WebSphere Business Integration Server Foundation. Адаптер осуществляет конвертацию между протоколами и форматами SOA и существующими приложениями и системами. К примеру, адаптер для SAP преобразовывает из закодированного в SOA XML-over-Hypertext Transport Protocol в форматы программного интерфейса существующего бизнес-приложения и RFC.
Сервисы, реализованные путем выполнения предустановленных SQL-запросов, XML-запросов или хранимых процедур.DB2 в соединении с сервером приложения WebSphere. Параметры для запроса поступают от входящего сообщения операции SOA, а результат обеспечивает исходящее сообщение.
Сервисы, реализованные при помощи Java-классов и EJBs.Сервер приложения WebSphere.

Резюме

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

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

  • Упрощенный доступ к данным с использованием SDO
  • Определение сервиса и введение в развивающуюся модель компонента
  • Типы компонентов для упрощения процесса разработки
  • Основные типы компонентов
  • Построение и настройка сервиса
  • Компоненты процесса: BPEL и business state machines
  • Настройка сервисов: шаблоны проектирования, шаблоны и переменные значения
  • Сервис-ориентированные пользовательские интерфейсы
  • SOA-подход к управлению
  • Инструменты разработки жизненного цикла программного обеспечения SOA
  • Безопасность в SOA

Ресурсы

  • Оригинал статьи SOA programming model for implementing Web services, Part 1: Introduction to the IBM SOA programming model
  • Спецификация Java Message Service в ее различных итерациях.
  • В статье J2EE Connector architecture предоставлено решение Java-технологии для задачи взаимодействия между множественными серверами приложений и соверменными корпоративными информационными системами.
  • Руководство на сайте IBM developerWorks Introduction to the J2EE Connector Architecture, в котором дается прекрасный обзор архитектуры Коннектора J2EE.
  • Посетите книжный магазин Developer Bookstore, где вы найдете обширный список технической литературы, включая сотни трудов по Web-сервисам.
  • Станьте членом сообщества developerWorks, приняв участие в блогах developerWorks.
  • Сотни информационных и вводных статей, руководств для начинающих и продвинутых пользователей на тему разработки приложений Web-сервисов находятся на сайте developerWorks в разделе SOA and Web services.

Комментарии

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-сервисы, XML
ArticleID=96767
ArticleTitle=Модель программирования SOA для реализации Web-сервисов, Часть 1: Введение в модель программирования SOA
publish-date=06142005