Значение IBM System z и z/OS в сервис-ориентированной архитектуре: Глава 4. Воплощение SOA в среде z/OS

Страница 1 из 4  Опции документа Обсудить Выскажите мнение об этом учебном пособии Помогите нам улучшить содержание

Уровень сложности: средний

Алекс Лоув Койманс, руководитель проектов, Международная организация технической поддержки (ITSO) в Центре Паукипси
Ник де-Грееф, старший ИТ-архитектор, Международная организация технической поддержки (ITSO) в Центре Паукипси
Даниэль Райш, старший сертифицированный ИТ-архитектор, Международная организация технической поддержки (ITSO) в Центре Паукипси
Эран Йона, ИТ-архитектор, Международная организация технической поддержки (ITSO) в Центре Паукипси

17.09.2009

Первое издание (август 2006). Данное руководство касается WebSphere Application Server for z/OS Version 6.02, WebSphere Message Broker V6.0 for z/OS, WebSphere Process V6 for z/OS, WebSphere ESB V6 for z/OS, CICS Transaction Server V3.1, CICS Transaction Gateway V5 и V6, DB2 UDB for z/OS V8, IMS Transaction Manager, IMS Connect. Документ создан или модифицирован 5 сентября 2006 года.

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

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

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

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

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

4.1 Стратегии построения информационных систем

Существуют два основных методологических подхода к ориентации информационных систем на сервисы: восходящий и нисходящий.

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

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

В начало

4.1.1 Золотая середина

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

Как правило, справедливы следующие утверждения:

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

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

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

В начало

4.2 Эволюция в направлении SOA

На рис. 4-2 показано эволюционное преобразование имеющейся ИТ-среды в модель SOA.

Многие предприятия используют мэйнфреймы для обеспечения работы критически важных бизнес-приложений. На разработку этих программ израсходованы большие средства. Большая часть бизнес-транзаций во всем мире выполняется приложениями CICS, IMS и DB2. Весьма желательно, чтобы эти приложения можно было использовать при реализации модели сервис-ориентированной архитектуры.

Этапы процесса:

1. Идентификация имеющихся ИТ-ресурсов.
   На этом этапе создаются репозитории приложений, а имеющаяся функциональность анализируется на предмет возможности многократного использования в форме сервиса.
2. Создание сервисов на основе имеющихся задач.
   После того как выделена функциональность, представляющая многократно используемую бизнес-логику, она может быть представлена в виде сервисов.
3. Наделение сервисов функциональностью SOAP.
   После того как сервисы созданы, они готовы к использованию внешними потребителями, однако может потребоваться возможность вызывать одни сервисы из других. Для этого необходима поддержка SOAP.
4. Интеграция поверх Web-сервисов.
   На данный момент сервисы готовы к интеграции и взаимодействию с другими сервисами по технологии Web-сервисов, например с помощью протокола SOAP. SOAP может быть реализован поверх HTTP или JMS с помощью промежуточного ПО управления сообщениями, такого как WebSphere MQ.
5. Создание ESB.
   Чтобы обеспечить поддержку растущего числа запросов, сохраняя гибкость, безопасность и высокую готовность системы, необходима высококачественная инфраструктура. Кроме того, нужно иметь возможность интегрировать новые Web-сервисы с имеющимися информационными системами, которые еще не поддерживают стандартных протоколов Web-сервисов. Для этого требуются функции конверсии протоколов и трансформации данных, а также маршрутизации. Эти весьма необходимые функции обеспечиваются корпоративной сервисной шиной – ESB.
6. Многократное использование сервисов.
   Возможность многократного использования сервисов – это одна из ключевых особенностей SOA. Инфраструктура должна обеспечивать возможность многократного использования ресурсов, предоставляя общедоступный перечень определений бизнес-сервисов, хранящихся в репозитории.
7. Согласование сервисов.
   После того как составлен достаточный набор сервисов, каждый из которых поддерживает конкретную функцию управления, из доступных сервисов могут быть составлены бизнес-процессы. При необходимости сервисы комбинируются с неавтоматизированными функциями и предусматривается возможность реагирования на события. Это мы называем согласованием (choreography) процесса.
8. Моделирование бизнес-процесса.
   Этот и следующий шаги связаны, в основном, с интеграцией ИТ в процесс управления, и здесь главную роль играет бизнес-аналитик, а не ИТ-специалист. Бизнес-аналитик определяет бизнес-процесс с точки зрения управления. Моделируя процесс, аналитик определяет, какие части процесса реализуются с помощью автоматических подсистем, а какие выполняет человек.
