При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Вся введенная информация защищена.

My developerWorks:

Сообщения:

Выйти

Выбрать язык:

Миграция с WebSphere Commerce на инструментарий SOA: Часть 1, Введение в серию

Шива Мохан, разработчик ПО, IBM

Шива Мохан (Shiva Mohan) готовится получить степень магистра по электронно-вычислительной технике (робототехника в медицине) в Университете Восточного Онтарио (UWO), Канада. В качестве техника-стажёра он принимал участие в программе IBM Extreme Blue в 2006 г. Он имеет степень бакалавра наук по информатике (с отличием), полученную в UWO, и в дальнейшем намеревается стать магистром делового администрирования. Его предыдущий исследовательский опыт был связан с проектами, имеющими отношение к сервис-ориентированной архитектуре, соглашениям об уровне сервиса и показателям уровня сервиса. Два из этих проектов экспонировались на CASCON 2004 и 2005.

Дэвид Юань, разработчик программного обеспечения, IBM

Дэвид Юань (David Yuan) - специалист по разработке программного обеспечения в группе разработки e-Commerce в лаборатории IBM в Торонто. Уже три года Дэвид занимается вопросами миграции WebSphere Commerce. В его компетенции находятся вопросы распределённой конфигурации и миграции WebSphere Commerce. Дэвид имеет учёную степень кандидата наук по молекулярной биологии. Ранее он открыл два новых гена в геноме человека.

Описание: В Части 1 данной серии статей из пяти частей содержится обзор перевода бизнес-процесса с WebSphere® Commerce на SOA при помощи методики Esperanto.

Пометить это!

Дата: 20.06.2007
Уровень сложности: средний
Активность: 1265 просмотров
Комментарии:

Введение

Эта первая статья предваряет серию статей из пяти частей, в которой предлагается обзор необходимых шагов по переводу бизнес-процесса с WebSphere Commerce на модель жизненного цикла сервис-ориентированной архитектуры (SOA) при помощи инструментов SOA foundation. Эта серия публикуется как часть проекта Extreme Blue 2006 года, Esperanto. В проекте разрабатывалась методика поэтапной миграции ранних J2EE-приложений на модель жизненного цикла SOA. В рамках проекта мы в качестве эксперимента применяли нашу методику к WebSphere Commerce. В данных статьях обсуждается применение этого приложения. В этой статье, первой в серии, приводится обзор серии, рассматриваются относящиеся к делу аспекты WebSphere Commerce, а также инструменты SOA.

В начало

Зачем переходить на SOA?

Модель жизненного цикла SOA состоит из:

Моделирования бизнес-процессов в ПО.
Сборки процессов как сервисных компонентов.
Развёртывания сервисных компонентов в среде выполнения.
Мониторинга развёрнутых процессов на предмет циклических улучшений и оптимизации.

Применение Esperanto к WebSphere Commerce предполагает следующие внешние процессы:

Моделирование в WebSphere Business Modeler.
Сборку в WebSphere Integration Developer.
Выполнение в WebSphere Process Server.

Моделирование процессов в WebSphere Business Modeler позволяет клиентам WebSphere Commerce запускать симуляции и получать динамический отклик на развёрнутом экземпляре WebSphere Commerce. Это помогает определить области системы, которые клиенты хотели бы изменить. Использование WebSphere Integration Developer обеспечивает более лёгкое изменение процесса, разработчики имеют дело с визуальными процессами, которые можно легко переконфигурировать для удовлетворения нужд клиента. К тому же, предусматривается включение выполняемых человеком задач в правила эскалации, таймауты и роли, а также экстернализация бизнес-политик для улучшения конфигурируемости при выполнении.

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

В начало

Обзор серии

В серии готовящихся к публикации руководств и статей мы обсудим применение методики Esperanto к WebSphere Commerce:

В первом руководстве, "Часть 2: Как заставить WebSphere Commerce и WebSphere Process Server разговаривать", подробно рассматриваются шаги, необходимые для того, чтобы заставить сервер WebSphere Commerce, раннее J2EE-приложение, "разговаривать" с WebSphere Process Server, одним из инструментов SOA foundation, в сквозном режиме (при котором поток управления идёт от WebSphere Commerce к процессу, а затем обратно к серверу WebSphere Commerce).
Во втором руководстве, "Часть 3: Экстернализация разрешения на выполнение с сервера WebSphere Commerce на WebSphere Process Server", демонстрируется сама миграция. Мы начинаем с процесса в WebSphere Commerce и обработки заказов. Затем мы определяем, какой подпроцесс мы хотим перевести на SOA - разрешение на выполнение (release to fulfillment). После создания процесса мы модифицируем WebSphere Commerce для многократного использования ключевых шагов процесса, и одновременно экстернализируем политики и логику процесса для обеспечения более лёгкого его изменения.
Плоды экстернализации мы пожинаем в "Части 4: Экстернализация разрешения на выполнение с WebSphere Commerce на WebSphere Process Server". Мы показываем изменение процесса в WebSphere Commerce, добавляя такие функции как выявление подлогов, задержки времени выполнения заказов, одобрение со стороны продавца и т. д. Для этого требуется меньше времени и небольшие изменения в коде Java™.
Последняя статьи из этой серии, "Часть 5: Соединяем всё вместе - методика Esperanto", содержит некоторую информацию по данной методике. В Части 5 объясняются различные конструктивные шаблоны методики Esperanto, когда она применяется на этапе анализа и изменения кода.

Предполагаемая аудитория

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

В начало

Чему вы научитесь из этих статей

Прочитав эти статьи, вы сможете:

Извлекать процесс из WebSphere Commerce в SOA.
Помещать извлечённый процесс обратно в WebSphere Commerce, чтобы коммуникация между процессом и сервером была бесшовной.
Влиять на изменение процесса и экстернализировать политики во вновь созданных процессах, чтобы своевременно и с экономической выгодой изменять поведение WebSphere Commerce.

В начало

Обзор WebSphere Commerce

WebSphere Commerce предоставляет полный набор инструментов и интерфейсов для разработки Web-сайта электронной коммерции. Он обеспечивает разработчику достаточную гибкость, чтобы быстро создавать специализированные решения, эффективно решающие бизнес-проблемы:

Создание сайта "бизнес для клиента" (business to consumer, B2C).
Создание сайта "бизнес для бизнеса" (business-to-business, B2B), соединяющегося с существующими системами, поставщиками и дистрибьюторами.

Ключевые компоненты решения WebSphere Commerce показаны на Рисунке 1. В него включены функции каталога, продажи, маркетинга, торговли и управления заказами.

Рисунок 1. Ключевые компоненты WebSphere Commerce

В WebSphere Commerce используется конструктивный шаблон Модель-Представление-Контроллер (Рисунок 2). Большинство сегодняшних Web-приложений используют сегодня этот же самый шаблон. Контроллер слушает события, запускаемые представлением, и выполняет соответствующие действия.

Рисунок 2. Конструктивный шаблон Модель-Представление-Контроллер в WebSphere Commerce

Сервер WebSphere Commerce принимает запросы от приложений тонких клиентов на основе браузера. Все запросы, в каком бы формате они ни были, транслируются в общий формат уровнем контроллера (шаблон MVC). Как только запросы будут переведены в этот общий формат, их будут понимать команды WebSphere Commerce.

Команды WebSphere Commerce - это Java-компоненты, содержащие программную логику, связанную с обработкой конкретного запроса. Основные типы команд - команды контроллера и команды задач.

Команды контроллера: Содержат логику, относящуюся к определённому бизнес-процессу. Используйте их для реализации высокоуровневой логики процесса для бизнес-задачи. В общем, команды контроллера содержат управляющие операторы (например, "if, then, else") и активизируют команды задач для выполнения отдельных задач в бизнес-процессе. По умолчанию для команд контроллера задействован контроль доступа.
Команды задач: Реализуют отдельные фрагменты бизнес-задачи. По умолчанию для команд задач не используется контроль доступа. Механизм презентации и лежащее в его основе представление данных показано на Рисунке 3.
Фасад бизнес-логики: Фасад бизнес-логики активизирует соответствующую команду контроллера. Этот стандартный интерфейс реализуется как сессионный компонент без сохранения состояния, который вызывается контроллером для инициирования команд контроллера.
Компоненты доступа: Компоненты доступа - это простые персистентные объекты с методами setter и getter. Компонент доступа ведёт себя как Java-компонент и скрывает он клиента все относящиеся к конкретным корпоративным компонентам программные интерфейсы, например JNDI, домашний и удалённый интерфейсы. Rational® Application Developer обеспечивает инструментальную поддержку для создания компонентов доступа из схемы.

Рисунок 3. Уровни презентации и данных в WebSphere Commerce

Подсистема "Управление заказами" состоит из трёх частей, как показано на Рисунке 4.

Рисунок 4. Подсистема управления заказами в WebSphere Commerce

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

В начало

Среда Web-сервисов

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

При экстернализации бизнес-операций в WebSphere Commerce как Web-сервисов, WebSphere Commerce становится сервис-провайдером. Модель развёртывания для Web-сервисов предполагает наличие центрального сервера с опубликованным WSDL, определяющим поддерживаемые сервисы. Оттуда клиенты, будь то внешние системы, Web-приложения или расширенные клиентские приложения, подключаются к центральному серверу и вызывают сервисы, определённые общедоступным WSDL.

При обработке запросов Web-сервисов движок Web-сервисов WebSphere Application Server передаёт запрос к среде Web-сервисов WebSphere Commerce. Среда обрабатывает запрос и генерирует ответ. Для генерации подобных SOAP-ответов в среде используются сервисы составления JSP. На Рисунке 5 приводится общая схема среды Web-сервисов WebSphere Commerce.

Рисунок 5. Среда Web-сервисов в WebSphere Commerce

При вызове бизнес-операций, находящихся вне WebSphere Commerce, последний становится пользователем сервиса. WebSphere Commerce поддерживает создание клиентов для OAGIS-основанных Web-сервисов. Он обеспечивает два типа клиентских инструментариев для вызова Web-сервисов: с применением подхода JAX-RPC, а также инструментарий Eclipse Modeling Framework (EMF).

В начало

Обзор инструментов SOA foundation

В данных статьях мы будем использовать WebSphere Business Modeler (далее - Business Modeler), WebSphere Integration Developer (далее - Integration Developer) и WebSphere Process Server (далее - Process Server).

Business Modeler моделирует бизнес-процессы, которые мы хотим экстернализировать. Мы используем эти модели для выполнения симуляций, просмотра влияния на изменение процесса и их экспорта в Integration Developer. Экспорт - это начало создания исполняемых процессов, запускающихся на сервере процессов. Business Modeler помогает полностью визуализировать, понять и задокументировать бизнес-процессы. Функция совместной работы, когда специалисты в данной области объединяются в группу для чёткого определения бизнес-моделей и повышения эффективности, приносит быстрые результаты. Это усиливает связь между процессами WebSphere Commerce и стратегическими задачами клиента.

После моделирования процессов в Business Modeler, мы собираем модели как исполняемые процессы в Integration Developer. Мы создаём процессы BPEL и собираем сервисные компоненты. Использование модели программирования архитектуры компонентов сервиса (Service Component Architecture, SCA) и модели данных объектов данных сервиса (Service Data Objects, SDO) упрощает интеграцию. SCA-компоненты определяют, трансформируют, маршрутизируют и являются посредниками бизнес-объектов SDO. Кроме того, WebSphere Adapters обеспечивают возможность соединения с серверами Enterprise Information Systems.

И наконец, процессы разворачиваются на Process Server. Process Server обеспечивает идеальную платформу для улучшенной бизнес-интеграции с помощью различных технологий. При помощи Process Server приложения бизнес-интеграции определяют бизнес-логику и процессы на основе Web Services - Business Process Execution Language (WS-BPEL), задач для выполнения человеком и бизнес-правил. Process Server также поддерживает Common Event Infrastructure (CEI) для динамического мониторинга событий. Это обеспечивает продвинутую функциональность, например правила эскалации для выполняемых человеком задач.

Кроме того, использование WebSphere Business Monitor (не обсуждается в данных статьях) обеспечивает полный цикл обратной связи с Business Modeler путём наблюдения за поведением моделей при их выполнении в Process Server. Это позволяет клиентам запускать симуляции, основываясь на реальных данных с развёрнутых систем.

В начало

Заключение

В данной статье приводится обзор готовящейся к публикации серии статей из четырёх частей по поэтапному переходу на SOA для WebSphere Commerce. Части 2 - 5 этой серии будут опубликованы в течении нескольких следующих месяцев, и в них будет идти речь о преимуществах SOA и методики Esperanto.

Ресурсы