ebXML - Краткое руководство

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

Проблема с EDI в том, что он очень дорогой и изначально создавался для мира мэйнфреймов. Теперь ebXML заменяет EDI.

Определение

ebXML означает Eлектронный Bпрактичность Exрастяжимый MArkup Lболь. Это глобальный стандарт электронного бизнеса, который позволяет кому угодно и где угодно проводить деловые операции с кем угодно через Интернет.

Особенности

Возможности ebXML следующие:

ebXML - это сквозная XML-структура B2B.
ebXML - это набор спецификаций, обеспечивающих модульную структуру.
ebXML опирается на существующие стандарты Интернета, такие как HTTP, TCP / IP, MIME, SMTP, FTP, UML и XML.
ebXML может быть реализован и развернут практически на любой вычислительной платформе.
ebXML предоставляет конкретные спецификации для динамического взаимодействия B2B.

ebXML Vision

ebXML предназначен для создания глобального электронного рынка, на котором предприятия любого размера и в любом месте могут:

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

Почему именно ebXML?

Существующие структуры B2B не подходят:
- EDI и RosettaNet слишком тяжелы и слишком жестки.
- BizTalk является проприетарным, от одного поставщика и на одной платформе.

Протокол простого доступа к объектам (SOAP); Язык определения веб-сервисов (WSDL); и только универсального описания, обнаружения и интеграции (UDDI) недостаточно:
- WSDL не касается делового сотрудничества.
- SOAP в его базовой форме не обеспечивает безопасную и надежную доставку сообщений.
- UDDI не предоставляет возможности репозитория для бизнес-объектов.

Растет потребность в стандартизации делового сотрудничества для решения следующих вопросов:
- Деловые процессы
- Стороны, участвующие в деловом сотрудничестве, и их роли
- Обмен XML-документами при деловом сотрудничестве
- Безопасность, надежность, качество обслуживания требований делового сотрудничества
Все эти потребности решаются с помощью ebXML.

Организации-учредители ebXML

ebXML - это совместная инициатива СЕФАКТ ООН и OASIS.

UN/CEFACT:

Это означает Центр Организации Объединенных Наций по упрощению процедур торговли и электронному бизнесу.
Он поддерживает стандарты ЭДИФАКТ ООН для электронного обмена данными (EDI).

OASIS:

Это означает Организация по развитию стандартов структурированной информации.
Он создает и поддерживает спецификации взаимодействия XML, широкую отраслевую поддержку.

По определению итеративный жизненный цикл B2B collaboration включает в себя следующие шаги:

Определение процесса
Партнерское открытие
Регистрация партнера
Электронный плагин
Выполнение процесса
Управление процессом
Развитие процесса

Общие спецификации ebXML предназначены для охвата почти всего процесса сотрудничества B2B и предназначены для удовлетворения описанных выше потребностей.

Архитектура ebXML, определенная командой ebXML, обеспечивает:

Способ определения бизнес-процессов и связанных с ними сообщений и содержимого.
Способ регистрации и обнаружения последовательностей бизнес-процессов с помощью связанных обменов сообщениями.
Способ определения профиля компании.
Способ определения соглашений с торговыми партнерами.
Единый транспортный уровень сообщений.

Следовательно, техническая архитектура ebXML состоит из пяти модулей:

Спецификации бизнес-процессов
Профиль партнера и соглашения
Реестр и репозиторий
Основные компоненты
Служба обмена сообщениями

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

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

Спецификации для определения бизнес-процессов позволяют организации выразить свои бизнес-процессы так, чтобы они были понятны другим организациям. Это позволяет интегрировать бизнес-процессы внутри компании или между несколькими компаниями.

В ebXML Business Process Specification Schema (BPSS)предоставляет определение XML-документа, описывающего, как организация ведет свой бизнес. EbXML BPSS - это декларация партнеров, ролей, сотрудничества, хореографии и обмена бизнес-документами, составляющих бизнес-процесс.

Следующая диаграмма дает концептуальное представление о бизнес-процессе.

Деловое сотрудничество

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

Самым распространенным является бинарное сотрудничество, при котором два партнера обмениваются документами. Многостороннее сотрудничество происходит при обмене информацией между более чем двумя сторонами.