9. Мониторинг бизнес-процесса.
   После того как процесс выстроен, необходимо контролировать его ход, оценивая различные характеристики. Информация о течении процесса должна быть представлена в аспектах управления, понятных бизнес-аналитику.

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

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

В начало

4.3 Идентификация имеющихся ресурсов (этап 1)

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

Для того чтобы определить имеющиеся ИТ-ресурсы и выявить функциональность информационных систем на платформах Windows, AIX® и z/OS, можно использовать пакет программ WebSphere Studio Asset Analyzer. Он позволяет в различных средах находить программы, написанные на разных языках программирования: коболе, PL/I, C++, Java, CICS, IMS и DB2.

Для модернизации имеющегося кода путем рефакторинга можно использовать пакет программ Asset Transformation Workbench.

Специально для сбора информации относительно работы приложений CICS и характера межпрограммных связей предназначен пакет программ CICS Interdependency Analyzer.

В начало

4.4 Создание, запуск и интеграция сервисов (этапы 2, 3 и 4)

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

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

На большинстве мэйнфреймов ключевые приложения работают в средах CICS и IMS. Как правило, эти транзакционные серверы предоставляют доступ к своим приложениям через потоки данных терминалов 3270 (экранные формы) или структуры данных языков программирования, такие как Cobol Copybooks или включаемые файлы PL/I. Для задействования имеющейся функциональности имеется несколько способов:

1. Если функциональность доступна только через экранное взаимодействие (онлайновые транзакции) с IMS или CICS, необходимо решение, скрывающее оригинальный вид экранной формы от пользователя и представляющее доступ к этой функциональности посредством интерфейса Web-сервиса. Набор служб WebSphere Host Access Transformation Services (HATS) существует уже несколько лет. Он позволяет организовывать доступ через WebWeb и посредством Web-сервисов к приложениям, рассчитанным на работу с терминалами 3270.
2. Если функциональность доступна из конкретной программы CICS, можно воспользоваться Web-сервисами CICS и шлюзом IMS SOAP Gateway, которые обеспечивают возможность представления таких программ в форме Web-сервисов. Чтобы представить программу CICS или IMS в виде сервиса, необходимо поставить ей в соответствие XML-схему и создать необходимый для среды Web-сервисов документ WSDL. IBM предоставляет инструменты для создания Web-сервисов на основе имеющихся прикладных ресурсов, и ниже мы это проиллюстрируем.
3. Если требуемая функциональность обеспечивается сочетанием работы с экранными формами терминала 3270 и вызовов программы CICS, для согласования этих взаимодействий и представления функциональности как единого сервиса можно использовать функцию Service Flow Feature (SFF) сервера транзакций CICS. SFF – это стандартная функция CICS версии 3, обеспечивающая доступ к интерфейсам транзакций и приложений CICS (как экранным, так и процедурным) без вмешательства в их код. Таким образом, при ее использовании нет необходимости изменять прикладные ресурсы CICS, включаемые в состав сервиса.

В следующем разделе мы подробнее рассмотрим упомянутые технологии.

В начало

4.4.1 WebSphere Host Access Transformation Services

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

HATS – это средство создания Web-интерфейсов для приложений, рассчитанных на работу с терминалом IBM 3270Web. Оно было разработано в самом начале появления WWW и существовало под разными названиями. Одним из больших преимуществ HATS является то, что по мере появления новых программных технологий их поддержка добавляется в данный инструмент. Это освобождает программистов от необходимости постоянно модернизировать приложения.

Первой функцией HATS было преобразование экранов 3270 в HTML-страницы в реальном времени. Позднее в генерируемый код стал включаться Javascript, затем – код JSP и Java для поддержки разработки макросов, а теперь HATS может еще и представлять имеющиеся JSP-программы в виде Web-сервисов.

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

При использовании HATS создаются приложения J2EE, работающие в среде WebSphere Application Server под управлением z/OS или на распределенной платформе.

В начало

4.4.2 Web-сервисы CICS

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

