ebXML. Kritische Darstellung eines Standards zur Unterstützung von e-Business-Prozessen


Diplomarbeit, 2002

272 Seiten, Note: 1


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Die ebXML Initiative
1.2 Zielsetzung und Aufbau der Arbeit
1.3 Formale und rechtliche Anmerkungen

2 EbXML Systemübersicht und Grundlagen
2.1 EbXML Anwendungsbeispiel
2.2 EbXML Komponenten
2.2.1 Business Process Specification Schema (BPSS)
2.2.2 Registry/Repository
2.2.3 Collaboration-Protocol Profile (CPP) und Agreement (CPA)
2.2.4 Core Components
2.2.5 Messaging Services
2.3 Ansichten der ebXML Architektur
2.3.1 Business Operational View (BOV)
2.3.2 Functional Service View (FSV)
2.4 Funktionale Phasen eines ebXML Szenarios
2.5 Kurze Zusammenfassung und Folgerungen
2.6 Grundlagen: Die Unified Modelling Methodology
2.6.1 Klassifizierung der Modellierungsaktivitäten in UMM
2.6.1.1 UMM Workflows
2.6.1.2 UMM Phasen
2.6.1.3 UMM Iterationen
2.6.2 Workflows und Worksheets in UMM und ebXML
2.6.2.1 Business Modelling Workflow
2.6.2.2 Requirements Workflow
2.6.2.3 Analysis Workflow
2.6.2.4 Design Workflow
2.6.3 Das UMM Metamodell
2.6.4 UMM Patterns

3 Geschäftsprozess-Modellierung in ebXML
3.1 Die Grundidee
3.2 Geschäftsprozesse
3.3 Das ebXML Business Process Specification Schema
3.3.1 BPSS Systemüberblick
3.3.2 Business Transactions
3.3.2.1 Business Signals
3.3.2.2 Dokumente einer Business Transaction
3.3.2.3 Grundlegende Semantik von Business Transactions
3.3.2.3.1 Erstellung rechtsverbindlicher Verträge
3.3.2.3.2 Non-Repudiation
3.3.2.3.3 Authorization Security
3.3.2.3.4 Document Security
3.3.2.3.5 Reliability
3.3.2.4 Semantik von Business Transactions zur Laufzeit
3.3.2.4.1 Time-outs
3.3.2.4.2 Exceptions
3.3.3 Binary Collaborations
3.3.4 Multiparty Collaborations
3.3.5 Choreography
3.3.6 Das Gesamtmodell in UML
3.3.7 Umsetzung der UML Version in XML
3.3.7.1 Production Rules
3.3.7.2 Packages und weitere zusätzliche Elemente der XML Version
3.3.7.2.1 ProcessSpecification
3.3.7.2.2 SubstitutionSet
3.3.7.2.3 Include
3.3.7.3 Namensvergabe und Referenzierung in ebXML
3.3.8 XML Version des ebXML BPSS
3.4 Das Business Service Interface (BSI)
3.5 Folgerungen des ebXML BPSS

4 EbXML Registry und Repository
4.1 Das Registry Information Model (RIM)
4.1.1 RIM Übersicht: High Level Public View
4.1.2 RIM Detailansicht
4.1.2.1 Interfaces RegistryObject und Versionable
4.1.2.2 Interface RegistryEntry und seine Unterklassen
4.1.2.3 Interface Association
4.1.2.4 Klassifizierung eines RegistryEntry
4.1.2.5 Abbildung von Prüfungsketten
4.1.2.6 RIM Sicherheitsaspekte
4.2 EbXML Registry Services
4.2.1 Systemübersicht des ebXML Registry
4.2.1.1 Architektur des Registry
4.2.1.2 Profile und Verträge im ebXML Registry
4.2.1.3 Interface Services
4.2.2 Der ObjectManagement Service
4.2.3 Der ObjectQueryManagement Service
4.2.3.1 Browse and Drill Down Query
4.2.3.2 Filtered Query
4.2.3.3 SQL Query
4.2.3.4 Content Retrieval
4.2.4 Sicherheit des Registry
4.3 Folgerungen des ebXML Registry/Repository

5 Weitere Inhalte des ebXML Registry
5.1 Collaboration-Protocol Profile and Agreement
5.1.1 Überblick über CPP und CPA
5.1.2 Struktur eines CPP
5.1.2.1 Element CollaborationProtocolProfile
5.1.2.2 Element PartyInfo
5.1.2.3 Element CollaborationRole
5.1.2.4 Element DeliveryChannel
5.1.3 Struktur eines CPA
5.2 Core Components
5.2.1 Konzept der Core Components
5.2.2 Gesamtzusammenhang der Core Component Dokumentationen
5.2.2.1 Context and Re-Usability of Core Components
5.2.2.2 Catalogue of Context Drivers
5.2.2.3 Document Assembly and Context Rules
5.2.2.4 Naming Convention for Core Components
5.2.2.5 Core Component Discovery and Analysis
5.2.2.6 Guide to the Core Component Dictionary
5.2.3 Gesamtzusammenhang: Business Process, CPP/CPA und Core Components

6 EbXML Message Service
6.1 Simple Object Access Protocol (SOAP)
6.1.1 Struktur einer SOAP Nachricht
6.1.2 SOAP Messages with Attachments (SWA)
6.1.3 Sicherheit und Zuverlässigkeit von SOAP
6.2 Überblick über den ebXML Message Service
6.3 Packaging
6.4 EbXML SOAP Extensions
6.4.1 Header Extensions
6.4.1.1 <MessageHeader> Element
6.4.1.2 <TraceHeaderList> Element
6.4.1.3 <Errorlist> Element
6.4.1.4 <Acknowledgement> Element
6.4.1.5 <Via> Element
6.4.2 SOAP Body Extensions
6.5 Weitere Dienste des Message Service Handler (MSH)
6.6 Zuverlässigkeit der Nachrichtenübertragung
6.6.1 EbXML Reliable Messaging Protocol
6.6.2 Fehlerbehandlung
6.7 Sicherheit der ebXML Nachrichtenübertragung

7 Kritische Würdigung von ebXML
7.1 Vorhandene Kritiken über ebXML
7.1.1 "Overview of the ebXML Architectures"
7.1.2 "ebXML and Interoperability"
7.1.3 "ebXML and SMEs"
7.1.4 "Market Impact of the ebXML Infrastructure Specifications"
7.1.5 "Process Modelling for e-Business"
7.2 Reaktionen auf die Artikel
7.3 Praktische Schwierigkeiten und Mängel der ebXML Spezifikationen
7.3.1 EbXML BPSS
7.3.2 EbXML Registry/Repository
7.3.3 EbXML CPP/CPA
7.3.4 EbXML Core Components
7.3.5 EbXML Message Service

8 Zusammenfassung und Ausblick

Anhang
Anhang A: Beispiel einer XML Business Process Specification
Anhang B: BPSS Document Type Definition (DTD)
Anhang C: BPSS XML Schema
Anhang D: EbXML Links
Anhang E: EbXML Glossar

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2-1: Überblick über den Dialog zweier Unternehmen zur Durchführung von e-Business mit ebXML

Abbildung 2-2: Zusammenhang zwischen BOV und FSV

Abbildung 2-3: ebXML Business Operational View

Abbildung 2-4: ebXML Functional Service View

Abbildung 2-5: Elemente und Vorgänge der funktionalen ebXML Phasen Implementierung, Discovery und Retrieval

Abbildung 2-6: UMM Phasen und Workflows

Abbildung 2-7: Übersicht der UMM Workflows und Artifacts

Abbildung 2-8: UMM Metamodell

Abbildung 2-9: UMM Metamodell und ebXML BPSS

Abbildung 3-1: Übergangsgraph eines Automaten

Abbildung 3-2: Synchronisation zweier Automaten

Abbildung 3-3: ebXML Business Process und Anwendungsfallbeispiel

Abbildung 3-4: Zusammenhang zwischen UMM und ebXML

Abbildung 3-5: Komponenten des ebXML BPSS und ihre Beziehung zu UMM, CPP/CPA und Core Components

Abbildung 3-6: Zusammenhang des BPSS mit anderen ebXML Komponenten

Abbildung 3-7: UML Klassendiagramm einer Business Transaction

Abbildung 3-8: UMM Business Transaction Pattern - Request/Response

Abbildung 3-9: Document Flows und Business Signals einer Transaktion und ihre Reihenfolge

Abbildung 3-10: UML Sequenzdiagramm eines Nachrichtentransfers

Abbildung 3-11: UML Klassendiagramm der Elemente einer Business Transaction-Nachricht

Abbildung 3-12: UML Klassendiagramm der Elemente einer Binary Collaboration

Abbildung 3-13: UML Klassendiagramm einer Multiparty Collaboration

Abbildung 3-14: UML Klassendiagramm einer Choreographie

Abbildung 3-15: UML Klassendiagramm des ebXML BPSS Gesamtmodells

Abbildung 3-16: Hierarchisches Modell des Elements Package

Abbildung 3-17: Hierarchisches Modell der DTD

Abbildung 3-18: Das Business Service Interface

Abbildung 4-1: UML Klassendiagramm der Objekte des RIM

Abbildung 4-2: UML Klassendiagramm: Detailansicht des RIM

Abbildung 4-3: Beispiel einer Assoziation eines RegistryEntry

Abbildung 4-4: Beispiel eines Klassifikationsbaums

Abbildung 4-5: UML Klassendiagramm der Klassifikation eines RegistryEntry im RIM

Abbildung 4-6: UML Klassendiagramm des Sicherheitsmodells im RIM

Abbildung 4-7: Mögliche Topologien der Architektur eines ebXML Registry

Abbildung 4-8: UML Klassendiagramm der Interfaces des ebXML Registry

Abbildung 4-9: UML Klassendiagramm der Hierarchie der Klasse RegistryResponse

Abbildung 4-10: UML Zustandsdiagramm des Lebenszyklus eines Repository Items

Abbildung 4-11: UML Sequenzdiagramm des Protokolls SubmitObject

Abbildung 4-12: UML Sequenzdiagramm des Protokolls GetRootClassificationNodes

Abbildung 4-13: UML Klassendiagramm der Basisstruktur eines Clause

Abbildung 4-14: UML Sequenzdiagramm einer typischen Sequenz von Queries und Retrieval

Abbildung 5-1: Übersicht der Definition eines CPP

Abbildung 5-2: Übersicht der Definition eines CPA

Abbildung 5-3: Übersicht des Zusammenspiels von CPP/CPA und ebXML Registry

Abbildung 5-4: Beispiele für DeliveryChannels

Abbildung 5-5: Core Components in einem Business Document

Abbildung 5-6: Zusammenhang der Core Component Technical Reports und Catalogues

Abbildung 5-7: Discovery und Analyse

Abbildung 5-8: Übersicht der Typen von Core Component-Einträgen im Katalog

Abbildung 5-9: Zusammenhang zwischen Business Process und Core Components

Abbildung 5-10: Bestandteile eines Business Document

Abbildung 5-11: Gesamtzusammenhang zwischen Core Components, CPP, CPA und Business Process

Abbildung 6-1: Struktur einer SOAP Nachricht

Abbildung 6-2: Struktur einer SWA Nachricht

Abbildung 6-3: Funktionale Module des ebXML Message Service

Abbildung 6-4: Struktur eines ebXML Message Package

Abbildung 6-5: Auszug aus einem XML Message Package

Abbildung 6-6: Erfolgreiche Nachrichtenübertragung mit ebXML Reliable Messaging Protocol

Abbildung 6-7: Verlust einer Nachricht während der Übertragung

Abbildung 6-8: Verlust einer Bestätigung während der Übertragung

Abbildung 6-9: Wiederholtes Senden nicht bestätigter Nachrichten

Tabellenverzeichnis

Tabelle 3-1: UMM Vorgabewerte der Requesting Business Activities

Tabelle 3-2: UMM Vorgabewerte der Responding Business Activities

Tabelle 3-3: Umsetzung der UML Klassen aus BPSS in XML Elemente

Tabelle 3-4: Reihenfolge der Elemente in BPSS DTD und Schema

Tabelle 6-1: Varianten zuverlässiger Nachrichtenübertragung in ebMS Version

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Die ebXML Initiative

Electronic Business XML (ebXML) wurde als Projekt zur Entwicklung von Spezifikationen für die direkte Kommunikation und Zusammenarbeit zwischen Partnern im e-Business im Mai 2001 nach 18 Monaten abgeschlossen. Es gilt als eine der ambitioniertesten und wichtigsten Anstrengungen in diesem Bereich, nicht nur für die beiden Initiatoren UN/CEFACT und OASIS.