Многостороннее сотрудничество на самом деле является хореографическим двоичным сотрудничеством.

На самом низком уровне деловое сотрудничество можно разбить на бизнес-операции.

Деловые операции

Бизнес-транзакция - это атомарный уровень работы в бизнес-процессе. Он либо успешен, либо полностью терпит неудачу.

Бизнес-операции - это операции, в которых торговые партнеры фактически передают бизнес-документы.

Потоки бизнес-документов:

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

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

Хореография:

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

Деловые документы

Бизнес-документы состоят из объектов бизнес-информации или небольших фрагментов информации, которые были идентифицированы ранее.

Эти фрагменты или компоненты, конечно, не несут никакой информации. Это просто структуры, такие как схема XML или DTD, которые определяют информацию и представление. Конечным результатом является предсказуемая структура, в которую помещается информация, так что получатель окончательного документа может интерпретировать ее для извлечения информации.

Пример спецификации бизнес-процесса

Ниже приведен частичный пример спецификации бизнес-процесса:

<BusinessTransaction name="Create Order">
    <RequestingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P2D"
        timeToAcknowledgeAcceptance="P3D">
    <DocumentEnvelope BusinessDocument="Purchase Order"/ >
    </RequestingBusinessActivity>
    <RespondingBusinessActivity name=""
        isNonRepudiationRequired="true"
        timeToAcknowledgeReceipt="P5D">
    <DocumentEnvelope isPositiveResponse="true"
        BusinessDocument="PO Acknowledgement"/>
    </DocumentEnvelope>
    </RespondingBusinessActivity>
</BusinessTransaction>

Заключение

Спецификация бизнес-процесса:

Описывает сотрудничество между двумя партнерами
Определяет роли, отношения и обязанности
Определяет хореографию деловых документов
Выражается в формате, нейтральном к платформе и поставщику
Можно моделировать с помощью UMM (Методология моделирования СЕФАКТ ООН)
Формально описывается схемой спецификации бизнес-процессов (BPSS)
На это ссылаются CPP и CPA.
Относится к определениям бизнес-документов.

Профиль протокола совместной работы

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

Бизнес-возможности через бизнес-процесс.
Роль (покупатель или страховщик), которую они играют в рамках сотрудничества.
Каналы доставки и транспортные протоколы. (HTTP, SMTP и т. Д.)
Способ упаковки деловых документов.
Ограничения безопасности (SSL, цифровые сертификаты).
Индивидуальная настройка в соответствии со спецификациями бизнес-процессов.

CPP хранится в реестре ebXML с глобальным уникальным идентификатором (GUID), и деловые партнеры могут найти CPP друг друга через реестр.

Информация в CPP доступна для поиска, поэтому потенциальный торговый партнер может определить, есть ли у организации возможности для ведения бизнеса.

Структура CPP

CPP определяет пространства имен в своем корневом элементе и версии, чтобы различать любые последующие изменения. Структура CPP состоит из корневого элемента профиля протокола совместной работы со следующими элементами:

PartyInfo: Элемент PartyInfo предоставляет информацию об организации.
Packaging:Элемент Packaging предоставляет информацию о том, как фактически создаются сообщения. Сообщения обрабатываются как сообщения SOAP.
Signature: Необязательная часть документа
Comment elements: могут быть включены.

<CollaborationProtocolProfile
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="1.1">
<PartyInfo>
    ...
    <!--REQUIRED, Repeatable-->
...
</PartyInfo>
<Packaging id="ID">
    ...
    <!--REQUIRED-->
    ...
<Packaging>
<ds:Signature>
    ...
    <!--OPTIONAL-->
    ...
</ds:Signature>
<Comment>
    ...
    <!-- OPTIONAL -->
    ...
</Comment>
</CollaborationProtocolProfile>

Соглашение с торговым партнером

Соглашение с торговым партнером (TPA) - это контракт, определяющий как юридические условия, так и технические характеристики для обоих партнеров в торговых отношениях. Цена за конверсию рассчитывается на основе CPP торговых партнеров.

Правила, указанные в электронной TPA, не зависят от бизнес-процессов любой из сторон. Техническое описание условий TPA выражается в документе XML, который настраивает каждую ИТ-систему для работы в соответствии с правилами соглашения.