В CICS Web-сервисы впервые получили поддержку в версии 2.3, с помощью SOAP. Благодаря реализации этого протокола стало возможным обращаться к Web-сервисам из программ CICS. В версии 3.1 поддержка Web-сервисов стала неотъемлемым свойством сервера транзакций. Поддерживаются такие стандарты, как SOAP 1.2 и WS-AtomicTransaction. Благодаря поддержке Web-сервисов CICS получил возможность выступать в качестве как поставщика, так и потребителя сервисов, и стал полноценным звеном системы сервис-ориентированной архитектуры.

Средства разработки
Чтобы представить программу CICS в виде Web-сервиса, необходимо привести ее в соответствие с XML-схемой и создать WSDL-документ, описывающий Web-сервис. После этого приложения могут отправлять запросы и получать ответы от других приложений посредством интерфейса CICS COMMAREA. Для того чтобы облегчить программистам и разработчикам сервисов задачу модернизации приложений, существуют инструментальные средства.

IBM предлагает для этой цели два средства разработки: поставляемый с CICS версии 3.1 пакет CICS Web Services Assistant, а также WebSphere Developer for zSeries (WD/z). Web Services Assistant содержит базовую функциональность для запуска Web-сервисов. WD/z обеспечивает обширный набор дополнительных возможностей адаптации и оптимизации и содержит все средства разработки, необходимые для создания приложений для z/OS.

CICS Web Services Assistant
CICS Web Services Assistant – это набор пакетных утилит, облегчающих задачу трансформации имеющихся приложений CICS в Web-сервисы и обеспечение возможности вызова Web-сервисов, предоставляемых внешними поставщиками. Этот инструмент поддерживает быстрое развертывание приложений CICS в составе как поставщиков, так и потребителей сервисов, требуя минимум программирования. Он позволяет создать документ WSDL на основе простой языковой конструкции либо конструкции из имеющегося документа WSDL и поддерживает кобол, C/C++ и PL/I. CICS Web Services Assistant также генерирует информацию, необходимую для автоматического преобразования в реальном времени сообщений SOAP в контейнеры и объекты COMMAREA и наоборот.

WebSphere Developer for z
WebSphere Developer for z (WD/z) представляет собой всеобъемлющий набор инструментов, необходимых для разработки ПО для мэйнфреймов, включая Web-разработку, объединение смешанных нагрузок и разработку композитных приложений. WD/z может генерировать артефакты CICS WSBind и языковые конструкции для преобразования между WSDL, XML и форматами данных, свойственными конкретному языку в среде Web-сервисов, а также позволяет доработать сгенерированный артефакт в соответствии с нуждами разработчика.

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

На рис. 4-4 проиллюстрировано, как CICS выступает в роли поставщика сервисов. Запрос SOAP принимается модулем приема данных HTTP (называемым CICS Web support) вне зависимости от того, отправлен он через HTTP или посредством монитора триггеров WebSphere MQ для CICS (если запрос отправлен посредством SOAP через JMS). В обоих случаях запрос поступает затем на конвейер SOAP for CICS для обработки заголовков SOAP, инициализации транзакционной среды и системы обеспечения безопасности, а затем осуществляется вызов целевого адаптера сообщений с помощью сообщения XML. Перед вызовом процедуры, реализующей бизнес-логику, адаптер преобразует сообщение XML в формат COMMAREA. После того как выполнение процедуры закончено, адаптер создает соответствующее сообщение XML, которое передается на конвейер для добавления к нему заголовков SOAP и возвращается потребителю сервиса.

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

Пакеты программ CICS Web Services Assistant и WebSphere Developer for z на основе языковых конструкций или тиражируемого участка кода (copybook) прикладной программы, реализующей бизнес-логику, генерируют документ WSDL и файл WSBind. Документ WSDL используется, чтобы создать запросчик сервиса. Файл WSBind необходим, чтобы указать CICS, какую программу следует вызвать, какой интерфейс при этом использовать и как отобразить сообщение XML на интерфейс.

Определение ресурсов требуется, чтобы задать транспорт. В качестве транспорта может быть использован как протокол HTTP, так и WebSphere MQ. В случае использования HTTP в CICS необходимо создать определение TCPIPSERVICE. При использовании WebSphere MQ нужно создать очередь запросов посредством определения QLOCAL.

CICS в качестве запросчика сервисов
На рис. 4-5 проиллюстрирована работа CICS по вызову Web-сервиса. Документ WSDL для удаленного поставщика сервиса обрабатывается либо Web Services Assistant либо WD/z. В результате создается файл WSBind – языковая конструкция, используемая в качестве интерфейса со стороны программы – запросчика сервиса. Имеется также ресурс PIPELINE, указывающий на конфигурационный файл конвейера, и ресурс WEBSERVICE.

