ebXML - Szybki przewodnik

Firmy nieuchronnie wchodzą ze sobą w interakcje na różne sposoby. Do ostatnich lat wiele dużych firm komunikowało się automatycznie za pomocą elektronicznej wymiany danych (EDI), która umożliwia dwóm firmom komunikowanie się za pomocą z góry określonych sygnałów.

Problem z EDI polega na tym, że jest bardzo drogi i pierwotnie został stworzony dla świata mainframe. Teraz ebXML zastępuje EDI.

Definicja

ebXML oznacza Eelektroniczny Business E.xrozciągliwy Markup Lból. Jest to globalny standard dla biznesu elektronicznego, który umożliwia każdemu i wszędzie dokonywanie transakcji biznesowych z kimkolwiek przez Internet.

funkcje

Cechy ebXML są następujące:

ebXML to kompleksowa struktura XML B2B.
ebXML to zestaw specyfikacji, które umożliwiają tworzenie modułowej struktury.
ebXML opiera się na istniejących standardach internetowych, takich jak HTTP, TCP / IP, MIME, SMTP, FTP, UML i XML.
ebXML można zaimplementować i wdrożyć na praktycznie każdej platformie komputerowej.
ebXML zapewnia konkretne specyfikacje umożliwiające dynamiczną współpracę B2B.

ebXML Vision

ebXML ma na celu stworzenie globalnego rynku elektronicznego, na którym przedsiębiorstwa dowolnej wielkości i gdziekolwiek mogą:

znaleźć się elektronicznie.
prowadzić biznes -
- za pomocą wymiany wiadomości XML.
- zgodnie ze standardowymi sekwencjami procesów biznesowych.
- z jasną semantyką biznesową.
- korzystanie z gotowych, zakupionych aplikacji biznesowych.
- zgodnie z wzajemnie uzgodnionymi protokołami partnerskimi.

Dlaczego ebXML?

Istniejące ramy B2B nie są odpowiednie:
- EDI i RosettaNet są zbyt ciężkie i zbyt sztywne.
- BizTalk to zastrzeżony, jeden dostawca i jedna platforma.

Simple Object Access Protocol (SOAP); Język definicji usługi sieci Web (WSDL); i Uniwersalny opis, wykrywanie i integracja (UDDI) nie są wystarczające:
- WSDL nie dotyczy współpracy biznesowej.
- SOAP w swojej podstawowej formie nie zapewnia bezpiecznego i niezawodnego dostarczania wiadomości.
- UDDI nie zapewnia możliwości repozytorium dla obiektów biznesowych.

Istnieje coraz większe zapotrzebowanie na standaryzację współpracy biznesowej w celu rozwiązania następujących problemów:
- Procesy biznesowe
- Strony zaangażowane we współpracę biznesową i ich role
- Wymiana dokumentów XML w ramach współpracy biznesowej
- Bezpieczeństwo, niezawodność, jakość usług, wymagania współpracy biznesowej
Wszystkie te potrzeby są zaspokajane przez ebXML.

Organizacje założycielskie ebXML

ebXML to wspólna inicjatywa UN / CEFACT i OASIS.

UN/CEFACT:

To oznacza Centrum Narodów Zjednoczonych ds. Ułatwień w Handlu i Elektronicznego Biznesu.
Utrzymuje standardy UN / EDIFACT dla elektronicznej wymiany danych (EDI).

OASIS:

To skrót od Organization for Advance of Structured Information Standards.
Tworzy i utrzymuje specyfikacje interoperacyjności XML, szerokie wsparcie branżowe.

Z definicji iteracyjny cykl życia B2B collaboration obejmuje następujące kroki:

Definicja procesu
Odkrywanie partnerów
Rejestracja partnera
Wtyczka elektroniczna
Wykonanie procesu
Zarządzanie procesem
Ewolucja procesu