Свойства TPA включают его имя, имена партнеров, даты начала и окончания, роли и другие параметры. Обычно одна сторона генерирует CPA и предлагает ее другой стороне на утверждение. Как только обе стороны достигли соглашения, каждая из них берет электронную копию одного и того же CPA и использует ее для настройки своих систем.

CPA также может быть добавлен в реестр для справки, но это не стандартное требование.

Структура CPA

CPA определяет пространства имен в своем корневом элементе и версии, чтобы различать любые последующие изменения. Структура CPP состоит из корневого элемента соглашения о протоколе сотрудничества, а также следующих элементов:

Start and End: Эти элементы представляют в скоординированном всемирном времени начало и конец периода, в течение которого эта CPA активна.
PartyInfo:Элемент PartyInfo предоставляет информацию об организации. Здесь элементы PartyInfo включены для обеих сторон, участвующих в соглашении.
Packaging:Элемент Packaging предоставляет информацию о том, как фактически создаются сообщения. Сообщения обрабатываются как сообщения SOAP.
Signature: Необязательная часть документа.
Comment elements: могут быть включены.

<CollaborationProtocolAgreement
xmlns="http://www.ebxml.org/namespaces/tradePartner"
xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"
xmlns:xlink = "http://www.w3.org/1999/xlink"
cpaid="http://www.example.com/cpas/CPAS"
version="1.7">
<Status value = "proposed"/>
<Start>1998-04-07T18:50:00</Start>
<End>1999-04-07T18:50:00</End>
<ConversationConstraints invocationLimit = "150"
concurrentConversations = "10"/>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
</PartyInfo>
<PartyInfo>
    ...
    <!--REQUIRED, repeatable-->
    ...
    </PartyInfo>
<Packaging id="N20">
    ...
    <!--REQUIRED, repeatable-->
    ...
</Packaging>
<ds:Signature>
    <!--OPTIONAL-->
</ds:Signature>
<Comment xml:lang="en-gb">
    <!--OPTIONAL-->
</Comment>
</CollaborationProtocolAgreement>

Что такое реестр и репозиторий:

Реестр ebXML служит индексом и шлюзом приложений для репозитория во внешний мир и содержит API, который управляет тем, как стороны взаимодействуют с репозиторием. Репозиторий ebXML является держателем компонентов.

Реестр ebXML занимает центральное место в архитектуре ebXML.
Реестр также можно рассматривать как API к базе данных элементов, поддерживающей электронный бизнес с помощью ebXML.
Реестр ebXML служит базой данных для обмена соответствующей информацией о компании для деловых операций ebXML, такой как корпоративные возможности, бизнес-процессы, технические чертежи, формы заказов, счета-фактуры и т. Д.
Элементы в репозитории создаются, обновляются или удаляются посредством запросов в реестр.
Репозитории предоставляют торговым партнерам общую бизнес-семантику.
Реестр ebXML - это интерфейс для доступа и обнаружения общей бизнес-семантики.
Интерфейс реестра разработан так, чтобы быть независимым от стека базовых сетевых протоколов, например HTTP или SMTP через TCP / IP.

Реестр обеспечивает стабильное и постоянное хранилище представленного контента, которое включает схему и документы XML, описания процессов, основные компоненты, описания контекста, модели UML, информацию о сторонах и даже программные компоненты. Это можно представить как программный стек сервисов, как показано ниже:

Цели реестра ebXML

Целью реестра ebXML является обеспечение обмена информацией между заинтересованными сторонами с целью интеграции бизнес-процессов между ними.

Преимущества реестра ebXML

Реестр ebXML обеспечивает следующие преимущества:

Обнаружение и обслуживание зарегистрированного контента.
Поддержка совместной разработки, при которой пользователи могут создавать XML-контент и отправлять его в реестр для использования и возможного улучшения уполномоченными сторонами.
Сохранение языка выполнения бизнес-процессов веб-служб (WS-BPEL), WSDL и бизнес-документов во время взаимодействия между торговыми партнерами.
Безопасный контроль версий зарегистрированного контента.
Федерация сотрудничающих реестров для обеспечения единого представления зарегистрированного контента путем беспрепятственного запроса, синхронизации и перемещения зарегистрированного контента.
Уведомление о событиях по электронной почте или через веб-службы.