Программа – запросчик сервиса выдает команду EXEC CICS INVOKE WEBSERVICE, передавая языковую конструкцию запроса по интерфейсу CHANNEL. Чтобы преобразовать языковую конструкцию в сообщение SOAP, используются данные в соответствующем ресурсе WEBSERVICE. Сообщение передается по конвейеру, вызывая программы-обработчики в соответствии с файлом конфигурации конвейера. Оно направляется удаленному поставщику сервисов либо по HTTP, либо через WebSphere MQ. Когда получено ответное сообщение SOAP, оно передается назад по конвейеру, преобразуется в языковую конструкцию и возвращается программе – запросчику сервиса.

В начало

4.4.3 Адаптер CICS Service Flow Feature

Адаптер CICS Service Flow Feature обеспечивает возможность вызова приложений CICS в качестве сервисов. При этом также возможно создавать Web-сервисы в CICS, задействующие сочетание готовых транзакций, рассчитанных на терминальную обработку, и вызываемых программ CICS.

Один из способов создания Web-сервисов на основе имеющихся прикладных ресурсов, как рассчитанных на работу с терминалами 3270, так и программно-ориентированных, – это использование адаптера CICS Service Flow Feature. CICS Service Flow Feature является интеграционным адаптером бизнес-сервисов для всех приложений CICS. Он содержит как инструментальные средства, так и компоненты периода исполнения, которые позволяют создавать бизнес-сервисы CICS для встраивания в SOA и для совместного использования бизнес-процессами.

CICS Service Flow Feature позволяет реализовать бизнес-сервисы CICS, составляя последовательность взаимодействий между приложениями этого сервера транзакций. Он включает:

• интегрированную среду графического моделирования, позволяющую создавать бизнес-сервисы CICS, составляя диаграмму взаимодействий приложений этого сервера транзакций;
• средство автоматической генерации кода на основе составленной диаграммы взаимодействий приложений. Сгенерированное приложение в высокой степени оптимизировано для среды CICS и сохраняет неотъемлемые качества сервиса, обеспечиваемые имеющейся реализацией приложения CICS;
• компонент периода исполнения CICS Integrator Adaptor, расширяющий среду CICS Transaction Server for z/OS. Он содержит адаптеры, использующие интерфейсы CICS для вызова терминально-ориентированных транзакций CICS и программ COMMAREA в соответствии со схемой выполнения сервиса.

Бизнес-сервисы CICS, реализованные с помощью CICS Service Flow Feature и хранимые в этой среде, предоставляют интерфейсы бизнес-функций, которые готовы к публикации в качестве Web-сервисов SOA посредством использования Web-сервисной функциональности транзакционного сервера CICS версии 3.1. Ресурсы приложений CICS, определенные схемой сервиса, не требуют модификации для поддержки бизнес-сервисов.

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

В начало

4.4.4 Поддержка SOA в IMS

Шлюз IMS SOAP Gateway – это Web-сервисное решение, интегрирующее ресурсы IMS в SOA. Этот шлюз позволяет приложениям IMS взаимодействовать с программами вне этой среды посредством SOAP, предоставляя и запрашивая сервисы. Таким образом, с его помощью приложения можно вызывать в качестве Web-сервисов.

Для генерации описания сервисов в файлах WSDL здесь также используются функции WebSphere Developer for z.

На рис. 4-6 показан пример конфигурации, в которой различные клиенты подсоединяются к приложениям IMS по протоколу SOAP.

Клиентское приложение SOAP отправляет SOAP-запрос по протоколу HTTP серверу IMS SOAP Gateway Server, чтобы вызвать транзакцию IMS. Сообщение SOAP содержит входные данные для транзакции IMS в формате XML.

Сообщение принимается конечной точкой HTTP/SOAP шлюза IMS SOAP Gateway, который передает его модулю SOAP Processor. SOAP Processor открывает конверт сообщения SOAP, чтобы получить универсальный идентификатор ресурса пространства имен, соответствующий уникальному сервису URN. URN необходим, чтобы найти файл внутренних сервисов, содержащий их реквизиты, требуемые для выполнения транзакции IMS. Затем считывается тело сообщения SOAP, содержащее входные данные для транзакции IMS. Как реквизиты внутренних сервисов, так и входные данные транзакции IMS передаются коннектору Gateway Connector для дальнейшей обработки. На основе информации о соединении и взаимодействии, передаваемой SOAP Processor, Gateway Connector составляет соответствующее сообщение для IMS Connect. В области данных этого сообщения будет помещено полезное содержание оригинального сообщения. Затем оно будет отправлено IMS Connect по соединению TCP/IP.