Ogólne specyfikacje ebXML mają obejmować prawie cały proces współpracy B2B i mają na celu spełnienie opisanych powyżej potrzeb.

Architektura ebXML zdefiniowana przez zespół ebXML zapewnia:

Sposób definiowania procesów biznesowych oraz związanych z nimi komunikatów i treści.
Sposób rejestrowania i odkrywania sekwencji procesów biznesowych z powiązanymi wymianami komunikatów.
Sposób definiowania profili firmowych.
Sposób definiowania umów z partnerami handlowymi.
Jednolita warstwa transportu wiadomości.

W konsekwencji architektura techniczna ebXML składa się z pięciu modułów:

Specyfikacje procesów biznesowych
Profil partnera i umowy
Rejestr i repozytorium
Podstawowe komponenty
Usługa przesyłania wiadomości

Moduły te zostaną omówione w następnych pięciu kolejnych rozdziałach. Diagram przedstawia uproszczoną architekturę ebXML:

Proces biznesowy to coś, co robi firma, na przykład kupowanie części komputerowych lub sprzedaż profesjonalnej usługi. Polega na wymianie informacji między dwoma lub więcej partnerami handlowymi w przewidywalny sposób.

Specyfikacje definicji procesów biznesowych umożliwiają organizacji przedstawienie procesów biznesowych tak, aby były zrozumiałe dla innych organizacji. Umożliwia integrację procesów biznesowych w firmie lub między wieloma firmami.

Plik ebXML Business Process Specification Schema (BPSS)zawiera definicję dokumentu XML opisującego sposób prowadzenia działalności przez organizację. EbXML BPSS to deklaracja partnerów, ról, współpracy, choreografii i wymiany dokumentów biznesowych, które składają się na proces biznesowy.

Poniższy diagram przedstawia koncepcyjny pogląd na proces biznesowy.

Współpraca biznesowa

Współpraca biznesowa to choreograficzny zestaw czynności związanych z transakcjami biznesowymi, w których dwóch partnerów handlowych wymienia się dokumentami.

Najpopularniejsza jest współpraca binarna, w której dwaj partnerzy wymieniają się dokumentami. Współpraca wielostronna ma miejsce, gdy informacje są wymieniane między więcej niż dwoma stronami.

Współpraca z wieloma podmiotami to w rzeczywistości układy choreografii Binary Collaborations.

Na najniższym poziomie współpracę biznesową można podzielić na transakcje biznesowe.

Transakcje biznesowe

Transakcja biznesowa to atomowy poziom pracy w procesie biznesowym. Albo się to udaje, albo całkowicie zawodzi.

Transakcje biznesowe to transakcje, w których partnerzy handlowi faktycznie przekazują dokumenty biznesowe.

Obiegi dokumentów biznesowych:

Transakcja biznesowa jest realizowana, gdy dokument biznesowy przepływa między rolami żądającymi i odpowiadającymi. Zawsze istnieje żądający dokument biznesowy i opcjonalnie odpowiadający dokument biznesowy, w zależności od pożądanej semantyki transakcji, na przykład powiadomienie w jedną stronę lub konwersacja w dwie strony.

Rzeczywistą definicję dokumentu uzyskuje się za pomocą specyfikacji podstawowego komponentu ebXML lub metodologii zewnętrznej w stosunku do ebXML, ale w wyniku czego powstaje DTD lub schemat, na który może wskazywać specyfikacja procesu biznesowego ebXML.

Choreografia:

Choreografia wyraża się w kategoriach stanów i przejść między nimi. Działalność biznesowa jest nazywana stanem abstrakcyjnym, a współpraca biznesowa i transakcje biznesowe określane są jako stany konkretne. Choreografia jest opisana w schemacie specyfikacji procesów biznesowych ebXML przy użyciu koncepcji diagramów aktywności, takich jak stan początkowy, stan zakończenia itp.

Dokumenty biznesowe

