Важные моменты

13.1.5 Сервисная шина

Реализация потоков сообщений в брокере заняло больше времени, чем ожидалось. Частично это явилось результатом того, что Broker версии 5 не имел реализации схемы SOAP 1.1 и не мог импортировать WSDL, а частично – результатом того, что, используя SOAP/HTTP в качестве транспортного протокола, мы привнесли дополнительные затраты, связанные с распространением и агрегацией, из-за трудностей интеграции с SOAP/JMS.

Также мы никогда не касались проблем, связанных с обработкой ошибок на транспортном уровне. Ошибки транспортных протоколов при использовании SOAP/JMS лучше обрабатывать при помощи промежуточного ПО, в отличие от использования SOAP/HTTP. Если применяются двусторонние взаимодействия SOAP, то хорошая SOA-архитектура должна решать вопрос обработки сообщений об ошибках SOAP от имени SOAP-клиентов.

Некоторые из этих проблем сразу же разрешаются при переходе на WebSphere Business Integration Message Broker версии 6 и использовании WebSphere Platform Messaging и WebSphere MQ, где это необходимо. Некоторые другие проблемы решаются путем изучения шаблонов для SOA, например как описано в книге Patterns: Model-Driven Development Using IBM Rational Software Architect, SG24-7105.

Уроки, которые мы извлекли из использования версии 5, следующие.

Отделяйте архитектуру и реализацию сервисной шины от дизайна и реализации компонентов proxyAssessorSystem, реализованных на этой сервисной шине.

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

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

Основная причина этих проблем состоит в том, что нам нужно было пересмотреть бизнес-требования с участием бизнес-аналитика, когда ИТ-архитектор выявил необходимость создания системы proxyAssessorSystem. Результатом было бы более четкое разделение проблем между ESB и уровнем процесса.

Более совершенный инструментарий ESB в WebSphere Version 6, лучшие шаблоны и модели SOA и реализация конечных автоматов для бизнес-протоколов в WebSphere Process Server Version 6 улучшили бы проектирование и реализацию сервисной шины.

13.1.6 Заключение

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

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

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

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

13.2 Изменения в инструментарии и промежуточном программном обеспечении

С момента реализации данного сценария большая часть соответствующего программного обеспечения перешла с WebSphere версии 5 на версию 6. В некоторых случаях различия в архитектуре и реализации были очень незначительны, но в других – внесены существенные улучшения, как в области повышения производительности разработки, так и в области надежности решения.

13.2.1 WebSphere MQ

Система WebSphere MQ перешла с версии 5 на версию 6. Единственными изменениями, повлиявшими на проект, были следующие:

• В WebSphere MQ версии 6 для управления используется обозреватель на основе Eclipse, а не на основе Microsoft Management Console;
• версию WebSphere MQ Workflow необходимо обновить, чтобы конфигурация очередей могла свободно работать с WebSphere MQ версии 6.

13.2.2 WebSphere MQ Workflow

Версия WebSphere MQ Workflow повысилась с 3.1.4 до 3.1.7.

13.2.3 WebSphere Application Server

WebSphere Application Server V6.0 включает в себя платформу обмена сообщениями, построенную на основе JMS. Эта платформа существенно отличается от встроенной системы обмена сообщениями и дополнительно плагина WebSphere MQ messaging, имевшегося в версии 5. С точки зрения архитектуры система обмена сообщениями WebSphere Application Server интегрируется с сервером WebSphere MQ, работающим на другом сервере, и в то же время является составной частью WebSphere Application Server. Это должно упростить создание шины сообщений, интегрирующей те части решения, которые связаны с сервером приложений и WebSphere MQ, и должно сделать возможным (с точки зрения производительности и надежности) создание односторонних взаимодействий между Process Choreographer и такими компонентами приложений, как сообщения SOAP/JMS.

13.2.4 WebSphere Business Integration Message Broker

WebSphere Business Integration Message Broker включает в себя узел JMS, который значительно упрощает интеграцию с WebSphere Application Server при использовании шины SOAP/JMS.

WebSphere Business Integration Message Broker поддерживает SOAP-схему для импортирования WSDL и для агрегирования запросов SOAP/http, что значительно повышает производительность ИТ-специалиста, отвечающего за создание брокерного компонента сценария.