Соответствие

Согласно спецификации ebXML Registry Services, реализация реестра соответствует спецификации ebXML, если она удовлетворяет следующим условиям:

Он поддерживает информационную модель реестра ebXML.
Он поддерживает синтаксис и семантику интерфейсов реестра и безопасности.
Он поддерживает DTD реестра ebXML.
Поддержка синтаксиса и семантики SQL-запроса в реестре не является обязательной.

Реализация клиента реестра соответствует спецификации ebXML, если удовлетворяет следующим условиям:

Он поддерживает ebXML CPA и процесс начальной загрузки.
Синтаксис и семантика клиентских интерфейсов реестра.
Сообщение об ошибке ebXML DTD.
DTD реестра ebXML.

Объекты реестра и метаданные

Объекты реестра

Относится к объекту, который передается в реестр на хранение и хранение.

называется "Элемент репозитория"
XML-документ или DTD, модели бизнес-процессов, CPP и т. Д.

Metadata

Он используется реестром для классификации объектов реестра и управления ими.
Он представлен регистрационной записью

Информационная модель реестра (RIM)

Информационная модель реестра (RIM) предоставляет общий план метаданных в реестре ebXML. Это может быть представлено как программный стек служб или как пирамида служб, как показано на рисунке ниже. Элементы информационной модели представляют метаданные о контенте, а не сам контент в репозитории. Информационная модель реестра определяет типы объектов, хранимых и упорядоченных в реестре.

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

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

... Форма определения xbXML, упрощенная Эриком Чиу

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

Как правило, основные компоненты используются во многих различных областях, отраслях и бизнес-процессах. В среде ebXML основные компоненты являются строительными блоками для семантики XML и бизнес-словаря, которые используются в сообщениях и документах.

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

Основной компонент может использоваться в нескольких бизнес-секторах, но он также может стать контекстно-зависимым для бизнес-домена, например отдельной отрасли.

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

Инструменты и справочные материалы

Список основных справочных материалов и инструментов для основных компонентов, предоставляемых ebXML для бизнес-аналитиков и технических аналитиков, выглядит следующим образом:

Context and the Re-usability of Core Components: Этот документ содержит определения контекста, источники списков значений классификации и графическую модель, изображающую отношения основного компонента и дескриптора контекста.
Catalog of Context Drivers: В этом документе представлен каталог контекстных драйверов.
Document Assembly and Context Rules: Здесь описаны процедуры и схемы для сборки документов с использованием контекстно-зависимых основных компонентов.
Core Components Dictionary:Этот документ разделен на разделы. Каждый раздел начинается с информации о применимой категории и типе основного компонента.
Core Components Editor and Browser: Эти инструменты помогают аналитикам просматривать существующие основные компоненты и интегрировать их для определения формата XML-сообщений, которыми обмениваются торговые партнеры, а также для правильного определения и применения контекстных правил.

Примеры основных компонентов:

Основной компонент A:
- Поставщик (Industry1)
- Производитель (отрасль 2)
- Поставщик (отрасль 3)
Основной компонент B:
- Дистрибьютор (отрасль 1)
- Оптовый торговец (отрасль 2)
- Торговец (отрасль 3)
Основной компонент C:
- Магазин (отрасль 1)
- Аутлет (промышленность 2)
- Розничный продавец (отрасль 3)

Заключение

Основные компоненты:

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

Полное сообщение называется пакетом сообщений, который является объектом многоцелевых расширений электронной почты (MIME). Пакет сообщений состоит из двух основных частей:

SOAP Message Container: Это обязательная часть сообщения, содержащая элементы расширения SOAP для ebXML, такие как информация о маршрутизации, информация о торговых партнерах, идентификация сообщения и информация о семантике доставки.
Payload Containers: Это необязательная часть сообщения, которая может содержать информацию любого типа, которой должны обмениваться стороны.

Критерии дизайна сообщений

Согласно спецификации службы обмена сообщениями, цели разработки службы сообщений ebXML заключаются в следующем:

По возможности используйте существующие стандарты.
Быть простым в реализации.
Поддержите предприятия любого размера.
Поддержка большого количества протоколов связи (HTTP, SMTP, FTP и т. Д.)
Поддержка полезных данных любого типа (XML, транзакции EDI, двоичные данные и т. Д.)
Поддержка надежного обмена сообщениями.
Обеспечьте безопасность.

