Введение

В статье испоьзуется особый сценарий Обработки заказа и предоставления его производителю (OTMPS), который был рассмотрен в первой статье этой серии (см. Ресурсы), для описания способа интегрирования множественных объектов. Эти объекты представляют входные данные для IBM® WebSphere® Studio Application Developer Integration Edition(Application Developer) и применяются для разработки исполняемого приложения бизнес-процесса по требованию.

Рисунок 1 иллюстрирует разработку бизнес-процесса по требованию. Ценные наработки, такие как существующие XSD схемы могут быть импортированы в WebSphere Business Integration Modeler. После этого аналитик создает модель, используя WebSphere Business Integration Modeler (для получения подробной иформации обращайтесь к части 3 из этой серии статей -- см. Ресурсы). Полученные объекты экспортируются для дальнейшего использования в разработке исполняемого конечного продукта. Разработчик структуры использует IBM Rational XDE для моделирования прецедентов сценария и для разработки объектной модели процессов и сервисов. Java-классы генерируются из объектной модели с помощью функции XDE code generation. Экспортированная объектная модель затем преобразуется в элементы XML схемы с помощью Application Developer. Команда разработчиков использует Application Developer для того, чтобы интегрировать Java-код и элементы схемы XML с дополнительными компонентами и сервисами для завершения реализации исполняемого конечного продукта. Получившееся приложение (файл EAR) затем развертывается на WebSphere Business Integration Server Foundation.

Рисунок 2 иллюстрирует высокоуровневую структуру для OTMPS, с одним процессом (Order process subsystem) и тремя сервисами: 1)validation & topology generation, 2)manufacturing plant и 3) rule faсade. Клиентские приложения посылают заказы через сервисный интерфейс Order process Subsystem для осуществления процесса. Процесс принимает входные данные как группу заказов клиента, из клиентских приложений и отправляет проверенные, преобразованные заказы на производство. Сервис Validation & Topology Generation проверяет правильность заказов, взаимодействуя с внешними верификационными приложениями. Данные, посылаемые на этот сервис, упаковываюстя как Validation Info. Сервис Manufacture Plant отвечает за отправку подтвержденных заказов на соответствующее производственное предприятие, в виде Списка Материалов. Данные, посланные на этот сервис, упаковываются как Manufacturing Info. Оба сервиса предоставляют оболочку для существующих функций или приложений бизнес партнеров и используют протоколы, такие как WebSphere MQ, чтобы осуществлять взаимодействие с внешними приложениями. Для облегчения изготовления, компоненты процесса реализуют многие из своих решений по внешним правилам. Мы использовали структуру Business Rule Beans (BRBeans) для создания, изменения и активизации правил. Как показано на рисунке 3, правила определены в BRBeans и доступны через сервис rule service faсade.

В начало

Объектное моделирование

Вы можете использовать Rational XDE для моделирования объектов на Унифицированном Языке Моделирования (UML) и для того, чтобы генерировать необходимый Java-код. Для нашего сценария мы смоделировали объекты, такие как Order, OrderItem и OrderSubItem. Эти объекты используются как часть сообщений, которыми обмениваются между собой компоненты процесса и сервисы. Мы также смоделировали дополнительные объекты, такие как ExceptionInput, который используется как входное сообщение в обработке ошибок, и вспомогательные объекты, например, LogUtil для регистрации.

Для того, чтобы создать описанные выше объекты в Rational XDE, вам нужно для начала создать новый проект моделирования на Java с определенным именем и директорией по умолчанию, как показано на рисунке 3.

В Model Explorer View добавьте Java-пакет в модель, где вы храните объекты.

Откройте Main diagram (основную диаграмму) под Java-пакетом. В Main diagram используйте примечания UML для того, чтобы создать объекты с атрибутами и взаимоотношениями между ними. В нашем примере мы создали объекты Order, OrderItems и OrderSubItems. Объект Order имеет взаимоотношения агрегирования с OderSubItem, как показано в datagraph на рисунке 4.

После того, как модель готова, вы можете сгенерировать Java-код из модели, выбрав опцию меню, как показано на рисунке 5.