UN/CEFACT, das "United Nations Center for Trade Facilitation and Electronic Business" [http://www.unece.org/cefact], ist als globale Organisation verantwortlich für Strategien und die technische Entwicklung von Handelserleichterungen, auch im e-Business. Insbesondere entwickelte UN/CEFACT internationale Standards wie UN/EDIFACT für Electronic Data Interchange (EDI).

OASIS, die "Organization for the Advancement of Structured Information Standards" [http://www.oasis-open.org], ist ein gemeinnütziges Konsortium, das Spezifikationen im Bereich der strukturierten Informationsverarbeitung und zur direkten Kommunikation zwischen Unternehmen erstellt. Letztere basieren auf öffentlichen Standards wie XML und SGML.

Seit mehr als 25 Jahren stellt EDI Unternehmen eine papierlose Geschäftsabwicklung, Kostenreduktion und verbesserte, effiziente Geschäftsprozesse in Aussicht, die auf dem elektronischem Austausch der für die Prozesse nötigen Informationen basieren. Idealerweise sollen Unternehmen jeglicher Größe diese elektronische Geschäftsabwicklung, das sogenannte e- Business, vollkommen spontan und ohne jegliche vorausgehenden Abstimmungen betreiben können. Jedoch erfüllte EDI diese Vision nicht: Nur große Firmen konnten sich eine Implementierung leisten. EDI-gestütztes e-Business spielte sich daher vor allem im Umfeld großer, dominanter Firmen ab, die den Handelspartnern ihre eigenen Standards aufzwangen.

In den vergangenen Jahren wurde die Extensible Markup Language (XML) schnell zum bevorzugten Datenformat für den Austausch strukturierter Informationen und ihrer Metadaten von e-Business-Anwendungen im Internet. Obwohl XML offenere, flexiblere Geschäftsmodelle als EDI ermöglicht, löste es EDI entgegen vieler Erwartungen nicht ab. Zum einen waren mit einer erfolgreichen Implementierung schon zu viele Erfahrungen in der Abwicklung von Geschäftsprozessen mit EDI verbunden und große Summen investiert, zum anderen sorgte die rapide Zunahme an unterschiedlichen XML Spezifikationen für große Verwirrung und unnötigen Mehrfachaufwand bei den Anwendern. Trotz oder gerade wegen der Flexibilität von XML und seinem unbestrittenen Potential, webbasierte Transaktionen zu vereinfachen, waren nach wie vor für eine problemlose Kommunikation unterschiedlicher Systeme aufwendige Abstimmungen nötig.

Die heute in nahezu allen Unternehmen eingesetzten Enterprise Resource Planning (ERP)-Systeme bieten vielfältige Möglichkeiten für die automatisierte Kommunikation über Unternehmensgrenzen hinweg und unterstützen e- Commerce, Customer Relationship Management (CRM) und Supply Chain Management (SCM). Bisherige Middleware-Ansätze wie CORBA [http://www.corba.org] oder DCOM [http://www.microsoft.com/com/tech/ DCOM.asp] erleichtern zwar die Integration zweier Systeme, behandeln aber nicht das Problem, Kommunikationssysteme zu errichten, die hunderte und tausende von Systemen miteinander verbinden. Denn eine besondere Herausforderung liegt darin, diese Systeme auch bei kleinen und mittelgroßen Unternehmen ohne großen Kostenaufwand in ein Netzwerk vieler, miteinander flexibel verbundener und zusammenarbeitender Unternehmen zu integrieren, das auf Interaktionen zwischen den Teilnehmern aufgebaut ist. [ChCh01 S.11, 207] Deshalb sollte ein Standard für ein flexibles System im Internet geschaffen werden, in dem alle Unternehmen automatisch mit allen gewünschten Geschäftspartnern auch kurzfristige Geschäftsbeziehungen aufnehmen und direkt kommunizieren können, und zwar ohne aufwendige Abstimmungen und ohne große technologische Hindernisse. Der Standard, der die Infrastruktur für eine solche Interoperabiliät errichten soll, ist ebXML.

Die Vision von ebXML ist

"... to deliver a single set of internationally agreed-upon technical specifications that consist of common XML semantics and related document structures to facilitate global trade." [ebREQ S.6]

"... to create a single global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML based messages. ebXML enables anyone, anywhere, to do business with anyone else over the internet." [ebWhite S.1]

Die ebXML Spezifikationen sollen

"... together enable a modular, yet complete electronic business framework. If the Internet is the information highway for electronic business, then ebXML can be thought of as providing the on ramps, off ramps, and the rules of the road." [ebWhite S.1]

Die meisten bisher eingesetzten e-Business Infrastrukturen automatisierten im Wesentlichen statische, das heißt etablierte, langfristige Geschäftsbeziehungen zwischen bereits bekannten Partnern. Im Gegensatz hierzu soll mit ebXML eine Basis für dynamische Geschäftsbeziehungen geschaffen werden. Dabei bedeutet dynamisch nicht nur die Unterstützung der Suche nach neuen Geschäftspartnern, sondern auch Automatisierung der für eine direkte Zusammenarbeit nötigen Abstimmungen zwischen den Partnern und eine automatische Konfiguration der Kommunikationssysteme. Der Return on Investment (ROI) ergibt sich hier insbesondere aus der potentiellen Ausweitung der Umsätze durch zahlreiche zusätzliche Geschäftsabschlüsse und nicht nur aus Kostenreduzierungen, Zeiteinsparungen oder Vorteilen eines verbesserten Informationsaustauschs. [ChCh01 S.281]

Mit seinem standardisierten Nachrichtensystem begegnet ebXML den Problemen, denen ein Unternehmen gegenübersteht, wenn es mit hunderten von Geschäftspartnern integriert werden und mit ihnen zahlreiche unterschiedliche Geschäftsaktivitäten durchführen muss. Eine Firma, die beispielsweise fünf Kernprozesse automatisiert, wobei jeder dieser Prozesse im Durchschnitt fünf Geschäftsdokumente erfordert und diese Prozesse mit 100 ihrer Geschäftspartner durchführt, muss 2.500 unterschiedliche Netz-Endknoten erstellen und verwalten. Es ist möglich, dass diese Endknoten jederzeit geändert werden müssen, z.B. aufgrund eines neuen Dokumentenformats, geänderter Sicherheitsanforderungen,

URLs etc. Betrachtet man große Unternehmen beispielsweise aus der Luft- und Raumfahrtindustrie mit bis zu 30.000 Lieferanten oder große Automobilhersteller mit ca. 2.500 Informationssystemen, wird sehr leicht deutlich, welcher Aufwand nötig wäre, um an solchen "highly connected", eng verbundenen Systemen teilnehmen zu können. Insbesondere auch kleine Lieferanten müssten einen hohen Aufwand betreiben, um für jeden ihrer wichtigen Kunden spezifische Implementierungen vorzunehmen. [ChCh01 S.197]

EbXML ist ein offener technischer Rahmen, der XML einsetzt, auf widerspruchsfreie und einheitliche Art und Weise standardisiert und erweitert, um eine globale, systemunabhängige, interoperable Infrastruktur für Business-to- Business (B2B)-Transaktionen im Internet aufzubauen. Jedes Unternehmen soll durch die Modellierung seiner Geschäftspraktiken und Informationen in standardisierter Form als XML Dokument an ebXML teilnehmen können.

EbXML basiert auf internationalen Standards wie den XML Empfehlungen des World Wide Web Consortiums (W3C) [http://www.w3.org], anderen technischen Spezifikationen der Internet Engineering Task Force (IETF) [http://www.ietf.org], International Organization for Standardization (ISO) [http://www.iso.ch], Institute of Electrical and Electronics Engineers (IEEE) [http://www.ieee.org], International Electrotechnical Commission (IEC) [http://www.iec.ch], UN/CEFACT, OASIS und der Object Management Group (OMG) [http://www.omg.org] - und soll selbst ein internationaler Standard werden. [ebREQ S.6]

Das Gesamtprojekt war in mehrere Teams aufgeteilt, die verschiedene Aspekte bearbeiteten, z.B. Geschäftsprozess-Modellierung, Verwaltung und Speicherung, Kernkomponenten, Nachrichten-Service, Technischer Aufbau und Sicherheit. Es wurde von mehr als 75 Industrieunternehmen und mehr als 2.000 Partnergesellschaften aus mehr als 30 Ländern unterstützt. [ebWhite S.1] Auch wenn bei der Abschlusskonferenz vom 7.-11. Mai 2001 in Wien alle ebXML Spezifikationen vorlagen, war klar, dass trotz dieser immensen Leistung die Entwicklung von ebXML in allen Bereichen weitere Arbeiten verlangen würde. Dieser noch andauernde Prozess erfolgte unter der Führung der beiden Initiatoren UN/CEFACT und OASIS sowie mit Unterstützung zahlreicher großer e-Business Organisationen wie z.B. RosettaNet [http://www.rosettanet.org], Open Applications Group (OAG) [http://www.openapplications.org] und Covisint [http://www.covisint.com].

1.2 Zielsetzung und Aufbau der Arbeit

In dieser Arbeit wird versucht, die sehr komplexen ebXML Spezifikationen und Zusammenhänge verständlich zusammenzufassen und zu erläutern. Sie stützt sich vor allem auf die Unterlagen, die im Mai 2001 zur ebXML Abschlusskonferenz veröffentlicht wurden.

Anhand eines allgemeinen Einführungsbeispiels und einer Übersicht über ebXML werden in Kapitel zwei die ebXML Komponenten zunächst allgemein vorgestellt und in den darauffolgenden Kapiteln detailliert erläutert. Dazu wird im Vorfeld die grundlegende Modellierungsmethodik dargestellt, auf die ebXML als Rahmen für eine flexible, direkte Kommunikation und Zusammenarbeit im Internet aufsetzt.

Den Schwerpunkt der Arbeit bildet die Geschäftsprozess-Modellierung in ebXML, die ausführlich in Kapitel drei beschrieben wird. Dieser Teil wird deshalb sehr detailliert behandelt, da die Erkenntnisse der vorliegenden Arbeit als Grundlage für eine spätere weitere Untersuchung dienen sollen, ob Prozesse in ebXML mit Petri-Netzen abgebildet und somit ihre Zusammenhänge simuliert werden können.

Nach der Beschreibung der weiteren ebXML Komponenten, nämlich ebXML Registry und Repository in Kapitel vier, Collaboration-Protocol Profiles/Agreement und Core Components in Kapitel fünf und dem ebXML Message Service in Kapitel sechs, wird in Kapitel sieben ebXML als Gesamtheit einer ausführlichen kritischen Würdigung unterzogen.

Kapitel acht rundet die gesamte Arbeit mit einer Zusammenfassung aller erarbeiteten Ergebnisse ab und gibt einen Ausblick auf weitere Entwicklungen in diesem Bereich des e-Business.

In Anhang A findet sich ein Beispiel für eine ebXML Geschäftsprozess- Spezifikation als XML Dokument, in Anhang B die zugehörige XML DTD und in Anhang C das XML Schema. Anhang D enthält einige interessante ebXML Links. Das anschließende ebXML Glossar in Anhang E dient als Nachschlagewerk für ebXML Termini.

1.3 Formale und rechtliche Anmerkungen

Die vorliegende Arbeit beruht zum großen Teil auf den englischsprachigen Spezifikationen und Veröffentlichungen des ebXML Projekts. Sämtliche Literaturhinweise sind deshalb allein wegen der Übersetzung in die deutsche Sprache als sinngemäße Zitate zu verstehen. Aus Gründen der Einheitlichkeit wird diese Art der Quellenangabe auch für die wenigen deutschsprachigen Literaturquellen fortgeführt. Wörtliche Zitate sind in jedem Fall durch die veränderte Textformatierung und umschließende Anführungszeichen kenntlich gemacht.

Eine Quellenangabe am Ende eines beschreibenden Textabschnitts bezieht sich auf den gesamten Abschnitt, eventuell auch auf vorhergehende Abschnitte, sofern dort keine andere Quelle kenntlich gemacht ist. Abweichungen von dieser Formatierung sind beispielsweise zu Beginn eines größeren Textteils jeweils gesondert gekennzeichnet.

Einige der englischen Originalbegriffe wurden unverändert aus den ebXML Spezifikationen übernommen. Dies erfolgte teils wegen ihrer besonderen Bedeutung und spezifischen Definition in ebXML, teils wegen der prägnanten englischen Ausdrucksweise, die sich nur schwierig annähernd kurz, einfach und präzise in der deutschen Sprache wiedergeben lässt. Solche Begriffe sind durch kursive Schreibweise hervorgehoben. Alle kursiv gesetzten Ausdrücke sind im anhängenden ebXML Glossar gesammelt und zusätzlich zur Erklärung im laufenden Text nochmals kurz erläutert. Das Glossar dient somit als allgemeines Nachschlagewerk für die ebXML Terminologie. Gängige, meist englische Fachtermini und Abkürzungen aus dem Bereich der Informationstechnologie, wie z.B. Software, HTTP oder FTP, werden als bekannt vorausgesetzt und nicht eigens erläutert. Alle Akronyme erscheinen im Abkürzungsverzeichnis zu Beginn der Arbeit.

Angegebene Auszüge von XML Dateien und daraus direkt in den laufenden Text übernommene <Elemente> oder attribute sind durch eine veränderte Schriftart hervorgehoben.

Die Spezifikationen des ebXML Projekts sind im Internet öffentlich unter http://www.ebxml.org/specs zugänglich. Jede dieser Spezifikationen unterliegt folgender Copyright-Bestimmung:

Copyright © UN/CEFACT and OASIS, 2001. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to ebXML, UN/CEFACT, or OASIS, except as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by ebXML or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and ebXML DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

2 EbXML Systemübersicht und Grundlagen

Das folgende Kapitel liefert anhand eines Anwendungsbeispiels einen ersten Überblick, wie ein Geschäftsablauf in ebXML funktionieren kann und mit Hilfe welcher ebXML Komponenten diese Funktionalität gewährleistet wird. Danach wird die allgemeine Architektur eines ebXML Systems vorgestellt, die in zwei unterschiedliche Sichtweisen getrennt ist, um eine höhere Flexibilität von Systemen im e-Business zu ermöglichen. Auf der Grundlage eines dieser Views werden die für die Durchführung eines ebXML Szenarios benötigten Phasen erläutert.

Als Grundlage für das Vorgehensmodell einer ebXML Implementierung und der Modellierung von ebXML Geschäftsabläufen schließt die Vorstellung der Unified Modelling Language (UMM) dieses Kapitel ab.

2.1 EbXML Anwendungsbeispiel

Die folgende Abbildung 2-1 beschreibt stark vereinfacht ein Anwendungs- Szenario zwischen zwei Geschäftspartnern, die zunächst ihre Systeme konfigurieren, dann eine einfache Geschäftstransaktion und den dazugehörigen Datenaustausch durchführen. Anhand dieses Szenarios sollen die einzelnen Prozesse und Schritte aufgezeigt werden, die für Konfiguration und Einsatz von ebXML Anwendungen und der jeweiligen Systemkomponenten nötig sind. [ebTA S.7-9]

Dieses einfache Beispiel dient als Einstieg in ebXML und kann etwa um mehrere Partner mit gemeinsamen Geschäftsprozessen und Datenaustausch oder um ein Service-Portal für Geschäftsprozesse erweitert werden. [ebTA S.35-39]

Abbildung 2-1: Überblick über den Dialog zweier Unternehmen zur Durchführung von e-Business mit ebXML [ebTA S.8]

In Abbildung 2-1 überprüft Firma A den Inhalt eines über das Internet zugänglichen ebXML Registry (Schritt 1) und beschließt, eine eigene ebXML Anwendung zu erstellen und einzusetzen (2). Die Entwicklung von kundenspezifischer Software ist dabei nicht nötig, vielmehr können ebXML- kompatible Anwendungen und Komponenten erworben werden, die direkt für Kundenbedürfnisse anpassbar sind, sogenannte "shrink-wrapped solutions". Firma A gibt Informationen über sich samt Implementierungsdetails und Webadressen an das ebXML Registry (3). Dieses Profil beschreibt Möglichkeiten und Grenzen des Unternehmens hinsichtlich der von ihm unterstützten ebXML Business Scenarios. Solche Szenarios sind in XML ausgedrückte Business Processes samt zugehöriger Datenpakete, die das Unternehmen A in ebXML abbilden kann. Nach erfolgreicher Prüfung von Datenformat und Szenarios auf ihre Korrektheit bestätigt das ebXML Registry die Speicherung der Daten.

Unternehmen B findet die von A unterstützten Geschäftsabläufe im ebXML Registry und lädt sich daraus die seinem Bedarf entsprechenden Daten der Szenarios und Profile (4). B stellt eine Anfrage an A hinsichtlich der gemeinsamen Teilnahme an einem ebXML Business Scenario und erwirbt die entsprechende ebXML Anwendungssoftware. Bevor die Zusammenarbeit beginnen kann, schickt B seinen Vorschlag mit Details der vereinbarten Geschäftsabläufe direkt an die ebXML Software-Schnittstelle der Firma A. Dieser Vorschlag beschreibt das gemeinsame Szenario detailliert und enthält spezielle Vereinbarungen, z.B. Informationen über besondere Anforderungen an Nachrichten zur Transaktionsdurchführung, Ausnahmebehandlungen und Sicherheitsanforderungen. Akzeptiert Firma A den Vorschlag (5), können A und B nun im Rahmen von ebXML e-Business betreiben (6). [ebTA S.8]

2.2 EbXML Komponenten

Die in dem Anwendungsszenario aus Abbildung 2-1 bereits angesprochenen Komponenten von ebXML werden hier kurz zusammengefasst dargestellt. Die folgenden Teilkapitel beziehen sich auf [ChCh01 S.18; UBL01 S.5], andere Quellen sind zusätzlich angegeben.

2.2.1 Business Process Specification Schema (BPSS)

Das Ziel von ebXML ist die Errichtung eines allgemeinen Metamodells für Geschäftsprozesse, mit dem jeder Geschäftsprozess auf maschinenlesbare Art und Weise modelliert werden kann. Dies soll Unternehmen ermöglichen, Software zu entwickeln, die sich automatisch den spezifischen Geschäftsprozessen ihrer Handelspartner anpasst.

Das Business Process Specification Schema (BPSS) ist ein Schema zur Spezifikation von Geschäftsprozessen und Informationsmodellen. Es beschreibt die Umsetzung der Geschäftsprozesse in XML Dokumente mit Hilfe bestimmter Semantik, Elementen und Eigenschaften und definiert allgemeine Geschäftsprozesse formal. Ein BPSS bezieht sich in einer Zusammenarbeit zwischen zwei oder mehreren Geschäftspartnern auf einzelne Aktivitäten einer Geschäftstransaktion. Das BPSS ist stark von der Unified Modelling Methodology (UMM) beeinflusst, einer von UN/CEFACT entwickelten Modellierungsmethode für Geschäftsprozesse, und verwendet die Sprache Unified Modelling Language (UML). Allerdings wird die Anwendung dieser Standards nicht zwingend vorausgesetzt.

2.2.2 Registry/Repository

Das ebXML Registry und ebXML Repository stellen die zentralen technischen Komponenten von ebXML dar. Sie bilden zusammen als Registrier- und Speicherdatenbank das Datenbanksystem von ebXML. In dieser Datenbank sind alle nötigen Informationen über ebXML Objekte abgelegt, so dass Benutzer darauf zugreifen und Daten über potentielle Geschäftspartner abrufen, Vereinbarungen treffen und Transaktionen durchführen können. Einträge sind z.B. Profile von Geschäftspartnern, Datenkomponenten, Nachrichtendefinitionen, XML Schemata und XML Dokumente von Geschäftsprozessen. Der Zugriff zu den Daten des ebXML Registry ist über Application Programming Interfaces (APIs) möglich und kann unabhängig von den verwendeten Übertragungsprotokollen erfolgen. [Hous01 S.2]

2.2.3 Collaboration-Protocol Profile (CPP) und Agreement (CPA)

Im e-Business benötigen potentielle Geschäftspartner einen Mechanismus, um Informationen über Unternehmen und von ihnen unterstützte Geschäftsprozesse, technische Implementierungsdetails und Schnittstellenanforderungen zu veröffentlichen.

Dies wird in ebXML mit Hilfe eines Collaboration-Protocol Profile (CPP) erreicht, einem XML Dokument, das ein an ebXML teilnehmendes Unternehmen und die von ihm in ebXML umsetzbaren Business Scenarios zusammen mit den Formaten der hierfür benötigten Business Documents beschreibt. CPPs sind in einem ebXML Registry öffentlich zugänglich abgelegt und können so von allen Interessenten untersucht und zur Grundlage für neue ebXML Geschäftsbeziehungen werden.

Ein Collaboration-Protocol Agreement (CPA) repräsentiert den formalen Vertrag und die spezifischen technischen Vereinbarungen zweier Handelspartner bezüglich genau einer bestimmten Geschäftsbeziehung. Es wird derzeit manuell aus den CPPs der beiden beteiligten Partner ermittelt. CPP und CPA stehen in enger Beziehung zum BPSS. Zusammen mit dem ebXML Message Service liefern sie die Informationen, die für die Konfiguration der beteiligten Systeme und ihrer ebXML-kompatiblen Softwareprodukte nötig sind. [ebTA S.16-18]

2.2.4 Core Components

Die Core Components stellen die Basisinformationen der Dokumente dar, die zwischen Geschäftspartnern ausgetauscht werden, wie etwa Adressen oder Produkte, ihre Beziehungen zu anderen Informationseinheiten. Sie werden in einem speziellen Umfeld eines ebXML Business Scenarios eingesetzt. Eine in einem bestimmten Geschäftsprozess genutzte Core Component wird zum Business Information Object (BIO). Mehrere BIOs können zu Formularen für Business Documents zusammengefasst werden, die mit Daten versehen auszutauschende Business Documents werden.

Diese Kernkomponenten werden von einer Instanz eines Business Document referenziert. Sie werden aus Datenbanken übernommen und können erweitert oder strukturiert zusammengefasst werden, so dass sie in mehreren allgemeinen Geschäftsstrukturen verwendet werden können. Core Components haben eindeutige Identifikationsmerkmale und können in einem mehrsprachigen Geschäftsumfeld eingesetzt werden. [ebTA S.23-24]

Allerdings ist die formale Spezifikation für Core Components noch nicht abgeschlossen, wenn auch Aspekte ihrer Entwicklung, Definition, Zweck, Struktur etc. detailliert beschrieben werden. Dies ist eine der Folgeaktivitäten des ebXML Projekts.

2.2.5 Messaging Services

Die Spezifikation des ebXML Message Service ermöglicht einen standardisierten, sicheren und zuverlässigen Austausch von Nachrichten zwischen Geschäftspartnern, ohne von proprietären Technologien und Lösungen abhängig zu sein. Der Messaging Service wird von vielen anderen ebXML Komponenten benötigt, z.B. für den Zugang zum ebXML Registry. Er erweitert das Simple Object Access Protocol (SOAP) um die Merkmale Zuverlässigkeit und Sicherheit und kann jegliche Arten geschäftlicher Dateninhalte übertragen.

2.3 Ansichten der ebXML Architektur

Eine Modellierung der Geschäftsprozesse und Informationen ist in ebXML zwar nicht obligatorisch, sollte aber, falls durchgeführt, nach der Unified Modelling Methodology (UMM) von UN/CEFACT erfolgen. Basierend auf dem Open-edi Reference Model (ISO/IEC 14662) schlägt UMM eine Trennung der Systemarchitektur in verschiedene Sichtweisen/Views vor, um eine höhere

Flexibilität von Systemen im e-Business zu ermöglichen. Die Views sind streng voneinander getrennt, um eine maximale Zusammenarbeit und Rückwärtskompatibilität zu Altsystemen zu gewährleisten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Zusammenhang zwischen BOV und FSV [ISOI97 S.7]

Die Business Operational View (BOV), wie in Abbildung 2-2 dargestellt, befasst sich mit der Bedeutung und dem Austausch der in Transaktionen enthaltenen Geschäftsinformationen, außerdem mit Aufbau und Details geschäftlicher Transaktionen, etwa Konventionen, Abmachungen, Sequenzen und gegenseitigen Verpflichtungen. Die BOV ist damit speziell auf die Anforderungen der beteiligten ebXML Geschäftspartner ausgerichtet, die geschäftliche Entscheidungen treffen und gegenseitig Verpflichtungen eingehen müssen.

Die Functional Service View (FSV) dagegen konzentriert sich auf die informationstechnologischen Aspekte eines ebXML Systems wie etwa funktionale Kapazitäten, Schnittstellendienste, Protokolle und Messaging Services. [ebTA S.9-11; ChCh01 S.38]

2.3.1 Business Operational View (BOV)

Wie Abbildung 2-3 zeigt, erfasst die BOV Informationen über Business Collaborations in einer Core und Business Library. Diese im ebXML Repository enthaltenen Dateien enthalten die Definitionen der Daten und Prozesse mit ihren Beziehungen und Querverweisen, gegebenenfalls klassifiziert nach einem allgemein anerkannten, branchenüblichen Klassifikationsschema. Die Core Library stellt die Verbindung zwischen einer branchenspezifischen Fachsprache und den durch allgemeine Modelle abgebildeten Informationen dar, während die Business Library Daten über Geschäftsprozesse und Unternehmen enthält. Alle Einträge sind in einem ebXML Registry verzeichnet und können dort abgerufen werden. Die Standardisierung der Geschäftsprozesse gemäß UMM erfolgt in den drei Phasen Anforderungsermittlung, Analyse und Entwurf:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: ebXML Business Operational View [ebTA S.11]

Die erste Phase der Requirements Artifacts definiert die Anforderungen an einen Geschäftsprozess und die von ihm benötigten Informationen. Sie beschreibt die Problemstellung mit Hilfe von UML Use Case Diagrammen und zusätzlichen Erläuterungen. Als Artifacts werden Modellierungsergebnisse der einzelnen Phasen bezeichnet, die zusammengenommen eine Beschreibung des

Geschäftsprozesses auf unterschiedlichen Detaillierungsebenen und aus verschiedenen Betrachtungsperspektiven ergeben. Sie dienen jeweils als Input für die nächste Phase.

In der zweiten Phase, der Analyse, werden UML Aktivitäts- und Sequenzdiagramme erzeugt, die Geschäftsprozesse beschreiben. Konzeptuelle Klassendiagramme enthalten die Informationen der auszutauschenden Business Documents, ihre Objektorientierung ist nicht zwingend. Die dritte Standardisierungsphase ist die Designphase, in der objektorientierte Vorgehensweisen der UMM angewandt werden können, indem zu UML Kollaborationsdiagrammen Zustandsdiagramme erzeugt werden. Die Klassendiagramme aus der Analysephase werden vervollständigt. In Analyse- und Designphase kann auf allgemeine, in der Business Library abgelegte Business Processes verwiesen werden. [ebTA S.11-12]

2.3.2 Functional Service View (FSV)

Die Functional Service View (FSV) unterstützt die informationstechnologischen Anforderungen von ebXML Systemen. Dabei dient der ebXML Registry Service als zentrale Speichereinrichtung für Geschäftsprozess- und Informationsmodelle, ihre XML Dokumente, Core Components und CPPs. [ebTA S.13-14]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: ebXML Functional Service View [ebTA S.13]

Wie Abbildung 2-4 zeigt, können Geschäftspartner über ein Business Service Interface (BSI) die im ebXML Registry verzeichneten Geschäftsprozess- und Informationsmodelle und Profile möglicher Geschäftspartner abrufen. Aus den CPPs zweier Partner wird ein CPA abgeleitet, das den Informationsaustausch eines gemeinsamen, integrierten Prozesses steuert. Alle benötigten Informationen sind im ebXML Registry verzeichnet und als Objekte im Repository abgelegt.

Die vorliegende Beschreibung der ebXML Sichtweisen BOV und FSV ist aus der "ebXML Technical Architecture Specification v1.0.4" [ebTA] entnommen und wurde in dieser Form als ebXML Spezifikation verabschiedet. In dem späteren White Paper "Proposed Revisions to ebXML Technical Architecture Specification v1.0.4" [bpTAREV] wird vorgeschlagen, die aus UMM übernommene Sicht BOV an dieser Stelle aus der Spezifikation zu nehmen, und die FSV in die folgenden funktionalen Phasen von ebXML einzugliedern.

2.4 Funktionale Phasen eines ebXML Szenarios

[vgl. für die folgenden Abschnitte ebTA S.14-15] In Anlehnung an die FSV werden in ebXML die Phasen Implementierung, Discovery und Retrieval und schließlich Einsatz unterschieden, um ein einfaches Szenario von Interaktionen und Nachrichtenaustausch zwischen zwei Geschäftspartnern durchzuführen.

Implementierung

Die erste Phase befasst sich vor allem mit dem Aufbau einer Anwendung für die ebXML Infrastruktur. Ein Geschäftspartner, der eine Transaktion mit ebXML abwickeln möchte, informiert sich in einem ebXML Registry zunächst über die ebXML Spezifikationen in Form von Geschäftsprozess- und InformationsMetamodellen. Im Anschluss daran lädt er Core Library und Business Library aus dem Registry, gegebenenfalls auch Informationen über mögliche Geschäftspartner und die von ihnen unterstützten Geschäftsprozesse. Er hinterlegt sein eigenes Collaboration-Protocol Profile (CPP) im Registry.

Discovery und Retrieval

Die zweite Phase, Discovery und Retrieval, deckt die Aspekte ab, die Ermittlung und Wiedergewinnung weiterer ebXML Ressourcen betreffen. Ein Teilnehmer, der in seinem System ein Business Service Interface eingerichtet hat, kann über diese Schnittstelle Daten möglicher Geschäftspartner ermitteln, ihre CPPs anfordern, oder Updates für Core Library, Business Library, Business Process and Information Meta Models abfragen.

Haben zwei Teilnehmer ihre CPPs mit den allgemeinen Informationen ausgetauscht, die Zusammenarbeit verhandelt und sich in Form eines Collaborative Partner Agreement (CPA) auf bestimmte gemeinsame Geschäftsprozesse geeinigt, kann die Abwicklung von Geschäftsprozessen im Rahmen von ebXML beginnen.

Einsatzphase

In der Einsatzphase/Run Time Phase erfolgt schließlich die Ausführung des vereinbarten ebXML Szenarios und den damit verbundenen Transaktionen. Mit Hilfe des ebXML Message Service tauschen die Trading Partners die benötigten Nachrichten entsprechend dem CPA festgelegten Ablauf aus.

Abbildung 2-5 fasst die Vorgänge und Elemente der ersten beiden Phasen zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5: Elemente und Vorgänge der funktionalen ebXML Phasen Implementierung, Discovery und Retrieval [ebTA S.15]

2.5 Kurze Zusammenfassung und Folgerungen

Im Rückblick auf die bislang beschriebenen Eigenschaften von ebXML ist festzuhalten, dass die ebXML Spezifikationen keine funktionale Beschreibung eines Integrationsprodukts im e-Business darstellen. Vielmehr ist ebXML darauf ausgerichtet, flexible, geschäftsprozessorientierte Lösungen für die automatisierte Zusammenarbeit zwischen Unternehmen zu liefern und die unternehmensübergreifenden Geschäftsprozesse zu unterstützen. Die zahlreichen Spezifikationen in XML gelten als Grundlage für Vereinbarungen und dienen der Konfiguration oder Integration von ebXML Produkten: BPSS ist Grundlage für Spezifikationen von Business Processes oder Business Collaborations. CPP und CPA liefern die Grundlage, um Partnern die formale Definition ihrer Vereinbarungen zu erleichtern. Zusammen mit dem ebXML Message Service spezifizieren diese Komponenten genau die Dienste, die eine Zusammenarbeit in einem komplexen Netz aus Geschäftsverbindungen realisieren. [ChCh01 S.35-36] Die ebXML Spezifikationen bieten somit die Möglichkeit einer direkten Zusammenarbeit und Standardisierung der Kommunikation zwischen unterschiedlichen Softwareprodukten. Sie stellen Informationen für die Konfiguration hochentwickelter Systeme bereit, die über Protokoll- und verschiedene Geschäftsprozess-Ebenen hinausgehen. Dies bedeutet in der Praxis, dass zur Implementierung eines ebXML-fähigen Systems eine Vielzahl von Middleware-Produkten benutzt werden kann. [ChCh01 S.19] Als Middleware bezeichnet man Software, die als Mittelschicht zwischen zwei Anwendungsprogrammen gesetzt wird, um als Datenintegrator die gesamte Kommunikation zwischen diesen beiden unterschiedlichen Programmen zu übernehmen. [GoPr00 S.101]

Die wesentlichen Grundlagen, auf denen ebXML aufbaut, und die diese Standardisierung ermöglichen, wird im folgenden Teilkapitel erläutert.

2.6 Grundlagen: Die Unified Modelling Methodology

Das ebXML Integrationsmodell basiert auf der Idee, dass der Grossteil der Geschäftsbeziehungen der meisten Unternehmen auf eine kleine Anzahl gemeinsamer Geschäftsprozesse reduziert werden kann. Diese Prozesse sind entweder allgemeingültig oder spezifisch für eine bestimmte Industrie, Wertkette oder ein Geschäftsmodell. Sind die geschäftlichen Interaktionen standardisiert und ausreichend formal beschrieben, können standardisierte Nachrichten zu ihrer Automatisierung benutzt werden. So ist es Unternehmen möglich, mit allen bereits bestehenden und potentiellen Partnern, die diese Prozesse ebenfalls unterstützen, e-Business zu betreiben. [ChCh01 S.44]

In diesem Teilkapitel soll zunächst erläutert werden, wie Beschreibungen solcher Geschäftsprozesse entwickelt werden können und auf welche Art man Geschäftsprozesse modellieren kann, um die Anwendung ebXML-fähiger Tools zur Implementierung dieser Prozesse zu vereinfachen. Dies erfolgt in ebXML durch die Verwendung des Vorgehensmodells UN/CEFACT Modelling Methodology (UMM), das eine Standard-Modellierungsmethodik enthält, zusammen mit der Unified Modelling Language (UML), einer Standard- Modellierungssprache.

Die Unified Modelling Methodology (UMM)

Geschäftsprozessmodelle in ebXML dienen nicht nur der Dokumentation. Die Beschreibungen von Kollaborationen im ebXML BPSS sind vielmehr deklarative, maschinen-interpretierbare Spezifikationen. Zusammen mit den in den CPAs festgelegten Vereinbarungen können sie zur Konfiguration ebXML-gerechter Middleware genutzt werden und eine eigene Programmierung der e-Business- Schnittstellen überflüssig machen. Deshalb ist eine Methodik nützlich, die das Vorgehen zur Bildung solcher formalen Beschreibungen organisiert. Diese Methodik liefert die UN/CEFACT Modelling Methodology. [ChCh01 S.44]

Wegen der großen Vielfalt und beliebigen Komplexität von Geschäftsprozessen sind einige Schritte nötig, um von einer abstrakten Problembeschreibung zu einer ausreichend spezifischen Beschreibung zu gelangen, die eine technische Umsetzung ermöglicht. Nützliche Hilfsmittel sind dabei im Wesentlichen eine Modellierungssprache für die präzise Modellierung der zu automatisierenden Geschäftsprozesse und ihrer Aktivitäten, außerdem ein Standardprozess zur Organisation der Aktivitäten, die dieses Modell entwickeln, sowie

Schemasprachen zur Modellierung der Geschäftsinformationen, die im e-Business ausgetauscht werden. [ChCh01 S.46]

Modellierungssprache

Die Unified Modelling Language (UML) [http://www.uml.org] ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme. Sie berücksichtigt die aufgrund der Komplexität heutiger Systeme gestiegenen Anforderungen, deckt ein breites Spektrum von Anwendungsgebieten ab und eignet sich für konkurrierende, verteilte, zeitkritische und sozial eingebettete Systeme. UML ist jedoch keine Methode, sondern kann lediglich Basis für verschiedene Methoden sein, da sie eine definierte Menge von Modellierungskonstrukten mit einheitlicher Notation und Semantik bereitstellt. Die Object Management Group (OMG) erklärte UML zum Standard. Der International Organization for Standardization (ISO) liegt UML zur Standardisierung vor. [Oest01 S.VIII]

Auf eine Einführung in UML, ihre Elemente und Konstrukte wird an dieser Stelle verzichtet, da dies nicht in den Themenbereich der vorliegenden Arbeit fällt. Eine gute Einführung bietet [FoSc00].

Entwicklungsprozess

Als Gegenstück zur UML wurde der Rational Unified Process (RUP) von den UML Entwicklern Jacobson, Booch und Rumbaugh entwickelt [http://www.rational.com/products/rup/index.jsp]. RUP bietet den Standard- Prozess zur Standard-Modellierungssprache UML und bildet somit ein Vorgehensmodell im Software Engineering. RUP ist wie UML generisch, das heißt kann für spezifische Typen von Software-Entwicklungsprojekten spezialisiert werden. [FoSc00 S.11]

Die UN/CEFACT Modelling Methodology (UMM) ist eine modifizierte Untermenge des RUP. UMM fungiert als Rahmen für die Modellierung von Geschäftsprozessen mit UML mit dem Fokus auf e-Business-Projekte. UMM beeinflusst insbesondere die Geschäftsprozess-Modellierung in ebXML, wie im weiteren Verlauf der Arbeit noch gezeigt wird.

Vor allem durch den Schwerpunkt der Prozessmodellierung in e-Business- Systemen hebt sich UMM von anderen Methoden ab. Prozesse werden von den Informationen getrennt betrachtet, die während der Ausführung eines Prozesses ausgetauscht werden. "Noch strenger" sind Prozesse von der Syntax der Informationscodierung getrennt. Die syntaktisch neutralen Modelle der UMM können mit oder ohne Codierung in XML in einem Laufzeitsystem eingerichtet werden. [ChCh01 S.49]

Weder UML noch UMM sind Bestandteile von ebXML. Sie sind vielmehr unabhängige, für sich stehende, nützliche Werkzeuge, die nicht in allen Bereichen einer ebXML Implementierung zwingend erforderlich sind. [ChCh01 S.44]

Schemasprache

Die sogenannte erweiterbare Auszeichnungssprache, eXtensible Markup Language (XML), umfasst Grundregeln zur Auszeichnung und Strukturierung von Daten. XML 1.0 [XML01] erlangte im Februar 1998 den Status einer offiziellen Empfehlung des World Wide Web Consortium (W3C) und wurde im Oktober 2000 überarbeitet. XML ist eine Teilmenge der sehr komplexen Standard Generalized Markup Language (SGML) und ermöglicht wie SGML die Definition verschiedener Auszeichnungssprachen für unterschiedliche Anwendungszwecke. [Ray01 S.11-12]

Eine Erläuterung aller Standards und Spezifikationen, die aus der Grundidee von XML entstanden, würden den Rahmen dieser Arbeit weit übersteigen. Deshalb sei an dieser Stelle auf die Homepage des W3C und Einführungsliteratur wie [Ray01], [GoPr00] oder [Born01] verwiesen.

Im Zusammenhang mit ebXML sind insbesondere Document Type Definitions (DTD) relevant, die die Struktur von XML Dokumenten beschreiben. Dabei handelt es sich um einen Satz von Regeln oder Deklarationen, die festlegen, welche Auszeichnungssymbole, sogenannte "Tags", verwendet werden und was diese enthalten können.

Im Mai 2001 wurde ein neuer Standard zur Dokumentenmodellierung vom W3C empfohlen: XML Schema [XML01a; XML01b]. Anders als DTDs verwenden diese Schemata wohlgeformte XML Fragmente, sogenannte "Templates", um zu zeigen, wie ein Dokument aussehen sollte. Sie ermöglichen auch eine mächtigere Datentypüberprüfung, so dass Fehler sowohl im Inhalt als auch in der Verwendung von Tags gefunden werden können. [Ray01 S.6-7, S.205-210]

2.6.1 Klassifizierung der Modellierungsaktivitäten in UMM

Einer der grundlegenden Standards für UMM ist das bereits in Kapitel 2.3 angesprochene Open-edi Reference Model (ISO/IEC 14662). UMM als Modellierungsmethodik konzentriert sich auf die im selben Kapitel erläuterte Business Operational View (BOV) und nicht auf die Functional Service View (FSV). So stellt UMM eine Möglichkeit bereit, auf technologisch-neutrale, implementierungs-unabhängige Art und Weise die Modellierung von Geschäftsprozessen zu spezifizieren, die einen Informationsaustausch zwischen unterschiedlichen Systemen erfordern. Jede technische FSV Umsetzung ist möglich, egal ob objektorientierte Techniken, XML, UN/EDIFACT oder beliebige Protokolle verwendet werden. [UMM01 Kap.1 S.2-3]

Die UMM klassifiziert die Aktivitäten eines Entwicklungsprojekts für e-Business- Software genau wie der allgemeinere RUP in drei Bereiche: [ChCh01 S.49-53]

1. Ein Arbeitsablauf/Workflow ist eine logische Anordnung von Modellierungs- Aktivitäten innerhalb eines e-Business-Projekts. UMM konzentriert sich auf vier der neun Workflows aus RUP, nämlich Modellierung, Anforderungen, Analyse und Design, die im Laufe dieses Kapitels näher erläutert werden.
2. Eine Phase beschreibt das Zeitintervall zwischen zwei wichtigen Meilensteinen in einem Projekt. Wie in RUP wird in vier Haupt-Projektphasen Anfang, Ausarbeitung, Konstruktion und Übergang unterschieden. Innerhalb einer Phase können mehrere Workflows bearbeitet werden.
3. Eine Wiederholung/Iteration bezeichnet einen Entwicklungszyklus innerhalb eines Projekts. Sie beginnt mit der Anforderung einer Funktionalitätsverbesserung oder einer Änderung und beinhaltet die Implementierung und das Testen des modifizierten (Prototyp-)Systems. Eine Modifikation kann wiederum Änderungsanforderungen ergeben, diese eine nächste Iteration auslösen usw. Innerhalb einer Phase können mehrere Iterationen auftreten.

Abbildung 2-6 gibt einen Überblick über den Zusammenhang der Phasen und Workflows und verdeutlicht den Focus der UMM auf die ersten beiden Phasen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-6: UMM Phasen und Workflows [UMM01 Kap.1 S.5]

2.6.1.1 UMM Workflows

UMM behandelt die folgenden vier Workflows und ihre Funktionen:

- Der Business Modelling Workflow ermittelt und organisiert Geschäftsprozesse und Informationen im B2B-Umfeld. Schlüsselkonzepte und Geschäftsmodelle werden in Gruppen eingeteilt.
- Der Requirements Workflow benutzt die Geschäftsmodelle als Input, um die Anforderungen an die Lösung des B2B-Problems zu verdeutlichen. Detaillierte Anforderungsabbildungen, UML Use Case Diagramme, werden erstellt.
- Der Analysis Workflow verfeinert die Use Cases und detailliert die auftretenden Aktivitäten und Kollaborationen zu ersten Klassendiagrammen.
- Der Design Workflow definiert präzise die Veränderungen der e-Business- Kollaborationen im Zeitablauf und die Struktur der zwischen den Partnern ausgetauschten Daten.

Jeder dieser Workflows produziert eine Reihe von Artifacts, die einen Geschäftsvorfalls auf unterschiedlichen Detaillierungsebenen beschreiben und jeweils als Input für den folgenden Workflow dienen. Eine Untermenge dieser Artifacts, sogenannte Deliverables, bezeichnen formal akzeptierte oder vertraglich vereinbarte Artifacts zwischen Projektteam und der Kunden- oder Benutzerseite. [UMM01 Kap.1 S.5-6]

Ihre Anwendung in ebXML ist bereits aus Abbildung 2-3 in Kapitel 2.3.1 bekannt, wo aus der Perspektive der BOV anhand der Artifacts die Phasen einer Standardisierung von Geschäftsprozessen kurz erläutert wurden.

An dieser Stelle ist festzuhalten, dass der Begriff des Workflow in UMM nicht mit dem allgemein bekannten gleichen Begriff aus dem Bereich des Workflow Management [http://www.wfmc.org] übereinstimmt. Im Workflow Management bezeichnet ein Workflow den integrierten Fluss von elektronischen Dokumenten und orientiert sich an den operationalen Anwendungen im täglichen Arbeitsablauf. Ziel des Einsatzes eines Workflow-Management-Systems ist es, die Produktivität zu erhöhen, schneller auf Rückfragen und Probleme von Kunden zu reagieren und die im Unternehmen ablaufenden Prozesse besser zu kontrollieren und zu steuern. Workflow Management unterstützt somit die Planung, Aufgabenverteilung, Verarbeitung und Kontrolle von Geschäftsfällen oder Vorgängen.

In UMM dagegen bezeichnet der zentrale Begriff Workflow eine Gruppe logisch miteinander in Beziehung stehender Modellierungsaktivitäten innerhalb eines Entwicklungsprojektes im e-Business.

2.6.1.2 UMM Phasen

UMM übernimmt die Vorstellungen des RUP, dass jedes Software Engineering- oder e-Business-Projekt im Allgemeinen die folgenden vier Phasen durchläuft:

- In der Anfangsphase stehen vor allem die Anforderungsspezifikationen im Mittelpunkt. Zweck und Umfang des Gesamtprojekts werden festgelegt, auch ein Prototyp kann entwickelt werden.
- In der Ausarbeitungsphase werden die Anforderungen im Detail analysiert. Ein Prototyp für die Architektur des Systems wird erstellt, der zur Basis des Gesamtsystems wird.
- In der Konstruktionsphase werden Software und XML DTDs und Schemata entwickelt, implementiert und getestet.
- In der Übergangsphase wird der Testvorgang abgeschlossen und das Projekt kommt zum Einsatz.

Die für UMM besonders relevanten Workflow-Aktivitäten konzentrieren sich auf die ersten beiden Phasen. Dies zeigt die zunehmende Bedeutungsverlagerung hin zu beschreibenden, ausführbaren Spezifikationen, was sich auch in der Aufwandsverteilung über die Phasen widerspiegelt: Während sich der Aufwand in einem Software Engineering-Projekt üblicherweise zu ca. 10%, 30%, 50% und 10% jeweils auf Anfangs-, Ausarbeitungs-, Konstruktions- und Übergangsphase verteilt, ist in einem ebXML Projekt vor allem für die Anfangsphase ein deutlich höherer Aufwand zu verzeichnen. Dies liegt beispielsweise an der Vielzahl von Partnern, die sich auf einen gemeinsamen Projektumfang einigen müssen. Dagegen verringert sich der Aufwand in der Konstruktionsphase, da in ebXML durch BPSS und CPAs ein Rahmen vorgegeben wird, der durch eine ebXML- konforme Middleware implementiert werden kann. [ChCh01 S.51-52]

2.6.1.3 UMM Iterationen

Mit Hilfe von Iterationen sollen umfangreiche, komplexe Projekte in kleinere, leichter zu handhabende Teilprojekte aufgeteilt werden, die ihrerseits Workflows und Phasen enthalten. Daraus resultieren robustere Projekte, da Fehler besser entdeckt und frühzeitig bearbeitet werden können. Zudem wird die Integration der einzelnen Teile allmählich umgesetzt und nicht bis zum Ende des Gesamtprojekts verschoben. Aus Iterationen bestehende Projekte können auch schneller und leichter an Änderungen angepasst werden. Im Gegensatz zu den Workflows und Phasen gibt es in UMM keine vordefinierten Iterationen, sie müssen je nach Projekt individuell festgelegt werden. [ChCh01 S.53]

2.6.2 Workflows und Worksheets in UMM und ebXML

Die während der aufeinander folgenden UMM Workflows Business Modelling, Requirements, Analysis und Design jeweils erzeugten Artifacts sind in Abbildung 2-7 zusammengefasst. Sie müssen zwar detailliert genug für die Implementierung, aber unabhängig von einem speziellen, vorgegebenen Rahmen sein. Zusammen mit den Erkenntnissen aus den UMM Phasen bilden sie Modelle und Beschreibungen in Form von Konstrukten, Terminologien und UML Diagrammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-7: Übersicht der UMM Workflows und Artifacts [UMM01 Kap.1 S.7]

Eine alternative Möglichkeit, diese Ergebnisse festzuhalten, sind Tabellenblätter/Worksheets. Dies sind Vorlagen mit vordefinierten, für spezielle Anforderungen erweiterbare Strukturen der Workflow-Ergebnisse. Worksheets können auch als Hilfsmittel für die Prozessmodellierung in UMM dienen. Ihr Sinn und Zweck liegt in der Erfassung aller Informationseinheiten, die für die vollständige Beschreibung eines Geschäftsprozesses benötigt werden. So kann dieser Geschäftsprozess registriert, klassifiziert, wieder gefunden und wieder verwendet werden und sorgt somit für eine reibungslose Verarbeitung durch die Anwendungsprogramme. UMM unterstützt die Erstellung solcher Dokumente, die in der Projekt-Implementierungsphase als maschinen-interpretierbare Spezifikationen relevanter Geschäftsprozesse und zur Konfiguration von ebXML- fähigen Kollaborationssystemen im e-Business dienen. [ChCh01 S.53; bpWS S.9] Das Dokument "Business Process Analysis Worksheets & Guidelines v1.0" [bpWS] diskutiert die Anwendung von Worksheets und Tools zur Unterstützung der vier UMM Workflows. Die Worksheets können auch unabhängig von UMM eingesetzt werden.

Mit Hilfe eines Lexikons, das Informationen über Prozessdefinitionen, Relationen und Querverweise in branchenspezifischer Terminologie enthält, ermöglicht UMM den Übergang zwischen Branchen-Fachsprache und UML Modellen. Die

Ergebnisse können aus einer Bibliothek mit Business Information Objects und Business Processes wieder verwendet werden. Diesen beiden UMM Datenbanken entsprechen die bereits in Kapitel 2.3.1 erwähnten ebXML Bibliotheken Core Library und Business Library, die mit zunehmender Verbreitung von ebXML ständig erweitert werden. [UMM01 Kap.1 S.7]

Abgesehen von der technischen ebXML Spezifikation BPSS, die stark von UMM beeinflusst wurde, liefert das ebXML Dokument "Business Process and Business Information Analysis Overwiew v1.0" [bpOVER] einen Überblick über methodologische Aspekte der Analyse von Geschäftsprozessen und Informationen. Die einzelnen Workflows und ihre Artifacts werden in den folgenden Abschnitten näher erläutert.

2.6.2.1 Business Modelling Workflow

[vgl. für das folgende Teilkapitel ChCh01 S.54-57 und bpWS S.17-22] Der Business Modelling Workflow in UMM liefert einen ersten Überblick über den allgemeinen geschäftlichen Kontext des Projekts, die relevanten Geschäftsprozesse, ihr Umfeld, die Anforderungen, Problembereiche und den Zweck des einzuführenden e-Business Systems. Die Geschäftsprozesse werden Prozess- und Geschäftsbereichen zugeordnet. Ein Prozessbereich/Process Area ist eine Gruppe von Geschäftsprozessen und Transaktionen, die zusammengenommen eine komplette Wertkette bilden. Eine Wertkette besteht nach M.E. Porter [Port99 S.67] aus allen Aktivitäten und Prozessen, durch die ein Produkt entworfen, hergestellt, vertrieben ausgeliefert und unterstützt wird, und die von Hersteller, Lieferanten und weiteren Partnern ausgeführt werden. Ein Geschäftsbereich/Business Area ist eine Menge von Process Areas in einem speziellen Umfeld, wobei dieses Umfeld nach verschiedenen Kriterien wie Funktion, Informationsart oder Einflussbereich abgegrenzt werden kann.

Das Ergebnis des Business Modelling Workflow ist die Business Operations Map (BOM), die diese allgemeinen Übersichten liefert und deren Informationen in den nachfolgenden Workflows verfeinert werden, so dass schließlich die präzise Spezifikation direkt in maschinen-interpretierbare ebXML Geschäftsprozesse umgesetzt werden kann.

Die BOM umfasst:

- Kontext des Projekts und des zu entwickelnden e-Business-Systems, Festlegung der Process Areas und Business Area
- Beschreibungen der Prozesse mit UML Use Case Diagrammen und Szenarios
- Identifikation von Business Information Objects für die während eines Business Process ausgetauschten Informationen.

Worksheets, die in ebXML zur Unterstützung dieses Workflow angeboten werden, sind die Business Reference Model Form, Business Area Form, Process Area Form und Identify Business Process Form. [bpWS S.19-22] Das zentrale Modellierungskonstrukt des Business Modelling Workflows in UMM sind UML Anwendungsfälle/Use Cases. Ein Anwendungsfall beschreibt aus der Sicht seiner Akteure das Verhalten eines Systems als Menge der Aktivitäten, die zu einem wahrnehmbaren Ergebnis führen. Er zeigt auf, was ein System tut, aber nicht auf welche Weise. [Oest01 S.5]

Weitere Details zum Business Modelling Workflow finden sich in [UMM01 Kap.2].

2.6.2.2 Requirements Workflow

[vgl. für das folgende Teilkapitel ChCh01 S.57-60 und UMM01 Kap.1 S.7, Kap.3] Der Requirements Workflow modelliert die Business Processes eines UMM oder ebXML Projekts. Die UML Use Cases des Business Modelling Workflow werden im Business Requirements View (BRV) weiter detailliert. An dieser Stelle nehmen die Bedürfnisse und Anforderungen der beteiligten Partner zum erstem Mal Einfluss auf die weiteren Ergebnisse.

Die Hauptergebnisse des Requirements Workflow in ebXML sind Modelle für:

- Business Collaborations in Form von UML Use Cases für Inputs, Outputs, Bedingungen, Systemgrenzen und Funktionalitäten und in Form von UML Aktivitätsdiagrammen für Choreographien von Prozessen.
- Business Transactions durch die Modellierung von Funktionen.
- Economic Elements, die wirtschaftliche Elemente einer Transaktion wie z.B. Ereignisse, Ressourcen, Partnertypen, Vereinbarungen spezifizieren.

Für eine Anwendung der Business Collaborations in ebXML müssen Kollaborationen zwischen mehreren Partnern in paarweise Kollaborationen zerlegt werden. Eine Choreography verbindet diese Binary Collaborations, so dass Multiparty Collaborations entstehen. Ebenso verbindet sie die Business Transactions einer Business Collaboration. Die beteiligten Partner werden danach klassifiziert, welche Rolle sie in einer Transaktion spielen, ob sie eine Anfrage stellen (Requesting Role) oder antworten (Responding Role).

Ein Schwerpunkt des Requirement Workflow liegt in der Modellierung der dynamischen Aspekte des e-Business-Systems. Diese werden mit UML Aktivitätsdiagrammen abgebildet. Aktivitätsdiagramme beschreiben die Ablaufmöglichkeiten eines Systems mit Hilfe von Aktivitäten. Eine Aktivität ist ein einzelner Schritt in einem Ablauf, ein Zustand mit einer internen Aktion und einer oder mehreren ausgehenden Transitionen, die automatisch dem Abschluss der internen Aktion folgen. [Oest01 S.92]

Worksheets, die in ebXML zur Unterstützung dieses Workflow angeboten werden, sind z.B. Business Process Use Case Worksheet [bpWS S.23-24], Business Collaboration Worksheet [bpWS S.29] oder Business Collaboration Protocol Table Worksheet [bpWS S.29-30].

2.6.2.3 Analysis Workflow

[vgl. für das folgende Teilkapitel ChCh01 S.60-64 und bpWS S.31] Im Analysis Workflow werden die vorhandenen Modelle der Business Transactions und Business Collaborations nochmals verfeinert, so dass mit der Konstruktionsphase und der Implementierung begonnen werden kann. Die Ergebnisse des Analysis Workflow sind in der Business Transaction View (BTV) festgehalten und beschreiben vor allem die Business Transactions näher, aus denen die Business Collaborations bestehen. Sie können direkt als XML Spezifikationen verwendet werden.

Jede Business Transaction besteht aus einer Reihe von Aktivitäten. Für jede Aktivität ist eine Partnerrolle mit einer bestimmten Berechtigung definiert, die ein Partner besitzen muss, um die Aktivität auslösen zu können. Responding Business Activities können im Gegensatz zur Requesting Business Activity mit mehreren Business Documents verbunden sein, die verschiedene Ergebniszustände anzeigen können. Für die Business Activities einer Transaktion können Werte für Interaktionsparameter festgelegt oder die Werte von vorgegebenen Mustern übernommen werden, z.B. Time-to-acknowledge-receipt, Time-to-acknowledge- acceptance, Time-to-perform, Authorization-required oder Non-repudiation-of- origin-and-content.

Zusätzlich erstellt der Analysis Workflow Business Documents, also eine erste Analyse der Informationen, die als Nachrichten zwischen Geschäftspartnern ausgetauscht werden. Zu den UML Aktivitätsdiagrammen können UML Zustandsdiagramme und weitere Interaktionsdiagramme wie Kollaborations- und Sequenzdiagramme erstellt werden. Die Modellierung der Informationen kann mit Klassendiagrammen erfolgen.

Worksheets, die in ebXML zur Unterstützung dieses Workflow angeboten werden, sind Business Transaction Worksheet, Business Transaction Property Values Table und Business Transaction Transition Table. [bpWS S.32-34] Weitere Details liefert [UMM01 Kap.4, Kap.9].

2.6.2.4 Design Workflow

[vgl. für das folgende Teilkapitel UMM01 Kap.1 S.8 und bpWS S.34] Der Design Workflow beschreibt die Anforderungen an die Informationen, die in den Business Documents, entsprechend ihrer Beschreibung in den Business Transactions, ausgetauscht werden. Somit detailliert er das Informationsmodell weiter, weist allen Klassenmodellen Business Information Objects zu, verfeinert Syntax und Semantik der Service Protokolle und wendet bestimmte Muster für den Informationsaustausch an.

Bei der Erstellung der BIOs wird zunächst versucht, vorhandene Einträge aus der Business Library zu verwenden. Falls das benötigte BIO dort nicht existiert, kann es mit Core Components aus der Core Library erzeugt und in der Business Library abgelegt werden, wo es nun weiteren Business Documents zur Verfügung steht.

In diesem Zusammenhang bietet ebXML das Business Information Context Worksheet, die Document Content Description und das Content Mapping als unterstützende Vorlagen an. [bpWS S.35-37]

Weitere Details finden sich in [UMM01 Kap.5, Kap.9].

2.6.3 Das UMM Metamodell

Ein wesentlicher Schritt bei einer Modellierung von Softwaresystemen ist die Abstraktion von Objekten der Anwendungsdomäne zu Klassen des Modells, allgemeiner ausgedrückt von Exemplaren zu Modellobjekten, die gleichartig strukturierte Instanzen oder solche mit gleichem Verhalten zusammenfassend beschreiben. Betrachtet man die Modellierung selbst als Anwendung, so werden die Modellobjekte, die entworfenen Klassen und Assoziationen selbst zu

Ausprägungen der allgemeineren Metaobjekte wie Klassen oder Generalisierung. [SeGu00 S.268]

Ein Geschäftsprozess- und Informationsmodell stellt im Allgemeinen die Spezifikation der Struktur und des Verhaltens von Objekten dar, die miteinander über Schnittstellen verschiedener Geschäftspartner in einem speziellen konzeptuellen Bereich agieren. Geschäftsprozess- und Informationsmodelle können in der Unified Modelling Language (UML) ausgedrückt werden, da diese Sprache ausdrucksstark genug ist, um die Struktur und das Verhalten solcher Objekte festzuhalten. [UMM01 Kap.1 S.9]

Das UML Metamodell definiert UML und beschreibt ihre Syntax mit UML Diagrammen und ihre Semantik mit Hilfe der Object Constraint Language (OCL) und der natürlichen Sprache. [SeGu00 S.272]

Auf weitere Ausführungen des UML Metamodells wird an dieser Stelle verzichtet. Eine gut verständliche Einführung bietet [Neum98]. Dieses UML Metamodell wird für UMM um eine spezifische Syntax und Semantik für bestimmte Bereiche von Geschäftsprozessen, sogenannte Stereotypen, erweitert und bildet so das UMM Metamodell. Die Syntax des UMM Metamodells erleichtert die Konstruktion objektorientierter Geschäftsprozess- und Informationsmodelle. Tools und Anwendungen, die sowohl Syntax als auch Semantik des UMM Metamodells unterstützen, können auch Konstruktion und Ausführung von Geschäftsprozessen unterstützen. [UMM01 Kap.1 S.10-12]

Das UMM Metamodell ist ein Mechanismus, der es Geschäftspartnern erlaubt, Details eines bestimmten geschäftlichen Szenarios mit einer umfassenden Modellierungsmethodik abzubilden. Es beschreibt Regeln der Klassifikation von Geschäftskonzepten und direktem Zusammenarbeiten, so dass einheitliche Geschäftsprozesse umgesetzt werden können.

Im Rahmen des UMM Metamodells werden unterschiedliche Views auf Geschäftsprozesse unterstützt, die jeweils eigene Semantiken enthalten und somit die Grundlage für die Artifacts der Workflows bilden. Diese erleichtern die Informationsintegration und Kommunikationsfähigkeit von Geschäftsprozessen. Abbildung 2-8 zeigt die verschiedenen Perspektiven, aus denen jedes Geschäftsprozess- und Informationsmodell betrachtet werden kann. [bpOVER S.15-17]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-8: UMM Metamodell [UMM01 Kap.1 S.10]

Der Business Service View spezifiziert neben den Informationsobjekten des Design Workflow die Dienste der Netzwerkkomponenten und Agenten, ihren je nach Transaktionstyp für Interaktionen nötigen Nachrichtenaustausch und legt z.B. Rollentypen, Sicherheits- und Zeitparameter fest. [UMM01 Kap.1 S.12] Ausführliche Details über das UMM Metamodell finden sich in [UMM01 Kap.8], wo für alle Sichten die jeweilige Syntax und Semantik in UML Klassendiagrammen beschrieben sind.

Eine zusätzliche Sicht des UMM Metamodells ist das ebXML Business Process Specification Schema (BPSS). Es dient der Spezifikation genau der Elemente und Informationen, die zur Konfiguration ebXML-konformer Software benötigt werden, damit ebXML Transaktionen ausgeführt werden können. Durch die Nutzung von Modellierungselementen aus anderen Sichten bildet es eine semantische Untergruppe des UMM Metamodells. Das BPSS ist als eigenständige Version in UML oder XML spezifiziert. Es ist der einzige Teil des UMM Metamodells, der zur Zeit für eine Einführung von ebXML obligatorisch ist. [bpOVER S.15-17]

Abbildung 2-9 verdeutlicht den Zusammenhang zwischen dem UMM Metamodell und den Spezifikationsschemata des BPSS.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-9: UMM Metamodell und ebXML BPSS [in Anlehnung an bpOVER S.16]

EbXML verlangt, dass alle Artifacts der Geschäftsprozesse und Informationen mit der Semantik des UMM Metamodells konform gehen. Dies gewährleistet größtmögliche Kompatibilität zwischen einem Geschäftsprozess-Modell und seiner Unterelemente und entspricht den Anforderungen von Wiederverwendbarkeit des Modells bei gleichzeitiger Vergleichbarkeit und Abgrenzbarkeit. Mit UMM Metamodell-konformen Modellen können XML Instanzen des ebXML BPSS generiert werden. [bpOVER S.18]

2.6.4 UMM Patterns

[vgl. für das folgende Teilkapitel ChCh01 S.62-63 und UMM01 Kap.1 S.14, Kap.9] Ein Muster/Pattern bezeichnet im Software Engineering eine allgemeine Lösung eines allgemeinen Problems in einem gegebenen Zusammenhang. In UMM sind Patterns wieder verwendbare, generalisierte Abstraktionen von Geschäftsprozessen, die auf viele fachspezifische Bereiche angewendet werden können. Während ein Metamodell Syntax und Grammatik für den Entwurf von Geschäftsprozessen liefert, sind Patterns subjektive Konstrukte, die den Anforderungen spezifischer Szenarios entsprechen, also das Metamodell auf allgemeine Geschäftsprozesse und Informationen dieser Bereiche anwenden. Ein Design Pattern einer Business Transaction ist eine bestimmte Gruppe von Transaktionen mit sinnvoll vorgegebenen Parameterwerten.

Für jede der Sichten des UMM Metamodells sind solche Patterns definiert, die mit Hilfe von UML Aktivitätsdiagrammen abgebildet und ausführlich erläutert werden.

Für das Business Transaction View Metamodell sind mit den Analysis Patterns die Parameterwerte einzelner Aktivitäten festgelegt und folgende Stereotypen definiert: [UMM01 Kap.9 S.12-18]

- Commercial Transaction modelliert den Angebot-Annahme-Prozess mit gegenseitigen Verpflichtungen der Parteien für eine Vertragserfüllung.
- Query/Response fragt dem Geschäftspartner vorliegende Informationen ab, z.B. Datenbankinhalte.
- Request/Response wird in Verträgen benutzt, bei denen der anfragende Partner Informationen anfordert, die dem anderen Partner vorliegen, und wenn das Ergebnis der Anfrage eine Menge komplexer und interdependenter Informationen darstellt.
- Request/Confirm wird in Verträgen benutzt, bei denen der anfragende Partner eine Bestätigung anfordert, z.B. bezüglich früherer Vereinbarungen oder der Geschäftsbedingungen des antwortenden Partners.
- Information Distribution modelliert informelle Transaktionen für das Versenden von Informationen, die auch abgelehnt werden können.
- Notification - modelliert formelle Transaktionen für das Versenden von Informationen, die nicht zurückgewiesen werden können.

Für die Business Service View (BSV) sind Design Patterns für verschiedene Kombinationen von Agenten und Services definiert. Diese sind in einem Netzwerk für die Ausführung von Business Transactions und Business Collaborations konfiguriert und in UML Use Case Diagrammen, Klassendiagrammen und Sequenzdiagrammen dargestellt.

Beispiele für Patterns werden im folgenden Kapitel im Zusammenhang mit Business Transactions kurz erläutert. Weitere Details der UMM Patterns finden sich in [UMM01 Kap.9].

3 Geschäftsprozess-Modellierung in ebXML

3.1 Die Grundidee

Das allgegenwärtige TCP/IP und Internet machen es für viele Systeme leicht, mit ihrer Umwelt zu kommunizieren. Mittlerweile sind interaktive Systeme zur Norm geworden. Überraschenderweise wurden erst relativ spät Anstrengungen unternommen, diese verteilten interaktiven Systeme zu modellieren, so z.B. Ende der 80er Jahre durch Robin Milner [Miln89, Miln99]. In seiner Theorie der sogenannten π-Rechnung modelliert er laufende Kommunikationssysteme, insbesondere auch unter dem Aspekt der Mobilität, sowohl physikalisch als auch virtuell. Für ebXML kann diese Idee der Mobilität auf Statusveränderungen übertragen werden: Änderung der Geschäftspartner, des Dokumentenformats, Kapazitäten etc., also jede Veränderung einer bestehenden Beziehung zwischen zwei Unternehmen. Die Geschäftsprozess-Modellierung in ebXML liefert eine formale Beschreibung der Interaktionen zwischen zwei völlig voneinander getrennten Einheiten. Mit Hilfe von Nachrichten, die im Rahmen einer Kollaboration zwischen den Parteien ausgetauscht werden, sollen die Status der beiden Entitäten synchronisiert werden. [ChCh01 S.198]

Ein Unternehmen kann als riesiger, komplexer Automat betrachtet werden, dessen logischer Status aus riesigen Datenmengen, sein physischer Status aus Rohmaterialien, Gütern, Geld etc. besteht. Der Zugriff auf den Zustand des Automaten ist in dem Sinn begrenzt, dass dieser nur für das eigene Unternehmen zugänglich ist, das der Zustand beschreibt und zu dem er gehört. Für alle anderen aussenstehenden Unternehmen ist der interne Status verborgen.

Der Zustand dieses Automaten bzw. Unternehmens kann geändert werden, indem eine Aktion angestoßen wird, z.B. Auslieferung eines Auftrags oder Bezahlung eines Lieferanten. Will ein anderes Unternehmen diesen Zustand erfragen oder ändern, so geschieht dies durch eine Interaktion. Interaktionen stoßen in der Regel einige Aktionen innerhalb des Automaten an, die nach bestimmten Regeln ablaufen. Diese gegenseitige Beeinflussung erlaubt es letztlich dem Unternehmen, seinen eigenen Zustand mit dem eines Geschäftspartners zu synchronisieren. Dabei kennzeichnen Aktionen, sobald sie ausgeführt werden, den Übergang/die Transition von einem Zustand in einen anderen. Interaktionen und Aktionen bilden zusammengenommen die Geschäftsprozesse eines Unternehmens. Es können beliebig viele verschiedene, endliche Aktionen und Zustände in einem Unternehmen existieren. [ChCh01 S.198-199]

Formal besteht ein Automat aus:

- einer endlichen Menge Q von Zuständen, in denen sich der Automat befinden kann: Q = {q0, q1, ...}
- dem Startzustand q0
- einer endlichen Menge von Transitionen, die Aktionen a festlegen, mit denen der Automat von einem Zustand q in einen anderen q' wechselt. Für jedes Paar aus Zustand und Aktion (q, a) existiert maximal eine Transition in einen Folgezustand q'
- einer Menge von Endzuständen F ⊆ Q

Ein Automat kann als gerichteter Graph dargestellt werden, mit den Status (q0, q1, ...) als Kreise, Transitionen als Pfeile (a, b, c) und Endzuständen, die mit einem doppelten Kreis gekennzeichnet sind. Abbildung 3-1 zeigt ein Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: Übergangsgraph eines Automaten [ChCH01 S.199]

Dieses Modell kann um die Begriffe Ereignis und Bedingung erweitert werden, die als Voraussetzung einer Aktion erfüllt sein müssen. Aktionen können automatisch angestoßen werden, sobald ein Zustand q erreicht wird, gegebenenfalls unter Berücksichtigung von Bedingungen. Ebenso kann ein

Ereignis, auch in Kombination mit einer Bedingung, eine Aktion einleiten, die den Automaten in einen anderen Zustand q' überführt.

Ist die Anzahl der möglichen Zustände sehr groß, wird dieses Schaubild schnell unübersichtlich und deshalb häufig durch ein Aktivitätsdiagramm ersetzt, das den Automaten aus einer anderen Perspektive betrachtet. Es zeigt nicht die einzelnen Zustände, die ein Automat annehmen kann, sondern die kontrollierte Abfolge von Aktivitäten bzw. Aktionen, die innerhalb eines Unternehmens stattfinden können, also seine Geschäftsprozesse.

Dies gilt genauso bei Unternehmen im e-Business, die sich an B2B-Aktivitäten beteiligen. Die internen sequentiellen Prozesse laufen auch hier im Hintergrund ab. Diese Prozesse müssen interagieren, um gegenseitige Verpflichtungen, Transfer von Ressourcen und viele weitere Aspekte der gemeinsamen Aktivitäten abzubilden.

Aus diesem Grund werden die Aktionen eines Unternehmens in interne und extern sichtbare Aktionen unterteilt. Und genau hier wird die Verbindung zu ebXML geknüpft: EbXML und insbesondere die Spezifikation ebXML Business Process Specification Schema (BPSS) schaffen einen Rahmen, der die extern sichtbaren Aktionen, anfragende und antwortende Aktivitäten, für die beteiligten Geschäftspartner sichtbar darstellt.

Der Automat, bzw. das Unternehmen, wird als Black Box betrachtet. Ein Paar (b,

b) repräsentiert die komplementären Aktionen der beiden Automaten, die über einen gekennzeichneten Anschluss/Labelled Port eine Synchronisation ermöglichen. Ein Automat kann eine Vielzahl solcher Anschlüsse haben und ein Anschluss kann beliebig viele Verbindungen zu beliebig vielen Automaten herstellen.

In ebXML werden diese Synchronisationspunkte durch Responding und Requesting Business Activities dargestellt. Wurden diese abgeschlossen, ist der Zustand eines Unternehmens mit dem seines Geschäftspartners konsistent. Die Synchronisation kann wie in Abbildung 3-2 als eine gemeinsame Transition zwischen den beiden Zustandsübergangsdiagrammen dargestellt werden. [ChCh01 S.199-200]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-2: Synchronisation zweier Automaten [ChCh01 S.201]

Diese Idee gemeinsam benutzter Transitionen wurde bereits 1962 von Carl Adam Petri in seiner Dissertation "Kommunikation mit Automaten" eingeführt.

Derartige Graphen sind seitdem als Petri-Netze [http://www.daimi.au.dk/~petrinet/] bekannt.

Aus diesen theoretischen Modellen können einige Schlussfolgerungen gezogen werden:

1. Es ist nicht nötig, Prozesse bis ins Detail darzulegen, um ihre Interaktionen zu modellieren. Es genügt, sich auf die extern sichtbaren Aktionen zu konzentrieren. Diese Erkenntnis erleichtert die Einführung von ebXML in der Praxis, da viele Unternehmen ihre internen Abläufe als wertvolles Eigenkapital und Geschäftsgeheimnis betrachten und nur äußerst ungern preisgeben.
2. Interaktionen werden allein durch Aktionen der beiden nebenläufigen Automaten unterstützt. Insbesondere benötigen sie keinen dritten Automaten zur Handhabung ihrer Interaktionen, wie beispielsweise B2B-Marktplätze oder Broker. Es sei denn, dies ist absichtlich so gewollt.
3. Eine Menge von Informationssystemen kann als kommunizierender und mobiler Automat betrachtet werden. Innerhalb einer Firma können die Systeme zu einem einzigen logischen Automaten zusammengefasst werden. Über Unternehmensgrenzen hinweg ist dies nicht mehr möglich, ihre jeweiligen Zustände können jedoch durch gegenseitige Kommunikation synchronisiert werden.

[ChCh01 S.201]

3.2 Geschäftsprozesse

Ein Geschäftsprozess kann definiert werden als eine präzise definierte Folge von Aktivitäten, die ausgehend von einem Startzustand nacheinander durchgeführt werden, bis ein Endzustand erreicht wird. Nach der Ausführung einer neuen Aktivität befindet sich der gesamte Prozess in einem neuen Zustand. Bestimmte Regeln kontrollieren die Folge der Aktivitäten. [ChCh01 S.202] Der Begriff "Geschäftsprozess" ist wohl eines der meistbenutzten und meist überladenen Begriffe, wenn es um die Beschreibung einer Abfolge einzelner Schritte geht. Einige in der Literatur benutzte Einordnungen und Erklärungsansätze sind:

- Unternehmens-Geschäftsprozess/Enterprise Business Process (eBP): Ein eBP beschreibt die Schritte, die benötigt werden, um eine Aktivität auszuführen, ohne dass beteiligte Systeme und Systemgrenzen berücksichtigt werden. Durch ihre abstrakte Sichtweise kann ein eBP für eine unternehmensweite Modellierung, Vergleich oder Dokumentation von Entwürfen benutzt werden.
- Ausführbarer Geschäftsprozess/Executable Business Process (xBP): Dies ist ein eBP, der durch ein Business Process Management System (BPMS) kontrolliert wird. Ein xBP ist auf ein Unternehmen begrenzt, seine Ausführung ist genau wie ein eBP langfristig ausgelegt. Ein xBP besteht aus speziellen Interaktionen zwischen Nutzern, Systemen und Geschäftspartnern und verbindet diese.
- Aktivität eines Geschäftsprozesses/Business Process Activity (BPA): Eine BPA repräsentiert eine kurzzeitige Interaktion zwischen Benutzern oder Systemen. Eine Aktivität kann als einzelner Schritt eines ausführbaren Geschäftsprozesses betrachtet werden und bildet für sich genommen eine abgeschlossene Einheit.
- Arbeitsablauf/Workflow: Ein Workflow wird oft mit der automatischen Verarbeitung von Dokumenten assoziiert, wie bereits in Kap. 3.1.1.1 erwähnt. Hier weiß das verarbeitende System nichts über den Inhalt der Dokumente, sondern leitet sie lediglich an mehrere Personen weiter. Eine Integration der Systeme oder Partner findet i.d.R. nicht statt.

[ChCh01 S.202-203]

In Anlehnung an das UMM Metamodell beschreibt ein ebXML Business Process im Detail, wie Geschäftspartner Rollen, Beziehungen und Verantwortlichkeiten übernehmen, um eine Zusammenarbeit mit anderen zu ermöglichen. Die Interaktion zwischen den Rollen findet als zeitlich und sequentiell koordinierte Folge, als sogenannte Choreographie von Transaktionen, statt. Eine Business Transaction stellt den Austausch elektronischer Dokumente dar. Business Documents bestehen aus wieder verwendbaren Business Information Objects (BIOs). Der Business Process bestimmt unter Berücksichtigung von Übertragungs- und Sicherheitsaspekten die Reihenfolge des Informationsaustausches. Business Processes können aus mehreren wieder verwendbaren Kernprozessen zusammengesetzt werden, BIOs aus wieder verwendbaren Core Components. Generische Business Processes und BIOs sind in einer UMM Business Library abgelegt. [ebBPSS S.3]

Abbildung 3-3 zeigt eine stark vereinfachte Darstellung von ebXML Business Processes und eines beispielhaften Anwendungsfalls zwischen Geschäftspartnern.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-3: ebXML Business Process und Anwendungsfallbeispiel [bpOVER S.19]

Zusammenfassend bezeichnet ein ebXML Business Process also den Oberbegriff für Kollaborationen von Geschäftspartnern. Eine Business Collaboration beschreibt, wie zwei nebenläufige, ausführbare Geschäftsprozesse zweier Partner und alle ihre Elemente auf geschäftlicher Ebene interagieren.

Wie ebXML Prozesse modelliert werden, um eine reibungslose automatische Zusammenarbeit zweier System zu ermöglichen, beschreiben die folgenden Teilkapitel.

3.3 Das ebXML Business Process Specification Schema

Mit Geschäftsprozess-Modellen können einzelne Geschäftsprozesse abstrahiert werden, die miteinander operieren und eine Zusammenarbeit von Geschäftspartnern ermöglichen. Im e-Business werden diese Modelle auf Software-Komponenten übertragen, die im Namen der Geschäftspartner zusammenarbeiten. Das Ziel des ebXML Business Process Specification Schema (BPSS) ist es, die abstrakte Modellierung von Geschäftsprozessen mit der Spezifikation von Software-Komponenten im e-Business zu verbinden.

BPSS basiert insbesondere auf dem Metamodell der UN/CEFACT Modelling Methodology (UMM) und bildet daraus eine semantische Untermenge. Dieses Subset soll die direkte Definition von Elementen unterstützen, die benötigt werden, um ein System so zu konfigurieren, dass ebXML Transaktionen durchgeführt werden können. [ChCh01 S.157-158]

Mit UMM können Details eines spezifischen Geschäftsprozess-Szenarios auf konsistente Art und Weise festgehalten werden. Das Metamodell unterstützt eine Vielzahl von Geschäftsprozess-Aspekten und bietet eine umfassende Semantik. Auf dieser Semantik basiert die Spezifikation der Abbildungen, die zur Vereinfachung von Geschäftsprozess- und Informationsintegration und der Interoperabilität empfohlen werden. [bpTAREV S.6]

Die folgende Abbildung 3-4 veranschaulicht den Zusammenhang zwischen UMM und ebXML:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-4: Zusammenhang zwischen UMM und ebXML [ebBPSS S.4]

Mit der Methodik von UMM und dem Inhalt der UMM Business Library kann ein Benutzer ein umfassendes Geschäftsprozess- und Informationsmodell erstellen, das dem UMM Metamodell entspricht. Da das ebXML BPSS eine semantische Untermenge des UMM Metamodells darstellt, können dann automatisch aus dem Geschäftsprozess- und Informationsmodell die benötigten Elemente und Beziehungen extrahiert und zu einer ebXML BPSS-konformen Geschäftsprozess- Spezifikation transformiert werden. Ähnlich ist auch das Metamodell der ebXML Core Components auf das UMM Metamodell ausgerichtet: Der Benutzer kann auf gleiche Weise Elemente und Beziehungen extrahieren und sie gemäß den ebXML Core Component Spezifikationen in ein ebXML Dokumentenmodell umwandeln. Die Definition eines ebXML Dokuments wird durch die Kombination von BPSS und Core Components festgelegt. [ebBPSS S.4-5]

Damit stellt BPSS alle Semantik, Elemente und Eigenschaften bereit, die zur Spezifikation einer Kollaboration zwischen Geschäftspartnern nötig sind, außerdem Parameter für die Konfiguration der Systeme, so dass die Zusammenarbeit zwischen mehreren e-Business Software-Komponenten durchgeführt werden kann. Eine Kollaboration wird mit Hilfe von Business Partner Roles umgesetzt, die in bestimmten koordinierten Transaktionen durch den Austausch von Business Messages zusammenarbeiten. BPSS spezifiziert alle Nachrichten, die zwischen Partnerrollen ausgetauscht werden sowie, deren Inhalt und Timing. [ebBPSS S.2, S.10]

EbXML BPSS ist derzeit der einzige Teil des UMM Metamodells, der für die Spezifikation ebXML-konformer Software obligatorisch ist. [bpTAREV S.6] Vorherrschende Schlüsselkonzepte von BPSS sind Wiederverwendung, Rekursion und Vorlagemuster. [ebBPSS S.13] Ein weiterer Schlüsselaspekt von ebXML besteht darin, die Choreographie der Aktivitäten von den formalen Definitionen geschäftlicher Dokumente zu entkoppeln. [ChCh01 S.195]

Das Besondere ist, dass ebXML BPSS unabhängig von ebXML verwendet werden könnte, um Geschäftsprozesse formal so zu erfassen und kommunizieren, dass sie eindeutig von den eingebundenen Parteien verstanden werden können und als maschinenlesbare Spezifikation eines Protokolls zum Austausch von Nachrichten und Signalen dient. Systeme und Anwendungen können automatisch mit Hilfe einer BPSS Instanz konfiguriert werden und so eine spezielle Kollaboration automatisch durchführen. Bislang gab es keinen formalen Rahmen, der diesen direkten Übergang von der Modellierung zur Durchführung erreichte. EbXML BPSS ist die erste derartige Spezifikation, die bei einer ebXML Implementierung direkt zur Konfiguration einer B2B-Infrastruktur benutzt werden kann. Sie ist damit auch ein Beispiel für die allgemein im Software Engineering stattfindende Bewegung, eher deklarative als prozedurale Systeme zu errichten. [ChCh01 S.157, 175]

BPSS wurde als einzige ebXML Spezifikation in zwei eigenständigen, klar miteinander verbundenen Versionen beschrieben, in UML und XML. Die UML Version besteht lediglich aus UML Klassendiagrammen und stellt die Verbindung zur UMM her. Sie ist nicht für die direkte Erzeugung von ebXML BPSS Instanzen bestimmt, sondern bildet eine in sich geschlossene Erklärung aller Elemente und Beziehungen, die für eine ebXML-konforme Geschäftsprozess- Spezifikation benötigt werden. Alle Methodiken und/oder Metamodelle, die für die Erzeugung solcher Spezifikationen benutzt werden, müssen mindestens diese Elemente und Beziehungen unterstützen. Die XML Version spezifiziert dagegen Instanzen des ebXML BPSS in XML und soll von ebXML-unterstützender Software unmittelbar interpretiert werden können. [ebBPSS S.2] Software für die Ausführung von Kollaborationen allgemein und auch für ebXML Business Collaborations wird als Business Service Interface (BSI) bezeichnet. Das BPSS spezifiziert die prozessbezogenen Parameter, die zur Konfiguration eines BSI benötigt werden. [ebBPSS S.14]

3.3.1 BPSS Systemüberblick

Die technische Spezifikation ebXML BPSS liefert eine konsistente Modellierungsmethode für Geschäftsprozesse und definiert Semantik, Elemente und Eigenschaften, die für die Definition von Business Transactions und ihre Anordnung zu Business Collaborations nötig sind. Kollaborationen bestehen aus einer Menge von Rollen, die über koordinierte Transaktionen durch den Austausch von Business Dokuments zusammenarbeiten. [ebBPSS S.14]

Eine Instanz des BPSS definiert eine Sicht auf die Nachrichten, die zwischen zwei oder mehreren Partnerrollen ausgetauscht werden, um eine Business Activity durchzuführen, beispielsweise zwischen mehreren Partnern bei komplexen Vorgängen oder zwischen zwei Parteien, wie etwa beim Abschluss einer Versicherung. Die Instanz umfasst im Wesentlichen die maschinenlesbare XML Spezifikation der Business Collaborations, die ein ebXML Business Service Interface benötigt.

Die Architektur des ebXML BPSS besteht aus den folgenden funktionalen Komponenten, die es zusammen ermöglichen, alle Laufzeitaspekte eines Geschäftsprozessmodells zu definieren:

- UML Version des BPSS in Form von UML Klassendiagrammen.
- XML Version des BPSS in Form von DTDs und Schemata.
- Produktionsregeln/Production Rules, die die Abbildung der UML Klassendiagramme auf XML DTDs definieren.
- Definitionen von Business Signals, die den aktuellen Status einer Transaktion signalisieren.

Abbildung 3-5 zeigt eine Übersicht der Komponenten und ihrer Zusammenhänge.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-5: Komponenten des ebXML BPSS und ihre Beziehung zu UMM, CPP/CPA und Core Components [ebBPSS S.7]

Ein Benutzer extrahiert und transformiert die von ihm benötigten Informationen aus einem bestehenden Geschäftsprozess- und Informationsmodell. Damit verbundene Produktionsregeln können dabei helfen, eine XML Version der Geschäftsprozess-Spezifikation zu erstellen. Alternativ kann die XML Version direkt mit einem XML Tool erzeugt werden, und Produktionsregeln können die Transformation in ein XML Metadata Interchange (XMI)-Format [http://www.omg.org/technology/documents/formal/xmi.htm] unterstützen, so dass bei Bedarf eine UML Version erzeugt werden könnte. [ebBPSS S.15]

Das XML Dokument beschreibt die Kollaboration zweier Geschäftspartner, die als Rollen miteinander im Rahmen von Business Transactions agieren. Jede Transaktion besteht aus vordefinierten Nachrichten und kann zusätzlich von Business Signals unterstützt werden. [ebBPSS S.11]

Eine Transaktion kann mit Hilfe eines der zahlreichen UMM Standardmuster/Patterns implementiert werden. Diese Muster legen den Austausch von Geschäftsdokumenten und Signalen zwischen Geschäftspartnern fest, damit die gewünschte elektronische Transaktion durchgeführt werden kann. UMM bietet eine Auswahl von Standard Patterns und das ebXML BPSS eine Reihe von Modellierungselementen, um diese Muster festzulegen. [bpTAREV S.7]

Die Spezifikation der Geschäftsprozesse in XML dient als wichtigster Input für die Bildung eines Collaboration-Protocol Profile (CPP) und Collaboration- Protocol Agreements (CPA). Das CPP definiert, welche Rollen und Geschäftsprozesse von einem ebXML Partner unterstützt werden. Das CPA, das eine konkrete Geschäftsbeziehung beschreibt, wird um technische Parameter erweitert und ergibt die Konfiguration einer lauffähigen ebXML Implementierung. CPP und CPA stellen eine direkte Verbindung zwischen der Geschäftsprozess-Modellierung und der Spezifikation ebXML-konformer Software im e-Business dar. Sie dienen der direkten Konfiguration des ebXML Business Service Interface. [ebBPSS S. 5-6, 9-10]

Nur ein XML Dokument, das BPSS-konform als Prozess-Spezifikation erzeugt wurde, ist die einzige offiziell gültige Dokumentation der Prozess-Spezifikation oder der Geschäftstransaktion, die als Definition zur Festlegung von Vereinbarungen zwischen Parteien benutzt werden kann. [ChCh01 S.159]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-6: Zusammenhang des BPSS mit anderen ebXML Komponenten [ebBPSS S.15]

Wie aus Abbildung 3-6 hervorgeht, werden Business Documents aus der Kombination der gemeinsamen Elemente von ebXML BPSS und ebXML Core Components erstellt. Die Zusammensetzung eines Business Document basiert auf dem Kontext, der meist durch die Geschäftsprozesse vorgegeben ist, die das Dokument benutzen. Die Spezifikation eines Business Process verweist auf die

Definition der von ihm benötigten Dokumente, aber definiert sie nicht selbst. [ebBPSS S.14] Dokumente, die verschickt werden, können XML-basiert sein, als beliebig oder gar nicht strukturierte Daten angehängt werden, und/oder auf dem Metamodell der ebXML Core Component -Spezifikationen (vgl. Kapitel 5.2) aufsetzen. [ebBPSS S.10]

In jedem Fall wird die XML Version einer Geschäftsprozess-Spezifikation im ebXML Repository gespeichert und im ebXML Registry für zukünftige Zugriffe mit klassifizierenden Schlüsseln verwaltet, die während der Entwurfsphase abgeleitet wurden. Die Kombination aus Geschäftsprozess-Spezifikation und Dokumenten zweier Geschäftspartner wird zur Grundlage für die Vereinbarungen, mit denen sie e-Business betreiben können. Zur Implementierung von CPP oder CPA werden die XML Dokumente oder ihre relevanten Bestandteile einfach in das CPP und CPA eingebettet oder es wird auf sie verwiesen. CPP und CPA Dokumente können nur XML Versionen der ebXML Geschäftsprozess- Spezifikationen referenzieren. Unter der Anleitung von CPP und CPA werden die XML Dokumente zu Konfigurationsdateien eines oder mehrerer Business Service Interfaces, also der Software, die eine Kollaboration tatsächlich handhabt. [ebBPSS S.14-15]

BPSS Instanzen können zu verschiedenen Konstrukten kombiniert werden:

- Business Transactions definieren ein Protokoll der zwischen den Partnern ausgetauschten Business Documents.
- Binary Collaborations beschreiben eine Zusammenstellung von Business Transactions unter Berücksichtigung des zeitlichen Ablaufs und ihrer Reihenfolge.
- Multiparty Collaborations bestehen aus mehreren Binary Collaborations.

[ChCh01 S.158]

Die Definition einer Kollaboration kann als Bestandteil eines Vertrags zwischen den beteiligten Parteien angesehen werden, nicht aber als der eigentliche Vertrag selbst. Die Inhalte der Nachrichten, die zwischen den Parteien ausgetauscht werden, können zwar speziellen Vereinbarungen über den Austausch von Ressourcen entsprechen, sind aber selbst nicht Inhalt der Spezifikation. Genau wie bei einem herkömmlichen Vertrag sind die internen Zusammenhänge und die Art und Weise, wie Vereinbarungen in Organisationen umgesetzt sind, nach außen verborgen und spielen meist für den eigentlichen Vertrag keine Rolle. [ChCh01 S.159]

Da die Entstehung von Verträgen in ebXML derzeit nicht explizit behandelt wird, könnte dies ein Aspekt zukünftiger Erweiterungen der ebXML Spezifikationen sein. Die ebXML Beschreibung "ebXML E-Commerce Patterns v1.0" [bpPATT] liefert einige gute Ansätze dafür.

EbXML BPSS spezifiziert keine eigene Notation zur Darstellung der Elemente einer Prozess-Spezifikation. Sie baut vielmehr auf den Vorgaben der UMM für Business Transactions, Binary Collaborations und Multiparty Collaborations auf. Die folgenden Kapitel beschreiben die verschiedenen Konstrukte des ebXML BPSS, ihre Beziehung zueinander und wie sie zu einer vollständigen Multiparty Collaboration zusammengesetzt werden. Das hierfür verwendete Vorgehen ist aus Gründen der besseren Verständlichkeit "bottom up", also von der Transaktion hin zur Kollaboration. EbXML BPSS empfiehlt eine "top down" Vorgehensweise, um dabei möglichst viele "lower level" Inhalte wiederzuverwenden.

Im Folgenden werden diese Konstrukte behandelt:

1. Spezifikation einer Business Transaction, mit Business Signals und zugehörigen Nachrichten.
2. Spezifikation einer Binary Collaboration unter Verwendung der Business Transaction.
3. Spezifikation einer Multiparty Collaboration unter Verwendung von Binary Collaborations.
4. Spezifikation einer Choreographie für Binary und Multiparty Collaborations.

Diese Spezifikationen können für die Definition sehr komplexer Multiparty Collaborations verwendet werden. Dennoch würde auch schon eine einfache Kollaboration zwischen zwei Partnern, die aus einer einzigen Transaktion besteht, eine ebXML-konforme Spezifikation von Geschäftsprozessen darstellen. Komplexe Binary Collaborations, Multiparty Collaborations und Choreographies sind für eine Übereinstimmung mit ebXML BPSS folglich nicht erforderlich. [ebBPSS S.16]

3.3.2 Business Transactions

Transaktionen sind die kleinste Arbeitseinheit in Geschäftsbeziehungen, entsprechend bilden Business Transactions den Kern der ebXML BPSS Spezifikation.

Alle ausgetauschten Nachrichten sind als Elemente einer Business Transaction definiert, so dass diese als ein Protokoll der übertragenen Nachrichten angesehen werden kann. Eine Business Transaction kann nicht weiter in unabhängige Teile zerlegt werden. Sie wird stets zwischen zwei Partnern durchgeführt, die gegensätzliche Rollen einnehmen, Requesting und Responding Role. [ebBPSS S.35]

Eine Business Transaction ist immer entweder erfolgreich oder schlägt aus verschiedenen Gründen fehl. Ist sie erfolgreich, kann sie als rechtsverbindlich zwischen den beiden Parteien bezeichnet werden oder auf andere Art ihre gemeinsamen Aktivitäten bestimmen. Schlägt sie fehl, sind alle Aktionen, die mit ihr in Verbindung stehen, null und void, und die beteiligten Parteien müssen auf alle gegenseitigen Ansprüche verzichten, die auf der Transaktion beruhen. Die jeweiligen Systeme müssen dann auf den Zustand vor Beginn der Transaktion zurückgesetzt werden, ein "rolling back" der Transaktion muss stattfinden. [ChCh01 S.159]

Wie das UML Klassendiagramm einer Transaktion in der folgenden Abbildung 3-7 zeigt, besteht eine Business Transaction aus einer Requesting Business Activity, einer Responding Business Activity und einer oder mehreren Nachrichten, die zwischen ihnen übermittelt werden. Die abstrakte Superklasse Business Action beinhaltet die gemeinsamen Attribute der Requesting und Responding Business Activities.

Die Begriffe Requesting und Responding Business Activity beziehen sich nicht auf eine physische Einheit wie eine Nachricht oder ein Dokument. Sie beschreiben vielmehr den Zustand, in dem eine Partei gerade eine Anfrage sendet, auf Antwort wartet, den möglichen Erfolg der Transaktion berechnet oder gerade eine Antwort sendet. Implizit gibt es eine Requesting und Responding Role, die eine Requesting oder Responding Activity durchführen, sie werden jedoch erst explizit, wenn die Transaktion in einer Business Transaction Activity innerhalb einer Binary Collaboration genutzt wird. [ebBPSS S.17-18]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-7: UML Klassendiagramm einer Business Transaction [ebBPSS S.17]

Durch die Zuweisung der Rollen durch eine Instanz der Business Transaction, einer Business Transaction Activity, erst zum Zeitpunkt einer konkreten Verwendung der Transaktion in einer Binary Collaboration wird eine höhere Flexibilität in der Verwendung der Transaktionsdefinition ermöglicht. Eine Business Transaction Activity beschreibt den aktuellen Zustand einer Transaktion und bezieht sich auf die Definition genau einer Business Transaction. Eine Transaktionsdefinition kann von mehreren Business Transaction Activities verwendet werden. Sie legt ein sehr spezialisiertes und klar abgegrenztes Protokoll von Interaktionen zwischen zwei Rollen fest und kann den Bedeutungsinhalt einer Transaktion so präzise formulieren, dass diese vom Business Service Interface eindeutig umgesetzt werden kann. [ebBPSS S.12] Dieses Hinzufügen wichtiger Bedeutungsinhalte zu der reinen Nachrichtenübertragung von A nach B unterscheidet ebXML von anderen Ansätzen, die den Austausch von Nachrichten lediglich als Erweiterung des Middleware-Konzepts betrachten. [ChCh01 S.159]

Eine Business Transaction legt exakt fest, wann die Requesting Activity bzw. Responding Activity die Kontrolle über die Transaktion innehat und wann die Kontrolle von einer auf die andere Aktivität übergeht. Eine Transaktion startet immer mit einer Request Message der Requesting Activity, geht dann meist zur Responding Activity über und wieder zurück zur Requesting Activity. [ebBPSS S.35] Ob eine Response Message benötigt wird, hängt von der Definition der Business Transaction ab. Beispielsweise werden für Vertragsgestaltungen oder sonstige Vereinbarungen Anfrage- und Antwortnachricht benötigt, während andere Transaktionen als Notiz dienen und keine Antwort verlangen. Eine Message besteht aus einem oder mehreren Business Documents und wird auch als Business Dokument Flow bezeichnet. Die Request Message ist im XML Dokument Teil des <RequestingBusinessActivity>-Elements, die möglichen Antworten sind Teil des <RespondingBusinessActivity>- Elements. [ebBPSS S.17-18]

Die Business Documents, die im Rahmen einer Business Transaction ausgetauscht werden, können separat definiert und von mehreren Business Transactions benutzt werden. Die Inhalte der Dokumente werden nicht von BPSS spezifiziert, sondern mit Hilfe der ebXML Core Components, anderer XML DTDs oder Schemata einer BPSS Instanz festgelegt. [ChCh01 S.159-160]

Der folgende Ausschnitt eines XML Dokuments zeigt eine Transaktion, die nur aus einer Anfrage besteht:

Abbildung in dieser Leseprobe nicht enthalten

Quelle: [ebBPSS S.18]

Das ebXML BPSS bietet eine Reihe eindeutiger Semantiken, mit denen Transaktionen und Kollaborationen definiert werden können. In diesem Rahmen kann der Benutzer beliebig viele spezielle Transaktionen und Kollaborationen erstellen. Vordefinierte Patterns kombinieren diese mögliche Flexibilität mit einer Einheitlichkeit, die Entwurf und Implementierung deutlich beschleunigen und eine generische Verarbeitung ermöglichen. UMM definiert einige Patterns als Vorlagen für die Definition von Business Transactions, z.B. Request/Response, Request/Confirm, wie bereits in Kapitel 2.6.4 erwähnt. Sie geben je nach Transaktionstyp einen geeigneten Zeitrahmen und verschiedene Kombinationen von Nachrichten, ihrer Attribute und Signale vor, die über den Erfolg einer Transaktion entscheiden. Alle dort empfohlenen Sicherheits- und Zeitparameter werden von BPSS als Elementattribute übernommen. Es wird erwartet, dass zukünftig weitere Patterns für Choreographien entwickelt werden. [ebBPSS S.13] Die Definition einer Business Transaction kann auch als UML Aktivitätsdiagramm mit den verschiedenen Rollen als Schwimmbahnen/Swimlanes dargestellt werden. Die an einer Business Transaction beteiligten Rollen sind allgemein festgelegt, die Verwendung der Transaktionen als Business Transaction Activity definiert den spezifischen Fluss der Dokumente zwischen den Rollen. Document Envelopes, die die zu übertragenden Nachrichten umhüllen, werden durch UML Objekte repräsentiert, die von/zu einer allgemeinen Requesting bzw. Responding Activity fließen. [ChCh01 S.173]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-8: UMM Business Transaction Pattern - Request/Response [UMM01 Kap.9 S.16]

Abbildung 3-8 zeigt das UMM Business Transaction Pattern für die Aktivität Request/Response, modelliert als UML Aktivitätsdiagramm. Analog sind die Patterns Query/Response und Request/Confirm beschrieben, bei Information Distribution und Notification entfällt das DocumentResponse-Objekt.

In den folgenden Teilabschnitten wird zunächst ausführlich auf weitere Elemente und die Semantik von Business Transactions eingegangen, bevor mit der Modellierung von Binary und Multiparty Collaborations fortgefahren wird.

3.3.2.1 Business Signals

UMM Patterns legen auch fest, ob mit einer Message/ Document Flow zusätzlich ein oder mehrere Business Signals verbunden sind, die den Document Flow quittieren. Sie sind einfache Signale und enthalten keine Daten, die von der aktuellen Business Transaction benötigt werden. Ihre Struktur ist universell und ändert sich nicht von Transaktion zu Transaktion. Solche Quittierungsnachrichten werden nicht explizit modelliert, vielmehr legen Parameter der Transaktion fest, ob die Business Signals erforderlich sind oder nicht. [ebBPSS S.17]

Abbildung 3-9 zeigt die möglichen Nachrichtenflüsse und Signale einer Business Transaction.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-9: Document Flows und Business Signals einer Transaktion und ihre Reihenfolge [ebBPSS S.19]

Eine Transaktion startet immer mit einer Request Message der Requesting Activity und übergibt damit die Kontrolle über die Transaktion an die Responding Role. Nach dem Erhalt der Request Message sendet die Responding Acivity gegebenenfalls ein ReceiptAcknowledgement Signal und/oder danach ein AcceptanceAcknowledgement Signal an die Requesting Role zurück. Wurde anschließend auch die angeforderte Response Message an die Requesting Role übermittelt, erhält diese wieder die Kontrolle über die Transaktion, sobald die letzte dieser Nachrichten eingetroffen ist. Ein eventuell angefordertes ReceiptAcknowledgement Signal ist ausschließlich ein Signal und beläßt die Kontrolle bei der Requesting Activity. Es hat keinen Einfluß auf den Erfolg oder Fehler einer Transaktion. [ebBPSS S.36]

Diese Quittierungssignale/ Business Signals sind Dokumente auf Anwendungsebene, die den aktuellen Stand einer Business Transaction signalisieren. Ob z.B. ein ReceiptAcknowledgement und/oder AcceptanceAcknowledgement Signal benötigt wird, ist in dem jeweils für die Transaktion vorgegebenen Pattern festgelegt. Diese und weitere mögliche Parameter werden mit einer geeigneten Zeitdauer versehen, innerhalb der die Business Signals zurückgemeldet werden müssen. [ebBPSS S.37] Business Signals unterstützen Verarbeitung und Verwaltung von Dokumenten und Document Envelopes, noch bevor Business Rules, also allgemeine Verarbeitungsbedingungen, auf den Inhalt der Dokumente angewendet werden. Sie sind von Protokoll- und Transportsignalen unterer Ebenen getrennt. Das ReceiptAcknowledgement Signal zeigt an, dass eine Nachricht fehlerfrei empfangen wurde. Ist der Parameter isIntelligibleCheckRequired gesetzt, wird eine Nachricht nur dann mit einem ReceiptAcknowledgement bestätigt, wenn sie lesbar ist, das heißt einen Struktur- bzw. Schemagültigkeitstest bestanden hat. Sowohl der fehlerfreie Empfang als auch die Lesbarkeit einer Nachricht werden überprüft und gegebenenfalls bestätigt, noch bevor Business Rules angewendet werden oder die Bedingungen oder Ausdrücke der Business Documents oder Document Envelopes ausgewertet werden.

Das AcceptanceAcknowledgement Signal signalisiert die Annahme der empfangenen Message für die weitere Verarbeitung. Dies ist der Fall, wenn der Inhalt der in der Nachricht übermittelten Business Documents die gegebenen Business Rules einhält. [ebBPSS S.19-20] Ein positives Signal ist nicht gleichbedeutend mit der positiven Antwort auf eine Anfrage, z.B. der Annahme eines Vertragsangebot, sondern zeigt nur, dass der Vertragsgegenstand den Geschäftsbedingungen des Vertragspartners entspricht.

Abbildung 3-10 veranschaulicht in einem UML Sequenzdiagramm die Reihenfolge der Nachrichten und Signale zwischen Sender und Empfänger:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-10: UML Sequenzdiagramm eines Nachrichtentransfers [ChCh01 S.165]

Die Signale werden angefordert, indem den Business Activities mit den Parametern timeToAcknowledgeReceipt oder timeToAcknowledgeAcceptance ein Zeitlimit gesetzt wurde. Kann aufgrund von Fehlern eines der angeforderten Signale in der festgelegten Zeit nicht gesendet werden, kann der in der Business Transaction Activity festgelegte Parameter timeToPerform nicht eingehalten werden, wird die Transaktion null und void und kann nicht erfolgreich abgeschlossen werden. [ebBPSS S.20] Das Attribut timeToPerform wird bei der Business Transaction Activity gesetzt und nicht bei der Definition einer Business Transaction selbst - dies geschieht aus den ähnlichen Flexibilitätsgründen wie bei der Zuweisung der Requesting und Responding Roles zum selben Zeitpunkt. Die gleiche Business Transaction kann in unterschiedlichen Zusammenhängen mit leicht unterschiedlicher Zeitdauer benutzt werden. Die zeitlichen Parameterwerte sollten etwa im Stundenbereich gesetzt werden, damit ein System nicht aufgrund eventueller Überlastungen Ausnahmemeldungen erzeugt. Signale können innerhalb von Sekunden zurückgesendet werden. [ChCh01 S.164-165]

Tabellen 3-1 und 3-2 zeigen die Parameterwerte, die UMM für die Eigenschaften der Business Transaction Activites der einzelnen Business Transaction Patterns vorschlägt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-1: UMM Vorgabewerte der Requesting Business Activities [UMM01 Kap.9 S.19]

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-2: UMM Vorgabewerte der Responding Business Activities [UMM01 Kap.9 S.19]

[...]

Ende der Leseprobe aus 272 Seiten

Details

Titel
ebXML. Kritische Darstellung eines Standards zur Unterstützung von e-Business-Prozessen
Hochschule
Johann Wolfgang Goethe-Universität Frankfurt am Main
Note
1
Autor
Jahr
2002
Seiten
272
Katalognummer
V185815
ISBN (eBook)
9783656990703
ISBN (Buch)
9783867466950
Dateigröße
3659 KB
Sprache
Deutsch
Schlagworte
kritische, darstellung, standards, unterstützung
Arbeit zitieren
Carmen Hackländer (Autor:in), 2002, ebXML. Kritische Darstellung eines Standards zur Unterstützung von e-Business-Prozessen, München, GRIN Verlag, https://www.grin.com/document/185815

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: ebXML. Kritische Darstellung eines Standards zur Unterstützung von e-Business-Prozessen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden