Первая часть заключительной лекции представляет собой завершающий анализ. Какие уроки мы извлекли из создания решения? Повлияет ли этот опыт на интеграционные проекты, в которых будете принимать участие вы?
Во второй части лекции мы перечислим некоторые изменения, которые были
введены в следующую версию платформы WebSphere. Команда IBM System
House, которая, как вы, возможно, помните из предисловия, осуществляет
спонсорскую поддержку данного курса, отвечала за взаимодействие с разработчиками
с целью совершенствования интеграционных возможностей промежуточного
программного обеспечения от IBM. Поэтому для вас не должно
быть удивительным, что в версии 6 платформы WebSphere появилось много
новых возможностей и усовершенствований, которые делают создание сценария
для работы с внешними
Наиболее существенные улучшения можно найти в области интеграции
технологий обмена сообщениями и серверов приложений вокруг
Подробную информацию о применении данного профиля и расширении
возможностей Rational
Эти и другие усовершенствования должны подтолкнуть вас к тому, чтобы вы основывали свои новые интеграционные проекты на платформе WebSphere версии 6, а не версии 5.
Основные извлеченные нами уроки главным образом касаются способа совместной работы членов команды. В основном эти уроки сосредоточены на роли архитектора и взаимодействии архитектора с бизнес-аналитиком и ИТ-специалистом, а также на политиках и инструкциях, созданных для проекта бизнес-аналитиком и ИТ-архитектором. Метод совместной работы этих ролей и инструменты, помогающие им в работе, более чем что-либо иное определяют результат проекта по интеграции.
Мы обнаружили, что WebSphere Business Integration Modeler является полезным инструментом для формулировки требований и анализа.
Мы подчеркиваем слово "опытный", поскольку, когда целью является создание предсказаний на ранних стадиях, подробной информации о реализации процесса нет. Опытный бизнес-аналитик сможет указать элементы, имеющие значительную стоимость, и основные операции, не погружаясь в попытки моделирования деталей реализации процесса.
Мы обнаружили, что исходные цели бизнес-аналитика по сбору требований, изучению
возможностей для совершенствования процесса,
Чтобы можно было дать ход проекту в целом, определение процесса должно происходить параллельно с подробным анализом бизнеса.
Анализ процесса с точки зрения поиска возможностей для усовершенствования отличается от проектирования процесса, который будет надежно функционировать, используя комбинацию ручных и автоматизированных операций.
Нужно знать, что модель процесса, созданная бизнес-аналитиком, скорее всего, не будет для остального проекта полностью адекватным определением процесса.
В нашем проекте аналитик уделял основное внимание совершенствованию процесса,
которое необходимо для компании LGI, но не бизнес- и ИТ-взаимосвязям, которые
нужно создать между LGI и
Вот простой пример, где дополнительный анализ и использование лучших практических
схем для
В разделе 10.4.7, "Конфигурирование потока для ожидания ответа от
Принимающая операция была импортирована прямо из определения процесса
в бизнес-модели. До тех пор пока ИТ-специалист не начал тестировать процесс, не
было уделено достаточного внимания тому факту, что данная модель неявно требует,
чтобы ответы от
Если полагаться на выполнение двух приведенных ниже условий, реализация будет неустойчивой:
Более совершенной архитектурой было бы использование схемы публичного/личного
процесса, типичной для
Широко распространено мнение, что лучшей ИТ-моделью для взаимодействий с использованием протоколов является модель на основе конечных автоматов, а не модель процессов. В WebSphere Process Server Version 6 предлагается механизм реализации моделей конечных автоматов для бизнес-взаимодействий.
Наш вывод состоит в том, что модель
Например, в случае со сценарием для работы с внешними
С точки зрения процесса мы рекомендуем, чтобы:
Мы решили импортировать BPEL-код из Modeler и детализовать его в WebSphere Studio
Этот подход зародился в нашей команде после разработки
При разработке BPEL-модели аналитик и архитектор широко взаимодействовали
друг с другом в духе кооперативной разработки. Полученный BPEL-код был импортирован
в WebSphere Studio
Наша рекомендация для специалиста по процессу, которая наиболее подходит при использовании Modeler версии 6, состоит в том, чтобы перед экспортированием BPEL из Modeler детализовать бизнес-процесс, чтобы он соответствовал принятым стандартам, в частности по схеме имен и структуре пакетов. Специалист по процессу также может смоделировать потоки данных в модели процесса и сгенерировать BPEL-код, более напоминающий готовый исполняемый процесс.
Проводить обширное переименование и реорганизацию без создания нежелательных и трудных в устранении побочных эффектов сложно в любых инструментах. Проблема еще больше усложняется при использовании нескольких инструментов, которые связаны друг с другом механизмами экспорта/импорта и в которых изменения имен и интерфейсов должны отражаться в многочисленных артефактах. Мы вносили больше ошибок и тратили больше времени на нами же вызванные проблемы с изменениями имен и интерфейсов, чем во всех прочих проблемах исходного кода.
Мы предлагаем давать артефактам имена, состоящие из краткой описательной
части и простого уникального тега, например короткого числа. Имена можно объ-
единять путем добавления к номеру префикса для каждого подразделения, например,
AssessAvail_A1.wsdl. Избегайте любой ценой специальных
символов, таких, как (, [, {
и т. п. И старайтесь делать имена и пути действительно краткими, чтобы избежать
проблем с ограничением максимальной длины пути в продуктах Eclipse, работающих
в Windows. Может помочь создание соглашения об именах, основанного на компо-
нентах. Мы постоянно спрашивали: этот запрос о доступности направляется в прокси
или реальному
У нас были на выбор три формы метаданных для описания интерфейсов нашего решения:
Мы решили использовать WSDL. Это привело к некоторым проблемам при обмене
данными об интерфейсах между WebSphere Business
Теперь, когда WebSphere Business
Реализация потоков сообщений в брокере заняло больше времени, чем ожидалось.
Частично это явилось результатом того, что
Также мы никогда не касались проблем, связанных с обработкой ошибок на
транспортном уровне. Ошибки транспортных протоколов при использовании SOAP/
Некоторые из этих проблем сразу же разрешаются при переходе на WebSphere
Business
Уроки, которые мы извлекли из использования версии 5, следующие.
Отделяйте архитектуру и реализацию сервисной шины от дизайна и реализации компонентов proxyAssessorSystem, реализованных на этой сервисной шине.
ИТ-специалист, реализуя компоненты брокера, должен был сформировать основу
для передачи сообщений, а также реализовать специфические свойства, которые
требуются
При разработке сервисной шины и ее компонентов слишком мало учитывалась роль архитектуры. У архитектора не было инструментов для описания сервисной шины вплоть до уровня проектирования взаимодействий. Специалист по реализации обнаружил, что в версии 5 промежуточного ПО очень много работы требуется для того, чтобы создать сервисную шину, на основе которой строится система proxyAssessorSystem.
Основная причина этих проблем состоит в том, что нам нужно было пересмотреть
бизнес-требования с участием бизнес-аналитика, когда ИТ-архитектор выявил
необходимость создания системы proxyAssessorSystem. Результатом было бы более
четкое разделение проблем между
Более совершенный инструментарий
Использованный нами подход разработки, направляемой бизнесом, и создание решения для конкретной бизнес-проблемы сконцентрировали внимание нашей команды на моделировании решения, а затем на детализации модели вплоть до реализации с использованием многочисленных инструментов и компонентов промежуточного программного обеспечения.
В сравнении с общепринятой разработкой, направляемой информационными технологиями, мы меньше обращали внимания на разработку ИТ-инфраструктуры и как можно больше – на воплощение бизнес-требований в решении.
Нам нужно было уделить больше внимания пониманию и формулировке проблем, связанных с ИТ: архитектурные вопросы были возложены на ИТ-специалистов, которые решали их в ходе реализации. Проект выполнялся бы более эффективно, если бы эти проблемы были решены заранее. Это, вероятно, было признаком работы в лаборатории, без работы с реальной ИТ-инфраструктурой. Если бы это был реальный проект, то ИТ-инфраструктура уже существовала бы и больше внимания нужно было бы уделять внесению в нее изменений.
Тем не менее существует параллель, которую можно перенести на проекты в реальном
мире, в которых используют подход с разработкой, направляемой бизнесом.
Важно заранее определить, какие изменения и какие ресурсы должны быть введены в
команду, занимающуюся инфраструктурой, чтобы создать сервисную шину, поддерживающую
возможности, необходимые для новых
С момента реализации данного сценария большая часть соответствующего программного обеспечения перешла с WebSphere версии 5 на версию 6. В некоторых случаях различия в архитектуре и реализации были очень незначительны, но в других – внесены существенные улучшения, как в области повышения производительности разработки, так и в области надежности решения.
Система WebSphere MQ перешла с версии 5 на версию 6. Единственными изменениями, повлиявшими на проект, были следующие:
Версия WebSphere MQ Workflow повысилась с 3.1.4 до 3.1.7.
WebSphere Application Server V6.0 включает в себя платформу обмена сообщениями,
построенную на основе
WebSphere Business
WebSphere Business
В WebSphere
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 наш выбор
шаблона рабочей системы и выбрать вариант с шаблоном, ориентированным на
брокер (или
В версии 6 WebSphere Studio
Существует масса конкретных улучшений инструментария, которые упростят организацию процесса разработки и сделают разработку более продуктивной. Особенно заслуживают упоминания три изменения, поскольку они влияют на наш сценарий:
Одним из преимуществ, которые ощущаются сразу, является то, что обслуживать рабочий сервер гораздо удобнее, чем встроенный тестовый сервер, и, вероятно, серверных сред для управления станет меньше. Второе преимущество, касающееся разработчика, состоит в более простом переходе от модульного тестирования к полномасштабной тестовой среде.
Последняя область, в которой можно найти усовершенствования, – это мастера создания трансформаций и java-фрагментов, которые агрегируют несколько входных сообщений в одно выходное.
Modeler версии 6 является дальнейшим развитием версии 5. Главная область усовершенствований – моделирование бизнес-параметров – выходит за рамки нашего сценария.
Существует несколько небольших изменений для улучшения интеграции Modeler с остальной частью решения, в частности:
Эта возможность немедленно устранила бы первый шаг, который мы делали в ходе
детализации BPEL из Modeler в WebSphere Studio
В этом сценарии мы уже использовали Rational
Функциональность, которая нам больше всего требовалась при разработке
в Rational
Проверьте: может быть, IBM или другой производитель уже разработали плагин. Существуют статьи, в которых обсуждаются проблемы, связанные с трансформацией между UML и WSDL. Обратитесь, например, к статье MS General Web services UML to WSDL Binding Auto-generation Guidelines, которую можно найти по адресу http://www.imsglobal.org/gws/gwsv1p0pd/imsgws_transfv1p0pd.html
Первая часть заключительной лекции представляет собой завершающий анализ. Какие уроки мы извлекли из создания решения? Повлияет ли этот опыт на интеграционные проекты, в которых будете принимать участие вы?
Во второй части лекции мы перечислим некоторые изменения, которые были
введены в следующую версию платформы WebSphere. Команда IBM System
House, которая, как вы, возможно, помните из предисловия, осуществляет
спонсорскую поддержку данного курса, отвечала за взаимодействие с разработчиками
с целью совершенствования интеграционных возможностей промежуточного
программного обеспечения от IBM. Поэтому для вас не должно
быть удивительным, что в версии 6 платформы WebSphere появилось много
новых возможностей и усовершенствований, которые делают создание сценария
для работы с внешними
Наиболее существенные улучшения можно найти в области интеграции
технологий обмена сообщениями и серверов приложений вокруг
Подробную информацию о применении данного профиля и расширении
возможностей Rational
Эти и другие усовершенствования должны подтолкнуть вас к тому, чтобы вы основывали свои новые интеграционные проекты на платформе WebSphere версии 6, а не версии 5.
Основные извлеченные нами уроки главным образом касаются способа совместной работы членов команды. В основном эти уроки сосредоточены на роли архитектора и взаимодействии архитектора с бизнес-аналитиком и ИТ-специалистом, а также на политиках и инструкциях, созданных для проекта бизнес-аналитиком и ИТ-архитектором. Метод совместной работы этих ролей и инструменты, помогающие им в работе, более чем что-либо иное определяют результат проекта по интеграции.
Мы обнаружили, что WebSphere Business Integration Modeler является полезным инструментом для формулировки требований и анализа.
Мы подчеркиваем слово "опытный", поскольку, когда целью является создание предсказаний на ранних стадиях, подробной информации о реализации процесса нет. Опытный бизнес-аналитик сможет указать элементы, имеющие значительную стоимость, и основные операции, не погружаясь в попытки моделирования деталей реализации процесса.
Мы обнаружили, что исходные цели бизнес-аналитика по сбору требований, изучению
возможностей для совершенствования процесса,
Чтобы можно было дать ход проекту в целом, определение процесса должно происходить параллельно с подробным анализом бизнеса.
Анализ процесса с точки зрения поиска возможностей для усовершенствования отличается от проектирования процесса, который будет надежно функционировать, используя комбинацию ручных и автоматизированных операций.
Нужно знать, что модель процесса, созданная бизнес-аналитиком, скорее всего, не будет для остального проекта полностью адекватным определением процесса.
В нашем проекте аналитик уделял основное внимание совершенствованию процесса,
которое необходимо для компании LGI, но не бизнес- и ИТ-взаимосвязям, которые
нужно создать между LGI и
Вот простой пример, где дополнительный анализ и использование лучших практических
схем для
В разделе 10.4.7, "Конфигурирование потока для ожидания ответа от
Принимающая операция была импортирована прямо из определения процесса
в бизнес-модели. До тех пор пока ИТ-специалист не начал тестировать процесс, не
было уделено достаточного внимания тому факту, что данная модель неявно требует,
чтобы ответы от
Если полагаться на выполнение двух приведенных ниже условий, реализация будет неустойчивой:
Более совершенной архитектурой было бы использование схемы публичного/личного
процесса, типичной для
Широко распространено мнение, что лучшей ИТ-моделью для взаимодействий с использованием протоколов является модель на основе конечных автоматов, а не модель процессов. В WebSphere Process Server Version 6 предлагается механизм реализации моделей конечных автоматов для бизнес-взаимодействий.
Наш вывод состоит в том, что модель
Например, в случае со сценарием для работы с внешними
С точки зрения процесса мы рекомендуем, чтобы:
Мы решили импортировать BPEL-код из Modeler и детализовать его в WebSphere Studio
Этот подход зародился в нашей команде после разработки
При разработке BPEL-модели аналитик и архитектор широко взаимодействовали
друг с другом в духе кооперативной разработки. Полученный BPEL-код был импортирован
в WebSphere Studio
Наша рекомендация для специалиста по процессу, которая наиболее подходит при использовании Modeler версии 6, состоит в том, чтобы перед экспортированием BPEL из Modeler детализовать бизнес-процесс, чтобы он соответствовал принятым стандартам, в частности по схеме имен и структуре пакетов. Специалист по процессу также может смоделировать потоки данных в модели процесса и сгенерировать BPEL-код, более напоминающий готовый исполняемый процесс.
Проводить обширное переименование и реорганизацию без создания нежелательных и трудных в устранении побочных эффектов сложно в любых инструментах. Проблема еще больше усложняется при использовании нескольких инструментов, которые связаны друг с другом механизмами экспорта/импорта и в которых изменения имен и интерфейсов должны отражаться в многочисленных артефактах. Мы вносили больше ошибок и тратили больше времени на нами же вызванные проблемы с изменениями имен и интерфейсов, чем во всех прочих проблемах исходного кода.
Мы предлагаем давать артефактам имена, состоящие из краткой описательной
части и простого уникального тега, например короткого числа. Имена можно объ-
единять путем добавления к номеру префикса для каждого подразделения, например,
AssessAvail_A1.wsdl. Избегайте любой ценой специальных
символов, таких, как (, [, {
и т. п. И старайтесь делать имена и пути действительно краткими, чтобы избежать
проблем с ограничением максимальной длины пути в продуктах Eclipse, работающих
в Windows. Может помочь создание соглашения об именах, основанного на компо-
нентах. Мы постоянно спрашивали: этот запрос о доступности направляется в прокси
или реальному
У нас были на выбор три формы метаданных для описания интерфейсов нашего решения:
Мы решили использовать WSDL. Это привело к некоторым проблемам при обмене
данными об интерфейсах между WebSphere Business
Теперь, когда WebSphere Business
Реализация потоков сообщений в брокере заняло больше времени, чем ожидалось.
Частично это явилось результатом того, что
Также мы никогда не касались проблем, связанных с обработкой ошибок на
транспортном уровне. Ошибки транспортных протоколов при использовании SOAP/
Некоторые из этих проблем сразу же разрешаются при переходе на WebSphere
Business
Уроки, которые мы извлекли из использования версии 5, следующие.
Отделяйте архитектуру и реализацию сервисной шины от дизайна и реализации компонентов proxyAssessorSystem, реализованных на этой сервисной шине.
ИТ-специалист, реализуя компоненты брокера, должен был сформировать основу
для передачи сообщений, а также реализовать специфические свойства, которые
требуются
При разработке сервисной шины и ее компонентов слишком мало учитывалась роль архитектуры. У архитектора не было инструментов для описания сервисной шины вплоть до уровня проектирования взаимодействий. Специалист по реализации обнаружил, что в версии 5 промежуточного ПО очень много работы требуется для того, чтобы создать сервисную шину, на основе которой строится система proxyAssessorSystem.
Основная причина этих проблем состоит в том, что нам нужно было пересмотреть
бизнес-требования с участием бизнес-аналитика, когда ИТ-архитектор выявил
необходимость создания системы proxyAssessorSystem. Результатом было бы более
четкое разделение проблем между
Более совершенный инструментарий
Использованный нами подход разработки, направляемой бизнесом, и создание решения для конкретной бизнес-проблемы сконцентрировали внимание нашей команды на моделировании решения, а затем на детализации модели вплоть до реализации с использованием многочисленных инструментов и компонентов промежуточного программного обеспечения.
В сравнении с общепринятой разработкой, направляемой информационными технологиями, мы меньше обращали внимания на разработку ИТ-инфраструктуры и как можно больше – на воплощение бизнес-требований в решении.
Нам нужно было уделить больше внимания пониманию и формулировке проблем, связанных с ИТ: архитектурные вопросы были возложены на ИТ-специалистов, которые решали их в ходе реализации. Проект выполнялся бы более эффективно, если бы эти проблемы были решены заранее. Это, вероятно, было признаком работы в лаборатории, без работы с реальной ИТ-инфраструктурой. Если бы это был реальный проект, то ИТ-инфраструктура уже существовала бы и больше внимания нужно было бы уделять внесению в нее изменений.
Тем не менее существует параллель, которую можно перенести на проекты в реальном
мире, в которых используют подход с разработкой, направляемой бизнесом.
Важно заранее определить, какие изменения и какие ресурсы должны быть введены в
команду, занимающуюся инфраструктурой, чтобы создать сервисную шину, поддерживающую
возможности, необходимые для новых
С момента реализации данного сценария большая часть соответствующего программного обеспечения перешла с WebSphere версии 5 на версию 6. В некоторых случаях различия в архитектуре и реализации были очень незначительны, но в других – внесены существенные улучшения, как в области повышения производительности разработки, так и в области надежности решения.
Система WebSphere MQ перешла с версии 5 на версию 6. Единственными изменениями, повлиявшими на проект, были следующие:
Версия WebSphere MQ Workflow повысилась с 3.1.4 до 3.1.7.
WebSphere Application Server V6.0 включает в себя платформу обмена сообщениями,
построенную на основе
WebSphere Business
WebSphere Business
В WebSphere
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 наш выбор
шаблона рабочей системы и выбрать вариант с шаблоном, ориентированным на
брокер (или
В версии 6 WebSphere Studio
Существует масса конкретных улучшений инструментария, которые упростят организацию процесса разработки и сделают разработку более продуктивной. Особенно заслуживают упоминания три изменения, поскольку они влияют на наш сценарий:
Одним из преимуществ, которые ощущаются сразу, является то, что обслуживать рабочий сервер гораздо удобнее, чем встроенный тестовый сервер, и, вероятно, серверных сред для управления станет меньше. Второе преимущество, касающееся разработчика, состоит в более простом переходе от модульного тестирования к полномасштабной тестовой среде.
Последняя область, в которой можно найти усовершенствования, – это мастера создания трансформаций и java-фрагментов, которые агрегируют несколько входных сообщений в одно выходное.
Modeler версии 6 является дальнейшим развитием версии 5. Главная область усовершенствований – моделирование бизнес-параметров – выходит за рамки нашего сценария.
Существует несколько небольших изменений для улучшения интеграции Modeler с остальной частью решения, в частности:
Эта возможность немедленно устранила бы первый шаг, который мы делали в ходе
детализации BPEL из Modeler в WebSphere Studio
В этом сценарии мы уже использовали Rational
Функциональность, которая нам больше всего требовалась при разработке
в Rational
Проверьте: может быть, IBM или другой производитель уже разработали плагин. Существуют статьи, в которых обсуждаются проблемы, связанные с трансформацией между UML и WSDL. Обратитесь, например, к статье MS General Web services UML to WSDL Binding Auto-generation Guidelines, которую можно найти по адресу http://www.imsglobal.org/gws/gwsv1p0pd/imsgws_transfv1p0pd.html
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.