После того как сообщение получено IMS Connect, диспетчер задач Adapter Task Manager внутри этого модуля вызывает XML-адаптер кобола, чтобы преобразовать данные и отправить их IMS OTMA, вызывающему транзакцию IMS. Затем планируется запуск приложения IMS, его выходные данные пересылаются IMS OTMA и затем IMS Connect.

Когда IMS Connect получает выходные данные, Adapter Task Manager снова вызывает XML-адаптер кобола, чтобы преобразовать сообщение из структуры данных приложения на коболе обратно в XML. Затем преобразованное сообщение отправляется в шлюз SOAP Gateway.

Gateway Connector получает сообщение с выходными данными и возвращает его SOAP Processor. SOAP Processor составляет ответное сообщение SOAP, содержащее выходные данные транзакции IMS. Затем HTTP/SOAP Endpoint отправляет это сообщение приложению – SOAP-клиенту по HTTP.

На момент написания этой книги IMS может выступать в роли только поставщика Web-сервисов и не может их запрашивать.

В начало

4.5 Создание ESB и многократное использование сервисов (этап 5)

После того как ресурсы, пригодные для многократного использования, идентифицированы и готовы к работе в среде Web-сервисов, следующий шаг – исключить межпрограммные связи типа «точка – точка», конвертеры и адаптеры ad hoc и начать построение ESB, которая станет инфраструктурой для взаимного обмена данными, выполняя функции посредника, преобразование протоколов, преобразование форматов и маршрутизацию. WebSphere ESB обеспечивает указанные функции на основе Web-сервисов и вдобавок предоставляет возможности связывания на базе таких компонентов, как WebSphere MQ, WebSphere Message Broker и WebSphere Event Broker.

В данном разделе мы покажем, как реализовать ESB в среде z/OS на примере типичного для этой операционной системы набора приложений.

В начало

4.5.1 Схема интеграции WebSphere ESB и CICS в операционной системе z/OS

Исходное состояние
Пусть некоторая компания использует набор приложений CICS, число которых достигает нескольких тысяч. Доступ к приложениям осуществляется посредством эмуляторов терминала 3270, а также сообщений MQ. Системы автоматизации производственного процесса развернуты в конфигурации параллельного сисплекса, при этом CICS работает в режиме CICSplex, а DB2 – в режиме совместного использования данных. Чтобы задействовать возможности сисплекса, MQ использует разделяемые очереди. Конфигурация изображена на рис. 4-7 на стр. 75. Структура сисплекса на иллюстрации не отображена.

Требования и эскиз решения
Компании требуется создать сервисы на основе имеющихся программ CICS. Для этого было решено развернуть WebSphere ESB под управлением z/OS. Установленные компоненты-посредники в WebSphere ESB обеспечивают доставку клиентских запросов к реализациям сервисов в CICS версии 3 и WebSphere Application Server for z/OS.

От контрагентов поступают запросы через Интернет, инициируемые в одних случаях Java-, в других – .NET-клиентами. Они доставляются по протоколу SOAP/HTTP. Минуя корпоративный межсетевой экран, запросы проверяются в демилитаризованной зоне (на иллюстрации не изображена).

После того как проверка безопасности в демилитаризованной зоне выполнена, клиентский запрос поступает на Sysplex Distributor, выполняющий балансировку нагрузки и обеспечивающий высокую готовность сервиса для внешних клиентов сети, обращающихся к инфраструктуре Parallel Sysplex под управлением z/OS. На основе правил, заданных в z/OS Workload Manager (WLM), Sysplex Distributor выбирает подходящую сервисную шину, чтобы обслужить поступающий запрос. Sysplex Distributor обменивается с z/OS WLM данными о времени отклика приложений, что позволяет ему осуществлять динамическую маршрутизацию.

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

Затем вызываются так называемые модули-посредники, входящие в состав WebSphere ESB, которые выполняют преобразование запросов и направляют их целевому поставщику Web-сервисов. Поставщик Web-сервисов может быть реализован как в среде CICS, так и на WebSphere Application Server for z/OS.

