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

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

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

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

• совершенствование интерфейса BPEL из WebSphere Business Integration Modeler;
• совершенствование обработки XSLT в операции назначения (Assign activity) WebSphere Integration Developer, создающее реальную альтернативу использованию трансформационных служб;
• поддержка агрегации для не MQ-протоколов в WebSphere Business Integration Message Broker;
• публикация UML-профиля для программных служб, написанного Саймоном Джонсоном (Simon Johnson) на Web-сайте http://www.ibm.com/developerworks/rational/library/05/419_soa/

Подробную информацию о применении данного профиля и расширении возможностей Rational Software Architect для поддержки SOA можно найти в книге Patterns: Model Driven Development using Rational Software Architect, SG24-7105.

Эти и другие усовершенствования должны подтолкнуть вас к тому, чтобы вы основывали свои новые интеграционные проекты на платформе WebSphere версии 6, а не версии 5.

13.1 Уроки, которые мы извлекли

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

13.1.1 Бизнес-моделирование и ИТ-архитектура

Мы обнаружили, что WebSphere Business Integration Modeler является полезным инструментом для формулировки требований и анализа.

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

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

Кто формирует исполняемый бизнес-процесс?

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

• Вопрос времени.

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

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

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

В нашем проекте аналитик уделял основное внимание совершенствованию процесса, которое необходимо для компании LGI, но не бизнес- и ИТ-взаимосвязям, которые нужно создать между LGI и оценщиками, чтобы автоматизированный процесс мог заработать. Из-за отсутствия опыта и навыков работы с информационными технологиями типа "бизнес-бизнес" (Business to Business, B2B) важность замены ручного взаимодействия между LGI и оценщиками на автоматизированное не было оценена в достаточной степени.

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

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

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

Если полагаться на выполнение двух приведенных ниже условий, реализация будет неустойчивой:

• оценщик создаст оба ответа в нужном порядке;
• инфраструктура не перепутает ответы.

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

Широко распространено мнение, что лучшей ИТ-моделью для взаимодействий с использованием протоколов является модель на основе конечных автоматов, а не модель процессов. В WebSphere Process Server Version 6 предлагается механизм реализации моделей конечных автоматов для бизнес-взаимодействий.

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

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

С точки зрения процесса мы рекомендуем, чтобы:

• CIM-модель принадлежала бизнес-аналитику, а одним из тех, с кем эту модель нужно согласовывать, был ИТ-архитектор;
• PIM-модель принадлежала ИТ-архитектору, а одним из тех, с кем эту модель нужно согласовывать, был бизнес-аналитик.

13.1.2 Экспортировать ли BPEL из WebSphere Business Integration Modeler?

Мы решили импортировать BPEL-код из Modeler и детализовать его в WebSphere Studio Application Development Integration Edition.

Этот подход зародился в нашей команде после разработки каскадной модели, поддерживаемой цепочкой инструментов. BPEL экспортировал бизнес-аналитик для специалиста по процессу.

При разработке BPEL-модели аналитик и архитектор широко взаимодействовали друг с другом в духе кооперативной разработки. Полученный BPEL-код был импортирован в WebSphere Studio Application Development Integration Edition специалистом по процессу. Однако оказалось, что специалист по процессу, работающий со сгенерированным BPEL, столкнулся с трудностями, поскольку наши стандарты разработки, сформированные архитектором в Rational Software Architect, не были включены в модель, созданную аналитиком. Следовательно, ИТ-специалист по процессу выбрал практичный вариант и удалил несколько артефактов, сгенерированных на BPEL в WebSphere Studio Application Development Integration Edition.

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

13.1.3 Имена

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

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

Мы предлагаем давать артефактам имена, состоящие из краткой описательной части и простого уникального тега, например короткого числа. Имена можно объ- единять путем добавления к номеру префикса для каждого подразделения, например, AssessAvail_A1.wsdl. Избегайте любой ценой специальных символов, таких, как (, [, { и т. п. И старайтесь делать имена и пути действительно краткими, чтобы избежать проблем с ограничением максимальной длины пути в продуктах Eclipse, работающих в Windows. Может помочь создание соглашения об именах, основанного на компо- нентах. Мы постоянно спрашивали: этот запрос о доступности направляется в прокси или реальному оценщику? Этот ответ от оценщика возвращается в Choreographer или в прокси? Однако мы обнаружили, что простая нумерация потоков работает лучше, чем что-либо еще.

13.1.4 Метаданные

У нас были на выбор три формы метаданных для описания интерфейсов нашего решения:

• UML,
• WSDL,
• смесь WSDL и XSD.

Мы решили использовать WSDL. Это привело к некоторым проблемам при обмене данными об интерфейсах между WebSphere Business Integration Message Broker и WebSphere Studio Application Development Integration Edition. Справиться с этими проблемами, возможно, было бы легче, если бы мы использовали в наших WSDL-описаниях импортированные, а не встроенные схемы. У нас было несколько случаев отклонения интерфейсов от стандарта, поскольку встроенные схемы в WSDL-интерфейсах без необходимости отклонялись от стандарта просто из-за того, что схемы разрабатывались в разное время.

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