Листинг 1 - это сгенерированный java-код для объекта Orders.

				 
package OrderItem;
/** @modelguid {69ABC89D-F18E-402D-9A61-D08451525E2C} */
public class Orders {
	/** @modelguid {16A7446B-B7C8-44B9-B258-F0455190D1D1} */
	private Boolean valid;
	
	/** @modelguid {6C9862A0-8143-4E98-BB3C-896FD8C29DB5} */
	private String mfgNum;

	/** @modelguid {6F1E2C0A-D44C-483C-96BB-3142012825A5} */
	private Boolean lastMileStone;

	/** @modelguid {FBDFC07E-FA81-44C0-AF6F-3084457FBA6E} */
	private OrderItem[] orderItems;

	/** @modelguid {57915FCB-161C-41E0-B570-D59AA36CCF03} */
	private OrderItem_OrderItem;
}
            

В начало

Интеграция модели процесса и модели объекта в Application Developer

Application Developer предоставляет среду разработки для приложений на основе техпроцесса. Она состоит из следующих элементов:

• Мастер сервисных проектов для создания первоначального проекта техпроцесса;
• Редактор BPEL для представления техпроцессов через элементы BPEL;
• Редактор XSD схем для редактирования XML-схем;
• Мастер создания web-сервисов и генерации XML схем для Java-классов.

Исполняемое приложение техпроцесса состоит из:

1. Техпроцесса BPEL (файл BPEL);
2. Web-сервисов (WSDL, интерфейс сервиса/классы реализации);
3. XML-схем (файлы XSD) для сообщений между сервисными элементами;
4. Java-классов, использующихся как переменные в BPEL;

Аналитик может устанавливать требования для исполняемых техпроцессов из WebSphere Business Integration Modeler через экспортированные объекты (BPEL, XSD и WSDL). Для дальнейшей обработки вы должны импортировать эти объекты модели в Application Developer .

Импорт объектов BPEL/XSD/WSDL из WebSphere Business Integration Modeler.

Рисунок 6 показывает модель OTMPS процесса OrderProcessSystem, экспортированную из WebSphere Business Integration Modeler. В данном технологическом процессе реализованы различные действия, точки принятия решений, планирование, циклы, пункты исполнения бизнес-правил, и получение доступа к сервисам.

Когда вы импортируете объекты в Application Developer из WebSphere Business Integration Modeler, импортируйте структуру папки, которая была сгенерирована при экспортировании из WebSphere Business Integration Modeler, так как созданные файлы используют эту структуру для того, чтобы ссылаться друг на друга.

Есть два способа экспортирования объектов модели процесса (BPEL, XSD, WSDL) из WebSphere Business Integration Modeler (более подробно см. Часть3 данной серии статей):

1. Экспортировать файлы в существующий сервисный проект в Application Developer;
2. Экспортировать файлы в любую директорию в файловой системе.

Если вы используете существующий сервисный проект в Application Developer, то мы рекомендуем вам, выполнить следующие шаги:

1. Во время экспортирования из WebSphere Business Integration Modeler, выберите в качестве экспортной директории местоположение сервисного проекта для Application Developer;
2. После того, как вы закончили экспортирование, запустите Application Developer. В навигаторе сервисов, обновите проект. Экспортированные файлы (BPEL/XSD/WSDL) автоматически импортируются в сервисный проект. Application Developer использует файлы для того, чтобы сгенерировать другие требуемые элементы, такие как Java-реализации каждого многосложного типа, XSD схемы и дополнительные WSDL-файлы.

Однако, если вы экспортируете объекты модели процесса WebSphere Business Integration Modeler в определенную директорию, вы должны осуществить следующие шаги для того, чтобы импортировать эти объекты в Application Developer:

1. В Application Developer создайте новый сервисный проект в перспективе Business Integration. Это сервисный проект, для которого вы собирались импортировать объекты из WebSphere Business Integration Modeler;
2. Импортируйте в сервисный проект директорию, в которую вы экспортировали файлы из WebSphere Business Integration Modeler. Эти файлы импортируются в выбранный вами проект.