Доступ к сервисам, реализованным на базе приложений J2EE, осуществляется посредством соединения сервисных шин с сервером WebSphere Application Server. Для использования сервисов CISC сервисные шины подключаются к данному транзакционному серверу. На рис. 4-7 WebSphere Application Server и WebSphere ESB изображены в виде двух отдельных прямоугольников. Чаще всего они разворачиваются на разных серверах, но в одной и той же ячейке WebSphere.

Среда CICS сконфигурирована в режиме CICSPlex, который обеспечивает высокую готовность и позволяет балансировать нагрузку на сервер транзакций. Подобным образом – в конфигурации Network Deployment – настроен и WebSphere Application Server, что также обеспечивает балансировку нагрузки, высокую готовность и отказоустойчивость.

Вызываемые транзакции CICS и WebSphere обращаются к базам данных DB2. СУБД DB2 сконфигурирована в соответствующем режиме совместного использования, который обеспечивает возможность полного совместного использования данных системами, входящими в состав кластера Parallel Sysplex.

Условия выбора
В данном примере было решено не использовать Web-сервисные возможности CICS для доступа к функциональности этого сервера транзакций, поскольку была лишь малая вероятность того, что потребуется вызывать отдельные приложения. Предполагалось, что они войдут в состав логического сервиса наряду с другими транзакциями CICS и сервисами, для чего они были включены в посреднические сценарии, а доступ к ним организован через ESB.

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

• Безопасность.
  Может быть реализована всесторонняя защита, ограничиваемая лишь выбранной схемой обеспечения безопасности на клиентской стороне. Поскольку все компоненты выполняются в одной и той же системе (сисплексе), контексты защиты не изменяются, и все действия, инициируемые запросчиком, выполняются в рамках учетной записи данного пользователя.
• Управление и балансировка нагрузки на всех этапах обработки – от Sysplex Distributor до основных СУБД, включая Web-сервисы.
• Высокая готовность.
  Так как это ключевая характеристика инфраструктуры SOA, каждый компонент имеет избыточную конфигурацию, основанную на возможностях резервирования, предоставляемых сисплексом.
• Управляемость.
  Все компоненты выполняются на одной и той же системе (сисплексе), что существенно облегчает системное управление, выявление проблем, анализ производительности и планирование мощности.
• Стоимость.
  Задачи WebSphere ESB выполняются на процессорах zAAP, что значительно снижает совокупную стоимость владения и увеличивает объем ресурсов процессоров общего назначения, доступных другим приложениям.
• Административное управление ИТ.
  Вне зависимости от количества запущенных в данной среде Web-приложений пользователь может продолжать использовать систему для основных приложений, таких как системы финансовой отчетности, системы автоматизации кадровой деятельности, средства бизнес-аналитики, пакетные задачи и т.п., при этом все программы могут совместно использовать одни и те же ресурсы и данные.
• Отчетность.
  Такие встроенные компоненты z/OS, как SMF и SMS, позволяют регистрировать каждый отдельный факт использования ресурсов и включать информацию об этом в отчет для анализа производительности и распределения затрат.
• Оптимизация.
  Исключение ненужного сетевого трафика достигается благодаря стандартным для технологии Parallel Sysplex возможностям соединения.
• Масштабируемость.
  В ожидании расширения бизнеса, которое может стать возможным благодаря развертыванию этой гибкой, реактивной и открытой архитектуры, компании могут начать планировать увеличение числа своих деловых партнеров. При этом директор по ИТ может задаться таким вопросом: предположим, бизнес вырастет на 35%, как это отразится на ИТ-ресурсах? Что необходимо изменить в инфраструктуре, чтобы адаптировать ее к росту бизнеса, и сколько времени уйдет на расширение конфигурации? Вопрос очень уместный, но в случае платформы z/OS ответ на него весьма простой. Все что требуется – это динамическое добавление ресурсов.

Вывод
Предположим, что мы развернули программное решение такой же архитектуры и с тем же качеством обслуживания на децентрализованной инфраструктуре. Если ESB и WebSphere Application Server выполняются на других платформах, используя данные CICS и основных СУБД, насколько сложной будет система? Какова будет ее окончательная совокупная стоимость владения? Является ли новая среда полностью управляемой?

В начало

4.6 Согласование процессов (этап 7)

Согласование бизнес-процессов – это следующий шаг на пути воплощения SOA. В данном разделе мы представим две типовых схемы запуска SOA на платформе z/OS.