Dokumenty biznesowe składają się z obiektów informacji biznesowych lub mniejszych porcji informacji, które zostały wcześniej zidentyfikowane.

Te fragmenty lub komponenty oczywiście nie zawierają żadnych informacji. Są to tylko struktury, takie jak schemat XML lub DTD, które definiują informacje i prezentację. Efektem końcowym jest przewidywalna struktura, w której umieszczane są informacje, tak aby odbiorca ostatecznego dokumentu mógł je zinterpretować w celu wyodrębnienia informacji.

Przykład specyfikacji procesu biznesowego

Poniżej przedstawiono częściowy przykład specyfikacji procesu biznesowego:

<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>

Wniosek

Specyfikacja procesu biznesowego:

Opisuje współpracę między dwoma partnerami
Definiuje role, relacje i obowiązki
Definiuje choreografię dokumentów biznesowych
Wyrażone w formacie neutralnym dla platformy i dostawcy
Może być modelowany za pomocą UMM (metodologia modelowania UN / CEFACT)
Formalnie opisane przez schemat specyfikacji procesów biznesowych (BPSS)
Odwołane przez CPP i CPA.
Odnosi się do definicji dokumentów biznesowych.

Profil protokołu współpracy

Profil protokołu współpracy (CPP) zawiera wszystkie niezbędne informacje o tym, jak dany partner handlowy zamierza prowadzić biznes elektroniczny. CPP definiuje następujące atrybuty partnera handlowego:

Możliwości biznesowe poprzez proces biznesowy.
Rola (kupujący lub ubezpieczyciel), jaką odgrywają we współpracy.
Kanały dostaw i protokoły transportowe. (HTTP, SMTP itp.)
Sposób pakowania dokumentów biznesowych.
Ograniczenia bezpieczeństwa (SSL, certyfikaty cyfrowe).
Konfiguracja osobna ze specyfikacjami procesów biznesowych.

CPP jest przechowywany w rejestrze ebXML z unikatowym identyfikatorem globalnym (GUID), a partnerzy biznesowi mogą znaleźć CPP drugiej strony poprzez rejestr.

Informacje w CPP są dostępne do przeszukiwania, więc potencjalny partner handlowy może określić, czy organizacja ma możliwości prowadzenia działalności.

Struktura CPP

CPP definiuje przestrzenie nazw w swoim elemencie głównym i wersję, aby rozróżnić wszelkie późniejsze zmiany. Struktura CPP składa się z głównego elementu profilu Collaboration Protocol z następującymi elementami:

PartyInfo: Element PartyInfo zawiera informacje o organizacji.
Packaging:Element Packaging dostarcza informacji o sposobie, w jaki wiadomości są faktycznie konstruowane. Komunikaty są przetwarzane jako komunikaty SOAP.
Signature: Opcjonalna część dokumentu
Comment elements: może być uwzględniony.

<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>

Umowa partnera handlowego

Umowa partnera handlowego (TPA) to umowa określająca zarówno warunki prawne, jak i specyfikacje techniczne dla obu partnerów w stosunkach handlowych. CPA pochodzi z CPP partnerów handlowych.

Zasady określone przez elektroniczny TPA są niezależne od procesów biznesowych obu stron. Opis techniczny warunków TPA jest wyrażony w dokumencie XML, który konfiguruje każdy system informatyczny do pracy na zasadach umowy.

Właściwości TPA obejmują jego nazwę, nazwy partnerów, daty rozpoczęcia i zakończenia, role i inne parametry. Zazwyczaj jedna strona generuje CPA i oferuje go drugiej stronie do zatwierdzenia. Gdy obie strony osiągną porozumienie, każda z nich pobiera elektroniczną kopię tego samego CPA i używa jej do konfiguracji swoich systemów.

CPA można również dodać do rejestru w celach informacyjnych, ale nie jest to standardowy wymóg.

Struktura CPA