В WebSphere Enterprise Service Bus предлагается альтернативная связь с компонента сервисной шины в архитектуре решения с рабочей средой. Нужно провести дополнительные исследования решения, чтобы определить связи сервисной шины с продуктами для версии 6. Одной из областей для усовершенствований, которую ИТ-архитектор будет ждать от нового продукта WebSphere Enterprise Service Bus, является более совершенная интеграция с инструментарием для создания служб. Стоимость размещения службы на сервисной шине не должна быть выше размещения службы в соединении "точка-точка". Разница в стоимости размещения – это одна из причин, по которой ИТ-архитектор, работающий в версии 5, выбирает для связей с продуктами подход, ориентированный на процесс, а не на шину.

13.2.5 WebSphere Business Integration Server Foundation

WebSphere Business Integration Server Foundation был заменен WebSphere Process Server version 6. Это некоторым образом повлияло на архитектуру сценария. В WebSphere Process Server используется система обмена сообщениями платформы WebSphere (WebSphere Platform messaging), а не запуск WebSphere MQ в качестве службы обмена сообщениями. Одним из последствий является то, что соединение типа "точка-точка" между WebSphere MQ Workflow и WebSphere Business Integration Server Foundation нельзя автоматически перенести в WebSphere Process Server.

Если вы помните, в разделе 5.5, "Шаг 3. Выбор и объединение шаблонов рабочих систем", мы выбрали шаблон рабочей системы, ориентированный на процесс, и дан- ное соединение типа "точка-точка" между WebSphere MQ Workflow и WebSphere Business Integration Server Foundation было одним из нескольких подобных соединений, которые следует перенести. Имеет смысл пересмотреть для версии 6 наш выбор шаблона рабочей системы и выбрать вариант с шаблоном, ориентированным на брокер (или ESB), вместо выбранного нами для версии 5 шаблона, ориентированного на процесс.

13.2.6 WebSphere Studio Application Development Integration Edition

В версии 6 WebSphere Studio Application Development Integration Edition был заменен на WebSphere Integration Developer.

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

1. Операция назначения (assign) теперь может обрабатывать ссылки на сложные сообщения. Это устраняет необходимость создания трансформаций для простых связей "один к одному" в процессе. Операции назначения на BPEL, экспортированные из Modeler, с большей вероятностью сохранятся в потоке выполнения.
2. Существует новая концепция проекта, во многом напоминающая идею набора сообщений (message set) в Broker, которая позволяет легко сохранять WSDL-файлы в отдельном проекте и ссылаться на него из разных потоков. Это способствует разработке более модульных потоков и должно унизить вероятность внесения ошибок размещения из-за сохранения по ошибке WSDL-файлов в папке, которая не видна мастеру размещения.
3. В интеграции тестового сервера из WebSphere Integration Developer используется подход, позаимствованный из инструментария Rational. Это тесная интеграция инструментария и сервера рабочей системы. Это упрощает тестирование на серверной рабочей системе без создания специального встроенного тестового сервера.

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

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

13.2.7 WebSphere Business Integration Modeler

Modeler версии 6 является дальнейшим развитием версии 5. Главная область усовершенствований – моделирование бизнес-параметров – выходит за рамки нашего сценария.

Существует несколько небольших изменений для улучшения интеграции Modeler с остальной частью решения, в частности:

1. BPEL-код, генерируемый для импортирования в WebSphere Integration Developer, удобнее в использовании.
2. Импортируемое содержимое разбивается на меньшие части, так что вместо импортирования всей модели можно импортировать процесс и не импортировать модель данных.

Эта возможность немедленно устранила бы первый шаг, который мы делали в ходе детализации BPEL из Modeler в WebSphere Studio Application Development Integration Edition. Нам приходилось удалять все ссылки на партнеров и связанные с ними структуры сообщений, такие, как интерфейсы, при импорте из Rational Software Architect.

13.2.8 Rational Software Architect

В этом сценарии мы уже использовали Rational Software Architect версии 6, и в данном курсе мы выполнили обновление его пакетом Fixpack 1, что повысило стабильность интеграции с WebSphere Business Integration Modeler.

Функциональность, которая нам больше всего требовалась при разработке в Rational Software Architect, – это трансформация между UML и WSDL. Для нас стало возможным создать наш собственный трансформационный плагин, используя расширения Rational Software Architect, как это описано в книге Patterns: Model Driven Development using Rational Software Architect, SG24-7105.

Проверьте: может быть, IBM или другой производитель уже разработали плагин. Существуют статьи, в которых обсуждаются проблемы, связанные с трансформацией между UML и WSDL. Обратитесь, например, к статье MS General Web services UML to WSDL Binding Auto-generation Guidelines, которую можно найти по адресу http://www.imsglobal.org/gws/gwsv1p0pd/imsgws_transfv1p0pd.html