В начало

4.6.1 Схема интеграции сервисов IMS в согласованные процессы

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

Исходное состояние
Пусть портфель приложений некоторой компании состоит из IMS-программ на коболе. Доступ к ним осуществляется через эмуляторы терминалов 3270 и посредством сообщений MQ. Компания крупная, использует средства разработки, тестирования, приемосдаточных испытаний и системы поддержки производственного процесса, развернутые на кластере Parallel Sysplex, причем системы IMS сконфигурированы в режиме IMSPlex, а MQ использует разделяемые очереди. Конфигурация изображена на рис. 4-8. Структура сисплекса на иллюстрации не показана.

Требования и эскиз решения
Компании из нашего примера необходимо обеспечить доступ к транзакциям IMS посредством Web-сервисов, в частности по причине необходимости интеграции бизнес-процессов с организациями-контрагентами. Для согласования интеграции ряд имеющихся транзакций IMS, возможно с небольшими изменениями, должен быть представлен в виде Web-сервисов. Существуют и другие задачи интеграции, которые могут быть решены посредством согласования бизнес-процессов. Компания решает развернуть WebSphere Process Server на той же самой платформе, где находятся и основные приложения, поскольку нуждается в высокой готовности и масштабируемости, обеспечиваемой платформой z/OS, и видит большие преимущества в том, чтобы поместить сервер бизнес-процессов и сервисную шину локально по отношению к IMS, MQ и DB2. Компании ясны также экономические преимущества, которые дает исполнение приложений Java на процессорах zAAP.

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

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

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

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

Условия выбора
Компания решила отказаться от использования IMS SOAP Gateway, в основном потому, что функциональность программ IMS не планируется использовать индивидуально: она будет агрегирована в составе новых сервисов WebSphere Process Server вместе с другими транзакциями IMS и прочих СУБД. Для вызова имеющейся функциональности IMS из WebSphere Process Server будет использоваться компонент IMS Connect.

Реализация Web-сервисов требует не только многократного использования функциональности приложений IMS, но также и возможностей отображения данных в WebSphere Process Server и взаимодействия с MQ посредством сообщений.

Особые преимущества развертывания решения на z/OS
Помимо высокой готовности и надежности, отмеченных в разделе 4.5.1 «Схема интеграции WebSphere ESB и CICS в операционной системе z/OS», выбор z/OS дает дополнительные уникальные возможности:

• двухэтапное завершение транзакций с помощью RRS, не требующее распределенных механизмов обработки, таких как XA;
• интеграция с RACF в области обеспечения безопасности без обмена идентификационными данными и дополнительных задач управления правами пользователей;
• локальное размещение данных, повышающее эффективность доступа к данным DB2 и транзакциям CICS.

В начало

4.6.2 Схема интеграции сервисов CICS в согласованные процессы

В данном сценарии мы покажем, как можно развернуть WebSphere Process Server в z/OS и как этот сервер приложений и CICS становятся частью сервис-ориентированной архитектуры, обеспечивая Web-сервисы по поддержке бизнес-процессов. Схема решения приведена на рис. 4-9.

Исходное состояние
Пусть некоторая компания использует традиционную среду CICS. Конечные пользователи работают с приложениями посредством эмуляторов «зеленых» терминалов 3270. Приложения CICS интегрированы с фронт-офисными приложениями, реализованными на WebSphere Application Server, который развернут на распределенной платформе. WebSphere Application Server использует функциональность приложений CICS посредством шлюза CICS Transaction Gateway. Для установки единого контекста безопасности с подсистемами CICS и DB2 на z/OS сервер приложений использует LDAP в этой же операционной системе с ее собственным механизмом аутентификации. DB2 for z/OS используется в качестве хранилища данных WebSphere Application Server. Система использует кластер Parallel Sysplex (на схеме не показан), на котором развернуты СУБД DB2, сконфигурированная в режиме совместного использования данных, и CICS в режиме CICSplex. WebSphere Application Server, находящийся на распределенной платформе, настроен на обеспечение высокой готовности с использованием балансировщиков нагрузки на интерфейсные системы и диспетчера WebSphere WLM на узлах WebSphere.