CPA definiuje przestrzenie nazw w swoim elemencie głównym i wersję, aby rozróżnić wszelkie późniejsze zmiany. Struktura CPP składa się z głównego elementu Umowy o współpracy oraz z następujących elementów:

Start and End: Elementy te reprezentują, w uniwersalnym czasie koordynowanym, początek i koniec okresu, w którym CPA jest aktywny.
PartyInfo:Element PartyInfo zawiera informacje o organizacji. Tutaj elementy PartyInfo są uwzględnione dla obu stron zaangażowanych w umowę.
Packaging:Element Packaging dostarcza informacji o sposobie, w jaki wiadomości są faktycznie konstruowane. Komunikaty są przetwarzane jako komunikaty SOAP.
Signature: Opcjonalna część dokumentu.
Comment elements: może być uwzględniony.

<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>

Co to jest rejestr i repozytorium:

Rejestr ebXML służy jako indeks i brama aplikacji dla repozytorium do świata zewnętrznego i zawiera interfejs API, który reguluje sposób interakcji stron z repozytorium. Repozytorium ebXML jest magazynem komponentów.

Rejestr ebXML ma kluczowe znaczenie dla architektury ebXML.
Rejestr można również traktować jako API do bazy danych pozycji, która obsługuje e-biznes z ebXML.
Rejestr ebXML służy jako baza danych do udostępniania odpowiednich informacji o firmie dotyczących transakcji biznesowych ebXML, takich jak możliwości korporacyjne, procesy biznesowe, plany techniczne, formularze zamówień, faktury i tak dalej.
Elementy w repozytorium są tworzone, aktualizowane lub usuwane na podstawie żądań kierowanych do rejestru.
Repozytoria zapewniają partnerom handlowym wspólną semantykę biznesową.
Rejestr ebXML to interfejs do uzyskiwania dostępu i wykrywania współdzielonej semantyki biznesowej.
Interfejs rejestru został zaprojektowany tak, aby był niezależny od bazowego stosu protokołów sieciowych, takiego jak HTTP lub SMTP przez TCP / IP.

Rejestr zapewnia stabilny, trwały magazyn przesłanych treści, który obejmuje schematy XML i dokumenty, opisy procesów, podstawowe komponenty, opisy kontekstu, modele UML, informacje o podmiotach, a nawet komponenty oprogramowania. Można to przedstawić jako zestaw usług, jak pokazano poniżej:

Cele rejestru ebXML

Celem rejestru ebXML jest umożliwienie wymiany informacji między zainteresowanymi stronami w celu integracji procesów biznesowych między nimi.

Korzyści z rejestru ebXML

Rejestr ebXML zapewnia następujące korzyści:

Odkrywanie i utrzymywanie zarejestrowanych treści.
Wsparcie dla wspólnego rozwoju, w którym użytkownicy mogą tworzyć zawartość XML i przesyłać ją do rejestru w celu wykorzystania i ewentualnego ulepszenia przez upoważnione strony.
Trwałość Web Services Business Process Execution Language (WS-BPEL), WSDL i dokumentów biznesowych podczas interakcji między partnerami handlowymi.
Bezpieczna kontrola wersji zarejestrowanych treści.
Federacja współpracujących rejestrów w celu zapewnienia jednego widoku zarejestrowanych treści poprzez bezproblemowe odpytywanie, synchronizację i przenoszenie zarejestrowanych treści.
Powiadomienie o wydarzeniu za pośrednictwem poczty elektronicznej lub usług internetowych.

Spełnienie

Zgodnie ze specyfikacją ebXML Registry Services Specification, implementacja rejestru jest zgodna ze specyfikacją ebXML, jeśli spełnia następujące warunki:

Obsługuje model informacji rejestru ebXML.
Obsługuje składnię i semantykę interfejsów rejestru i zabezpieczeń.
Obsługuje rejestr DTD ebXML.
Obsługa składni i semantyki zapytania SQL w rejestrze jest opcjonalna.

Implementacja klienta rejestru jest zgodna ze specyfikacją ebXML, jeśli spełnia następujące warunki:

Obsługuje ebXML CPA i proces ładowania początkowego.
Składnia i semantyka interfejsów klienta rejestru.
Komunikat o błędzie ebXML DTD.
DTD rejestru ebXML.

Obiekty rejestru i metadane

Obiekty rejestru

Odnosi się do obiektu, który został zgłoszony do rejestru w celu przechowywania i przechowywania

o nazwie „Pozycja repozytorium”
Dokument XML lub DTD, modele procesów biznesowych, CPP itp.

Metadata

Jest używany przez rejestr do klasyfikowania i zarządzania obiektami rejestru.
Jest reprezentowany przez wpis do rejestru

Model informacji rejestru (RIM)

Model informacji o rejestrze (RIM) zapewnia plan wysokiego poziomu dla metadanych w rejestrze ebXML. Można to przedstawić jako stos oprogramowania lub piramidę usług, jak pokazano na poniższym rysunku. Elementy modelu informacyjnego reprezentują metadane o treści, a nie samą treść w repozytorium. Model informacji rejestru definiuje typy obiektów przechowywanych i zorganizowanych w rejestrze.

Model informacyjny to mapa drogowa określająca typy metadanych i relacje między metadanymi. Model informacji rejestru może być odwzorowany na schemat relacyjnej bazy danych, schemat obiektowej bazy danych lub inny fizyczny schemat.

„Podstawowy komponent zawiera informacje o prawdziwej koncepcji biznesowej oraz związkach między tą koncepcją a innymi koncepcjami biznesowymi. Podstawowy komponent może być pojedynczą informacją biznesową lub rodziną informacji biznesowych. Jest kluczowy, ponieważ występuje w wielu różnych obszarach wymiany informacji branżowych / biznesowych ”

... Formularz definicji xbXML uproszczony przez Erica Chiu

Podstawowy komponent to podstawowy blok konstrukcyjny wielokrotnego użytku, który zawiera informacje reprezentujące koncepcję biznesową. Niektóre przykłady podstawowych składników części zamówienia zakupu to data zamówienia, podatek od sprzedaży i łączna kwota.

Ogólnie podstawowe komponenty są używane w wielu różnych dziedzinach, branżach i procesach biznesowych. W środowisku ebXML główne komponenty są elementami składowymi semantyki XML i słownictwa biznesowego, które są używane w wiadomościach i dokumentach.

Z konkretnego dokumentu biznesowego w procesie biznesowym możemy odwołać się do podstawowego komponentu, który zawiera minimalny zestaw informacji o e-biznesie. Jeśli procesy biznesowe są czasownikami w terminologii e-biznesu, podstawowymi składnikami są rzeczowniki i przymiotniki.

Główny komponent może być używany w kilku sektorach biznesowych, ale może też stać się zależny od kontekstu domeny biznesowej, takiej jak indywidualny obszar przemysłu.

Główny składnik współpracuje z rejestrem, ponieważ można go przechowywać i odzyskiwać przy użyciu standardowego rejestru ebXML. Centralna biblioteka podstawowych komponentów służy jako dokument referencyjny dla typowych praktyk biznesowych w branżowych procesach biznesowych.

Narzędzia i referencje

Lista niezbędnych referencji i narzędzi dla podstawowych komponentów dostarczanych przez ebXML dla analityków biznesowych i technicznych przedstawia się następująco:

Context and the Re-usability of Core Components: Ten dokument zawiera definicje kontekstu, źródła list wartości klasyfikacyjnych oraz model obrazowy przedstawiający relacje między głównym komponentem a deskryptorem kontekstu.
Catalog of Context Drivers: Ten dokument zawiera katalog sterowników kontekstowych.
Document Assembly and Context Rules: Opisuje procedury i schematy składania dokumentów przy użyciu podstawowych komponentów sterowanych kontekstowo.
Core Components Dictionary:Ten dokument jest podzielony na sekcje. Każda sekcja zaczyna się od informacji o odpowiedniej kategorii i typie podstawowego komponentu.
Core Components Editor and Browser: Narzędzia te pomagają analitykom przeglądać istniejące podstawowe komponenty i integrować je w celu zdefiniowania formatu komunikatów XML wymienianych między partnerami handlowymi oraz prawidłowego zdefiniowania i zastosowania reguł kontekstu.

Przykłady podstawowych komponentów:

Główny składnik A:
- Dostawca (Przemysł1)
- Producent (przemysł 2)
- Dostawca (przemysł 3)
Główny składnik B:
- Dystrybutor (przemysł 1)
- Hurtownik (przemysł 2)
- Kupiec (Przemysł 3)
Główny składnik C:
- Sklep (Przemysł 1)
- Outlet (przemysł 2)
- Sprzedawca (branża 3)

Wniosek

Podstawowe komponenty to -

Unikalna identyfikacja.
Struktury danych niskiego poziomu do wielokrotnego użytku
- -eg, impreza, adres, telefon, data, waluta
- -Context-sensitive
Służy do definiowania procesów biznesowych i modeli informacyjnych.
Ułatwia interoperacyjność między różnymi systemami.
Główny komponent w ebXML może zawierać inny podstawowy komponent.

Kompletna wiadomość jest nazywana pakietem wiadomości, który jest obiektem Multipurpose Internet Mail Extensions (MIME). Pakiet wiadomości składa się z dwóch głównych części:

SOAP Message Container: Jest to wymagana część wiadomości i zawiera elementy rozszerzenia SOAP dla ebXML, takie jak informacje o routingu, informacje o partnerach handlowych, identyfikacja wiadomości i informacje o semantyce dostarczania.
Payload Containers: Jest to opcjonalna część wiadomości i może zawierać wszelkiego rodzaju informacje, które mają być wymieniane między stronami.

Kryteria projektowania wiadomości

Zgodnie ze specyfikacją usługi przesyłania wiadomości, cele projektowe usługi wiadomości ebXML są następujące:

Tam, gdzie to możliwe, wykorzystuj istniejące standardy.
Bądź prosty do wdrożenia.
Wspieraj przedsiębiorstwa każdej wielkości.
Obsługa szerokiej gamy protokołów komunikacyjnych (HTTP, SMTP, FTP itp.)
Obsługa ładunków dowolnego typu (transakcje XML, EDI, dane binarne itp.)
Obsługuj niezawodne wiadomości.
Zapewnij bezpieczeństwo.

Architektura wiadomości

Usługa wiadomości ebXML została zaprojektowana do pracy w ogólnym kontekście inicjatywy ebXML. Jednak architektura techniczna ebXML jest modułowa, a usługa wiadomości może być używana niezależnie od ebXML.

Usługa wiadomości ebXML ma trzy logiczne poziomy architektoniczne między aplikacją biznesową a protokołami sieciowymi:

The Message Service Interface (MSI):Jest to interfejs aplikacji dla aplikacji biznesowych, który wywołuje funkcję obsługi komunikatów w celu wysyłania i odbierania komunikatów. Podobnie jak ODBC, JDBC i inne abstrakcyjne interfejsy usług, udostępnia funkcje obsługi komunikatów jako zdefiniowany zestaw interfejsów API dla programistów aplikacji biznesowych.
The Message Service Handler (MSH): Ma podstawowe usługi, takie jak przetwarzanie nagłówków, analizowanie nagłówków, usługi bezpieczeństwa, niezawodne usługi przesyłania wiadomości, pakowanie wiadomości i obsługa błędów.
The Message Transport Interface (MTI):Jest przeznaczony do wysyłania wiadomości przez różne sieci i protokoły komunikacyjne na poziomie aplikacji. Interfejs transportowy przekształca dane specyficzne dla ebXML w inne formy przenoszone przez usługi sieciowe i protokoły. Wymaga to pełnej wymiany między dwiema stronami, podłączania istniejących protokołów w stosie sieciowym.

Na poniższym diagramie przedstawiono architekturę przesyłania wiadomości ebXML.

Formatowanie wiadomości:

Wiadomość ebXML musi być sformatowana zgodnie ze specyfikacją usługi wiadomości ebXML i musi być zgodna ze składnią, formatem i regułami kodowania MIME. Definicje elementów XML są dostarczane przez schemat XML, który rozszerza protokół SOAP o zdefiniowanie nagłówka wiadomości ebXML, nagłówka śledzenia, manifestu, statusu i potwierdzenia.

Wniosek

Komunikacja ebXML -

Używa protokołu SOAP z załącznikami jako koperty ładunku.
Działa z różnymi protokołami komunikacyjnymi, takimi jak HTTP, SMTP, FTP.
Obsługuje semantykę wyższego poziomu potrzebną w transakcjach biznesowych. (Bezpieczeństwo i niezawodność)

Poniższy diagram przedstawia scenariusz ebXML, który ułatwia przyjęcie koncepcji ebXML. Przykład zaczerpnięto ze specyfikacji technicznej architektury.

Przykład pokazuje, jak organizacje przygotowują się do ebXML, szukają nowych partnerów handlowych, a następnie angażują się w biznes elektroniczny.

Firma A przegląda rejestr ebXML, aby zobaczyć, co jest dostępne w Internecie. W najlepszym przypadku firma A może ponownie wykorzystać wszystkie istniejące procesy biznesowe, dokumenty i podstawowe komponenty wspólne dla jej branży, które są już zapisane w rejestrze ebXML. W przeciwnym razie firma A projektuje brakujące części, przechowuje je w rejestrze ebXML i udostępnia swoim partnerom branżowym.
Firma A decyduje się na prowadzenie biznesu elektronicznego w sposób ebXML i rozważa wdrożenie lokalnej aplikacji zgodnej z ebXML. Interfejs usług biznesowych ebXML (BSI) zapewnia połączenie między firmą a zewnętrznym światem ebXML. Firma musi stworzyć profil współpracy (CPP), który opisuje obsługiwane możliwości procesu biznesowego, ograniczenia i techniczne informacje ebXML, takie jak wybór algorytmów szyfrowania, certyfikatów szyfrowania i wybór protokołów transportowych.
Firma A przesyła swój CPP do rejestru ebXML. Od tego momentu firma A jest publicznie notowana w rejestrze ebXML i prawdopodobnie zostanie odkryta przez inne firmy poszukujące nowych partnerów handlowych.
Firma B jest już zarejestrowana w rejestrze ebXML i szuka nowych partnerów handlowych. Firma B wysyła zapytanie do rejestru ebXML i otrzymuje CPP firmy A. Firma B ma wtedy dwa CPP: CPP firmy A i swój własny. Obie firmy muszą dojść do porozumienia w sprawie sposobu prowadzenia działalności, które w terminologii ebXML nazywa się Porozumieniem o współpracy (CPA). Firma B używa narzędzia ebXML do tworzenia CPA w celu uzyskania CPA na podstawie wymagań dwóch CPP
W tym scenariuszu firma B komunikuje się bezpośrednio z firmą A i wysyła nowo utworzony CPA do akceptacji do firmy A. Po uzgodnieniu CPA przez firmę A obie firmy są gotowe do prowadzenia elektronicznego biznesu.
Firmy wykorzystują następnie ramy ebXML i wymieniają się dokumentami biznesowymi zgodnie z CPA. Oznacza to, że obie firmy przestrzegają procesów biznesowych określonych w CPA.