Сервисный проект Application Developer включает web-сервисы и объекты процесса, расположенные в отдельных папках.

После того, как вы импортировали объекты, экспортированные из WebSphere Business Integration Modeler и обновили сервисный проект, вы увидите BPEL-процесс (например, OrderProcessSystem) в папке сервисного проекта. Рисунок 7 показывает сервисный проект OrderProcessSystemWorkflow с OrderProcessSystem.bpel и другими импортированными файлами.

После того, как вы импортировали объекты из WebSphere Business Integration Modeler в сервисный проект, откройте BPEL файл в редакторе BPEL. Рисунок 8 показывает BPEL-процесс для OrderProcessSystem.

BPEL-верификация

Все ошибки BPEL-верификации следует исправлять в редакторе BPEL. Например, если модель WebSphere Business Integration Modeler содержит служебное ролевое имя и модель экспортируется как микропоток больший, чем длина запущенного процесса (макро потоки), то некоторые служебные переменные (такие как служебные входные данные, или служебные выходные данные) будут автоматически генерироваться во время экспортирования WebSphere Business Integration Modeler. Это не является правильным для микропотока BPEL , потому что служебные действия могут быть связаны только с макропотоками. Разработчик увидит ошибки в редакторе BPEL, и должен будет их исправить, например, удаляя связанные служебные переменные.

В начало

Включение дополнительных моделей данных

Процессы и сервисы в системе используют элементы данных как часть процесса обмена сообщениями. Бизнес объекты экспортируются из WebSphere Business Integration Modeler в виде XSD-файлов.

Дополнительные Java-классы и соответствующие объекты XML-схем необходимы для реализации техпроцесса. Примеры этих расширенных объектов включают:

• Внутренние объекты, такие как объекты менеджера состояния техпроцесса;
• Контекстные данные клиента для событий;
• Объекты, используемые для исполнения бизнес правил;
• Внешние сервисные сообщения;
• Объекты, используемые для реализации внутренних сервисов.

Мы используем Rational XDE для создания этих дополнительных объектов и их Java-кода. Проект моделирования созданный в Rational XDE - это Java-проект с дополнительными объектами (такими как файлы модели), которые импортируются в Application Developer.

Если Java-объекты импортируются из Rational XDE и используются как часть обмена сообщениями (входящими/исходящими/сообщениями ошибок), то соответствующие XSD-элементы должны быть созданы с помощью Application Developer. Эти объекты и XSD-схемы являются частю генерации сервисного интерфейса и служебных объектов процесса. Они используются для получения доступа к сервисам партнеров. Другими словами, операции партнеров включают их как часть своих сообщений.

Вы можете ввести эти объекты через глобальные переменные Java или элементы XML-схемы. Чтобы использовать объекты как глобальные переменные Java, добавьте их в свойство "imports" в списке свойств процесса, нажав на заголовок процесса, например, OrderProcessSystem, как показано в рисунке 9.

Глобальные переменные Java могут быть доступны во всех действиях внутри процесса, куда импортированы объекты, но не доступны в подпроцессах.

Добавление глобальных переменных Java в области импортированных данных приводит к созданию элемента javaGlobals внутри BPEL файла процесса OrderProcessSystem, как показано в листинге 2.

				 
<process expressionLanguage="Java" name="OrderProcessSystem">
<wpc:javaGlobals>
		<wpc:import packages="com.ibm.coats.logging.LogUtil"/>
	      		
</wpc:javaGlobals>	
<process/>
            

XSD файл генерируется для каждого объекта, и используется в файле WSDL, на который ссылаются сообщения. Рисунок 10 показывает, как сообщение handleExceptionRequest ссылается на XSD-схему, сгенерированную из объекта ExceptionInput.