Требования и эскиз решения
В компании было решено заменить имеющуюся CRM-систему новой на основе ПО Siebel. В качестве БД для Siebel послужит DB2, работающая под управлением z/OS, что обеспечит высокую масштабируемость и стабильность. Как имеющиеся, так и новые приложения будут осуществлять доступ к функциям новой CRM-системы посредством вызовов Web-сервисов. Кроме того, некоторые функции CRM-системы требуют доступа к имеющимся приложениям: он также будет организован посредством Web-сервисов. Последнее возможно благодаря тому, что программы CICS могут быть представлены в виде сервисов с использованием Web-сервисных функций CICS. Поскольку компании необходимо также вызывать Web-сервисы из новых транзакций CICS, например относящихся к новым функциям, обращающимся к CRM-системе, возможность использования Web-сервисов оказывается очень удобной.

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

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

Кроме того, в компании эксплуатируется большое число распределенных серверов. Из-за высоких требований к готовности их администрирование обходится слишком дорого. Изучение возможностей WebSphere под управлением z/OS показало целесообразность начать консолидацию транзакций WebSphere в среде z/OS в свете ожидаемых преимуществ с точки зрения администрирования и показателей готовности, а также с экономической точки зрения (благодаря возможности исполнять основную массу приложений WebSphere на процессоре zAAP). С помощью справочника по планированию мощности zPSG была определена требуемая мощность новой системы.

Условия выбора
Компания реализует согласование бизнес-процесов посредством WebSphere Process Server, работающего под управлением z/OS. Данная операционная система была выбрана благодаря высоким показателям качества обслуживания. Сервер процессов должен быть масштабируемым для реализации запланированных проектов. По-прежнему будет применяться многократное использование LDAP в z/OS совместно с имеющимся стандартным решением аутентификации – реестром пользователей RACF.

Было решено использовать Web-сервисы в CICS и в то же время применять CTG для реализации тех Web-сервисов в WebSphere Process Server, к которым нет необходимости обращаться в CICS по SOAP. Такая практика целесообразна в случаях, когда функции CICS не используются в качестве самостоятельных сервисов.

Особые преимущества выбора z/OS
Кроме преимуществ высокой готовности и надежности, являющихся очевидными, описанное решение предоставляет ряд дополнительных уникальных возможностей:

• двухэтапное завершение транзакций по RRS, не требующее распределенных механизмов обработки, таких как XA;
• интеграция с RACF в области обеспечения безопасности без решений обмена идентификационными данными и дополнительных задач управления правами пользователей;
• локальное размещение данных, повышающее эффективность доступа к данным DB2 и транзакциям CICS;
• обмен по протоколу SOAP с приложениями CICS без необходимости использовать иное промежуточное ПО.

В начало

4.7 Моделирование и мониторинг бизнес-процессов (этапы 8 и 9)

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

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

В начало

4.7.1 Моделирование бизнес-процессов

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

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

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

В начало

4.7.2 Мониторинг бизнес-процессов

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

ПО IBM WebSphere Business Monitor позволяет осуществлять мониторинг бизнес-процессов в реальном времени, в наглядном виде представляя информацию о состоянии процесса, и включает следующие инструменты и функции:

• • сигналы и оповещения для ключевых пользователей, способствующие непрерывному улучшению бизнес-процесса;
• • настраиваемые панели представлений в форме страниц WebSphere Portal, дающие в наглядной форме информацию о результатах оценок состояния процессов и ключевых показателей эффективности;
• • многомерный анализ и отчетность с встроенной функциональностью бизнес-аналитики, поддерживаемые панелями представлений;
• • настраиваемые аналитические компоненты для мониторинга процессов в соответствии с требованиями бизнес-пользователей;
• • эффективные средства фильтрации отчетов;
• • возможность вызова заданных процедур или наборов процедур в реальном времени на основе определенного набора правил и политик (с помощью Adaptive Action Manager);
• • интеграция многоуровневого бизнес-анализа с бизнес-процессами;
• • расширенные возможности инноваций и оптимизации ключевых бизнес-процессов.

WebSphere Business Monitor может быть интегрирован с WebSphere Business Modeler Advanced для улучшения качества бизнес-моделирования, имитационного моделирования и анализа.

В начало

4.8 Заключение

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

SOA основана на сервис-ориентированном подходе и определяет особенности архитектурного решения, на базе которого осуществляется ее развертывание.

Однако этим ее роль не ограничивается: SOA определяет также конструктивные архитектурные элементы, используемые технологии (которые основаны на открытых стандартах) и схемы интеграции.

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

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

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

В начало

	Страница 1 из 4