Архитектура обмена сообщениями

Служба сообщений ebXML была разработана для работы в общем контексте инициативы ebXML. Однако техническая архитектура ebXML является модульной, и службу сообщений можно использовать независимо от ebXML.

Служба сообщений ebXML имеет три логических архитектурных уровня между бизнес-приложением и сетевыми протоколами:

The Message Service Interface (MSI):Это интерфейс приложения для бизнес-приложений, вызывающий функции обработчика сообщений для отправки и получения сообщений. Подобно ODBC, JDBC и другим интерфейсам абстрактных служб, он предоставляет функциональные возможности обработчика сообщений в виде определенного набора API для разработчиков бизнес-приложений.
The Message Service Handler (MSH): Он имеет базовые службы, такие как обработка заголовков, синтаксический анализ заголовков, службы безопасности, надежные службы обмена сообщениями, упаковка сообщений и обработка ошибок.
The Message Transport Interface (MTI):Он предназначен для отправки сообщений по различным сетям и протоколам связи на уровне приложений. Транспортный интерфейс преобразует данные, специфичные для ebXML, в другие формы, передаваемые сетевыми службами и протоколами. Это включает в себя полный обмен между двумя сторонами, совмещенный с существующими протоколами в сетевом стеке.

Архитектура обмена сообщениями ebXML показана на следующей диаграмме.

Форматирование сообщения:

Сообщение ebXML должно быть отформатировано в соответствии со спецификацией службы сообщений ebXML и должно соответствовать синтаксису, формату и правилам кодирования MIME. Определение элементов XML обеспечивается схемой XML, которая расширяет SOAP для определения заголовка сообщения ebXML, заголовка трассировки, манифеста, статуса и подтверждения.

Заключение

Обмен сообщениями ebXML -

Использует SOAP с вложениями в качестве конверта полезной нагрузки.
Работает по различным протоколам связи, таким как HTTP, SMTP, FTP.
Поддерживает семантику более высокого уровня, необходимую для бизнес-транзакций. (Безопасность и надежность)

На следующей диаграмме показан сценарий ebXML, который упрощает понимание концепции ebXML. Пример взят из Спецификации технической архитектуры.

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

Компания A просматривает реестр ebXML, чтобы узнать, что доступно в Интернете. В лучшем случае компания A может повторно использовать все существующие бизнес-процессы, документы и основные компоненты, общие для ее отрасли, которые уже хранятся в реестре ebXML. В противном случае компания A проектирует недостающие части, сохраняет их в реестре ebXML и делает их доступными для своих партнеров по отрасли.
Компания A решает вести электронный бизнес по методу ebXML и рассматривает возможность внедрения местного приложения, совместимого с ebXML. Интерфейс бизнес-услуг ebXML (BSI) обеспечивает связь между компанией и внешним миром ebXML. Компания должна создать профиль протокола совместной работы (CPP), который описывает поддерживаемые возможности бизнес-процессов, ограничения и техническую информацию ebXML, такую как выбор алгоритмов шифрования, сертификатов шифрования и выбор транспортных протоколов.
Компания A отправляет свой CPP в реестр ebXML. С этого момента компания A публично зарегистрирована в реестре ebXML и, вероятно, будет обнаружена другими компаниями, запрашивающими новых торговых партнеров.
Компания B уже зарегистрирована в реестре ebXML и ищет новых торговых партнеров. Компания B запрашивает реестр ebXML и получает CPP компании A. Компания B тогда имеет два CPP: CPP компании A и свой собственный. Обе компании должны прийти к соглашению о том, как вести бизнес, что в терминологии ebXML называется Соглашением о протоколе сотрудничества (CPA). Компания B использует инструмент формирования CPA ebXML, чтобы получить CPA из требований двух CPP.
В этом сценарии компания B связывается с компанией A напрямую и отправляет вновь созданный CPA для принятия компании A. После согласования CPA компанией A обе компании готовы к ведению электронного бизнеса.
Затем компании используют базовую структуру ebXML и обмениваются бизнес-документами, соответствующими CPA. Это означает, что обе компании следуют бизнес-процессам, определенным в CPA.