Бизнес объекты могут быть смоделированы с помощью WebSphere Business Integration Modeler или Rational XDE. В Rational XDE бизнес объекты моделируются и экспортируются как Java-классы. Эти Java-классы позднее могут быть преобразованы в элементы XML-схем для того, чтобы использовать их в качестве частей сообщений в определении WSDL, соответствующих web-сервисов. Потом, если вы генерируете Java-прокси или заглушки для этих сервисов (из WSDL-файлов), будет сгенерирован новый набор объектов данных с соответствующими операциями сериализации/де-сериализации и классами.

У нас есть два различных набора объектов данных для одинаковых бизнес-объектов – один импортирован из Rational XDE, а другой сгенерирован из WSDL-файла. Например, в объектах данных, созданных Rational XDE нет методов для поддержки определенной сериализации/де-сериализации, требующейся для web-сервисов. Они могут вызвать ошибки сериализации динамических данных при использовании с реализациями сервисов и клиентскими прокси. Вот некоторые рекомендации, которые могут помочь избежать этой проблемы:

1. Используйте объекты данных сгенерированные с помощью WSDL для сервисного обмена сообщениями и объекты данных из Rational XDE для внутренних операций сервисов и техпроцесса и добавляйте необходимые трансформации данных. Разработчики должны использовать подходящую структуру пакетирования (такую как отображение клиентского пространства имен в течение генерации объектов из WSDL) во время создания этих объектов для того, чтобы избежать переписывания существующих классов;
2. Используйте Rational XDE для моделирования бизнес-объектов, экспортируйте их как Java-классы, преобразуйте их в элементы XML-схем, и введите в WebSphere Business Integration Modeler. Затем все бизнес объекты будут экспортированы из WebSphere Business Integration Modeler.

После импортирования всех необходимых объектов, которые были экспортированы из Rational XDE и WebSphere Business Integration Modeler, разработчики добавляют определенные необходимые расширения к этим объектам, включая следующие:

• Обработчики ошибок для фиксирования системных исключений;
• Фрагмент Java-кода для реализации преобразования данных/генерации событий;
• Расширение бизнес-правил с использованием инструментов правил;
• Генерация привязок для сервисных конечных точек.

Эти расширения разработки будут рассмотрены в последующих статьях.

В начало

Заключение

Авторы описали структуру сценария OTMPS и использование Rational XDE для моделирования бизнес объектов на UML. Они рассказали, как интегрировать объекты, экспортированные из WebSphere Business Integration Modeler и Rational XDE для дальнейшей разработки в Application Developer. В следующей статье будет рассказано о разработке исполняемого приложения для процесса по требованию при помощи WebSphere Studio Application Developer Integration Edition.

Благодарности Авторы хотели бы поблагодарить Мартина Кина, Навьен Сачдева и Катерину Риви за их вклад, советы и помощь.

Ресурсы

• Оригинальная статья On demand business process life cycle, Part 4: Create the foundation for your on demand business processes.
  
  
• Предыдущие статьи серии "Жизненный цикл бизнес-процессов по требованию":
  • Часть 1: Создание основы для вашего бизнес-процесса по требованию
  • Часть 2: Процесс создания шаблонов электронного бизнеса
  • Часть 3: Моделирование бизнес-процессов при помощи WebSphere Business Integration Modeler
  
  
• Читайте спецификацию по A Business Process Execution Language для Web-сервисовМай 2003
  
  
• Узнавайте о том, как использовать BPEL и язык программирования Java вместе, чтобы создать приложения бизнес процесса в статье BPELJ: BPEL for Java technology.
  
  
• Технический комитет OASIS Web Services Business Process execution language
  
  
• Исследуйте технические подробности по Process Choreographerв WebSphere Business Integration Modeler.
  
  
• Посетите Книжный магазин Разработчика для полного перечня технических книг, включая сотни статей по Web-сервисам.
  
  
• Хотите еще? Зона developerWorks SOA and Web services включает сотни информативных статей и учебных пособий начального, среднего и продвинутого уровней о том, как разрабатывать Web-сервисные приложения.
  
  

Об авторах

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Объектное моделирование
• Интеграция модели процесса и модели объекта в Application Developer
• Включение дополнительных моделей данных
• Заключение
• Ресурсы
• Об авторах
• Комментарии