Seminar WWW und Datenbanken - www-stud.informatik.uni

Transcrição

Seminar WWW und Datenbanken
Jörn Gersdorf1
Sommersemester 2001
1
[email protected]
INHALTSVERZEICHNIS
1
Inhaltsverzeichnis
1 Einführung
3
1.1
Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Ziele von ebXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Überblick über ebXML
4
2.1
Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
ebXML-Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 ebXML Message Service
6
3.1
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.2
SOAP-Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
Grundsätzliche ebXML-Nachrichtenstruktur . . . . . . . . . . . . . . . . . . . .
8
3.4
ebXML-Erweiterungen zu SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5
Ausgewählte ebXML-Erweiterungen zu SOAP . . . . . . . . . . . . . . . . . . . 12
3.6
3.5.1
MessageHeader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5.2
Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Verläßliche Nachrichtenübermittlung . . . . . . . . . . . . . . . . . . . . . . . . 15
4 ebXML Business Processes
15
4.1
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2
Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3
Business Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4
4.5
4.6
4.3.1
UML-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Document Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1
4.4.2
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.5.1
4.5.2
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Choreographien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6.1
4.6.2
Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Jörn Gersdorf
INHALTSVERZEICHNIS
5 Verwandte Initiativen
2
26
5.1
BizTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2
UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6 Zusammenfassung
31
7 Anhang
32
Jörn Gersdorf
1. Einführung
1
3
Einführung
Seit Bestehen der elektronischen Datenverarbeitung versuchen Unternehmen, diese unter anderem zum Zwecke der Effizienzsteigerung und Kostenreduktion einzusetzen. Geschäftsprozesse sollen durch den Einsatz von Datenverarbeitung unterstützt werden, um sie schneller,
transparenter und flexibler zu machen.
Mit dem Aufkommen von Technologien, die häufig unter den Oberbegriffen Internet- und
eCommercetechnologien zusammengefaßt werden, ergeben sich neue Herausforderungen, aber
auch neue Möglichkeiten.
Die ebXML-Initiative will hier einen offenen Standard zur Integration von eBusiness-Applikationen im Internetumfeld schaffen.
Der Großteil dieser Seminararbeit basiert auf einigen vorläufigen ebXML-Spezifikationen, die
inzwischen durch die finalen Versionen ersetzt worden sind (siehe 1.2). Dies sind insbesondere
[ebXML-TA], [ebXML-BP-SS] sowie [ebXML-MSS]. Dabei ist zu beachten, dass die Spezifikationen selbst noch bearbeitet werden und teilweise auch noch Unstimmigkeiten beinhalten.
So zum Beipiel auch die Spezifikation [ebXML-BP-SS], in der widersprüchliche Aussagen
bezüglich des Elements DocumentEnvelope” zu finden sind1 .
”
1.1
Historie
Seit mehr als fünfundzwanzig Jahren praktizieren Unternehmen und Behörden bereits den
elektronischen Austausch von Daten (Electronic Data Interchange, abgekürzt EDI ). Darunter
wird der papierlose Austausch strukturierter Geschäftsdaten wie zum Beispiel Angebotsanfragen, Angebote, Rechnungen etc. verstanden. Ein wesentliches Merkmal dieses Austauschs ist
die Möglichkeit der automatischen Weiterverarbeitung der Nachrichten in der empfangenden
Anwendung.
Trotz der Vorteile, die ein papierloser Austausch von Geschäftsdaten mit sich bringt (Rationalisierung von Kommunikationsvorgängen, Optimierung von Geschäftsprozessen) hat sich
EDI nicht in der Breite durchsetzen können. Wegen der hohen Kosten einer Implementierung betreiben heute vorwiegend Großunternehmen EDI in den klassischen” Standards
”
EDIFACT respektive X.12. Weitere Nachteile dieser Formate sind die starre Ausrichtung auf
lang bestehende und unveränderte Geschäftsprozesse sowie die geringen Freiheitsgrade in den
Formatspezifikationen für die Realisierung spezifischer EDI-Nachrichten.
Durch die Verbreitung des Internets existieren zudem neue Möglichkeiten, die im klassischen
EDI nicht vorgesehen waren. Dazu gehören beispielsweise die elektronische Suche von Geschäftspartnern in sogenannten Repositories oder die elektronische Einigung auf bestimmte
Geschäftsprozessvorgänge.
XML bietet in diesem Zusammenhang die Möglichkeit, die auszutauschenden Nachrichten
in einem flexiblen, anerkannten und weit verbreiteten Format zu kodieren. Die Verwendung
von XML und anderen offenen Internetstandards verspricht eine einfache und kostengünstige
Implementierung von XML-basierten EDI-Standards, wodurch diese Technologie auch für
kleine und mittlere Unternehmen interessanter wird.
1
teilweise findet sich ”BusinessDocument” als Attribut zu ”DocumentEnvelope”, teilweise als Kindelement.
Jörn Gersdorf
2. Überblick über ebXML
1.2
4
Ziele von ebXML
Electronic business XML ( ebXML) ist ein Ende 1999 gegründetes gemeinsames Projekt der
UN/CEFACT (United Nations body for Trade Facilitation and Electronic Business) und der
OASIS (Organization for the Advancement of Structured Information Standards). Es hat
sich zum Ziel gesetzt, innerhalb von 18 Monaten eine offene XML-basierte Infrastruktur für
die elektronische Abwicklung von Geschäften bereitszustellen. Seit dem 14. Mai 2001 sind
die ebXML-Spezifikationen nun verabschiedet.
ebXML wird dabei unterstützt durch eine große Anzahl namhafter Unternehmen und Organisationen, darunter das X.12-Standardisierungsgremium, die XML/EDI-Gruppe, S.W.I.F.T.,
IBM und Sun Microsystems.
Ziel von ebXML ist es nicht, eine Reihe papierbasierter Geschäftsdokumente in eine XMLDTD zu übersetzen”, sondern ein Rahmenwerk für die Schaffung konsistenter, robuster und
”
integrationsfähiger (weil offener) eBusiness-Anwendungen zu definieren, um letztendlich dadurch einen einzigen globalen eBusiness-Markt zu schaffen. Dabei ist die Sichtweise nicht
dokumenten- sondern geschäftsprozessorientiert.
2
Überblick über ebXML
ebXML geht weit darüber hinaus, nur ein Format für den Austausch von Geschäftsnachrichten
zu definieren. ebXML stellt die folgenden Konzepte bereit:
• Einen Standardmechanismus, mit dem Geschäftsprozesse und das damit verbundene
Informationsmodell beschrieben werden können.
• Einen Mechanismus, mit dem Geschäftsprozesse in einer Registry hinterlegt und durch
andere Nutzer wiederverwendet werden können.
• Die Möglichkeit, Informationen über Teilnehmer an ebXML aus einer Registry abzurufen
und in dieser abzulegen. Diese Informationen können sein
– unterstützte Geschäftsprozesse
– Daten über Schnittstellen, über die die Geschäftsprozesse abgewickelt werden
– Geschäftsnachrichtstypen, über die Geschäftsprozesse abgewickelt werden
– technische Konfigurationsdaten über Transportprotokolle und Sicherheitsparameter.
• Ein Mechanismus, mit dem eine Vereinbarung über eine Geschäftsbeziehung beschrieben
werden kann und die aus den Daten, die über Teilnehmer in der Registry gespeichert
wurden, abgeleitet werden kann (Collaboration Protocol Agreements, CPA).
• Ein Messaging Service, der den Nachrichtenaustausch sicher und zuverlässig ermöglicht.
• Ein Mechanismus, den Messaging Service entsprechend der Vereinbarungen des CPA’s
zu konfigurieren.
Jörn Gersdorf
2. Überblick über ebXML
5
Dabei werden die entstehenden Beschreibungen und Nachrichten in XML kodiert.
Zur Entwicklung des ebXML-Standards wurden verschiedene Projekt-Teams gebildet, die
jeweils einen Ausschnitt des gesamten Frameworks entwickeln. Im einzelnen sind dies die
folgenden:
• Business Process
• Technical Architecture
• Core Components
• Transport/Routing and Packaging
• Registry and Repository
• Trading Partner
• Proof of Concept
2.1
Beispielszenario
Um einen Eindruck der Nutzung von ebXML zu gewinnen, wollen wir ein Beispielszenario
(Abb. 1) betrachten. Die einzelnen Schritte sind im Folgenden erläutert:
1
Scenarios
Profiles
Geschäftsdetails anfragen
Unternehmen A
Repository
Reg
is
3 Unte trierun
g
rneh
men Profil
A
Lokale System−
implementierung
2
Un
ab tern
Do
fra eh
& wnl
ge me
Pr oa
n
ns
of
d
ile Sc
pr
of
s
en
4
il e
ar
ios
5
ement
arrang
s
t
f
ä
h
c
Ges
Unternehmen B
6
ktionen
Transa
ühren
durchf
Abbildung 1: ebXML-Beispielszenario
Jörn Gersdorf
3. ebXML Message Service
6
1. Unternehmen A erfährt von einer ebXML-Registry. Es schaut die dort vorhandenen
Daten an und entscheidet sich dafür, selbst aktiv an ebXML teilzunehmen.
2. Das Unternehmen A plant und implementiert eine eigene ebXML-konforme Anwendung.
Dabei ist es aber auch nicht unbedingt notwendig, eine Individualanwendung zu erstellen. Vielmehr ist zu erwarten, dass es in Zukunft auch fertige ebXML-Anwendungen
von Drittherstellern gibt, die ein Unternehmen nur für die eigenen Belange konfigurieren
muss (in etwa analog zu anderen Softwaresystemen wie z. B. SAP R/3).
3. Um selbst von anderen Unternehmen gefunden werden zu können, erstellt Unternehmen
A ein sogenanntes Business Profile über sich selbst, das Informationen über die ebXMLSchnittstellen der eigenen Systeme sowie die von A unterstützten Geschäftsszenarien
(das sind in XML kodierte Geschäftsprozesse) enthält. Dieses Business Profile wird in
der ebXML-Registry abgelegt.
4. Unternehmen B sucht einen geeigneten Geschäftspartner. Es fragt daher bei einer
ebXML-Registry nach Unternehmen an, die die gesuchten Geschäftsprozesse unterstützen. Dabei findet Unternehmen B das Unternehmen A und fordert dessen Business
Profile an.
5. Unternehmen B sendet eine Nachricht an Unternehmen A, in dem es Interesse an einer
Geschäftsbeziehung gemäß des Business Profiles von Unternehmen A interessiert ist.
Bevor der eigentliche Austausch von Geschäftsnachrichten erfolgt, sendet Unternehmen
B einen Vorschlag für eine Geschäftsvereinbarung direkt an die ebXML-Schnittstelle von
Unternehmen A. Dieses enthält eine Vereinbarung über die zu nutzenden Geschäftsszenarien sowie über technische Parameter wie zum Beispiel zu nutzende Kommunikationskanäle, Adressen, Verschlüsselungs- und Signatureinstellungen etc.
Nach einer eventuellen Verhandlungsphase akzeptiert Unternehmen A die Vereinbarung.
6. Der eigentliche Austausch von ebXML-Geschäftsnachrichten kann beginnen.
2.2
ebXML-Lebenszyklus
Abbildung 2 zeigt einen Überblick über die einzelnen Phasen im Rahmen des ebXML-Modells
und ihren Zusammenhang mit den Elementen des ebXML-Modells.
In dieser Arbeit werden wir uns nur mit den Schritten Process Definition” und Process
”
”
Excecution” und den dabei angesprochenen Spezifikationen befassen.
3
3.1
ebXML Message Service
Überblick
Der ebXML-Message-Service definiert, wie Nachrichten verpackt”werden müssen, um ebXML”
konform versandt werden zu können. Dabei definiert dieser Standard nicht, wie die Nachrichten selbst (im ebXML-Jargon als payload data bezeichnet) zu formatieren sind, sondern
nur, mit welchen Headern etc. diese Nachrichten zu versehen sind, um als ebXML-Nachricht
Jörn Gersdorf
7
Business Process,
Core Components
Prozess−
definition
Prozess−
management
Business Process
Management
Prozess−
reengineering
Process
Reengineering
Registry/
Repository
Collaboration
Partner− Protocol Profile
entdeckung
Collaboration
Partner− Protocol Agreement
anmeldung
Prozess−
Plugin
ausführung
Business Service
Message Service,
Interface (BSI)
BSI
Abbildung 2: Lebenszyklus einer eBusiness-Anwendung nach ebXML
zu gelten. Tatsächlich können über den Messaging-Service auch nicht-XML-Daten versandt
werden.
Der Standard wurde mit Blick auf Erweiterbarkeit (gegeben durch die Nutzung von XML),
Möglichkeit der Persistenz von Nachrichten, Sicherheitsaspekte und Zuverlässig der Nachrichtenübermittlung (ein wenig in Richtung Quality of Service gehend) entworfen.
Als Transportmedium sind beliebige Kommunikationsprotokolle denkbar; im Standard selbst
sind jedoch nur HTTP und SMTP beschrieben.
Der ebXML-Message-Service ist in [ebXML-MSS] spezifiziert und ist de facto eine Erweiterung
des SOAP-Protokolls2 .
Erste Implementationen sind bereits in der Entstehung: Sun entwickelt mit der Java APIs for
XML Messaging (JAXML) eine Erweiterung zu Java, die explizit die ebXML Message Service
Specification unterstützen soll.
3.2
SOAP-Überblick
Da der ebXML-Messaging Service auf SOAP basiert, gebe ich im folgenden Abschnitt einen
kurzen Überblick über SOAP. Genauere Informationen zu vorhandenen Attributen etc. finden
sich in den Standards [SOAP, SOAPATTACH].
SOAP ist ein einfaches Protokoll, um Nachrichten zwischen Systemen auszutauschen. SOAP
nutzt hierbei XML. Dabei besteht SOAP aus drei Teilen:
• Der SOAP-Envelope definiert, was in einer Nachricht steht, wer sie erhalten soll und ob
eine Behandlung der Nachricht durch den Empfänger optional oder obligatorisch ist.
2
SOAP (Simple Object Access Protokoll), [SOAP], sowie SOAP with Attachments, [SOAPATTACH]
Jörn Gersdorf
8
• Die SOAP encoding rules definieren einen Serialisierungsmechanismus für Datentypen
wie int”, float”, Arrays etc.
”
”
• Die SOAP-RPC-Darstellung definiert eine Konvention, durch die ein RPC-Mechanismus3
repräsentiert wird.
Der ebXML-Messaging-Service bezieht sich dabei lediglich auf eine Erweiterung des SOAPEnvelopes. Eine SOAP-Nachricht besteht immer aus drei Teilen:
• Das Envelope-Element ist das Topelement der Nachricht.
• Der Header ist ein Container, durch den flexibel zusätzliche Eigenschaften zum SOAPProtokoll hinzugefügt werden können. Typischerweise können hier Eingenschaften wie
Authentifizierung oder Transaktionsbehandlung definiert werden.
• Der Body ist der Container, der die eigentliche Nachricht enthält. Der Inhalt des Bodys
wird vom SOAP-Server an die empfangende Anwendung übergeben.
Ein Beispiel-SOAP-Nachrichtenaustausch findet sich in Codebeispiel 1.
SOAP with Attachments
In vielen Nachrichten, die ausgetauscht werden sollen, sollen nicht nur in XML kodierte Daten
enthalten sein. Vielmehr ist es oftmals eine Anforderung, beispielsweise auch nicht-XMLDaten aus Altanwendungen (den sogenannten Legacy-Systemen) oder Binärdaten wie Grafiken über ein XML-konformes Protokoll wie SOAP zu versenden.
Auch der ebXML-Messaging-Service macht keinerlei Angaben, wie die Geschäftsnachrichten
selbst (der payload, siehe Kapitel 3.1) kodiert sein müssen. Deshalb setzt er auch auf SOAP
with Attachments auf.
SOAP with Attachments benutzt zur Bündelung einer SOAP-konformen Nachricht mit beliebigen anderen Daten, die in irgendeinem Zusammenhang zu der Nachricht stehen, den
Multipart/related MIME media type (RFC 2387) sowie ein URI-Schema, mit dem einzelne
MIME Container referenziert werden können (RFC 2111 und RFC 2557). Mittels des URISchemas kann aus der SOAP-konformen Nachricht bezug genommen werden auf die einzelnen
MIME Container und deren Inhalt.
Ein Beispiel hierzu findet sich in Codebeispiel 2. In diesem Beispiel wird eine Nachricht versandt, die eine Referenz auf eine in einem separaten MIME Container enthaltene Unterschrift
im Grafikformat TIFF enthält.
3.3
Grundsätzliche ebXML-Nachrichtenstruktur
Eine ebXML-Nachricht besteht aus einem oder mehreren MIME-Containern, wobei gilt:
3
remote procedure call = entfernter Prozeduraufruf, vgl. DCE.
Jörn Gersdorf
9
Codebeispiel 1 Beispiel: SOAP-Nachrichtenaustausch
Kursanforderungsnachricht:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:HoleKurs xmlns:m="irgendeine URI">
<symbol>DRES</symbol>
</m:HoleKurs>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Antwort auf die Kursanforderung:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:KursAntwort xmlns:m="irgendeine URI">
<kurs>34.5</kurs>
</m:KursAntwort>
</SOAP-ENV:Body>
Jörn Gersdorf
10
Codebeispiel 2 Beispiel: eine SOAP-Nachricht mit einem Anhang (einer Unterschrift)
MIME-Version: 1.0
ContentType: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<[email protected]>"
Content-Description: This is the optional message description.
--MIME_boundary Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <[email protected]>
<?xml version=’1.0’ ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
..
<theSignedForm href="cid:[email protected] "/>
..
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
--MIME_boundary
Content-Type: image/tiff
Content-Transfer-Encoding: binary
Content-ID: <[email protected] >
...binary TIFF image...
--MIME_boundary--
Jörn Gersdorf
11
• Es existiert genau ein sogenannter Header Container, der eine SOAP-Nachricht enthält.
In dieser SOAP-Nachricht werden auch alle Konfigurationen für ebXML vorgenommen.
• Es kann daneben einen oder mehrere sogenannte Payload Container geben, die applikationsabhängigige Geschäftsnachrichten oder -informationen enthalten. Diese müssen
nicht in XML kodiert werden.
Die SOAP-Nachricht selbst ist in die beiden Teile Header und Body aufgeteilt. Dabei werden im Header-Element die ebXML-spezifischen Headerinformationen hinzugefügt; im Body werden Kontrollinformationen sowie Informationen (Referenzen) zu den in den PayloadContainern enthaltenen Geschäftsnachrichten gegeben.
Die Struktur präsentiert sich demnach wie in Abbildung 3.
Komm un ik ation sp rotok oll U m sch l ag
(H TT P, SM T P, ...)
SOA P with A ttach m en ts
M IM E En vel op e
M IM E− Part
SOA P− EN V :En vel op e
SOA P− EN V :H ead er
eb:MessageHeader
eb:TraceHeaderList
N ach rich ten −
p ak et
H ead er−
Con tain er
Other:etc...
SOA P− EN V :Bod y
eb:Manifest
eb:etc.
Other:etc...
M IM E− Part(s)
Payl oad (s)
Payl oad −
Con tain er(s)
Abbildung 3: Aufbau einer ebXML-Nachricht
Mit dem ebXML-Messaging-Service werden die folgenden Möglichkeiten offeriert:
• Eindeutige Indentifikation der Nachricht
• Absender- und Empfängerangaben
• Angabe von Routing-Informationen, d.h. des nächsten ebXML-Message Service Handlers
• Signatur der Nachricht zur eindeutigen Identifikation des Absenders und zur Sicherstellung der Unversehrtheit der Nachricht
Jörn Gersdorf
12
• Empfangsbestätigung
• Fehlerbenachrichtigung
3.4
ebXML-Erweiterungen zu SOAP
ebXML erweitert SOAP-Nachrichten um einige Elemente (die ihrerseits auch wieder Unterelemente enthalten können), die insbesondere Zuverlässigkeits- und Sicherheitsaspekte definieren; sie sind für die Realisierung von eBusiness wichtig, werden aber von der SOAPSpezifikation nicht erfasst.
In den Tabellen 1 und 2 werden die einzelnen Elemente gemeinsam mit ihrer Bedeutung
aufgezeigt.
Element
MessageHeader
Pflicht/
Optional
Pflicht
TraceHeaderList
Optional
ErrorList
Optional
Signature
Via
Optional
Optional
Inhalt
Beinhaltet Routing-Informationen (Absender, Empfänger)
und Kontextinformationen über die Nachricht.
Beinhaltet Elemente, die Zwischenstationen von Nachrich”
”
ten auf ihrem Weg vom Absender zum Empfänger enthalten.
Vergleichbar mit Received -Feldern in Mails.
”
”
Beinhaltet Fehlermeldungen zu einer zuvor versandten
Nachricht.
Beinhaltet eine digitale Signatur (XML-Signature)
Ein Element, um Informationen an den nächsten ebXML
Message Service Handler zu senden, der diese Nachricht erhält (also eine Nachricht an Zwischenstationen die in der
”
”
TraceHeaderList auftauchen).
Tabelle 1: ebXML-Erweiterungen zum SOAP-Header
Element
Manifest
Acknowledgment
Pflicht/
Optional
Pflicht
Optional
StatusData
Optional
Inhalt
Beinhaltet Referenzen zu Payload-Containern.
Wird genutzt zur Eingangsbestätigung einer empfangenen
Nachricht.
Wird genutzt, um auf eine Statusanzeige einer zuvor gesandten Nachricht zu antworten.
Tabelle 2: ebXML-Erweiterungen zum SOAP-Body
3.5
3.5.1
Ausgewählte ebXML-Erweiterungen zu SOAP
MessageHeader
Der MessageHeader muss in allen Nachrichten vorhanden sein und ist ein Kind-Element des
SOAP-Header-Elementes. Er kann die folgenden Informationen enthalten:
Jörn Gersdorf
Element
From / To
CPAId
ConversationId
SequenceNumber
Service
Action
MessageData
QualityOfService
13
Inhalt
Beinhalten Absender und Empfänger der Nachricht
Beinhaltet eine Referenz auf ein Collaboration Protocol
Agreement. Ist in der Regel eine URI.
Identifiziert einen Satz von zusammengehörigen Nachrichten
innerhalb einer Nachrichtensitzung.
Gibt die Nachrichtennummer innerhalb einer ConversationId an. Wichtig für die Nachrichtenreihenfolge. Dabei ist
die SequenceNumber ein Integer, gezählt von 0 bis 99999999.
Identifiziert den Service, der mit der Nachricht angesprochen
werden soll. Der Service wird durch den Applikationsentwickler definiert. Er kann zum Beispiel Bestellungsannah”
me lauten.
”
Identifiziert einen Prozess innerhalb eines Services, der angestoßen werden soll.
Dient der eindeutigen Identifizierung einer Nachricht. Dabei
wird eine MessageId, ein Zeitstempel, eine RefToMessageId
(eine Id, auf die man sich bezieht) sowie ein Element Ti”
meToLive spezifiert.
”
Mit diesem Element kann die gewollte Dienstgüte definiert
werden. Dabei kann man festlegen, ob man eine (signierte oder unsignierte) Empfangsbestätigung erhalten möchte,
ob die Nachrichtenreihenfolge eingehalten und ob eine Nachricht zuverlässig versandt werden muss.
Ein Beispiel dürfte deutlicher machen, was gemeint ist. Unser Beispiel verwendet dabei nicht
nur den MessageHeader, sondern auch TraceHeaderList und Via.
Betrachten wir den ebXML-Header in Codebeispiel 3. In diesem Beispiel sendet exam”
ple.com” eine Nachricht an QRS543”. Diese Nachricht ist eine neue Bestellung aus dem
”
Servicebereich Bestellungen. Die Nachricht ist eine Antwort auf die Nachricht mit der Id
mid:UUID-1”. Es wird eine digital signierte Empfangsbestätigung verlangt. Die Nach”
richt muss genau einmal beim Empfänger verarbeitet werden. Es wird unter dem CPA
http://www.ebxml.org/cpa/123456 operiert. Dieses CPA muss vor dem ersten Versenden
einer Nachricht zwischen Empfänger und Absender definiert worden sein.
Der TraceHeader gibt an, welche Stationen die Nachricht genommen hat. Die Nachricht ist
bis zu diesem Zeitpunkt nur zu einer Zwischenstation - PartyB - gekommen.
Das Via-Element übergibt Informationen an die nächste Zwischenstation der Nachricht auf
ihrem Weg zum Empfänger. Im Beispiel gibt sie dem nächsten Empfänger den Auftrag, den
Empfang der Nachricht zu loggen.
3.5.2
Body
Das Body-Element besteht - wie in Tabelle 2 erläutert - aus den Elementen Manifest, StatusData und Acknoledgement. Wir betrachten hier im Besonderen das Manifest-Element.
Das Manifest-Element besteht im Wesentlichen aus Referenzen auf Payload-Container. Dabei
werden die Referenzen als Xlink-Simple-Links repräsentiert (siehe [XLINK]). Daneben kann
Jörn Gersdorf
14
Codebeispiel 3 Beispiel eines ebXML-Headers
<eb:MessageHeader id=".." eb:version="0.98"
SOAP-ENV:mustUnderstand="1">
<eb:From>uri:example.com</eb:From>
<eb:To type="someType">QRS543</eb:To>
<eb:CPAId>http://www.ebxml.org/cpa/123456</eb:CPAId>
<eb:ConversationId>987654321</eb:ConversationId>
<eb:Service type="myservicetypes">Bestellungen</eb:Service>
<eb:Action>NeueBestellung</eb:Action>
<eb:MessageData>
<eb:MessageId>mid:UUID-2</eb:MessageId>
<eb:Timestamp>20000725T121905.000Z</eb:Timestamp>
<eb:RefToMessageId>mid:UUID-1</eb:RefToMessageId>
</eb:MessageData>
<eb:QualityOfServiceInfo deliverySemantics="OnceAndOnlyOnce"
deliveryReceiptRequested="Signed" />
</eb:MessageHeader>
<eb:TraceHeaderList id=".." eb:version="0.98"
<eb:TraceHeader>
<eb:SenderURI>uri:example.com</eb:SenderURI>
<eb:ReceiverURI>url:PartyB.com/PartyBMsh</eb:ReceiverURI>
<eb:Timestamp>20001216T21:19:35.145Z-8</eb:Timestamp>
</eb:TraceHeader>
</eb:TraceHeaderList>
<eb:Via SOAP-ENV:mustUnderstand="1"
SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next"
eb:version="0.98">
<eb:CPAId>xyzCPA</eb:CPAId>
<eb:Service>Proxy</eb:Service>
<eb:Action>LogActivity</eb:Action>
</eb:Via>
Jörn Gersdorf
4. ebXML Business Processes
15
auch ein Schema referenziert werden, das angibt, welchem Schema der referenzierte PayloadContainer entspricht.
Auch hierzu sei ein Beispiel betrachtet (Codebeispiel 4). Hier wird Bezug genommen auf eine
Geschäftsnachricht, die im MIME-Container mit der Id payload-1” steht. Diese Geschäfts”
nachricht genügt dem referenzierten Schema.
Codebeispiel 4 Beispiel eines Manifests im Body-Tag
<eb:Manifest id="Manifest" eb:version="0.98"
<eb:Reference id="payload1"
xlink:role="http://abc.com/business/bestellungen"
xlink:href="cid:payload-1">
<eb:Description>Bestellung über 20 Lollies</eb:Description>
<eb:Schema location="http://abc.com/schemas/bestell/po.xsd"
version="1.0"/>
</eb:Reference>
</eb:Manifest>
3.6
Verläßliche Nachrichtenübermittlung
Im Rahmen des Reliable Messaging” wird ein Protokoll definiert, das festlegt, wie zwei Mes”
sage Service Handler (MSH) verläßlich Nachrichten miteinander austauschen können. Dabei
muss ein MSH, der dieses Protokoll unterstützt, einen Mechanismus für die persistente Speicherung von Nachrichten zur Verfügung stellen, um bei einem Systemausfall bereits empfangene Nachrichten weiterverarbeiten zu können.
Das ebXML-Protokoll bietet dabei zwei Semantiken an: OnceAndOnlyOnce” (hierbei darf
”
die empfangende Anwendung eine Nachricht nur genau einmal erhalten) und BestEffort”
”
(hierbei existiert keine verläßliche Nachrichtenübermittlung).
Daneben können die in Tabelle 3 aufgeführten Parameter festgelegt werden.
4
4.1
ebXML Business Processes
Überblick
ebXML basiert auf einer geschäftsprozessorientierten Sichtweise. Dabei beschreibt ein Geschäftsprozess detailliert, wie und wann ein Geschäftsteilnehmer bestimmte Rollen einnimmt,
welche Verbindungen es zu anderen Geschäftsteilnehmern gibt und welche Verantwortlichkeiten in diesem Zusammenhang auf den einzelnen Geschäftsteilnehmern lasten. Beispiele für
eine Zusammenarbeit auf Basis von Geschäftsprozessen sind in Abbildung 4 gezeigt.
Dabei geht es darum, den Interaktionsfluß zwischen Geschäftsteilnehmern zu beschreiben,
also etwa zu sagen, welche Schritte durchgeführt werden müssen, um eine Bestellung komplett durchzuführen. Es geht bei der Spezifikation von Geschäftsprozessen nicht darum, zu
Jörn Gersdorf
Parameter
TimeToLive
reliableMessagingMethod
AckRequested
Timeout
Retries
RetryInterval
PersistDuration
16
Bedeutung
Angabe, wann eine Nachricht ungültig wird. Falls dies der
Fall ist, muss das Ablaufen der Nachricht dem Sender in
”
”
einer ErrorList mitgeteilt werden.
ebXML oder Transport (d. h. ein Protokoll eines Fremdproduktes)
Empfangsbestätigung anfordern. Kann entweder signiert
oder unsigniert sein.
Spezifiziert die Dauer, die ein MSH auf eine Empfangsbestätigung warten muss, bevor er erneut eine Nachricht sendet.
maximale Wiederholungsanzahl
Intervall, in dem Wiederholungen erfolgen sollen (ausgedrück in XMLSchema timeduration)
Minimale Dauer, die eine Nachricht persistent aufbewahrt
werden muss.
Tabelle 3: Reliable Messaging Parameter
Langzeitvertrag
schliessen
Komponentenanforderungen
Planungsdokument
senden
bestellen
Partner A
Material senden
Partner B
Lieferung
arrangieren
Zahlung
arrangieren
Abbildung 4: Beispiele für Geschäftstransaktionen
Jörn Gersdorf
17
beschreiben, wie die Dokumente (z. B. Bestelldaten) auszusehen haben, die zwischen den Geschäftsteilnehmern ausgetauscht werden, sondern darum, zu beschreiben, wie die Interaktion
zwischen Geschäftsteilnehmern im Rahmen eines ebXML-Geschäftsprozesses aussieht (z. B.
Bestellung).
Dabei werden im Rahmen der Interaktion Geschäftsdokumente ausgetauscht. Diese Geschäftsdokumente können zusammengesetzt sein aus Komponenten der ebXML Core Library,
die die Core Components enthält.
Fertig beschriebene Geschäftsprozesse werden im ebXML-Repository zur Einsichtnahme potenzieller Geschäftspartner abgelegt.
Wichtig ist zu wissen, dass die Geschäftsprozesse von ebXML zwei Ansichten haben: eine
UML-Ansicht und eine XML-Ansicht. Diese sind jedoch als isomorph anzusehen. Diese
Ausarbeitung bezieht sich auf die XML-Ansicht, die auch auch im Repository abgelegt wird.
Die Spezifikation zur Modellierung von Geschäftsprozessen in ebXML findet sich in der Spezifikation [ebXML-BP-SS].
4.2
Struktur
Die Struktur von Geschäftstransaktionen in der ebXML-Welt wird in Abbildung 5 dargestellt.
Dort ist ersichtlich, dass Geschäftstransaktionen mit einem Dokumentenfluss assoziiert sind.
Geschäftstransaktionen ihrerseits werden wieder durch eine Choreographie in ihrer Abfolge
gesteuert. Die Choreographie wird durch eine sogenannte Collaboration zusammengefaßt und
von den Geschäftspartnern als solche referenziert.
Zusammenarbeit
(Collaboration)
Choreographie
Ro
lle
lle
Ro
Partner A
Partner B
Geschäfts−
Geschäfts−
proG
zess
eschäfts−
proG
zess
eschäfts−
prozess
prozess
Dokumenten−
Dokumenten−
fluss
Dokumenten−
fluss
Dokumenten−
fluss
fluss
Abbildung 5: Struktur von ebXML-Geschäftsprozessen
Im Einzelnen sieht es folgendermaßen aus: Zwei oder mehr Geschäftspartner nehmen über
Rollen an einer Collaboration teil. Rollen können zum Beispiel Käufer” oder Verkäufer”
”
”
Jörn Gersdorf
18
sein und drücken aus, welche Position ein Geschäftspartner innerhalb einer Collaboration
einnimmt. Die Rollen tauschen im Rahmen von Geschäftstransaktionen Informationen aus.
Dabei besteht jede Geschäftstransaktionen aus einem oder zwei vordefinierten Dokumentenflüssen. Die Reihenfolge, in der Geschäftstransaktionen abzuarbeiten sind, wird durch Choreographien definiert. Die einzelnen Begriffe werden im folgendenden nochmals näher beleuchtet:
1. Business Collaboration
Eine Collaboration ist eine Menge von Geschäftstransaktionen und bildet dadurch einen
unternehmensübergreifenden Geschäftsprozess ab. Jeder Geschäftspartner nimmt mindestens eine Rolle in einer Collaboration ein. Es gibt zwei Arten von Collaborations:
• Binary Collaborations: es nehmen zwei Geschäftspartner teil.
• Multiparty Collaborations: es nehmen mehr als zwei Geschäftspartner teil. Multiparty Collaborations werden aus Binary Collaborations zusammengesetzt”.
”
Binary Collaborations werden aus einer Menge von Geschäftsaktivitäten zusammengesetzt. Eine Geschäftsaktivität kann dabei entweder ein Geschäftsprozess sein (in diesem
Sinne ist die Aktivität atomar) oder eine andere Binary Collaboration. Mit dieser Definition wird Wiederverwendung von Collaborations erst möglich.
Beispiel: Ein Beispiel für eine Collaboration wäre ein Bestellvorgang.
2. Geschäftstransaktion
Eine Geschäftstransaktion ist atomar (in dem Sinne, dass sie nicht mehr in Unter”
Geschäftstransaktionen unterteilt werden kann) und wird zwischen zwei Partnern im
”
gegensätzlichen Rollen ausgeführt (z. B. Käufer und Verkäufer). Im Allgemeinen sind
diese Rollen als anfordernde und antwortende Rolle zu charakterisieren.
Ein weiteres Merkmal von Geschäftstransaktionen ist, dass sie auch im Datenbank”
sinne” atomar sind, d. h. sie können nur als Ganzes entweder erfolgreich sein oder
fehlschlagen.
Beispiel: Ist die Collaboration eine Bestellung, so könnten zugehörige Geschäftstransaktionen die Bestellung an sich, die Lieferung, die Zahlung sein.
3. Dokumentenfluss
Ein Dokumentenfluss ist die Realisierung einer Transaktion in Form von Dokumenten,
die die Geschäftspartner untereinander austauschen. Dabei gibt es immer ein Request””
Dokument und optional, falls eine Antwort notwendig ist, auch ein Response”-Dokument.
”
Die Dokumente selbst werden über ebXML Core Components definiert. Es ist allerdings
auch möglich, die Dokumente anders (auch als nicht-XML-Dokumente) zu definieren.
4. Choreographie
Die Choreographie defniert die Reihenfolge von Geschäftstransaktionen innerhalb einer
Binary Collaboration. In der UML-Ansicht von ebXML-Business-Processes würde man
die Choreographie als Aktivitätsdiagramm (welches einen endlichen Zustandsautomaten
modelliert) darstellen.
Im Rahmen der Choreographie ist es nicht nur möglich, eine reine sequentielle Reihenfolge festzulegen, sondern über sogenannte Guards (Wächter) können auch bedingte
Zustandsübergänge definiert werden.
Jörn Gersdorf
4.3
19
Business Transactions
Wir betrachten zunächst Geschäftstransactionen und ihre Modellierung in ebXML.
Eine Geschäftstransaktion hat folgende Eigenschaften in ebXML:
Atomar. Eine Geschäftstransaktion ist atomar. Er kann nicht in zwei Untergeschäftsprozesse
unterteilt werden.
Bestandteile. Eine Geschäftstransaktion besteht aus einer anfragenden Geschäftsaktivität,
gegebenenfalls einer antwortenden Aktivität sowie einem oder zwei Dokumentflüssen.
4.3.1
UML-Modellierung
In Abbildung 6 ist die UML-Darstellung wiedergegeben.
4.3.2
Beispiel
Wir betrachten nun ein Beispiel einer Geschäftstransaktion. Wir nehmen den einfachen Fall
einer Bestellung. In Codebeispiel 5 ist die Geschäftstransaktion in ebXML modelliert.
Codebeispiel 5 ebXML-Geschäftsprozess Bestellung”
”
<BusinessTransaction name="BestellungBT">
<RequestingBusinessActivity name=""
isNonRepudiationRequired="true"
timeToAcknowledgeReceipt="P2D"
timeToAcknowledgeAcceptance="P3D">
<DocumentEnvelope isPositiveResponse="true"
BusinessDocument="Bestellung" />
</RequestingBusinessActivity>
<RespondingBusinessActivity name=""
isNonRepudiationRequired="true"
timeToAcknowledgeReceipt="P5D">
BusinessDocument="Bestellung Bestätigung"/>
</RespondingBusinessActivity>
</BusinessTransaction>
In diesem Beispiel wird die Geschäftstransaktion mit dem Namen BestellungBT” (BT soll
”
für BusinessTransaction stehen) modelliert. Sie besteht aus einer anfragenden und einer
antwortenden Aktivität. Die Anfrage entspricht einer Bestellung, die Antwort einer Annahmebestätigung der Bestellung.
Das Attribut isNonRepudiationRequired” in beiden Aktivitäten besagt, dass der Empfänger
”
vor Versenden einer Empfangsbestätigung prüfen muss, ob die empfangene Nachricht syntaktisch korrekt und semantisch verständlich ist. Die Angaben P2D” oder P3D” bedeuten Pe”
”
”
riod 2 Days” bzw. Period 3 Days”. Diese Angaben entsprechen einem W3C/ISO-Standard.
”
Jörn Gersdorf
20
Abbildung 6: Klassendiagramm für Geschäftsprozess
Jörn Gersdorf
21
Innerhalb der beiden Geschäftsaktivitäten werden die Dokumentflüsse (hier relativ einfache)
definiert. Im Request-Fall wird ein Geschäftsdokument Bestellung” gesandt. Das Attribut
”
isPositiveResponse” besagt, dass es sich hierbei um einen Schritt innerhalb der Transaktion
”
handelt.
4.4
Document Flows
Dokumentflüsse repräsentieren die Dokumente, die zwischen Anfrager (Requester) und Antworter (Responder) effektiv versandt werden. Dabei werden die Dokumente im Rahmen der
Geschäftsprozessmodellierung selbst nicht definiert; vielmehr definiert man Umschläge” (Do”
cumentEnvelopes), die auf tatsächliche Dokumentspezifikationen verweisen.
Es gibt immer genau einen DocumentEnvelope für eine RequestingActivity. Für eine RespondingActivity kann es null, eine oder mehrere disjunkte DocumentEnvelopes geben. Disjunkt
meint hier, dass für je einen Zustand nur genau ein DocumentEnvelope gültig ist (z. B.
BestellAnnahme und BestellZurückweisung).
4.4.1
UML-Modellierung
In Abbildung 7 ist die UML-Darstellung wiedergegeben.
4.4.2
Beispiel
Das Codebeispiel 6 wird die Verwendung verdeutlichen.
Hierbei handelt es sich im Wesentlichen um das gleiche Beispiel wie Codebeispiel 5. Es wurde
um die Definition der Geschäftsdokumente im Element DocumentSpecification” erweitert.
”
Die DocumentSpecification gibt an, wo die Spezifikationen für die Geschäftsdokumente zu
finden sind (location).
Innerhalb der DocumentEnvelope-Elemente wird über das Attribut BusinessDocument” auf
”
die Definition des zu verwendenden Geschäftsdokument zurückgegriffen.
In der RespondingBusinessActivity sehen wir ein Beispiel, in dem mehrere disjunkte DocumentEnvelopes anhand des Attributs isPositiveResponse” verwendet werden. Im Fall isPo”
”
sitiveRespone = true” wird eine Bestellbestätigung versandt, im anderen Fall eine Ablehnung.
In diesem Attribut sind beliebige boolsche Ausdrücke erlaubt. Auch ein XPath-Ausdruck, der
bestimmte Werte im BusinessDocument selbst abfragt, ist erlaubt.
4.5
Collaborations
Wir betrachten nur binäre Collaborations, also solche zwischen zwei Geschäftspartnern. Die
Semantik von Multiparty Collaborations findet sich natürlich in [ebXML-BP-SS].
Eine binary Collaboration wird immer von genau zwei Rollen genutzt, die Authorized Roles
genannt werden, da sie Teilnehmer repräsentieren, die authorisiert sind, eine bestimmte binary
Collaboration zu nutzen.
Jörn Gersdorf
22
Abbildung 7: Klassendiagramm für DocumentEnvelope
Jörn Gersdorf
23
Codebeispiel 6 Beispiel DocumentEnvelope
<DocumentSpecification name="meineSpezi" location="irgendwo"
logicalModel="sonstwo">
<BusinessDocument name="Bestellung" />
<BusinessDocument name="Bestellung ok" />
<BusinessDocument name="Bestellung Ablehnung" />
<BusinessDocument name="Lieferinstruktionen" />
</DocumentSpecification>
<BusinessTransaction name="Bestellung">
<RequestingBusinessActivity name="">
BusinessDocument ="meineSpezi/Bestellung "/>
<Attachment name="Lieferinstruktionen"
mimeType="text/xml"
BusinessDocument ="meineSpezi/Lieferinstruktionen "
spec=""/>
</RequestingBusinessActivity>
<RespondingBusinessActivity>
BusinessDocument ="meineSpezi/Bestellung ok "/>
<DocumentEnvelope isPositiveResponse="false"
BusinessDocument ="meineSpezi/Bestellung Ablehnen "/>
</RespondingBusinessActivity>
</BusinessTransaction>
Jörn Gersdorf
24
Eine binary Collaboration besteht aus einer oder mehreren Business Activities. Business
Activities sind hierbei entweder Business Transaction Activities oder Collaboration Activities
(ob binär oder Multiparty ist hierbei egal). Bei jeder dieser Business Activities wird eine
der beiden Authorized Roles dem Initiator (=from) der Business Activity, die andere dem
Responder (=to) zugewiesen.
Eine Business Transaction Activity verweist hierbei auf eine Business Transaction, die anderswo definiert wurde. Hierdurch können also Geschäftstransaktionen wiederverwendet werden.
Analog verweist eine Collaboration Activity auf eine Collaboration.
Collaborations werden auch noch an anderer Stelle referenziert: Im Rahmen der Aushandlung
eines CPAs (Collaboration Protocol Agreement) zu Beginn der Geschäftsbeziehung einigen
sich die Geschäftspartner auf die Verwendung bestimmter Collaborations. Diese sind im CPA
festgehalten. Es werden also nicht die Business Transactions referenziert, sondern die auf
höherer Abstraktionsebene befindlichen Collaborations.
4.5.1
UML-Modellierung
Wir zitieren in Abbildung 8 wieder die Modellierung von Collaborations in UML-Syntax aus
[ebXML-BP-SS].
4.5.2
Beispiel
Wie üblich diskutieren wir nun ein Beispiel (Codebeispiel 7).
Codebeispiel 7 ebXML Collaboration
<BinaryCollaboration name="Gesamtbestellung" timeToPerform="P5D">
<Documentation>
timeToPerform = Periode 5 Tage ab Transaktionsstart
</Documentation>
<AuthorizedRole name="buyer"/>
<AuthorizedRole name="seller"/>
<BusinessTransactionActivity name="Bestellung"
businessTransaction="BestellungBT"
fromAuthorizedRole="buyer"
toAuthorizedRole="seller"
isLegallyBinding="true" />
<BusinessTransactionActivity name="Lieferungsanzeige"
businessTransaction="LieferanzeigeBT"
toAuthorizedRole="seller />
</BinaryCollaboration>
Zunächst werden die authorisierten Rollen definiert. Diese werden in den BusinessTransactionActivities verwendet, um festzulegen, wer eine bestimmte Transaktion anstoßen darf.
Jörn Gersdorf
25
Abbildung 8: Klassendiagramm für Binary Collaboration
Jörn Gersdorf
5. Verwandte Initiativen
26
Danach werden die Transaktionen definiert, die in der Collaboration Gesamtbestellung” ge”
nutzt werden dürfen. Es wird jeweils festgelegt, wer Initiator und wer Responder einer Transaktion sein darf. Besonders ist noch das Attribut isLegallyBinding”. Dieses gibt an, ob eine
”
bestimmte Transaktion als rechtlich bindend anzusehen ist.
4.6
Choreographien
Eine Choreographie ist sozusagen das Regiezentrum” eines Geschäftsprozesses. Sie gibt die
”
Reihenfolge und die bedingte Ausführung von Business Activities (also Business Transactions
bzw. Collaborations) innerhalb einer binary Collaboration an.
Diese Choreographie kann man sich als vorstellen als ein UML Aktivitätendiagramm, in dem
Business States durchlaufen werden. Ein solcher Business State kann eine Business Activity
sein; es gibt daneben aber auch besondere Business States wie Start (der Anfangszustand),
CompletionState (Endzustand), Fork (hier kann eine Verzweigung modelliert werden: ausgehend von einem Zustand wird auf zwei neue Zustände verzweigt), Join (hier werden mehrere
Zustände auf einen einzigen vereinigt).
Daneben können Transitionen durchlaufen werden. Diese beziehen sich immer auf Business
Activities, d. h. es wird von einer Business Activity auf eine andere umgeschaltet”.
”
Ein letzter Parameter ist Concurrency.” Dieser gibt an, ob mehrere Transaktionen des Trans”
aktionstyps, zu dem der Parameter Concurrency” gehört, zur gleichen Zeit als Teil der glei”
chen Business Transaction Activity offen sein dürfen.
4.6.1
UML-Modellierung
Die UML-Modellierung findet sich in Abbildung 9.
4.6.2
Beispiel
Wir schließen die Betrachtung von ebXML Business Processes mit dem letzten Beispiel: dem
Zusammenfügen der Business Transactions zu einer Collaboration, in der die Übergänge von
Transaktion zu Transaktion durch eine Choreographie definiert ist (siehe Codebeispiel 8).
Interessant ist hier vor allem auch die Nutzung einer sogenannten GuardCondition, die sicherstellt, dass eine bestimmte Transition nur dann ausgeführt wird, wenn diese Condition zutrifft.
Im Falle der GuardCondition gibt es die vier zulässigen Werte Sucess”, BusinessFailure”,
”
”
TechnicalFailure” und AnyFailure”, die sich allesamt auf den Status der zuvor ausgeführten
”
”
Business Transaction beziehen.
Alternativ könnte man auch eine GuardExpression nutzen; dies darf jede zulässige Expression
sein, die zu einem boolschen Wert evaluiert werden kann. Dabei darf per XPath-Ausdrücken
auch auf umgebende Dokumentinhalte (des DocumentEnvelopes) bezug genommen werden.
5
Verwandte Initiativen
Jörn Gersdorf
27
Abbildung 9: Klassendiagramm für Choreography
Jörn Gersdorf
28
Codebeispiel 8 ebXML Collaboration mit Choreography
<BinaryCollaboration name="Gesamtbestellung" timeToPerform="P5D">
<Documentation>
timeToPerform = Periode 5 Tage ab Transaktionsstart
</Documentation>
<AuthorizedRole name="buyer"/>
<AuthorizedRole name="seller"/>
<BusinessTransactionActivity name="Bestellung"
businessTransaction="BestellungBT"
toAuthorizedRole="seller"
isLegallyBinding="true" />
<BusinessTransactionActivity name="Lieferungsanzeige"
businessTransaction="LieferanzeigeBT"
toAuthorizedRole="seller />
<Start toBusinessState="Bestellung" />
<Transition fromBusinessState="Bestellung"
toBusinessState="Lieferungsanzeige" />
<Success fromBusinessState="Lieferungsanzeige"
guardCondition="Success" />
<Failure fromBusinessState="Lieferungsanzeige"
guardCondition="BusinessFailure" />
</BinaryCollaboration>
Jörn Gersdorf
29
Wegen der Bedeutung des eCommerce versuchen viele verschiedene Unternehmen, ihre Interessen in Standards einfließen zu lassen und auch eigene Standards zu definieren. Es gibt also
noch einige andere Initiativen, die teilweise unabhängig von ebXML agieren (z. B. BizTalk),
sich teilweise aber auch schon mit der ebXML-Initiative assoziiert haben (z. B. UDDI).
5.1
BizTalk
BizTalk ist eine Initiative, die von Microsoft ausgegangen ist. Microsoft stellt damit ein
Konzept vor, das auf 3 Säulen ruht:
• Das BizTalk Framework
• Das BizTalk Repository
• Der BizTalk Server
Das BizTalk Repository ist dabei ist eine XML-Schema-Bibliothek, in der jedes Unternehmen die von ihm anwendungsspezifisch entwickelten XML-Sprachen registrieren kann. Das
Repository ist im Internet unter http://www.biztalk.org zu erreichen.
Der BizTalk Server ist ein Produkt, das eine zentrale Verwaltung und Konfiguration des Nachrichtenroutings und der Transformation unterschiedlicher XML-Schemata ineinander sowie in
ältere nicht-XML-Formate (insbesondere EDIFACT) ermöglicht. Der BizTalk Server ist dabei ein Microsoft-Produkt, das mit dem BizTalk-Framework konform geht; allerdings können
auch andere Firmen Server auf Basis dieser Spezifikation erstellen. Microsoft sieht die in
Abbildung ???? aufgezeigte Schichtung bei Verwendung eines BizTalk-Framework compliant
(BFC) Servers vor.
Die Anwendung übergibt dabei dem BFC-Server die Geschäftsdokumente und möglicherweise
vorhandene Anhänge. Der BFC-Server generiert hieraus eine BizTalk-Message und schickt
diese über beliebige Transportkanäle (z.B. HTTP, SMTP, Microsoft Message Queue) an den
BFC-Server des Geschäftspartners, welcher die Nachricht wieder, falls notwendig, in ein für
die Empfängerapplikation verständliches Format übersetzt und ausliefert.
Aus diesem Konzept wird klar ersichtlich, das Microsoft auf den Enterprise Application Integration (EAI) Markt zielt. Beliebige Anwendungen, egal ob sie von Hause aus XML-fähig
sind oder Legacy-Formate wie EDIFACT benutzen, können so miteinander kommunizieren.
Firmen wie SAP, Peoplesoft, Ariba etc. unterstützen die BizTalk-Initiative.
Das BizTalk-Transportprotokoll ist ein XML-basiertes Protokoll zur Nachrichtenübermittlung. In der aktuellen Version 2.0 von BizTalk basiert es auf SOAP (vgl. Kapitel 3.2) und
erweitert dieses um folgende Eigenschaften:
• Zuverlässige Nachrichtenübermittlung
• Unterstützung von Attachments mittels MIME
• Sicherheit basierend auf S/MIME
Jörn Gersdorf
30
Das Framework selbst besteht aus folgenden Elementen:
• Business Documents
• BizTalk Documents
• BizTalk Messages
Business Document. Das Business Document ist hierbei ein XML-Dokument das die Geschäftsdaten enthält. Dies können Bestellungen, Rechnungen, Verkaufsprognosen oder
beliebige andere Geschäftsdaten sein. Struktur und Inhalt des Business Document werden nicht vorgeschrieben. Dies ist Aufgabe der kommunizierenden Unternehmen, die
das festgelegte Schema dann in einem XML-Repository wie der BizTalk-Library veröffentlichen können. Ein oder mehrere Business Documents bilden den Body des BizTalk
Documents.
BizTalk Document. Das BizTalk Document ist eine SOAP 1.1 Nachricht, dessen Body ein
oder mehrere Business Documents enthält und in dessen Header Einträge zur Nachrichtenbehandlung eingetragen werden. Hierzu gehören Angaben zur Gültigkeitsdauer eines
Dokumentes, eine eindeutige Identifizierungsnummer, Empfangsbestätigungen und Signatur der Nachricht.
BizTalk Message. Eine BizTalk Message ist eine MIME-codierte Nachricht, die über das
gewählte Transportprotokoll ausgetauscht wird und daher noch zusätzliche transportspezische Informationen enthält (z.B. SMTP- oder HTTP-Header). Eine BizTalk Message muss als Hauptdokument ein BizTalk Document enthalten und kann zusätzlich
noch weitere BizTalk Documents oder andere Daten im Binärformat wie Grafiken als
Attachments enthalten.
Das Nachrichtenformat ist in Abbildung 10 zusammenfassend dargestellt.
Fazit
Damit wird klar ersichtlich, dass BizTalk ein zu ebXML konkurrierendes Framework darstellt. Der Nachrichtentransportmechanismus weist sehr viele Parallelen auf. Größter und
bemerkenswertester Unterschied zu ebXML ist, dass BizTalk nicht das Modell verfolgt, Geschäftsprozesse als die Grundlage von eBusiness im Framework als zentralen Punkt zu verankern.
5.2
UDDI
Die UDDI-Initiative (Universal Description, Discovery and Integration Project) von IBM, Ariba und Microsoft wurde im September 2000 gegründet. Ziel von UDDI ist es, eine Standardregistierungsstelle (Registry) zu schaffen, die die Integration von Systemen in Netzmarktplätze
ermöglicht. Dabei wird XML genutzt, um strukturierte Informationen über Systemschnittstellen von Unternehmen in der Registry abzulegen.
Jörn Gersdorf
6. Zusammenfassung
31
Biz T al k M essag e
Biz T al k Docu m en t
SOA P− EN V :En vel op e
SOA P− EN V :H ead er
...
SOA P− EN V :Bod y
Business Document
A ttach m en t
(Biz T al k Docu m en t,
Grafik , ...)
Abbildung 10: BizTalk Nachrichtenstruktur
Es gibt drei Informationstypen in UDDI, die als white, green und yellow pages bezeichnet werden. Das white pages-Verzeichnis beinhaltet Adress- und Kontaktinformationen, das yellow
pages-Verzeichnis Brancheninformationen und das green pages-Verzeichnis technische Informationen über Schnittstellen von Unternehmen (z. B. Spezifikationen von Web-Services).
UDDI selbst versteht sich als Integrationsklammer” verschiedener eBusiness-Initiativen. So
”
sollen sich Unternehmen, unabhängig davon, ob sie ebXML oder beispielsweise BizTalk nutzen, in UDDI-Directories registrieren lassen. Sucht ein Unternehmen nach geeigneten Geschäftspartnern, so soll dies zunächst über UDDI geschehen. Erst nachdem so potenzielle
Geschäftspartner gefunden wurden, sollen weitere Informationen bei anderen Registries (z.
B. ebXML-Registry) abgefragt werden.
Fazit
UDDI konkurriert nur im Bereich des Repositories mit ebXML. Die Initiative sieht sich selbst
jedoch als Ergänzung zu ebXML, in dem Sinne, dass sie ein allgemeineres Repository implementieren möchte, das nicht nur ebXML-konforme Unternehmen, sondern zum Beispiel auch
BizTalk-Unternehmen katalogisiert.
6
Zusammenfassung
In dieser Arbeit wurde ebXML vorgestellt, eine durch die Erfinder des UN/EDIFACT-Standards geführte Initiative mit dem Ziel der Schaffung eines Standards für elektronische Marktplätze und die elektronische Abwicklung von Geschäften im Internet.
Es wird deutlich, dass ebXML eines der komplexesten XML-Framework darstellt, die entwickelt werden. Wo sich andere Frameworks wie z. B. BizTalk nur mit kleinen Teilbereichen
Jörn Gersdorf
VERZEICHNIS DER CODEBEISPIELE
32
wie dem Transport von XML-Nachrichten befassen, hat ebXML den Anspruch, daneben auch
alle Aspekte von der Geschäftsprozessmodellierung über die Definition von Schnittstellen und
Geschäftsvereinbarungen (CPPs bzw. CPAs) bis hin zur Schaffung einer Registry zu spezifizieren.
Nicht nur die starke Beachtung und Unterstützung seitens der Industrie spricht dafür, dass
sich dieser Standard vermutlich durchsetzen wird. Auch die konsequente Ausrichtung auf eine
geschäftsprozessorientierte Sicht läßt vermuten, dass genügend Flexibilität und Möglichkeiten
im Standard stecken, ihn in einer Vielzahl unterschiedlicher Branchen einzusetzen. Die bereits
arbeitenden branchenspezifischen Teilgruppen (z. B. Finanzen oder Versicherungen) haben
schon jetzt zahlreiche Definitionen erarbeiten können.
Der Einsatz der Metasprache XML wird die Akzeptanz weiter steigern können und durch
die Implementations- und damit Kostenvorteile werden - im Gegensatz zu EDIFACT - auch
Unternehmen abseits der Großindustrie für den Einsatz von ebXML gewinnen können.
Diese Arbeit konnte nur einen relativ kleinen Ausschnitt aus den vorhandenen ebXML-Spezifikationen vorstellen. Wichtige Teilbereiche wie die Registry konnten nur kurz angesprochen werden. Bei weitergehendem Interesse sei hier auf die Homepage des ebXML-Projektes
(http://www.ebxml.org) verwiesen.
7
Anhang
Abbildungsverzeichnis
1
ebXML-Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2
Lebenszyklus einer eBusiness-Anwendung nach ebXML . . . . . . . . . . . . . .
7
3
Aufbau einer ebXML-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4
Beispiele für Geschäftstransaktionen . . . . . . . . . . . . . . . . . . . . . . . . 16
5
Struktur von ebXML-Geschäftsprozessen . . . . . . . . . . . . . . . . . . . . . . 17
6
Klassendiagramm für Geschäftsprozess . . . . . . . . . . . . . . . . . . . . . . . 20
7
Klassendiagramm für DocumentEnvelope . . . . . . . . . . . . . . . . . . . . . 22
8
Klassendiagramm für Binary Collaboration . . . . . . . . . . . . . . . . . . . . 25
9
Klassendiagramm für Choreography . . . . . . . . . . . . . . . . . . . . . . . . 27
10
BizTalk Nachrichtenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Verzeichnis der Codebeispiele
1
Beispiel: SOAP-Nachrichtenaustausch . . . . . . . . . . . . . . . . . . . . . . .
2
Beispiel: eine SOAP-Nachricht mit einem Anhang (einer Unterschrift) . . . . . 10
3
Beispiel eines ebXML-Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Jörn Gersdorf
9
LITERATUR
33
4
Beispiel eines Manifests im Body-Tag . . . . . . . . . . . . . . . . . . . . . . . . 15
5
6
ebXML-Geschäftsprozess Bestellung” . . . . . . . . . . . . . . . . . . . . . . . 19
”
Beispiel DocumentEnvelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7
ebXML Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8
ebXML Collaboration mit Choreography . . . . . . . . . . . . . . . . . . . . . . 28
Literatur
[ebXML-TA]
ebXML
Technical
Architecture
Specification
v1.0.4,
ebXML
Technical
Architecture
Project
Team,
16.
February
2001,
http://www.ebxml.org/specdrafts/ebXML TA v1.0.4.pdf.
[ebXML-MSS]
ebXML Message Service Specification v0.99 (ebXML Transport,
Routing
&
Packaging),
ebXML
Transport,
Routing
and
Packaging
Project
Team,
13.
March
2001,
http://www.ebxml.org/specdrafts/ebxml message service specification v0 99.pdf.
[ebXML-BP-SS] ebXML Business Process Specification Schema v1.0, ebXML Context/Metamodel Group of the CC/BP Joint Delivery Team, 27. April 2001,
http://www.ebxml.org/specdrafts/specificationschemav1.00.pdf
[SOAP]
Simple Object Access Protocol (SOAP) 1.1, World Wide Web Consortium,
8. May 2000, http://www.w3.org/TR/SOAP/.
[SOAPATTACH] SOAP Messages with Attachments, World Wide Web Consortium, 11.
December 2000, http://www.w3.org/TR/2000/NOTE-SOAP-attachments20001211.
[XLINK]
Jörn Gersdorf
XML Linking Candidate Recommendation, World Wide Web Consortium,
http://www.w3.org/TR/xlink.

Seminar WWW und Datenbanken - www-stud.informatik.uni

Transcrição

Documentos relacionados

Optimierung von Web-Auftritten durch die Analyse des - SAS-Wiki

GmbH-Musterformulierungen

PDF, 147 kB - Commerzbank

Knigge-Tipps rund um die Kommunikation Wussten Sie, dass

Wochenblatt, Oktober 2005 - Evangelische Kirche der Pfalz

Integrationskomplexität bei ERP-Systemen

Aktueller Kursflyer - Food

Ein Tag bei RTL aktuell

Ausgabe 11 - Dezember 2010 - Teil 2

Juni 2015

Jahresabschluss und lageberIchT 2009

Aufgaben

In-Memory-Scanning mit Virensignaturen und ein generischer