Aufgrund der starken Zunahme internetbasierter E-BusinessAktivitäten werden Sprachen für die Modellierung von E-Business-Prozessen immer wichtiger. Ziel der Modellierung ist die formale Darstellung der organisationsübergreifenden Prozesse und aller prozeßrelevanten Objekte. Zur integrierten Modellierung von E-Business-Prozessen und den prozeßrelevanten Dokumenten wird daher eine neue Variante höherer Petri-Netze, die sogenannten XML-Netze, vorgeschlagen. XML-Netze sind eine formale, graphische Beschreibungssprache, die einerseits die Modellierung des XMLDokumentenflusses und andererseits die Modellierung des Kontrollflusses des zugrundeliegenden Geschäftsprozesses ermöglicht. XML-Netze basieren auf dem XML-Schema-Modell, einer neuen graphischen Beschreibungssprache für XML-Schemata, und der an das XML-Schema-Modell angelehnten graphischen Dokumentenmanipulationssprache XManiLa. Operationen auf XML-Dokumenten werden durch sogenannte Filterschemata beschrieben. XML-Netze können zunächst für den Entwurf der E-Business-Prozesse verwendet werden. Es können sowohl bestehende E-Business-Prozesse als auch Prozeßvarianten abgebildet und hinsichtlich struktureller Abweichungen untersucht werden. Aufgrund ihrer formalen Definition erlauben XML-Netze eine simulative Validierung der abgebildeten E-Business-Prozesse und können durch eine entsprechende Workflow-Engine direkt ausgeführt werden.
Aufgrund der starken Zunahme internetbasierter E-Business-Aktivitäten werden Sprachen für die Modellierung von E-Business-Prozessen immer wichtiger. Bei der Modellierung sollen die realen E-Business-Prozesse in einer für den Anwender verständlichen, aber –im Gegensatz zur natürlichsprachlichen Beschreibung– unmißverständlichen Notation, abgebildet werden. Ziel der Modellierung ist die formale Darstellung der organisationsübergreifenden Prozesse und aller prozeßrelevanten Objekte. Die formalen Prozeßbeschreibungen bilden die Basis für eine systematische Analyse, die Simulation und die Ablaufunterstützung der Prozesse. Bei der Ausführung der Prozesse müssen E-Business-Objekte auf elektronischem Wege zwischen den am Prozeß beteiligten Unternehmen ausgetauscht werden [Mer99]. Die prozeßrelevanten E-Business-Objekte können einfach strukturierte Objekte sein, bei denen es sich meist um Massendaten handelt, die unternehmensintern für die Durchführung des Prozesses benötigt werden und die üblicherweise in relationalen Dankenbanken verwaltet werden, beispielsweise Kundennummern oder die Stückzahlen von gelagerten Produkten. Komplex strukturierte Objekte wie Bestellungen, Rechnungen oder auch Personalakten sind u.a. Dokumente, die zwischen den Unternehmen oder den Prozeßbeteiligten eines Unternehmens ausgetauscht und bei der Durchführung des Prozesses gelesen oder bearbeitet werden. Die entsprechenden elektronischen Dokumente können mit Hilfe der Auszeichnungssprache Extensible Markup Language (XML) [HaM01, Ray01] strukturiert werden. Der XML-Standard [W3C00] bildet dabei die Basistechnologie für verschiedene Sprachen, beispielsweise XML Schema zur Beschreibung von Dokumentenklassen [W3C01a]. Aus prozeßorientierter Sicht sind die Modellierung, die Analyse, die (Um-)Gestaltung und die automatisierte Ausführung der Prozesse von Bedeutung [Jab00, Obe96]. Petri-Netze [ReR98] sind eine Beschreibungssprache für Abläufe, welche die Vorteile einer graphischen Darstellung und einer formalen Semantik vereint. Für eine Menge konkreter Abläufe können Ablaufschemata durch PetriNetze in einer für den Anwender verständlichen Form dargestellt werden [DeO96]. Dabei unterschieden sich die einzelnen höheren Petri-Netz-Typen [EHP02] in der Interpretation der ablaufrelevanten Daten. Prädikate/Transition-Netze [Gen86], bei denen die prozeßrelevanten Objekte als Relationen einer Datenbank interpretiert werden können, haben sich bereits bei dem Entwurf von Informationssystemen bewährt. Sie sind jedoch für die Beschreibung von Prozessen basierend auf XMLDokumenten wenig geeignet.
Zur integrierten Modellierung von E-Business-Prozessen und den prozeßrelevanten Dokumenten wird daher eine neue Variante höherer Petri-Netze, die sogenannten XML-Netze [LeO02], vorgeschlagen. Die Definition der XML-Netze erfordert eine formale graphische Beschreibungssprache für die prozeßrelevanten Dokumente, mit deren Hilfe die Struktur der Dokumente und Wertebereiche für deren Inhalt durch ein Schema vorgegeben werden können. Darüber hinaus werden die durchzuführenden Aktivitäten auf den entsprechenden XML-Dokumenten ebenfalls graphisch in einer ähnlichen Notation dargestellt. Um die verteilte Ausführung der Prozesse zu unterstützen, können die Ablaufmodelle in einzelne Prozeßteile, die Prozeßfragmente, zerlegt werden.
XML-Netze können mit unterschiedlichen Zielsetzungen zur Unterstützung von E-Business-Prozessen verwendet werden: Sie können zunächst für den Entwurf der Prozesse eingesetzt werden. Darüber hinaus kann das Verhalten der XML-Netze simuliert werden. Durch Analyse und Simulation der XML-Netze kann auch die Verbesserung der E-Business-Prozesse unterstützt werden. XML-Netze können sowohl bestehende E-Business-Prozesse als auch Prozeßvarianten abbilden und hinsichtlich struktureller Abweichungen untersucht werden.
Der Beitrag ist folgendermaßen gegliedert: Zunächst wird das XML-SchemaModell, eine Beschreibungssprache für Schemata für XML-Dokumente, vorgestellt. Danach wird die auf dem XML-Schema-Modell basierende Dokumentenmanipulationssprache XManiLa erläutert. Dazu werden Filterschemata eingeführt, welche als eine Art "Schablone" für die Anfrage-relevanten XML-Dokumente dienen. In Kapitel 4 werden XML-Netze an einem Beispiel erläutert.
Für die konzeptuelle Modellierung der E-Business-Prozesse ist es zunächst wichtig, die prozeßrelevanten Objekte zu modellieren. Für die relevanten Daten werden Methoden der konzeptuellen Datenmodellierung wie das Entity/Relationship-Modell (E/R-Modell) [Che76] verwendet. Die Modellierung komplexer Objekte, beispielsweise von XML-Dokumenten, wird bislang nicht ausreichend durch graphische Methoden unterstützt. 2.1
Die XML Schema-Spezifikation [W3C01a] ist sehr komplex und besitzt keine graphische Notation. Die konzeptuelle Modellierung von XML-Schemata dient dazu, Sachverhalte der Realwelt auf einem hohen Abstraktionsniveau abzubilden und damit die Schemata möglichst unabhängig von der Implementierung zu entwerfen. Ziele bei der Entwicklung einer Beschreibungssprache für den konzeptuellen Entwurf von XMLSchemata sind, ein formale Definition für XML-Schemata, welche die Menge aller zulässigen Modellierungskonstrukte und deren Beziehungen vorgibt, aufzustellen, eine graphische Darstellung für alle Modellierungskonstrukte anzubieten, die den Bedürfnissen des Modellierers entsprechend angepaßt werden kann, den stufenweisen Entwurf der Schemata durch Schematransformationen zu unterstützen und dabei auf bekannte Modellierungskonzepte zurückzugreifen, um erfahrenen Modellieren eine leicht erlernbare Beschreibungssprache zu Verfügung zu stellen und somit die Akzeptanz der Beschreibungssprache zu erhöhen.
Als Grundlage der Definition des XML-Schema-Modells (XSM) wurden die Klassendiagramme der UML (siehe beispielsweise [BRJ99]) gewählt. Verwandte Ansätze zur Modellierung von XML-Schemata sind in [BCF99, CSF00, MLM01, MeH01] zu finden. 2.2
XML-Schemata für eine Klasse von XML-Dokumenten mit ähnlicher Struktur können mit Hilfe des XML-Schema-Modells entworfen und durch Diagramme, die sogenannten XML-Schema-Diagramme (XSD), graphisch dargestellt werden. Nachfolgend werden die einzelnen Konstrukte des XML-Schema-Modells vorgestellt. Auf die formale Definition wird dabei jedoch aus Platzgründen verzichtet.
Alle Elemente mit gleichen Eigenschaften, d.h. mit ähnlicher Struktur, werden zu einem Elementtypen zusammengefaßt. Jedem Elementtypen werden ein (eindeutiger) Name, eine Menge von Attributen und ein Datentyp, der mögliche Inhalte der Elemente beschreibt, zugeordnet. Elementtypen, die keinen Inhalt besitzen, werden als leere Elementtypen bezeichnet. Den Attributen eines Elementtyps wird ebenfalls jeweils ein Datentyp zugeordnet, der den Wertebereich des Attributs bestimmt. Graphisch werden Elementtypen durch UML-Klassen repräsentiert, in denen auch die Attribute angegeben werden können.
Assoziationen beschreiben die Beziehungen zwischen den Elementen. Gleiche Assoziationen, d.h. Assoziationen derselben Art zwischen Elementen derselben Elementtypen, werden zu Assoziationstypen klassifiziert. Assoziationstypen dienen dazu, die Bildung eines komplexen Elementtyps aus anderen (komplexen oder atomaren) Elementtypen zu beschreiben. Die Konstruktionsvorschrift gibt für den Assoziationstypen an, wie der Inhalt der Elemente des Supertyps aus den Elementen der Subtypen gebildet wird. Zulässige Konstruktionsvorschriften für den Inhalt eines Elements des Supertypen sind die Sequenz, die Auswahl und die Permutation. Graphisch werden Assoziationstypen durch UML-Assoziationen, den Aggregationen, dargestellt (Abbildung 1). (b)
E (c)
E (a)
E1
E ...
...
E2 En E1 E2 En E1 E2 Abbildung 1: Graphische Darstellung von (a) Sequenztyp, (b) Auswahltyp und (c) Permutationstyptyp ...
En Jedem Elementtypen, der Subtyp eines Assoziationstypen ist, wird die entsprechende Kardinalität bezüglich dieses Assoziationstyps als Paar einer Minimumskardinalität und einer Maximumskardinalität angegeben. Die Kardinalität beschreibt, aus wie vielen Elementen dieses Typs sich ein Element des Supertyps zusammensetzen kann1. Beispiel: Abbildung 2 zeigt den Sequenztypen mit dem Supertypen Kunde für Kundendokumente einer Buchhandlung. Der Inhalt aller Elemente dieses Typs setzt sich folgendermaßen zusammen: Zuerst gibt es genau ein Element vom Typ Kundennummer, dann ein oder zwei Elemente vom Typ Adresse. Danach können beliebig viele Elemente vom Typ BestelltesBuch folgen, es muß aber kein solches Element vorkommen.
Kundennummer
Kunde
1..2 Adresse
*
BestelltesBuch Abbildung 2: Sequenztyp mit drei Subtypen unterschiedlicher Kardinalität
Name 0..1 Titel 1 In der Mathematik ist die Kardinalität als die Anzahl der Elemente einer Menge definiert. Hier wird der Begriff "Kardinalität" benutzt, um die Anzahl von aufeinanderfolgenden Elementen desselben Typs zu beschreiben, nicht also einer Menge von Elementen im streng mathematischen Sinn.
Durch den Einsatz von abstrakten Elementtypen können komplexe Elementtypen mittels Schachtelung von Assoziationstypen deklariert werden. Abstrakte Elementtypen klassifizieren Gruppierungen von Elementen und können in einer verkürzten Darstellung des XML-Schema-Diagramms weggelassen werden (beispielsweise im Elementtyp Name des XML-Schemas aus Abbildung 3).
Einen Spezialfall der XML-Schemata stellen die elementaren XML-Schemata dar, die sich aus Elementtypen und darauf definierten Assoziationstypen mit paarweise verschiedenen Supertypen zusammensetzen. Insbesondere existiert jeweils genau ein toplevel-Elementtyp2. Abbildung 3 zeigt ein elementares XML-Schema, das XMLDokumente für Mitarbeiter beschreibt. 3
Für eine Beschreibungssprache für dokumentenbasierte Geschäftsprozesse ist eine möglichst einheitliche Notation zur Definition von Schemata und die Spezifikation der Anfrage vorteilhaft, um den Entwurf von Abläufen mit Petri-Netzen so einfach wie möglich zu gestalten. Der für Geschäftsprozesse sinnvolle integrierte Ablauf- und Dokumenten- bzw. Datenentwurf erfordert neben der graphischen Notation zur Ablaufmodellierung und zum Entwurf der XML-Schemata auch eine graphische Notation zur Formulierung der Anfragen und der Dokumentenmanipulation.
Die Dokumentenmanipulationssprache XManiLa dient zur Selektion und Manipulation von XML-Dokumenten und ist eine Erweiterung des XML-Schema-Modells. Andere Anfragesprachen sind meistens textbasiert [AQH97, BMN02, DFF99, RLS98, W3C01b]. Bei XML-GL [CDF01], einer graphischen XML-Anfragesprache, liegt der Fokus auf der Erzeugung der Ergebnisdokumente für die jeweilige Anfrage. Die Grundlage für XManiLa bilden die sogenannten Filterschemata, die in ihrer Notation an XML-Schemata angelehnt sind. Verglichen mit den rein strukturbeschreibenden XML-Schemata ermöglichen Filterschemata zusätzlich die Zuweisung von Variablen oder Konstanten zu Elementtypen oder Attributen, die Auszeichnung eines Elements, das verändert werden soll (je nach Kontext, in dem das Filterschema eingesetzt wird, eingefügt oder gelöscht) und den Einsatz eines Elementplatzhalters an den Stellen, an denen der Inhalt der Dokumente für die Anfrage nicht relevant ist, weil er weder für die Auswahl eines Dokuments benötigt wird, noch Änderungen unterworfen ist. 3.1
Filterschemata stellen Schablonen für Dokumente und deren Elemente dar. Sie setzen sich aus Elementfiltern entsprechend den Elementtypen eines XML-Schemas zusammen. Für die Attribute von Elementtypen können Attributfilter eingesetzt werden. Attributfilter und Elementfilter können entweder Variablen oder konstante Werte enthalten. Die Konstanten stammen aus dem Wertebereich des entsprechenden Attri2 Ein top-level-Elementtyp ist ein Elementtyp, der nicht Subtyp eines Assoziationstypen ist. buts oder des Elementtyp-Inhalts. Sie können daher für Attribute oder atomare Elementtypen als einfache Werte, beispielsweise als Zeichenkette oder Zahl, angegeben werden. Die Elementfilter können mit Hilfe von Sequenz, Auswahl oder Permutation zu komplexen Elementfiltern zusammengesetzt werden. Ein Filterschema ist vergleichbar aufgebaut wie ein elementares XML-Schema. Die graphische Darstellung eines Filterschemas wird auch als Filterdiagramm bezeichnet.
Ein Filterschema ist zu einem bestimmten XML-Schema zulässig, wenn alle durch das Filterdiagramm beschriebenen XML-Dokumente gültig bezüglich dieses XMLSchemas sind. In Filterdiagrammen zulässiger Filterschemata können Elementtypnamen und Attributnamen weggelassen werden, wenn sie durch die Zuordnung des entsprechenden XML-Schema-Diagramms eindeutig sind. Abbildung 4 (a) zeigt ein zu dem Mitarbeiter-Schema aus Abbildung 3 zulässiges Filterdiagramm, welches das Mitarbeiterdokument aus Abbildung 4 (b) beschreibt.
Elementfilter können nicht nur als Schablone für Elemente eines Typs verwendet werden, sondern auch, um Elemente zu manipulieren, d.h. sie zu löschen oder zu erzeugen. In der graphischen Repräsentation wird der sogenannte Manipulationsfilter von den anderen Elementfiltern, auch Vergleichsfilter genannt, durch einen schwarzen Balken an der linken Kante des Rechtecks unterschieden.
(a) (b)
M 76543
P-3101 P-4005 N
P
P
Fähigkeit: Gruppenleitung Vorname: Sebastian
Initial: H. Nachname: Schulz
Abbildung 4: Zulässiges Filterschema zum XML-Schema aus Abbildung 3 3.2
Filterschemata alleine stellen noch keine Dokumentenanfragen oder -manipulationen dar. Die Anfragesprache XManiLa basiert auf der Kombination von XML-Schemata, Filterschemata und Konzepten der Petri-Netze. Eine Anfrage mit XManiLa besteht allgemein aus einer Stelle, einer Transition und einer Kante zwischen Stelle und Transition. Ein elementares XML-Schema dient zur Typung der Stelle. Alle für die Anfrage relevanten Dokumente müssen bezüglich dieses Schemas gültig sein. Als Kantenbeschriftung muß ein bezüglich des XML-Schemas zulässiges Filterschema gewählt werden. Die Richtung der Kante spezifiziert, ob es sich um eine Einfügeoperation oder eine Löschoperation handelt (siehe Abbildung 5).
Nachfolgend werden Beispiele für das Erzeugen eines neuen Mitarbeiterdokuments, das Löschen eines Elements aus einem bestehenden Mitarbeiterdokument und das Lesen von XML-Dokumenten zum XML-Schema aus Abbildung 3 vorgestellt. Mitarbeiter: Sebastian H. Schulz ID: 76543 Projekte: P-3101 P-4005
Fähigkeiten:
Gruppenleitung (b) M 63941 Beispiel: Erzeuge ein Mitarbeiterdokument für die neue Mitarbeiterin Henriette Meier mit der Nummer "63941". Das Dokument wird zur Menge der Mitarbeiterdokumente hinzugefügt. Die XManiLa-Anfrage ist in Abbildung 6 zu sehen.
Vorname: Henriette
Nachname: Meier füge Mitarbeiterin 63941 ein
Name Beispiel: Mitarbeiter "76543" hat die Mitarbeit in Projekt "P-3101" beendet. Das Element inProjekt mit dieser Projektnummer soll aus seinem Dokument gelöscht werden, alle anderen Informationen bleiben erhalten. Mitarbeiter lösche für 76543 das Projekt P-3101
Abbildung 7: Löschen eines atomaren Elements aus einem Dokument Das dazu notwendige Filterdiagramm zeigt Abbildung 7. Bei dieser XManiLa-Anfrage ist die Richtung der Kante entgegengesetzt zu der für Einfüge-Operationen, das Filterdiagramm spezifiziert daher das Entfernen von Dokumentteilen.
Beispiel: Gesucht wird ein Mitarbeiter, der entweder in Projekt P-3013 oder in Projekt P-4005 mitarbeitet. Für alle anderen Elementtypen als inProjekt werden im Filterdiagramm Elementplatzhalter eingesetzt, um zu beschreiben, daß vor und nach dem gesuchten Element beliebige andere Elemente stehen können. Die entsprechende XManiLa-Anfrage ist in Abbildung 8 zu sehen. □ lese Mitarbeiter von Projekt 3013 oder Projekt 4005 □
Abbildung 8: Suchen nach einem Element mit alternativem Inhalt 4
Insbesondere Geschäftsprozesse im E-Business werden durch die bestehenden AblaufBeschreibungssprachen bislang unzureichend unterstützt. Ablauforientierte Beschreibungssprachen ermöglichen zwar die Modellierung des Ablaufs, aber nicht die integrierte Darstellung komplexer Objekte. Zur Nutzung dieser Beschreibungssprachen müssen komplexe Objekte entweder als unteilbares Ganzes behandelt oder auf relationale Daten heruntergebrochen werden. Im ersten Fall kann nicht mehr auf Teile des Dokuments zugegriffen werden, im zweiten Fall kann das Dokument nicht mehr als Ganzes identifiziert werden, was u.a. die Manipulation der Dokumente erheblich erschwert. Andere Beschreibungssprachen konzentrieren sich auf die Modellierung der komplexen Objekte und der Operationen auf diesen Objekten. Sie sind jedoch nicht für die Modellierung eines umfassenden Ablaufs und seiner Dynamik geeignet. XML-Netze stellen einen neuen Typ höherer Petri-Netze dar. Sie setzen sich aus den üblichen Petri-Netz-Bestandteilen mit der nachfolgenden Interpretation zusammen: Jede Stelle in einem XML-Netz kann als Behälter für eine Menge von strukturierten Objekten zu einem gemeinsamen Schema, dem Stellentyp, interpretiert werden. Die Stellentypung erfolgt in einem XML-Netz im allgemeinen3 durch ein elementares XML-Schema. Die Transitionen sind über gerichtete Kanten mit den Stellen verbunden. Sie repräsentieren Aktivitäten, die jeweils eine Klasse von Operationen auf den Dokumenten der adjazenten Stellen definieren. Jeder Transition kann eine Transitionsinschrift, bestehend aus einem logischen Ausdruck, hinzugefügt werden. Jeder Kante wird eine Kanteninschrift zugewiesen. Die Kanteninschrift präzisiert die Operation, die auf den Dokumenten der adjazenten Kante durchgeführt wird. Sie ordnet der Kante eine Menge von zu dem XML-Schema der adjazenten Stelle zulässigen Filterschemata zu. Wird die Menge der in den Filterschemata auftretenden Variablen belegt, dann repräsentieren die konstanten Filterschemata die entsprechenden Dokumente der Stelle vor bzw. nach Durchführung der Aktivität. Zu jedem Zeitpunkt kann für jede Transition entschieden werden, ob sie bezüglich einer Variablenbelegung aktiviert ist, d.h. ob 3 XML-Netze können ohne Beschränkung der Allgemeinheit Teile von Prädikate/Transitionen-Netzen enthalten. Für Stellen dieser Netzteile geschieht die Stellentypung durch Relationenschemata. Die Stellen werden mit Relationen zu dem jeweiligen Schema markiert.
Person P ZA
KN * 0..1 AUS
N T S Name Te*l Sonstiges0..1 kZna[h1lu]ngsart auswahl[1]:(Ueb|Einzug)="Einzug" Person Versicherungsende ADMitName Versicherungshöhe
vid[1] * Name Tel ADListe vid[1]
*
Abgeschlossener-Vertrag
VertragsID Prämienhöhe
Abbildung 9: XML-Netz für den Beginn eines Versicherungsverhältnisses Bei der Akquise durch einen Außendienstmitarbeiter wird ein Versicherungsantrag aufgesetzt. Versicherungsanträge enthalten die Personalien des Antragstellers, die gewünschte Zahlungsart (Überweisung oder Lastschriftverfahren), den Versicherungsbeginn, die vereinbarte Laufzeit und die Versicherungshöhe. Der Außendienstmitarbeiter gibt zusätzlich seinen Namen und seine Kennung an. Das Versicherungsunternehmen muß nach Eingang des Antrags die Prämienhöhe festlegen, die dem Antrag hinzugefügt wird. Gleichzeitig wird die Liste des Außendienstmitarbeiters aktualisiert.
Am Tag des vereinbarten Versicherungsbeginns tritt die Versicherung in Kraft, der Versicherungsschutz wird aktiviert. Das Datum, an dem die Versicherung ausläuft, bestimmt sich automatisch durch die vereinbarte Laufzeit. Für den Kunden wird ein Versicherungsvertrag ausgefertigt, der seinen Namen, seine Telefonnummern, das A AID ADMitName:N VID Aktualisierung durch Abteilung
V VID
AV* AID PH
Akquise
PH Datum, an dem der Versicherungsschutz erlischt, Name und Kennung des verantwortlichen Außendienstmitarbeiters und die Versicherungshöhe enthält.
Die für den Ablauf relevanten XML-Schemata und das XML-Netz (ohne Markierung) zeigt Abbildung 9. □ XML-Netze können mitsamt ihrer Markierung als XML-Dokumente in einer XMLDatenbank gespeichert und verwaltet werden. Für XML-Schemata und Filterschemata können aus den entsprechenden Diagrammen XML-Dokumente abgeleitet werden, welche die jeweiligen Schemata exakt beschreiben. Petri-Netze können (beispielsweise) mit Hilfe der Petri Net Markup Language (PNML) [WeK02] durch XMLDokumente beschrieben werden, so daß eine integrierte Verwaltung der Prozeßbeschreibung in Form eines XML-Netzes und der zugehörigen Markierung möglich ist. 5
Im vorliegenden Beitrag wurden XML-Netze vorgestellt, die zur integrierten Dokumenten- und Ablaufmodellierung von E-Business-Prozessen eingesetzt werden können. XML-Netze sind eine neue Variante höherer Petri-Netze, deren Stellen als Behälter für XML-Dokumente, die zu dem der Stelle entsprechenden XML-Schema gültig sind, interpretiert werden. Die Operationen auf den Dokumenten werden durch die Transitionen und Filterschemata der jeweils adjazenten Kanten beschrieben. Zunächst wurden XML-Schemata und ihre graphische Repräsentation, die XML-SchemaDiagramme, vorgestellt. Danach wurden Filterschemata mit einer an XML-SchemaDiagrammen orientierten graphischen Darstellung beschrieben, die zur Formulierung von Anfragen an XML-Dokumente und Dokumentenmanipulationen verwendet werden können. Abschließend wurden XML-Schemata und Filterschemata zur Vorstellung der XML-Netze verwendet.
Einen Ansatzpunkt für weitere Forschungsarbeit stellt u.a. die Analyse der XMLNetze dar. Hierbei muß beispielsweise untersucht werden, welche Analysemethoden anderer Petri-Netz-Typen auf XML-Netze übertragen werden können, so daß sie noch für komplexe XML-Netze anwendbar sind und in einer angemessenen Zeit ein Ergebnis liefern. Andererseits kann es sicherlich sinnvoll sein, eine Transformation der XML-Netze in Petri-Netze anderer Netztypen durchzuführen, um die für diese Typen bekannten Analysemethoden anwenden zu können. Der Entwurf von XML-Netzen soll außerdem durch ein Vorgehensmodell unterstützt werden. Das Vorgehensmodell beschreibt die Vorgehensweise beim Entwurf des XML-Netzes, beginnend mit dem Petri-Netz eines elementares Typs bis hin zum fertigen XML-Netz. Für XML-Netze sollen auch Methoden entwickelt werden, wie XML-Netze in andere Ablaufbeschreibungssprachen, beispielsweise Ereignisgesteuerte Prozeßketten, übersetzt werden können. Dies ist besonders dann sinnvoll, wenn Ablaufschemata, die als XML-Netze modelliert wurden, Anwendern vermittelt werden sollen, die nicht mit Petri-Netzen, sondern einer anderen Ablaufbeschreibungssprache vertraut sind.
Die Entwicklung eines XML-Netz-Editors und -Simulators bildet die Basis für die prototypmäßige Implementierung eines XML-Netz-basierten WorkflowManagementsystems. Bei der Implementierung sollen weitgehend bereits am Markt verfügbare Produkte eingesetzt werden: Für die Verwaltung der XML-Dokumente wird der Tamino XML Server (http://www.softwareag.com/tamino/), ein natives XML-Datenbanksystem der Software AG (http://www.softwareag.com/) eingesetzt. Als Editor für die XML-Schemata wird der XML-Editor der XML Spy Suite (http://www.xmlspy.de/) der Firma Altanova (http://www.xmlspy.com/company.html) verwendet. Der Entwurf der Filterschemata soll durch ein Werkzeug unterstützt werden, das die Ableitung zulässiger Filterschemata aus den jeweiligen Dokumentenschemata durch Funktionalitäten wie das Ausblenden von Elementtypen, die (automatische) Zuweisung von Variablen oder den Eintrag von Konstanten durch den Modellierer ermöglicht. Das Werkzeug zum Entwurf der Ablaufschemata, der XMLNetz-Simulator und die Workflow-Engine zur Ablaufsteuerung sollen auf der INCOME Suite (http://www.promatis.de/produkte/income_suite/index.htm) der Firma PROMATIS (http://www.promatis.de/) aufgesetzt werden.
Literatur [AQH97] [BCF99] [BMN02] [BRJ99] [CDF01] [Che76] [CSF00] [DeO96] [DFF99] [EHP02]