Seminar WWW und Datenbanken - www-stud.informatik.uni
Transcrição
Seminar WWW und Datenbanken - www-stud.informatik.uni
Seminar WWW und Datenbanken Jörn Gersdorf1 Sommersemester 2001 1 [email protected] INHALTSVERZEICHNIS 1 Inhaltsverzeichnis 1 Einführung 3 1.1 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Ziele von ebXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Überblick über ebXML 4 2.1 Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 ebXML-Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 ebXML Message Service 6 3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 SOAP-Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Grundsätzliche ebXML-Nachrichtenstruktur . . . . . . . . . . . . . . . . . . . . 8 3.4 ebXML-Erweiterungen zu SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Ausgewählte ebXML-Erweiterungen zu SOAP . . . . . . . . . . . . . . . . . . . 12 3.6 3.5.1 MessageHeader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.2 Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Verläßliche Nachrichtenübermittlung . . . . . . . . . . . . . . . . . . . . . . . . 15 4 ebXML Business Processes 15 4.1 Ü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 UML-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.5.1 UML-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Choreographien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.6.1 UML-Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.6.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Jörn Gersdorf Seminar WWW und Datenbanken INHALTSVERZEICHNIS 5 Verwandte Initiativen 2 26 5.1 BizTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6 Zusammenfassung 31 7 Anhang 32 Jörn Gersdorf Seminar WWW und Datenbanken 1. Einführung 1 3 Einführung Seit Bestehen der elektronischen Datenverarbeitung versuchen Unternehmen, diese unter anderem zum Zwecke der Effizienzsteigerung und Kostenreduktion einzusetzen. Geschäftsprozesse sollen durch den Einsatz von Datenverarbeitung unterstützt werden, um sie schneller, transparenter und flexibler zu machen. Mit dem Aufkommen von Technologien, die häufig unter den Oberbegriffen Internet- und eCommercetechnologien zusammengefaßt werden, ergeben sich neue Herausforderungen, aber auch neue Mö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 vorlä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 widersprüchliche Aussagen bezüglich des Elements DocumentEnvelope” zu finden sind1 . ” 1.1 Historie Seit mehr als fünfundzwanzig Jahren praktizieren Unternehmen und Behörden bereits den elektronischen Austausch von Daten (Electronic Data Interchange, abgekürzt EDI ). Darunter wird der papierlose Austausch strukturierter Geschäftsdaten wie zum Beispiel Angebotsanfragen, Angebote, Rechnungen etc. verstanden. Ein wesentliches Merkmal dieses Austauschs ist die Möglichkeit der automatischen Weiterverarbeitung der Nachrichten in der empfangenden Anwendung. Trotz der Vorteile, die ein papierloser Austausch von Geschäftsdaten mit sich bringt (Rationalisierung von Kommunikationsvorgängen, Optimierung von Geschäftsprozessen) hat sich EDI nicht in der Breite durchsetzen kö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 unveränderte Geschäftsprozesse sowie die geringen Freiheitsgrade in den Formatspezifikationen für die Realisierung spezifischer EDI-Nachrichten. Durch die Verbreitung des Internets existieren zudem neue Möglichkeiten, die im klassischen EDI nicht vorgesehen waren. Dazu gehören beispielsweise die elektronische Suche von Geschäftspartnern in sogenannten Repositories oder die elektronische Einigung auf bestimmte Geschäftsprozessvorgänge. XML bietet in diesem Zusammenhang die Mö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 kostengünstige Implementierung von XML-basierten EDI-Standards, wodurch diese Technologie auch für kleine und mittlere Unternehmen interessanter wird. 1 teilweise findet sich ”BusinessDocument” als Attribut zu ”DocumentEnvelope”, teilweise als Kindelement. Jörn Gersdorf Seminar WWW und Datenbanken 2. Überblick über ebXML 1.2 4 Ziele von ebXML Electronic business XML ( ebXML) ist ein Ende 1999 gegrü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 für die elektronische Abwicklung von Geschäften bereitszustellen. Seit dem 14. Mai 2001 sind die ebXML-Spezifikationen nun verabschiedet. ebXML wird dabei unterstü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 Geschäftsdokumente in eine XMLDTD zu übersetzen”, sondern ein Rahmenwerk für die Schaffung konsistenter, robuster und ” integrationsfähiger (weil offener) eBusiness-Anwendungen zu definieren, um letztendlich dadurch einen einzigen globalen eBusiness-Markt zu schaffen. Dabei ist die Sichtweise nicht dokumenten- sondern geschäftsprozessorientiert. 2 Überblick über ebXML ebXML geht weit darüber hinaus, nur ein Format für den Austausch von Geschäftsnachrichten zu definieren. ebXML stellt die folgenden Konzepte bereit: • Einen Standardmechanismus, mit dem Geschäftsprozesse und das damit verbundene Informationsmodell beschrieben werden können. • Einen Mechanismus, mit dem Geschäftsprozesse in einer Registry hinterlegt und durch andere Nutzer wiederverwendet werden können. • Die Möglichkeit, Informationen über Teilnehmer an ebXML aus einer Registry abzurufen und in dieser abzulegen. Diese Informationen können sein – unterstützte Geschäftsprozesse – Daten über Schnittstellen, über die die Geschäftsprozesse abgewickelt werden – Geschäftsnachrichtstypen, über die Geschäftsprozesse abgewickelt werden – technische Konfigurationsdaten über Transportprotokolle und Sicherheitsparameter. • Ein Mechanismus, mit dem eine Vereinbarung über eine Geschäftsbeziehung beschrieben werden kann und die aus den Daten, die über Teilnehmer in der Registry gespeichert wurden, abgeleitet werden kann (Collaboration Protocol Agreements, CPA). • Ein Messaging Service, der den Nachrichtenaustausch sicher und zuverlässig ermöglicht. • Ein Mechanismus, den Messaging Service entsprechend der Vereinbarungen des CPA’s zu konfigurieren. Jörn Gersdorf Seminar WWW und Datenbanken 2. Überblick ü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 erlä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 Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 6 1. Unternehmen A erfährt von einer ebXML-Registry. Es schaut die dort vorhandenen Daten an und entscheidet sich dafü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 fü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 können, erstellt Unternehmen A ein sogenanntes Business Profile über sich selbst, das Informationen über die ebXMLSchnittstellen der eigenen Systeme sowie die von A unterstützten Geschäftsszenarien (das sind in XML kodierte Geschäftsprozesse) enthält. Dieses Business Profile wird in der ebXML-Registry abgelegt. 4. Unternehmen B sucht einen geeigneten Geschäftspartner. Es fragt daher bei einer ebXML-Registry nach Unternehmen an, die die gesuchten Geschäftsprozesse unterstü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 Geschäftsbeziehung gemäß des Business Profiles von Unternehmen A interessiert ist. Bevor der eigentliche Austausch von Geschäftsnachrichten erfolgt, sendet Unternehmen B einen Vorschlag für eine Geschäftsvereinbarung direkt an die ebXML-Schnittstelle von Unternehmen A. Dieses enthält eine Vereinbarung über die zu nutzenden Geschäftsszenarien sowie über technische Parameter wie zum Beispiel zu nutzende Kommunikationskanäle, Adressen, Verschlüsselungs- und Signatureinstellungen etc. Nach einer eventuellen Verhandlungsphase akzeptiert Unternehmen A die Vereinbarung. 6. Der eigentliche Austausch von ebXML-Geschäftsnachrichten kann beginnen. 2.2 ebXML-Lebenszyklus Abbildung 2 zeigt einen Überblick ü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 Überblick Der ebXML-Message-Service definiert, wie Nachrichten verpackt”werden müssen, um ebXML” konform versandt werden zu kö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 Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 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. Tatsächlich können über den Messaging-Service auch nicht-XML-Daten versandt werden. Der Standard wurde mit Blick auf Erweiterbarkeit (gegeben durch die Nutzung von XML), Möglichkeit der Persistenz von Nachrichten, Sicherheitsaspekte und Zuverlässig der Nachrichtenü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 unterstützen soll. 3.2 SOAP-Überblick Da der ebXML-Messaging Service auf SOAP basiert, gebe ich im folgenden Abschnitt einen kurzen Überblick ü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 Empfänger optional oder obligatorisch ist. 2 SOAP (Simple Object Access Protokoll), [SOAP], sowie SOAP with Attachments, [SOAPATTACH] Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 8 • Die SOAP encoding rules definieren einen Serialisierungsmechanismus für Datentypen wie int”, float”, Arrays etc. ” ” • Die SOAP-RPC-Darstellung definiert eine Konvention, durch die ein RPC-Mechanismus3 reprä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 zusätzliche Eigenschaften zum SOAPProtokoll hinzugefügt werden können. Typischerweise können hier Eingenschaften wie Authentifizierung oder Transaktionsbehandlung definiert werden. • Der Body ist der Container, der die eigentliche Nachricht enthält. Der Inhalt des Bodys wird vom SOAP-Server an die empfangende Anwendung ü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 Binärdaten wie Grafiken über ein XML-konformes Protokoll wie SOAP zu versenden. Auch der ebXML-Messaging-Service macht keinerlei Angaben, wie die Geschäftsnachrichten selbst (der payload, siehe Kapitel 3.1) kodiert sein müssen. Deshalb setzt er auch auf SOAP with Attachments auf. SOAP with Attachments benutzt zur Bü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 kö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 enthält. 3.3 Grundsätzliche ebXML-Nachrichtenstruktur Eine ebXML-Nachricht besteht aus einem oder mehreren MIME-Containern, wobei gilt: 3 remote procedure call = entfernter Prozeduraufruf, vgl. DCE. Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 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> Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 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-- Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 11 • Es existiert genau ein sogenannter Header Container, der eine SOAP-Nachricht enthält. In dieser SOAP-Nachricht werden auch alle Konfigurationen für ebXML vorgenommen. • Es kann daneben einen oder mehrere sogenannte Payload Container geben, die applikationsabhängigige Geschäftsnachrichten oder -informationen enthalten. Diese mü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 hinzugefügt; im Body werden Kontrollinformationen sowie Informationen (Referenzen) zu den in den PayloadContainern enthaltenen Geschäftsnachrichten gegeben. Die Struktur prä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 Möglichkeiten offeriert: • Eindeutige Indentifikation der Nachricht • Absender- und Empfängerangaben • Angabe von Routing-Informationen, d.h. des nächsten ebXML-Message Service Handlers • Signatur der Nachricht zur eindeutigen Identifikation des Absenders und zur Sicherstellung der Unversehrtheit der Nachricht Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 12 • Empfangsbestätigung • Fehlerbenachrichtigung 3.4 ebXML-Erweiterungen zu SOAP ebXML erweitert SOAP-Nachrichten um einige Elemente (die ihrerseits auch wieder Unterelemente enthalten können), die insbesondere Zuverlässigkeits- und Sicherheitsaspekte definieren; sie sind fü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, Empfänger) und Kontextinformationen über die Nachricht. Beinhaltet Elemente, die Zwischenstationen von Nachrich” ” ten auf ihrem Weg vom Absender zum Empfä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 nächsten ebXML Message Service Handler zu senden, der diese Nachricht erhä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 Eingangsbestä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 Ausgewä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: Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service Element From / To CPAId ConversationId SequenceNumber Service Action MessageData QualityOfService 13 Inhalt Beinhalten Absender und Empfänger der Nachricht Beinhaltet eine Referenz auf ein Collaboration Protocol Agreement. Ist in der Regel eine URI. Identifiziert einen Satz von zusammengehörigen Nachrichten innerhalb einer Nachrichtensitzung. Gibt die Nachrichtennummer innerhalb einer ConversationId an. Wichtig für die Nachrichtenreihenfolge. Dabei ist die SequenceNumber ein Integer, gezä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 Dienstgüte definiert werden. Dabei kann man festlegen, ob man eine (signierte oder unsignierte) Empfangsbestätigung erhalten möchte, ob die Nachrichtenreihenfolge eingehalten und ob eine Nachricht zuverlässig versandt werden muss. Ein Beispiel dü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 Empfangsbestätigung verlangt. Die Nach” richt muss genau einmal beim Empfä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 Empfä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 übergibt Informationen an die nächste Zwischenstation der Nachricht auf ihrem Weg zum Empfänger. Im Beispiel gibt sie dem nächsten Empfänger den Auftrag, den Empfang der Nachricht zu loggen. 3.5.2 Body Das Body-Element besteht - wie in Tabelle 2 erlä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 repräsentiert (siehe [XLINK]). Daneben kann Jörn Gersdorf Seminar WWW und Datenbanken 3. ebXML Message Service 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" SOAP-ENV:mustUnderstand="1"> <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> Jörn Gersdorf Seminar WWW und Datenbanken 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 Geschäftsnachricht, die im MIME-Container mit der Id payload-1” steht. Diese Geschäfts” nachricht genügt dem referenzierten Schema. Codebeispiel 4 Beispiel eines Manifests im Body-Tag <eb:Manifest id="Manifest" eb:version="0.98" SOAP-ENV:mustUnderstand="1"> <eb:Reference id="payload1" xlink:role="http://abc.com/business/bestellungen" xlink:href="cid:payload-1"> <eb:Description>Bestellung über 20 Lollies</eb:Description> <eb:Schema location="http://abc.com/schemas/bestell/po.xsd" version="1.0"/> </eb:Reference> </eb:Manifest> 3.6 Verläßliche Nachrichtenübermittlung Im Rahmen des Reliable Messaging” wird ein Protokoll definiert, das festlegt, wie zwei Mes” sage Service Handler (MSH) verläßlich Nachrichten miteinander austauschen können. Dabei muss ein MSH, der dieses Protokoll unterstützt, einen Mechanismus für die persistente Speicherung von Nachrichten zur Verfügung stellen, um bei einem Systemausfall bereits empfangene Nachrichten weiterverarbeiten zu kö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 verläßliche Nachrichtenübermittlung). Daneben können die in Tabelle 3 aufgeführten Parameter festgelegt werden. 4 4.1 ebXML Business Processes Überblick ebXML basiert auf einer geschäftsprozessorientierten Sichtweise. Dabei beschreibt ein Geschäftsprozess detailliert, wie und wann ein Geschäftsteilnehmer bestimmte Rollen einnimmt, welche Verbindungen es zu anderen Geschäftsteilnehmern gibt und welche Verantwortlichkeiten in diesem Zusammenhang auf den einzelnen Geschäftsteilnehmern lasten. Beispiele für eine Zusammenarbeit auf Basis von Geschäftsprozessen sind in Abbildung 4 gezeigt. Dabei geht es darum, den Interaktionsfluß zwischen Geschäftsteilnehmern zu beschreiben, also etwa zu sagen, welche Schritte durchgeführt werden müssen, um eine Bestellung komplett durchzuführen. Es geht bei der Spezifikation von Geschäftsprozessen nicht darum, zu Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes Parameter TimeToLive reliableMessagingMethod AckRequested Timeout Retries RetryInterval PersistDuration 16 Bedeutung Angabe, wann eine Nachricht ungü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) Empfangsbestätigung anfordern. Kann entweder signiert oder unsigniert sein. Spezifiziert die Dauer, die ein MSH auf eine Empfangsbestätigung warten muss, bevor er erneut eine Nachricht sendet. maximale Wiederholungsanzahl Intervall, in dem Wiederholungen erfolgen sollen (ausgedrü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 für Geschäftstransaktionen Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 17 beschreiben, wie die Dokumente (z. B. Bestelldaten) auszusehen haben, die zwischen den Geschäftsteilnehmern ausgetauscht werden, sondern darum, zu beschreiben, wie die Interaktion zwischen Geschäftsteilnehmern im Rahmen eines ebXML-Geschäftsprozesses aussieht (z. B. Bestellung). Dabei werden im Rahmen der Interaktion Geschäftsdokumente ausgetauscht. Diese Geschäftsdokumente können zusammengesetzt sein aus Komponenten der ebXML Core Library, die die Core Components enthält. Fertig beschriebene Geschäftsprozesse werden im ebXML-Repository zur Einsichtnahme potenzieller Geschäftspartner abgelegt. Wichtig ist zu wissen, dass die Geschä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 Geschäftsprozessen in ebXML findet sich in der Spezifikation [ebXML-BP-SS]. 4.2 Struktur Die Struktur von Geschäftstransaktionen in der ebXML-Welt wird in Abbildung 5 dargestellt. Dort ist ersichtlich, dass Geschäftstransaktionen mit einem Dokumentenfluss assoziiert sind. Geschäftstransaktionen ihrerseits werden wieder durch eine Choreographie in ihrer Abfolge gesteuert. Die Choreographie wird durch eine sogenannte Collaboration zusammengefaßt und von den Geschä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-Geschäftsprozessen Im Einzelnen sieht es folgendermaßen aus: Zwei oder mehr Geschäftspartner nehmen über Rollen an einer Collaboration teil. Rollen können zum Beispiel Käufer” oder Verkäufer” ” ” Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 18 sein und drücken aus, welche Position ein Geschäftspartner innerhalb einer Collaboration einnimmt. Die Rollen tauschen im Rahmen von Geschäftstransaktionen Informationen aus. Dabei besteht jede Geschäftstransaktionen aus einem oder zwei vordefinierten Dokumentenflüssen. Die Reihenfolge, in der Geschäftstransaktionen abzuarbeiten sind, wird durch Choreographien definiert. Die einzelnen Begriffe werden im folgendenden nochmals näher beleuchtet: 1. Business Collaboration Eine Collaboration ist eine Menge von Geschäftstransaktionen und bildet dadurch einen unternehmensübergreifenden Geschäftsprozess ab. Jeder Geschäftspartner nimmt mindestens eine Rolle in einer Collaboration ein. Es gibt zwei Arten von Collaborations: • Binary Collaborations: es nehmen zwei Geschäftspartner teil. • Multiparty Collaborations: es nehmen mehr als zwei Geschäftspartner teil. Multiparty Collaborations werden aus Binary Collaborations zusammengesetzt”. ” Binary Collaborations werden aus einer Menge von Geschäftsaktivitäten zusammengesetzt. Eine Geschäftsaktivität kann dabei entweder ein Geschäftsprozess sein (in diesem Sinne ist die Aktivität atomar) oder eine andere Binary Collaboration. Mit dieser Definition wird Wiederverwendung von Collaborations erst möglich. Beispiel: Ein Beispiel für eine Collaboration wäre ein Bestellvorgang. 2. Geschäftstransaktion Eine Geschäftstransaktion ist atomar (in dem Sinne, dass sie nicht mehr in Unter” Geschäftstransaktionen unterteilt werden kann) und wird zwischen zwei Partnern im ” gegensätzlichen Rollen ausgeführt (z. B. Käufer und Verkäufer). Im Allgemeinen sind diese Rollen als anfordernde und antwortende Rolle zu charakterisieren. Ein weiteres Merkmal von Geschäftstransaktionen ist, dass sie auch im Datenbank” sinne” atomar sind, d. h. sie können nur als Ganzes entweder erfolgreich sein oder fehlschlagen. Beispiel: Ist die Collaboration eine Bestellung, so könnten zugehörige Geschä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 Geschä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 über ebXML Core Components definiert. Es ist allerdings auch möglich, die Dokumente anders (auch als nicht-XML-Dokumente) zu definieren. 4. Choreographie Die Choreographie defniert die Reihenfolge von Geschäftstransaktionen innerhalb einer Binary Collaboration. In der UML-Ansicht von ebXML-Business-Processes würde man die Choreographie als Aktivitätsdiagramm (welches einen endlichen Zustandsautomaten modelliert) darstellen. Im Rahmen der Choreographie ist es nicht nur möglich, eine reine sequentielle Reihenfolge festzulegen, sondern über sogenannte Guards (Wächter) können auch bedingte Zustandsübergänge definiert werden. Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 4.3 19 Business Transactions Wir betrachten zunächst Geschäftstransactionen und ihre Modellierung in ebXML. Eine Geschäftstransaktion hat folgende Eigenschaften in ebXML: Atomar. Eine Geschäftstransaktion ist atomar. Er kann nicht in zwei Untergeschäftsprozesse unterteilt werden. Bestandteile. Eine Geschäftstransaktion besteht aus einer anfragenden Geschäftsaktivität, gegebenenfalls einer antwortenden Aktivität sowie einem oder zwei Dokumentflüssen. 4.3.1 UML-Modellierung In Abbildung 6 ist die UML-Darstellung wiedergegeben. 4.3.2 Beispiel Wir betrachten nun ein Beispiel einer Geschäftstransaktion. Wir nehmen den einfachen Fall einer Bestellung. In Codebeispiel 5 ist die Geschäftstransaktion in ebXML modelliert. Codebeispiel 5 ebXML-Geschä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"> <DocumentEnvelope isPositiveResponse="true" BusinessDocument="Bestellung Bestätigung"/> </RespondingBusinessActivity> </BusinessTransaction> In diesem Beispiel wird die Geschäftstransaktion mit dem Namen BestellungBT” (BT soll ” für BusinessTransaction stehen) modelliert. Sie besteht aus einer anfragenden und einer antwortenden Aktivität. Die Anfrage entspricht einer Bestellung, die Antwort einer Annahmebestätigung der Bestellung. Das Attribut isNonRepudiationRequired” in beiden Aktivitäten besagt, dass der Empfänger ” vor Versenden einer Empfangsbestätigung prüfen muss, ob die empfangene Nachricht syntaktisch korrekt und semantisch verständlich ist. Die Angaben P2D” oder P3D” bedeuten Pe” ” ” riod 2 Days” bzw. Period 3 Days”. Diese Angaben entsprechen einem W3C/ISO-Standard. ” Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 20 Abbildung 6: Klassendiagramm für Geschäftsprozess Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 21 Innerhalb der beiden Geschäftsaktivitäten werden die Dokumentflüsse (hier relativ einfache) definiert. Im Request-Fall wird ein Geschäftsdokument Bestellung” gesandt. Das Attribut ” isPositiveResponse” besagt, dass es sich hierbei um einen Schritt innerhalb der Transaktion ” handelt. 4.4 Document Flows Dokumentflüsse repräsentieren die Dokumente, die zwischen Anfrager (Requester) und Antworter (Responder) effektiv versandt werden. Dabei werden die Dokumente im Rahmen der Geschäftsprozessmodellierung selbst nicht definiert; vielmehr definiert man Umschläge” (Do” cumentEnvelopes), die auf tatsächliche Dokumentspezifikationen verweisen. Es gibt immer genau einen DocumentEnvelope für eine RequestingActivity. Für eine RespondingActivity kann es null, eine oder mehrere disjunkte DocumentEnvelopes geben. Disjunkt meint hier, dass für je einen Zustand nur genau ein DocumentEnvelope gültig ist (z. B. BestellAnnahme und BestellZurü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 Geschäftsdokumente im Element DocumentSpecification” erweitert. ” Die DocumentSpecification gibt an, wo die Spezifikationen für die Geschäftsdokumente zu finden sind (location). Innerhalb der DocumentEnvelope-Elemente wird über das Attribut BusinessDocument” auf ” die Definition des zu verwendenden Geschäftsdokument zurü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 Bestellbestätigung versandt, im anderen Fall eine Ablehnung. In diesem Attribut sind beliebige boolsche Ausdrücke erlaubt. Auch ein XPath-Ausdruck, der bestimmte Werte im BusinessDocument selbst abfragt, ist erlaubt. 4.5 Collaborations Wir betrachten nur binäre Collaborations, also solche zwischen zwei Geschäftspartnern. Die Semantik von Multiparty Collaborations findet sich natürlich in [ebXML-BP-SS]. Eine binary Collaboration wird immer von genau zwei Rollen genutzt, die Authorized Roles genannt werden, da sie Teilnehmer repräsentieren, die authorisiert sind, eine bestimmte binary Collaboration zu nutzen. Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 22 Abbildung 7: Klassendiagramm für DocumentEnvelope Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 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=""> <DocumentEnvelope isPositiveResponse="true" BusinessDocument ="meineSpezi/Bestellung "/> <Attachment name="Lieferinstruktionen" mimeType="text/xml" BusinessDocument ="meineSpezi/Lieferinstruktionen " spec=""/> </RequestingBusinessActivity> <RespondingBusinessActivity> <DocumentEnvelope isPositiveResponse="true" BusinessDocument ="meineSpezi/Bestellung ok "/> <DocumentEnvelope isPositiveResponse="false" BusinessDocument ="meineSpezi/Bestellung Ablehnen "/> </RespondingBusinessActivity> </BusinessTransaction> Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 24 Eine binary Collaboration besteht aus einer oder mehreren Business Activities. Business Activities sind hierbei entweder Business Transaction Activities oder Collaboration Activities (ob binä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 können also Geschä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 Geschäftsbeziehung einigen sich die Geschäftspartner auf die Verwendung bestimmter Collaborations. Diese sind im CPA festgehalten. Es werden also nicht die Business Transactions referenziert, sondern die auf hö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 ü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" fromAuthorizedRole="buyer" toAuthorizedRole="seller /> </BinaryCollaboration> Zunächst werden die authorisierten Rollen definiert. Diese werden in den BusinessTransactionActivities verwendet, um festzulegen, wer eine bestimmte Transaktion anstoßen darf. Jörn Gersdorf Seminar WWW und Datenbanken 4. ebXML Business Processes 25 Abbildung 8: Klassendiagramm für Binary Collaboration Jörn Gersdorf Seminar WWW und Datenbanken 5. Verwandte Initiativen 26 Danach werden die Transaktionen definiert, die in der Collaboration Gesamtbestellung” ge” nutzt werden dü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 Geschäftsprozesses. Sie gibt die ” Reihenfolge und die bedingte Ausführung von Business Activities (also Business Transactions bzw. Collaborations) innerhalb einer binary Collaboration an. Diese Choreographie kann man sich als vorstellen als ein UML Aktivitä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 Zustände verzweigt), Join (hier werden mehrere Zustände auf einen einzigen vereinigt). Daneben kö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” gehört, zur gleichen Zeit als Teil der glei” chen Business Transaction Activity offen sein dü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 Zusammenfügen der Business Transactions zu einer Collaboration, in der die Übergä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 ausgeführt wird, wenn diese Condition zutrifft. Im Falle der GuardCondition gibt es die vier zulässigen Werte Sucess”, BusinessFailure”, ” ” TechnicalFailure” und AnyFailure”, die sich allesamt auf den Status der zuvor ausgeführten ” ” Business Transaction beziehen. Alternativ könnte man auch eine GuardExpression nutzen; dies darf jede zulässige Expression sein, die zu einem boolschen Wert evaluiert werden kann. Dabei darf per XPath-Ausdrücken auch auf umgebende Dokumentinhalte (des DocumentEnvelopes) bezug genommen werden. 5 Verwandte Initiativen Jörn Gersdorf Seminar WWW und Datenbanken 5. Verwandte Initiativen 27 Abbildung 9: Klassendiagramm für Choreography Jörn Gersdorf Seminar WWW und Datenbanken 5. Verwandte Initiativen 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" fromAuthorizedRole="buyer" toAuthorizedRole="seller" isLegallyBinding="true" /> <BusinessTransactionActivity name="Lieferungsanzeige" businessTransaction="LieferanzeigeBT" fromAuthorizedRole="buyer" toAuthorizedRole="seller /> <Start toBusinessState="Bestellung" /> <Transition fromBusinessState="Bestellung" toBusinessState="Lieferungsanzeige" /> <Success fromBusinessState="Lieferungsanzeige" guardCondition="Success" /> <Failure fromBusinessState="Lieferungsanzeige" guardCondition="BusinessFailure" /> </BinaryCollaboration> Jörn Gersdorf Seminar WWW und Datenbanken 5. Verwandte Initiativen 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 unabhä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 Sä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 ältere nicht-XML-Formate (insbesondere EDIFACT) ermöglicht. Der BizTalk Server ist dabei ein Microsoft-Produkt, das mit dem BizTalk-Framework konform geht; allerdings kö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 übergibt dabei dem BFC-Server die Geschäftsdokumente und möglicherweise vorhandene Anhänge. Der BFC-Server generiert hieraus eine BizTalk-Message und schickt diese über beliebige Transportkanäle (z.B. HTTP, SMTP, Microsoft Message Queue) an den BFC-Server des Geschäftspartners, welcher die Nachricht wieder, falls notwendig, in ein für die Empfängerapplikation verständliches Format ü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-fähig sind oder Legacy-Formate wie EDIFACT benutzen, können so miteinander kommunizieren. Firmen wie SAP, Peoplesoft, Ariba etc. unterstützen die BizTalk-Initiative. Das BizTalk-Transportprotokoll ist ein XML-basiertes Protokoll zur Nachrichtenübermittlung. In der aktuellen Version 2.0 von BizTalk basiert es auf SOAP (vgl. Kapitel 3.2) und erweitert dieses um folgende Eigenschaften: • Zuverlässige Nachrichtenübermittlung • Unterstützung von Attachments mittels MIME • Sicherheit basierend auf S/MIME Jörn Gersdorf Seminar WWW und Datenbanken 5. Verwandte Initiativen 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 Geschäftsdaten enthält. Dies können Bestellungen, Rechnungen, Verkaufsprognosen oder beliebige andere Geschä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 veröffentlichen kö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 enthält und in dessen Header Einträge zur Nachrichtenbehandlung eingetragen werden. Hierzu gehören Angaben zur Gültigkeitsdauer eines Dokumentes, eine eindeutige Identifizierungsnummer, Empfangsbestätigungen und Signatur der Nachricht. BizTalk Message. Eine BizTalk Message ist eine MIME-codierte Nachricht, die über das gewählte Transportprotokoll ausgetauscht wird und daher noch zusätzliche transportspezische Informationen enthält (z.B. SMTP- oder HTTP-Header). Eine BizTalk Message muss als Hauptdokument ein BizTalk Document enthalten und kann zusätzlich noch weitere BizTalk Documents oder andere Daten im Binä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. Größter und bemerkenswertester Unterschied zu ebXML ist, dass BizTalk nicht das Modell verfolgt, Geschä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 gegründet. Ziel von UDDI ist es, eine Standardregistierungsstelle (Registry) zu schaffen, die die Integration von Systemen in Netzmarktplätze ermöglicht. Dabei wird XML genutzt, um strukturierte Informationen über Systemschnittstellen von Unternehmen in der Registry abzulegen. Jörn Gersdorf Seminar WWW und Datenbanken 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 über Schnittstellen von Unternehmen (z. B. Spezifikationen von Web-Services). UDDI selbst versteht sich als Integrationsklammer” verschiedener eBusiness-Initiativen. So ” sollen sich Unternehmen, unabhängig davon, ob sie ebXML oder beispielsweise BizTalk nutzen, in UDDI-Directories registrieren lassen. Sucht ein Unternehmen nach geeigneten Geschäftspartnern, so soll dies zunächst über UDDI geschehen. Erst nachdem so potenzielle Geschä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 Ergänzung zu ebXML, in dem Sinne, dass sie ein allgemeineres Repository implementieren mö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 geführte Initiative mit dem Ziel der Schaffung eines Standards für elektronische Marktplätze und die elektronische Abwicklung von Geschä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 Jörn Gersdorf Seminar WWW und Datenbanken VERZEICHNIS DER CODEBEISPIELE 32 wie dem Transport von XML-Nachrichten befassen, hat ebXML den Anspruch, daneben auch alle Aspekte von der Geschäftsprozessmodellierung über die Definition von Schnittstellen und Geschäftsvereinbarungen (CPPs bzw. CPAs) bis hin zur Schaffung einer Registry zu spezifizieren. Nicht nur die starke Beachtung und Unterstützung seitens der Industrie spricht dafür, dass sich dieser Standard vermutlich durchsetzen wird. Auch die konsequente Ausrichtung auf eine geschäftsprozessorientierte Sicht läßt vermuten, dass genügend Flexibilität und Mö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 können. Der Einsatz der Metasprache XML wird die Akzeptanz weiter steigern können und durch die Implementations- und damit Kostenvorteile werden - im Gegensatz zu EDIFACT - auch Unternehmen abseits der Großindustrie für den Einsatz von ebXML gewinnen kö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 für Geschäftstransaktionen . . . . . . . . . . . . . . . . . . . . . . . . 16 5 Struktur von ebXML-Geschäftsprozessen . . . . . . . . . . . . . . . . . . . . . . 17 6 Klassendiagramm für Geschäftsprozess . . . . . . . . . . . . . . . . . . . . . . . 20 7 Klassendiagramm für DocumentEnvelope . . . . . . . . . . . . . . . . . . . . . 22 8 Klassendiagramm für Binary Collaboration . . . . . . . . . . . . . . . . . . . . 25 9 Klassendiagramm fü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 Jörn Gersdorf 9 Seminar WWW und Datenbanken LITERATUR 33 4 Beispiel eines Manifests im Body-Tag . . . . . . . . . . . . . . . . . . . . . . . . 15 5 6 ebXML-Geschä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] Jörn Gersdorf XML Linking Candidate Recommendation, World Wide Web Consortium, http://www.w3.org/TR/xlink. Seminar WWW und Datenbanken