(Building a Web Services Network with BPEL
by Yves Coene and The Hoa Nguyen, OracleCorporation) Ивс Коэн,
Хоа Нгуен
Источник: сайт технологий корпорации Oracle (http://www.oracle.com/technology/index.html ), SOA Best Practices: The BPEL Cookbook ("Лучшие методы SOA: Рецептурная книга BPEL"), http://www.oracle.com/technology/pub/articles/bpel_cookbook/coene.html
Учебный пример, как European Space Agency (Европейское управление космических исследований) использовало возможности BPEL, домены BPEL и API Oracle BPEL Process Manager при построении удобной для партнеров сети Web-сервисов.
Загрузите для этой статьи:
Oracle BPEL Process Manager and Designer (http://www.oracle.com/technology/software/htdocs/devlic.html?url=http://www.oracle.com/technology/software/products/ias/bpel/index.html)
Благодаря поддержке со стороны набирающих силу стандартов Web-сервисов, все большее число организаций использует Web-сервисы в средах коллективной работы. Язык BPEL быстро становится платформой для управления Web-сервисами для совместной работы с участием нескольких предприятий. Язык BPEL предлагает компаниям, строящим онлайновый рынок или сеть для совместной работы, убедительные преимущества, опирающиеся на интеграцию слабосвязанных процессов и подход на основе стандартов.
Тем не менее, новые впечатляющие функциональные возможности, предлагаемые Web-сервисами, все же несут с собой некоторый риск. Во многих случаях ломаются отношения между партнерами или стремительно взлетает стоимость интеграции, если во время проектирования не было обращено внимание на определенные технические и административные проблемы:
• Партнеры должны заранее согласиться с ведением бизнеса согласно определенным критериям. Должны быть четко оговорены транспортный протокол, цель взаимодействия, форматы сообщений и деловые ограничения.
• Включение в сеть должно быть простым процессом; сети для совместной работы становятся результативными (successful), главным образом, благодаря своему расширению.
• Пользователи должны легко находить функционирующие бизнес-сервисы, иначе можно считать в значительной степени утраченными претензии сервис-ориентированной архитектуры (SOA). (Для этой цели полезны репозитории сервисов.) Если разработчики не могут без труда найти и многократно использовать сервисы, то можно сказать, что сервисы отсутствуют.
• Партнеры должны иметь возможность вести мониторинг Web-сервисов в реальном времени. Конечные пользователи должны быть в состоянии проследить движение определенного заказа, а партнеры по торговле - диагностировать конкретные "узкие места" в рамках бизнес-процесса.
Эти проблемы усиливаются, когда сеть для совместной работы эксплуатируется в хост-машинной среде (hosted environment). В этом случае партнеры преобразуют функциональности, которыми обладают унаследованные ими приложения, в Web-сервис. Этот Web-сервис публикуется в централизованном репозитории. Хост несет ответственность за управление сложными бизнес-процессами, которые, в свою очередь, используют Web-сервисы партнера.
В этой части The BPEL Cookbook "Поваренной книги BPEL" мы хотим выяснить архитектурные построения, связанные с упомянутыми проблемами, используя в качестве учебного примера проект European Space Agency (ESA), в разработке которого принимала участие наша группа из компании Spacebel s.a (Бельгия). Также мы обсудим как в этом проекте для построения дружественной к партнерам сети для совместной работы были использованы возможности BPEL, домены BPEL, и API Oracle BPEL Process Manager.
Краткий обзор сети ESA
В ESA была предпринята стратегическая инициатива по созданию управляемой BPEL-сети для совместной работы поставщиков сервисов, которая полностью базируется на открытых стандартах. В этой сети, получившей название "сеть Service Support Environment (SSE - среда поддержки сервисов)", объединяются сервисы от третьих фирм Earth Observation (EO) и Geographic Information System (GIS), чтобы предложить пользователям сложные сервисы с добавленной стоимостью. SSE является растущей сетью, в которой в настоящее время участвуют более 20 партнеров из девяти различных стран Европы.
Как показано на рис. 1, SSE представляет простую реализацию сети с поддержкой BPEL. Агентство ESA действует как брокер-посредник, который поддерживает совместную ориентированную на процессы работу различных партнеров по стандартам Web-сервисов: SOAP, WSDL, WS-Addressing, WS-Inspection и других. Эта сеть работает, используя топологию "ступица и спицы" (hub-and-spoke topology): поставщики услуг используют Oracle BPEL Designer, чтобы внести различные типы сервисов Earth Observation и GIS в централизованный репозиторий, создавая, таким образом, постоянно расширяющийся каталог сервисов.
SSE предлагает необходимую инфраструктуру для:
• размещения и управления центрального репозитория, который служит каталогом доступных сервисов;
• регистрации и поиска сервисов в центральном каталоге;
• выполнения как краткосрочных, так и длящихся значительное время бизнес-процессов в механизме Oracle BPEL;
• предоставления партнерам возможности вести мониторинг выполнения Web-сервисов, используя консоль Oracle BPEL Process Manager.
Конечные пользователи запрашивают определенные сервисы, просматривая каталог доступных сервисов. После получения запроса SSE вызывает требуемый бизнес-процесс. Этот бизнес-процесс для завершения запроса вызывает Web-сервис (который выполняется в местоположении поставщика сервисов).
Рисунок 1. Архитектура SSE
Сеть SSE допускает как синхронные, так и асинхронные модели взаимодействия. Агентство ESA экстенсивно использовало API Oracle BPEL Process Manager, чтобы предложить поставщикам сервисов и конечным пользователям предельно гибкие и простые в употреблении наработки.
Проектирование сети Web-сервисов
Открытые стандарты изменяют правила интеграции. В BPEL предлагается ориентированный на процессы подход к интеграции по всем предприятиям, в соответствии с которым взаимодействия партнеров определяются с использованием потоков процесса BPEL. Такая смесь SOA и BPEL обеспечивает уникальную возможность строить слабосвязанные сети для совместной работы.
"Ступица и спицы" (так принято называть подход, используемый в SSE) представляет собой широко используемую топологию сети, в которой подключение к различным партнерам устанавливает одна организация. Альтернативно, в сети может быть принята односторонняя одноранговая модель. В этом случае каждый партнер предлагает платформу для обеспечения защиты и подготовки к работе (инициализации) Web-сервисов.
Теперь исследуем следующие четыре области проектирования сети:
• настройка отношений интерфейса;
• упрощение вступления партнеров;
• создание централизованного реестра сервисов ;
• предоставление партнерам и конечным пользователям возможностей ведения мониторинга в режиме самообслуживания.
Настройка отношений интерфейса. Проектирование сети для совместной работы начинается с определения правил применения. Эти правила определяют сообщения, которыми обмениваются в рамках бизнес-процесса, последовательность, в которой происходит этот обмен сообщениями, и физические атрибуты этого сообщения. Чтобы партнеры могли общаться должным образом, все они должны быть в состоянии ответить на следующие вопросы:
• цель взаимодействия - является ли этот запрос запросом о цене или заказом?
• формат сообщения - как закодировано это сообщение?
• словарь - как должны быть структурированы наши сообщения, чтобы другие стороны могли понять и обработать их?
• деловые ограничения - как скоро мы должны ответить на запрос?
• канал связи - должны ли быть зашифрованы наши сообщения?
Чтобы помочь партнерам получить ответы на эти вопросы, агентство ESA от имени общественности опубликовало Interface Control Document ("Документ о контроле интерфейса") (http://services.eoportal.org/massRef/documentation/icd.pdf) для определения этих условий. В этом документе формализуются технические правила интеграции, которые были установлены, усовершенствованы и подтверждены в процессе разработки нескольких финансировавшихся ESA проектов. Протоколами для коммуникации между сервером SSE и поставщиками услуг являются SOAP с ориентацией на передачу сообщений по HTTP или HTTP для защищенного взаимодействия. (На момент написания настоящего документа мы анализируем использование спецификации WS-Security.) Язык определения Web-сервисов (Web Services Definition Language - WSDL) - это единственный контракт (точно определённое соглашение) интерфейса, связывающий все объекты; поставщик услуг должен создать файл WSDL, в котором описывается его интерфейс SOAP, и сделать этот файл доступным для других партнеров. Часть информации, содержащейся в файле WSDL, является фиксированной, но следующая информация должна быть представлена:
• выбор операции согласно выбранной модели взаимодействия (поиск, RFQ, заказ);
• физическое местоположение сервисов;
• импорт XSD Schema сервиса.
Для облегчения сравнения сервисов, согласованности и трансляции сообщений ESA передает полномочия использование XSD Schema, чтобы срочно отправить полезные XML-грузы. Кроме того, SSE требует использования главного (master) документа XSLT для гарантирования согласованности на уровне представления. В каждый сервис должна быть следующим образом импортирована таблица стилей шаблонов:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:oi="http://www.esa.int/oi">
<!-- Операторы импорта -->
<xsl:import href="./SSE.xsl"/>
<!-- Примените шаблон для корневого элемента из стандартного шаблона SSE -->
<xsl:template match="/">
<xsl:apply-imports/>
</xsl:template>
...
xsl:apply-imports обрабатывает корневой узел, используя правила шаблона, импортированные из таблицы стилей SSE. При регистрации сервиса поставщик сервисов обеспечивает URL XML Schema, WSDL и файл XSLT. Использование сети SSE предполагает применении стиля документа SOAP. Такой подход учитывает детализированную спецификацию сервиса - входные и выходные данные, а также проверку правильности входящих и исходящих сообщений, используя для этого XML Schema.
Принятый в ESA подход предлагает быстро создаваемые решения для компаний, рассчитывающих запустить сеть Web-сервисов с ограниченным числом партнеров. По мере роста размера сети потребуется ввести новые варианты форматов сообщений, правил коммуникации, обеспечения безопасности и механизмы транспорта.
Упрощение вступления партнеров. Рост любой сети в значительной степени зависит от той степени непринужденности, с которой новые партнеры могут присоединиться к ней и участвовать в ее работе. Для воздействия на этот процесс могут оказать большое влияние следующие факторы:
• интеграция с хабом - как партнеры создают и представляют свои Web-сервисы? Может ли хаб поддерживать различные транспортные протоколы?
• управление процессом - имеется ли надлежащее разграничение между процессами различных партнеров? Может ли партнер изменить свой бизнес-процесс, не затрагивая при этом надежность всей сети? Могут ли процессы быть сгенерированы "на лету" с использованием определения метаданных?
Сеть SSE преуспела в установлении наиболее сильных связей со своими партнерами, упрощая для этого технические требования, налагаемые на поставщиков сервисов. Агентство ESA достигает этой цели, распространяя среди партнеров программные средства для обеспечения связи между системами, разделяя платформу разработки и автоматически генерируя от имени партнеров потоки процесса.
Например, для ускорения процесса интеграции ESA распространяет SSE Toolbox - бесплатный инструментарий, который действует как интерфейс между SSE и существующими системами поставщиков сервисов. Комплект инструментов SSE, который построен на базе Sun Java Web Services Developer Pack (Пакет разработчика Web-сервисов на Java компании Sun), предлагает язык сценариев XML, поддерживающий различные механизмы внутренней интеграции; FTP, обмен файлами, JDBC, вызовы API Java, HTTP и так далее. Кроме того, он автоматически генерирует файл WSDL, требующийся для регистрации сервисов.
Различные партнеры вносят в центральный репозиторий множество сервисов. Разделение сред разработки и развертывания ограждает партнеров от изменений, производимых другими партнерами. В сети SSE такое разделение эффективно применяется при использовании доменов BPEL в среде Oracle BPEL Process Manager. Домены BPEL позволяют разработчику или администратору разделить единственный экземпляр Oracle BPEL Process Manager на многочисленные виртуальные "песочницы" BPEL. Домен BPEL идентифицируется с помощью идентификатора (ID) и защищен паролем. Когда поставщик сервисов регистрируется в сети SSE, API Oracle BPEL Process Manager вызывается для автоматического создания домена BPEL, в котором будут содержаться файлы определения сервисов.
Ниже приводится пример метода createDomain:
/**
* Создайте новое пространство домена для поставщика сервисов,
* предназначенное для хранения последовательности операций ее/его сервисов
* определения файлов в
*
* @param domainName Идентификатор для определения домена
* @param password Пароль, используемый для входа в соответствующий домен
* @exception RemoteException Системная ошибка коммуникации
* @exception WorkflowException Генерируется, если на сервере случайно
* произошла какая-то ошибка, не позволяющая произвести удаление
*
*/
throws RemoteException, WorkflowException{
if(ml.isDebugEnabled()) ml.debug("Enter createDomain
(domain = " + domainName + " password = " + password);
/**
* check if the being created domain exist?
*/
try {
Locator locator = new Locator(domainName, password);
ml.info("Stop creating domain: " + domainName +
" because it has already existed.");
throw new WorkflowException("1019");
} catch (com.oracle.bpel.client.ServerException e) {
;
}
try {
//obtain the domain admin password from the system configuration SSE.properties file
String domainAdminPassword = SystemConfigurationInfo.getProperty
(WorkflowConstant.BPEL_DOMAIN_ADMIN_PASSWORD);
ServerAuth auth = ServerAuthFactory.authenticate( domainAdminPassword, "localhost" );
if(ml.isDebugEnabled()) ml.debug("obtain authentication ok");
// Create server object ... this is our service interface
//
Server server = new Server( auth );
// Domain id is "newDomain", the password is "myPassword"
if(ml.isDebugEnabled()) ml.debug("create server instance ok");
//
Map domainProperties = new HashMap();
domainProperties.put( Configuration.DATASOURCE_JNDI,
SystemConfigurationInfo.getProperty
(CommonConstant.DEFAULT_BPELDOMAIN_DS_JNDI));
domainProperties.put( Configuration.TX_DATASOURCE_JNDI,
SystemConfigurationInfo.getProperty
(CommonConstant.DEFAULT_BPELDOMAIN_DS_JNDI));
if(ml.isDebugEnabled()) ml.debug("create domain - ds jndi property key/value:
" + Configuration.DATASOURCE_JNDI + "/" + SystemConfigurationInfo.getProperty
(CommonConstant.DEFAULT_BPELDOMAIN_DS_JNDI));
if(ml.isDebugEnabled()) ml.debug("create domain - tx_ds jndi property key/value:
" + Configuration.TX_DATASOURCE_JNDI + "/" + SystemConfigurationInfo.getProperty
(CommonConstant.DEFAULT_BPELDOMAIN_DS_JNDI));
server.createDomain(domainName, password, domainProperties);
if(ml.isDebugEnabled()) ml.debug("Enter createDomain
(domain = " + domainName + " password = " + password);
} catch( com.oracle.bpel.client.ServerException se ){
ml.error(se.getMessage());
if(ml.isDebugEnabled()) se.printStackTrace();
throw new WorkflowException("1018", se.getCause());
}
}
В приводимой ниже реализации метода runBuildScript, производится обращение к функции Oracle bpelc посредством Ant build script. Метод runBuildScript вызывает файл проекта Ant, который, в свою очередь, вызывает bpelc для сборки и развертывания процесса BPEL поставщика сервисов.
/ **
* Выполните сценарий ant, чтобы собрать процесс BPEL Oracle, который осуществляет технологический процесс.
* Сценарий также развертывает технологический процесс в доменах сервисов.
* Вся входная информация предлагается через таблицу свойств (props) входного параметра.
* В @param содержатся все необходимые свойства, используемые для сборки/развертывания последовательности
* операций процесса BPEL
* @throws WorkflowException
*/
private void runBuildScript(String buildFilename, Properties props) throws WorkflowException{
if(ml.isDebugEnabled())ml.debug("Enter runBuildScript(buildFileName = " + buildFilename +
", properties = ...");
try {
Project project = new Project();
project.init();
File buildFile = new File(buildFilename);
if (!buildFile.exists()) throw new WorkflowException("1015");
if(ml.isDebugEnabled()) ml.debug("ant build file: " + buildFile.getAbsolutePath());
ProjectHelper.configureProject(project, buildFile);
//prepare logger for the project build
PrintStream out = System.out;
BuildLogger logger = new DefaultLogger();
logger.setMessageOutputLevel(Project.MSG_DEBUG);
logger.setOutputPrintStream(out);
logger.setErrorPrintStream(out);
project.addBuildListener(logger);
//set project properties
Enumeration keys = props.keys();
while(keys.hasMoreElements()){
String key = keys.nextElement().toString();
project.setProperty(key, props.getProperty(key));
}
// test
//excute default target
project.executeTarget(project.getDefaultTarget());
if(ml.isDebugEnabled())ml.debug("Exit runBuildScript
(buildFileName = " + buildFilename +
", properties = ...");
}
catch (Exception ex) {
ml.error(ex.getMessage());
if(ml.isDebugEnabled()) ex.printStackTrace();
throw new WorkflowException("1002",ex.getCause());
}
}
При проектировании сети Web-сервисов нужно рассмотреть вопрос об использовании доменов BPEL для разделения проектирования процесса и платформы развертывания для всех вовлеченных сторон. Далее приводятся некоторые возможные применения:
• Разделить единый экземпляр Oracle BPEL Process Manager, превратив его в среду, обеспечивающую работу многих разработчиков. В этом случае идентификатор домена обычно определяет разработчика, владеющего этим доменом.
• Разделить единый экземпляр Oracle BPEL Process Manager на среды разработки и контроля качества (QA). В таком случае идентификаторы домена могут, например, быть такими: "test" и "QA".
• Разделить единый экземпляр Oracle BPEL Process Manager, превратив его тем самым в среду, которая может использоваться многими отделами или партнерами. В этом случае идентификаторы домена могут быть представлены названиями отделов или именами партнеров.
Создание централизованного реестра сервисов. После того, как определены сетевые отношения, партнеры могут свободно присоединяться и вносить свои сервисы. Возможность публикации и нахождения этих сервисов, конечно, является одним из дополнительных преимуществ платформы SOA.
В этом процессе партнеры публикуют свои Web-сервисы в централизованном реестре, где и происходит все управление информацией о сервисах. Такая централизованная инфраструктура способствует повышению возможностей многократного использования сервисов и минимизирует усилия и время, требующиеся для определения местонахождения сервиса. Отсутствие централизованного реестра приводит к несогласованности и хаосу. А это, в свою очередь, ухудшает гибкость и открытость сети.
Сеть SSE интенсивно использует централизованный репозиторий Web-сервисов; для обнаружения доступных (имеющихся в наличии) сервисов партнеры используют язык Web Services Inspection Language (WSIL - язык проверки Web-сервисов). Поставщики сервисов имеют возможность многократно использовать имеющийся Web-сервис (предлагаемый другими провайдерами в рамках сети), выбирая соответствующий файл WSDL. Эта задача выполняется путем добавления URL для WS-Inspection - http://services.eoportal.org/inspection.wsil в файл конфигурации инструментария Oracle BPEL Designer, UDDIProviderList.xml, как показано ниже.
<provider>
<description>ESA SSE Portal</description>
<type>wsil</type>
<inquiryURL>
http://services.eoportal.org/inspection.wsil
</inquiryURL>
</provider>
Инструментальное средство Oracle BPEL Designer в местоположении поставщика сервисов соединяется с сервером SSE и обнаруживает доступные сервисы и их файлы WSDL, используя протокол WS-Inspection. После соединения с сервером WS-Inspection список всех доступных сервисов отображается, как показано на рисунке 2.
Рис. 2. Список доступных сервисов SSE
Для каждого сервиса предлагается соответствующий файл WSDL и короткое текстовое описание. Ссылка на партнера для этого сервиса добавляется путем выбора файла WSDL. После того как поток процесса будет собран, он разворачивается на портале SSE с использованием консоли BPEL. (В своем следующем выпуске SSE собирается объединить реестр UDDI с Oracle BPEL. Когда регистрируется новый сервис, он будет также автоматически зарегистрирован и в этом реестре UDDI. Такая интеграция облегчит обнаружение сервисов внешними инструментальными средствами, которое теперь возможно только в том случае, если эти инструментальные средства поддерживают протокол WS-Inspection.)
Хотя вы можете построить SOA и воспользоваться многими ее преимуществами, не создавая репозиторий сервисов, в долгосрочной перспективе такой репозиторий необходим. Архитектура может обойтись и без репозитория, если возможности сервиса рассчитаны только на один проект. Однако большинство корпоративных сценариев характеризуются разнообразием сервисов и партнеров, причем большинство из них находятся в постоянном потоке.
Предоставление возможностей ведения мониторинга в режиме самообслуживания. В сети для совместной работы, где в бизнес-процессе участвует много сторон, критическим является ведение мониторинга выполнения бизнес-процесса, чтобы ключевые показатели эффективности для бизнес-процессов могли быть привязаны к соглашениям об уровне обслуживания. (Например, одним из ключевых требований при присоединении к сети может стать подтверждение получения запроса о цене в течение двух часов.) Мониторинг бизнес-процессов может предложить ключевое понимание, сколько времени потребуется определенному экземпляру бизнес-процесса для выполнения, почему происходят задержки, и как можно было бы исправить проблему для будущих транзакций.
Подобный уровень диагноза следует предложить партнерам и конечным пользователям. Создавая среду самообслуживания, партнеры и конечные пользователи получают возможность отслеживать свои индивидуальные процессы и, в свою очередь, облегчить проблемы, обнаруженные централизованной инфраструктурой мониторинга.
Для ведения мониторинга и отладки бизнес-процессов может быть использовано инструментальное средство Oracle BPEL Console (см. рис. 3). Агентство ESA и поставщики сервисов используют консоль BPEL для отслеживания, сколько экземпляров процесса BPEL выполняется или
Рис. 3. Мониторинг бизнес-процессов с помощью консоли Oracle BPEL Console
завершено, какова средняя продолжительность выполнения экземпляра процесса (чтобы получить детализированную разбивку потребления времени в рамках процесса), а также журнала аудита экземпляра процесса в текстовом формате, что позволяет партнерам увидеть промежуточные результаты.
Кроме того, конечные пользователи, заказавшие определенный сервис, имеют возможность проследить состояние своего заказа. Эта информация представлена вне консоли BPEL, и ее можно получить, используя API Oracle BPEL Process Manager. Поставщики сервисов предлагается использовать осмысленные названия областей в своих процессах BPEL; во время выполнения (в исполнительном периоде) портал извлекает название текущего "окна" BPEL, используя API IInstanceHandle.getStatus (), чтобы представить информацию о продвижении (прогрессе) конечного пользователя.
Областями (scopes) называются иерархически организованные части, на которые может быть разделен сложный бизнес-процесс. Они предлагают поведенческие контексты для действий. При использовании осмысленных названий областей в процессе BPEL партнеры получают возможность отслеживать состояние "непродолжительных" и "долговечных" бизнес-процессов.
Рассмотрим в качестве примера реализацию метода getOrderSubstatus. Этот метод позволяет партнерам ESS (Employee Self-Service - система самообслуживания) получать текущее состояние экземпляра процесса BPEL, используя названия областей, выполняемых в файле bpel.
* вызвать Oracle BPEL API, чтобы получить текущее состояние экземпляра потока операций, в соответствии с
* упорядоченностью, предлагаемой на входе
* @param ordered Идентифицированный заказ
* @param workflowId Название (или идентификатор) потока операций,
* который обрабатывает стадию заказа.
* Обычно имеются две стадии заказа: send rfq - послать (процесс)
* запрос о цене и send order - послать (процесс) заказ
* @param domain Домен, к которому принадлежит поток операций заказа
* @param password Пароль, используемый для входа в домен потока операций
* @return Текущее состояние экземпляра потока операций - более конкретно,
* это - название активных в текущее время областей в файле BPEL потока операций.
* @throws RemoteException
* @throws WorkflowException
*/
public String getOrderSubstatus(String ordered, String workflowId, String domain,
String password)
throws RemoteException, WorkflowException
{
if(ml.isDebugEnabled()) ml.debug("Enter getOrderSubstatus(ordered = " + ordered
+ ", workflowId = " + workflowId + ", domain = " + domain + ",
password = " + password);
String status = "";
try {
Locator locator = new Locator(domain, password);
IinstanceHandle instance = locator.lookupInstance(ordered + "_" + workflowId);
if( instance.isComplete() ) status = "Completed";
else status = instance.getStatus();
return status;
} catch (com.oracle.bpel.client.ServerException e)
{
// TODO Auto-generated catch block
ml.error(e.getMessage());
if(ml.isDebugEnabled()) e.printStackTrace();
throw new WorkflowException("1016", e.getCause());
}
}
Заключение
Агентство ESA строило всю свою сеть для совместной работы с прицелом на оперативность в действиях. Отношения интерфейса были гибко определены, чтобы обеспечить наиболее простое принятие и быстрое развитие. Использование агентством доменов, чтобы предложить независимое рабочее пространство предлагает поставщикам сервисов потрясающую гибкость; провайдеры могут изменять свои бизнес-процессы, не затрагивая стабильность сети. Области BPEL дали ESA возможность "на лету" (то есть, в высшей степени оперативно) отслеживать состояние процессов на микроуровне. Потоки процесса BPEL генерируются автоматически от имени поставщиков сервисов. Все эти факторы в совокупности вносят свой вклад в создание более удобной для партнеров сети и минимизируют авансовые инвестиции партнеров.
Однако, есть другие области проектирования сетей, например: управление распределенными транзакциями, организация безопасности и управление партнерами по торговле, которым мы здесь не уделили внимания. Поскольку размер сетей B2B постоянно растет, BPEL может взять на себя инициативу по управлению частными процессами. К примеру, продукт Oracle Integration B2B, который имеет возможность взаимодействовать с Oracle BPEL Process Manager, разрешает проблемы слаженной совместной работы публичных процессов, поддержки протоколов установления связи (RosettaNet, ebXML, EDI, HIPAA), обработки форматов сообщений (MIME, SMIME, AS2, XMLDSig) и управления партнерами по торговле (строгое выполнение обязательств, соглашения об уровне обслуживания, партнерские соглашения).