diplomarbeit xml standards im umfeld des kollaborativen...
TRANSCRIPT
Universität Paderborn
Diplomarbeit
XML Standards im Umfeld des kollaborativen Prozess- und
Projektmanagements
Marktanalyse und prototypische Implementierung einer Schnittstelle
zwischen Workflowsystemen basierend auf XML Standards
vorgelegt bei
Prof. Dr. Ludwig Nastansky
betreut durch
Dr. Rolf Kremer
vorgelegt von
Jing Tang
Vogeliusweg 23.1.16, 33100 Paderborn
Matrikel-Nr.: 6144127
Mai 2005
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 2
Inhaltverzeichnis
Abbildungsverzeichnis....................................................................................................5
Tabellenverzeichnis.........................................................................................................7
Abkürzungen ...................................................................................................................8
1. Einleitung.......................................................................................................11
1.1. Einordnung des Themas..................................................................................12
1.2. Ziel der Arbeit .................................................................................................13
1.3. Aufbau der Arbeit ...........................................................................................14
2. Grundlagen ....................................................................................................16
2.1. Prozessmanagement ........................................................................................16
2.1.1. Prozess .............................................................................................................16
2.1.2. Geschäftsprozess ..............................................................................................16
2.1.3. Workflow .........................................................................................................17
2.1.4. Prozessmanagement .........................................................................................18
2.1.5. Workflowmanagement.....................................................................................19
2.2. Projektmanagement.........................................................................................20
3. Unterstützung durch XML-Standards........................................................21
3.1. XML-Standards...............................................................................................21
3.1.1. XML.................................................................................................................21
3.1.2. XSLT................................................................................................................23
3.2. Standards des Prozessmanagements ...............................................................25
3.2.1. Wf-XML 2.0 ....................................................................................................25
3.2.2. BPML (BPMN, BPQL)....................................................................................28
3.2.3. BPEL4WS........................................................................................................30
3.2.4. ebXML .............................................................................................................33
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 3
3.3. Standards im Projektmanagement...................................................................35
3.3.1. MS Project XML..............................................................................................35
3.3.2. PMXML ...........................................................................................................36
3.4. Weitere Standards ...........................................................................................37
3.4.1. DSML v2..........................................................................................................37
3.4.2. HRXML ...........................................................................................................38
3.5. PAVONE-spezifische XML-Standards ..........................................................40
3.5.1. Workflowmodellierung (ProcessModeler XML).............................................40
3.5.2. Organisationsmodellierung (OrganizationModeler XML) ..............................41
3.5.3. PAVONE ProcessModeler Einordnung...........................................................42
4. Konzept einer generischen Schnittstelle .....................................................44
4.1. Ausführen BPEL Process................................................................................45
4.1.1. VB Parser für BPEL XML...............................................................................46
4.1.2. Transformation durch XSLT............................................................................47
4.1.3. Transformation durch JAVA............................................................................48
4.1.4. Analyse und Lösung.........................................................................................48
4.2. Choreographierung von BPEL Prozess...........................................................49
4.2.1. Web Services....................................................................................................50
4.2.1.1 SOAP (Simple Object Access Protocol) ........................................................51
4.2.1.2 WSDL (Web Services Decription Language)................................................52
4.2.1.3 UDDI (Universal Description Discovery and Integration) ............................54
4.2.2. Legacy Programme als Web Service einbinden...............................................56
5. Beschreibung der Implementierung............................................................58
5.1. PAVONE ProcessModeler und sein Eigenschaftsformat ...............................58
5.2. Überblick der Implementierungswerkzeuge von IBM WebSphere ................59
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 4
5.3. Entwicklung eines BPEL4WS Prozesses mit WSAD-IE................................61
5.4. Transformieren der BPEL4WS Prozessdefinition ..........................................65
5.4.1. Durch XSL automatisch generieren.................................................................65
5.4.2. Die Transformation mit XSLT.........................................................................65
5.5. Integration IBM WebSphere und Microsoft Excel mit BPEL4WS................71
5.5.1. Änderung des BPEL Prozess ...........................................................................73
5.5.2. AnyWS.dll Tool ...............................................................................................75
5.5.2.1 AnyWS.dll Schnittstelle.................................................................................76
5.5.2.2 Dynamic Function Calls.................................................................................77
5.5.2.3 Implementation „getStock” Web Service in VBA für Excel .........................80
5.6. Bewertung .......................................................................................................82
6. Schluß und Ausblick der Arbeit ..................................................................83
Anlagen ..........................................................................................................................86
Literaturverzeichnis......................................................................................................91
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 5
Abbildungsverzeichnis
Abbildung 1: Architektur und Schnittstelle des Workflows (vgl. [Kindler 2003]) ........17
Abbildung 2: Übersicht über die Sprachfamilie XML (vgl. [Thränert 2004]) ...............21
Abbildung 3: Beispiel eines XML-Dokuments ..............................................................22
Abbildung 4: XSLT Verarbeitungssequenz (vgl. [Klute, T.; Thiemann 2002]).............24
Abbildung 5: Wf-XML Operationskomponenten...........................................................26
Abbildung 6: Wf-XML Interoperation Beispiel .............................................................27
Abbildung 7: BPML Elemente (XML Schema) .............................................................29
Abbildung 8: BPEL4WS Elemente (XML Schema) ......................................................31
Abbildung 9: Abarbeitung eines BPEL4WS Prozesses (vgl. [Cubera et al. 2003, S.9]) 32
Abbildung 10: MS Project XML Elemente (XML Schema) ..........................................35
Abbildung 11: Beispiel von DSML ................................................................................38
Abbildung 12: ProcessModeler XML Elemente (XML Schema)...................................41
Abbildung 13: OrganizationModeler XML Elemente (XML Schema)..........................42
Abbildung 14: Architektur von BPEL und ProcessModeler (1).....................................44
Abbildung 15: Architektur von BPEL und ProcessModeler (2).....................................45
Abbildung 16: Nutzungsansätze von BPEL XML im ProcessModeler..........................46
Abbildung 17: Das WebServices-Modell (vgl. [Kolb 2005]).........................................51
Abbildung 18: Beispiel von WSDL ................................................................................53
Abbildung 19: Beispiel von UDDI .................................................................................55
Abbildung 20: Einen Prozess in PAVONE ProcessModeler definieren.........................58
Abbildung 21: Der Approve Prozess ..............................................................................62
Abbildung 22: Definieren des Approve Prozesses in WebSphere..................................64
Abbildung 23: Transformieren der Aktivitätsbeziehungen von BPEL ins PAVONE
ProcessModeler Format ..........................................................................................65
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 6
Abbildung 24: BPEL4WS in PAVONE ProcessModeler XML transformieren ............67
Abbildung 25: Transformierte BPEL Prozess in ProcessModeler..................................71
Abbildung 26: Modifizierung von BPEL Prozess zur Integration in Excel...................73
Abbildung 27: Definition einer BPEL Process Instance in WebSphere.........................74
Abbildung 28: Automatisch generierter Code nach WSDL ...........................................75
Abbildung 29: Sequenzdiagramm Funktionsaufruf ........................................................78
Abbildung 30: Bereitstellung eines Web Services Request in Excel..............................81
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 7
Tabellenverzeichnis
Tabelle 1: Überblick des Standards Wf-XML 2.0 ..........................................................26
Tabelle 2: Überblick des Standards BPML.....................................................................28
Tabelle 3: Überblick des Standards BPEL4WS..............................................................30
Tabelle 4: Überblick des Standards ebXML...................................................................33
Tabelle 5: Überblick des Standards MS Project XML ...................................................35
Tabelle 6: Überblick des Standards PMXML.................................................................36
Tabelle 7: Überblick des Standards DSML v2 ...............................................................37
Tabelle 8: Überblick des Standards HRXML .................................................................39
Tabelle 9: Überblick des Standards ProcessModeler XML............................................40
Tabelle 10: Überblick des Standards OrganizationModeler XML .................................41
Tabelle 11: Routing-Bedingungen in BPEL und PAVONE ProcessModeler XML ......70
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 8
Abkürzungen
API Application Programming Interface
AWSP Asynchronous Web Services Protocol
BPEL Business Process Execution Language
BPEL4WS Business Process Execution Language for Web Service
BPML Business Process Modeling Language
BPMN Business Process Modeling Notation
BPMS Business Process Management System
BPQL Business Process Query Language
BPSS Business Process Specification Schema
CORBA Common Object Request Broker Architecture
DCOM Distributed Component Object Model
DOM Document Object Model
DLL Dynamic Link Library
DSML v2 Directory Services Markup Language version 2.0
DTD Document Type Definition
EAI Enterprise Application Integration
ebXML electronic Business XML
EJB Enterprise Java Bean
ERP Enterprise Resource Planning
FTP File Transport Protocol
HR-XML Human Resources XML
HTTP Hyper Text Transfer Protocol
JDNI Java Naming and Directory Interface
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 9
KMU Klein- und mittelständische Unternehmen
LDAP Light Directory Access Protocol
MIME Multipurpose Internet Mail Extensions
OASIS Organization for the Advancement of Structured Information
Standards
PAVONE PM XML PAVONE ProcessModeler XML
PMXML Project Management XML
RMI Remote Method Invocation
RPC Remote Procedure Call
SAX Simple API for XML
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
SQL Structured Query Language
SSL Secure Socket Layer
UBR UDDI Business Registry Nodes
UDDI Universal Description Discovery & Integration
URI Uniform Resource Identifier
VB Visual Basic
WAS WebSphere Application Server
WBISF WebSphere Business Integration Server Foundation
WfMC Workflow Management Coalition
WfMS Workflow Management System
Wf-XML Workflow XML
WSAD-IE WebSphere Studio Application Developer Integration Edition
WSDL Web Service Describe Language
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 10
XML Extensible Markup Language
XPath XML Path Language
XSD XML Schema Definition Language
XSL Extensible Stylesheet Language
XSLT XSL Transformations
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 11
1. Einleitung
Aufgrund steigender Komplexität von Softwaresystemen und wachsender
Unternehmensstrukturen beschäftigen sich viele IT-Abteilungen mit den
Fragestellungen der Anwendungsintegration. Integration ist ein sehr teurer
Kosteneinzelposten, der zu einem hohen Prozentsatz aus Implementierungskosten
besteht und auch hohe laufende Kosten verursacht. Nach einer Studie (vgl. [Yager
2002]) verursachten Integrationskosten im Durchschnitt 24% des jährlichen IT Budgets.
Forrester Research (vgl. [Actional 2002]) beziffert die Ausgaben für
Integrationsbemühungen globaler Unternehmen im Jahr 2001 auf durchschnittlich $ 6,3
Millionen. Gerade wegen dieser hohen Kosten bleibt Integration ein kritisches Thema,
mit dem sich die IT- Abteilungen befassen müssen.
Führende Analysten haben Web Services (vgl. [Haas 2003]) als eine potentiell
revolutionäre Technologie im Bereich Enterprise Application Integration (EAI)
identifiziert, und zwar sowohl innerhalb der Grenzen einer Organisation als auch über
Unternehmensgrenzen hinaus. Dieses entspricht den aktuellen Anforderungen des E-
Commerce. Was Web Services revolutionär macht ist die komplette Nutzung der
Internet-basierten Infrastruktur, wie sie heute in Unternehmen anzutreffen ist und vor
allem die weit verbreitete Unterstützung durch Anbieter.
Web Services basieren auf einer Reihe von Standards, die es einer Applikation
ermöglichen, sich zu identifizieren, ihren angebotenen Services präzise zu beschreiben
und die Schnittstellen bereitzustellen, die andere Applikationen benötigen, um den Web
Service verwenden zu können.
XML (Extensible Markup Language) ist die Kerntechnologie, mit welcher diese
Informationen dargestellt werden. Wenn man sich die Applikationslogik eines Web
Services als eine Black Box vorstellt, stellen die XML-Daten die Mittel zur Verfügung,
mit denen diese Black Box untereinander kommuniziert.
Im Folgenden wird eingehend untersucht, in wie fern die XML- und Web Services-
Technologien eine wichtige Rolle in der Integration und Entwicklung von
Unternehmenssoftware darstellen.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 12
1.1. Einordnung des Themas
In den 90er Jahren war es Ziel vieler Unternehmen, ihre über die Jahre gewachsene
heterogene Systemlandschaft zu vereinheitlichen und auf eine gemeinsame
technologische Basis zu stellen. Inzwischen hat sich jedoch herausgestellt, dass
insbesondere unternehmenskritische Systeme nicht ohne weiteres ersetzt werden können.
Zu hohe Ablösungsaufwände und nicht ausreichende Infrastruktur bzw. Technologien
jenseits vom Mainframe zählen zu den Hauptgründen. Die Backend Connectivity wurde
hoffähig und bildet heute die Basis der Integrationstechnologien EAI [Eisch-Hagenauer
2001].
EAI ist eine Kombination aus Methoden und Technologien zur Integration von
heterogenen Systemen. Standards und Produkte spielen dabei eine wesentliche Rolle.
Mit steigender Komplexität der Geschäftsprozesse nimmt die Komplexität der
Systemlandschaften in Unternehmen zu. EAI-Konzepte und -Produkte sollen eine
geeignete Strukturierung der Systemlandschaft, abhängig von den geforderten
Anwendungsfeldern unterstützen. Die Anwendungsfelder lassen sich in zwei
Kategorien einteilen: Integration im Unternehmen und Integration über
Unternehmensgrenzen hinweg. Diese basieren hauptsächlich auf Internettechnologien
und zählen zu dem Bereich E-Business.
XML ist eine wichtige Technologie, die als weltweiter Standard für den Plattform- und
anwendungsunabhängigen Austausch von Daten genutzt wird. Durch XML haben sich
das Web, der E-Commerce und die Datenorganisation grundlegend verändert. XML
ermöglicht, Daten auf einfache Weise anwendungs- und herstellerneutral zu beschreiben.
Damit lassen sich Informationen zwischen einer Vielzahl verschiedener Anwendungen
einfach austauschen und weiterverarbeiten.
EAI ist eine der vielversprechendsten Anwendungen von XML. Die Vorteile der
Nutzung von XML in EAI sind:
• XML wird als Format zum Datenaustausch zwischen unterschiedlichen
Anwendungen genutzt. Mittels XML wird in einheitlicher Syntax die Semantik
der Daten zwischen verschiedenen Anwendungen übertragen. Darüber hinaus ist
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 13
XML-Code für Maschinen ebenso interpretierbar wie für Menschen. Hierdurch
wird der Datenaustausch einfacher und zuverlässiger.
• Mit Web Services ist ein neues Konzept für die Architektur von Enterprise-
Infrastrukturen entstanden. Heute werden Web Services als gut geeignete
Architektur der Unternehmenssoftware durch die Industrie anerkannt. Nicht nur
neue Software wird als Web Service entwickelt, sondern auch Legacy Systeme
werden darin verpackt (engl. wrapped), um Daten oder Methoden über
Schnittstellen als Web Service zu exportieren.
Ziel ist es, eine auf Standards basierende Integration zu erreichen. Dazu steht eine Reihe,
universell vereinbarter Standards zur Verfügung, deren Grundlage auf XML basiert.
1.2. Ziel der Arbeit
Ziel der Arbeit ist es, die Nutzbarkeit von XML in EAI zu untersuchen. Aus technischer
Sicht sollen die XML Standards, Implementierungsmechanismen und eventuelle
existierende Probleme untersucht werden sowie eine bessere Nutzung von XSLT
(Extensible Stylesheet Language Transformations) - eine Sprache zur Transformation
von XML-Dokumenten in andere XML-Dokumente - für XML betrachtet werden.
Darüber hinaus soll die Unterstützung von unterschiedlichen XML Standards durch
Applikationssoftware und Kunden beschrieben werden.
Durch eine Marktanalyse der XML Standards wird die Tendenz der neuen Technologie
aufgezeigt, inwieweit diese neue Technologie die Produktivität fördern kann.
Danach wird der PAVONE ProcessModeler - ein Produkt der PAVONE AG -
untersucht, ob dieser mit den neuesten Workflow Standards zusammenarbeiten kann.
Bestandteil dieser Untersuchung ist auch die Entwicklung von Schnittstellen zu einem
gängigen Workflow Standard.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 14
1.3. Aufbau der Arbeit
Diese Arbeit grenzt zunächst einige grundlegende Begriffe ab, und positioniert die
Diplomarbeit im Bereich der aktuellen XML Technologie.
In Kapitel 2 werden die Grundlagen erläutert (Prozessmanagement,
Workflowmanagement und Projektmanagement).
In Kapitel 3 werden die zugehörigen Standards beschrieben.
• Zuerst wird XML und allgemeine XML Technologien im Abschnitt 3.1
beschrieben.
• Workflow ist der Kern-Mechanismus von Applikation Integration, somit sind
Workflow XML Standards der Schwerpunkt der Untersuchungen, die im
Abschnitt 3.2 beschrieben werden. BPEL4WS ist ein von der Industrie vielfach
verwendeter Standard, weshalb die Nutzung dieses Standards für die
Implementierung für den PAVONE ProcessModeler durchgeführt wurde.
• Projektmanagement ist eine wesentliche Aufgabe für jedes Unternehmen,
deshalb werden XML-Standards für das Projektmanagement im Abschnitt 3.3
untersucht.
• Verzeichnisdienste und User Management sind grundlegende Komponente für
jede Enterprise Applikation. Die entsprechende XML Standards wie DSML und
HRXML werden im Abschnitt 3.4 vorgestellt.
• Danach wird die PAVONE-spezifische XML beschrieben und der PAVONE
ProcessModeler als eine Anwendung, welche XML nutzt, vorgestellt.
Anschließend wird im Kapitel 4 das Konzept einer generischen Schnittstelle dargestellt
und zwei Vorgehensweisen detailliert beschrieben.
In Kapitel 5 geht es um die detaillierte Untersuchung von BPEL4WS und die konkreten
Implementierung mit IBM WebSphere. Der erste Teil der Implementierung verifiziert
die Transformation zwischen BPEL4WS und dem ProcessModeler XML, einem BPEL
Prozess und einem PAVONE-spezifischen Prozess. Eine wichtige Erweiterung der
Implementierung realisiert mehrere verteilt auszuführende Web Services, die eine
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 15
heterogene Systemlandschaft von IBM WebSphere und Microsoft Excel beinhaltet, zu
choreographieren und durchzuführen.
Abschließend wird das Ergebnis der vorgestellten Arbeit bewertet und ein Ausblick
gegeben.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 16
2. Grundlagen
2.1. Prozessmanagement
2.1.1. Prozess
Ein Prozess ist die inhaltlich abgeschlossene, zeitliche und sachlogische Folge von
Aktivitäten, die zur Bearbeitung eines prozessprägenden betriebswirtschaftlichen
Objektes notwendig sind. (vgl. [Becker/Kugeler/Rosemann 2003])
Prozesse sind unternehmensspezifisch, dies bedeutet, dass jedes Unternehmen andere
Abläufe und damit auch andere Prozesse hat. Aber alle Unternehmen haben
Prozesshülsen (z. B. Personalbereitstellung, Auftragsabwicklung). Diese sind lediglich
von Branche zu Branche verschieden (z.B. benötigt ein Industrieunternehmen in der
Regel nicht soviel Personal wie ein Dienstleistungsunternehmen). Ein Prozess wird
durch folgende Merkmale bestimmt (vgl. [Kindler 2003]):
• Definierte Ein- und Ausgangsgrößen
• Verkettung von vor- und nachgelagerten Tätigkeiten
• Abhängigkeiten von beeinflussbaren/nicht beeinflussbaren Tätigkeiten
• Steuerbare Arbeitsausführungen
2.1.2. Geschäftsprozess
Ein Geschäftsprozess (Unternehmensprozess, Business Process) ist eine Abfolge von
Aktivitäten, die der Erzeugung eines Produktes oder einer Dienstleistung dienen. Er
wird durch ein oder mehrere Ereignisse gestartet und durch ein oder mehrere Ereignisse
abgeschlossen. Ferner liegt eine Organisationsstruktur zu Grunde. (vgl. [Hagen/Stucky
2004])
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 17
Die Geschäftsprozesse eines Unternehmens können sehr komplex sein. Nicht alle
Aktivitäten innerhalb der Abfolge des gesamten Geschäftsprozesses müssen bzw.
können automatisiert werden.
2.1.3. Workflow
Unter einem Workflow wird die zeitlich-strukturelle Aneinanderreihung von einzelnen,
zur Bearbeitung eines Gesamtvorganges notwendigen Teilaufgaben verstanden, wobei
sich diese Folge von Teilaufgaben aus einzelnen Aktivitäten zusammensetzt und durch
Ereignisse ausgelöst und beendet wird. In der Regel sind Workflows organisationsweite,
arbeitsteilige Prozesse, in die eine Vielzahl von Beteiligten einbezogen ist (vgl.
[Nastansky et al. 2002]).
Auf der Architekturebene besteht der Workflow aus einem Kern (Workflow Engine)
und verschiedenen Views, wie in Abbildung 1 dargestellt:
Abbildung 1: Architektur und Schnittstelle des Workflows (vgl. [Kindler 2003])
• Workflow Engine(s): Ausführen des Workflows, z. B. die Aktivität verfolgen,
Aufgaben zuweisen, Dokument pflegen, aktualisieren usw.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 18
• Developer’s view: Modellierung, Analysieren und Simulieren des Workflows.
• Agent’s view: Die Worklist anzeigen, pflegen und aktualisieren und die
Aufgabenauswahl für Agenten ermöglichen.
• Administrator’s & Manager’s view: Löschen des Workflows und Zuweisen der
Aktivitäten. Alle Management-Informationen sammeln und verwalten.
• Other Workflow Engines: Kooperation mit anderen Workflows.
2.1.4. Prozessmanagement
Für Unternehmen ist Prozessmanagement das Zusammenwirken von Menschen,
Maschinen, Materialien, Methoden und Umgebung zur Produktion eines bestimmten
Outputs (vgl. [Prozessmanagement 2004]). Es beschreibt sowohl die aktuellen und
zukünftigen Bedürfnisse des Unternehmens als auch die seiner Kunden. Es definiert den
Ist- und Soll-Zustand des Unternehmens und entwickelt Ziele und Strategien zur
Umsetzung des Soll-Zustandes. Es ermöglicht ein Management zur ständigen
Verbesserung der Unternehmensabläufe und ist ein umfassender Ansatz zur
prozessorientierten Gestaltung und Führung von Unternehmen.
Prozessmanagement bezeichnet die Lenkung der Wertschöpfungskette einer
Organisation durch planerische, organisatorische und steuernde Maßnahmen (vgl.
[NorCom Information Technology AG 2005]):
• Ausrichtung der Prozessleistung an aktuellen Markt- und Kundenbedürfnissen
sowie die Belebung traditioneller Geschäftsstrukturen durch Ablauforientierung
und Parametersteuerung;
• kontinuierliche Weiterentwicklung der Kernkompetenzen zur langfristigen
Sicherstellung von Liquidität und Rentabilität;
• oder ganz einfach: Menschen in der Organisation dazu bringen, miteinander
(über Verbesserungspotenziale) zu reden.
Zusammengefasst ist das Prozessmanagement verantwortlich für:
• Starten und Beenden von Prozessen
• Ressourcenzuteilung an die einzelnen Prozesse
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 19
• Prozesssynchronisation
• Prozesskommunikation
Das Hauptziel des Prozessmanagements ist, den Arbeitsfluss so zu organisieren, dass
die anfallende Arbeit zum richtigen Zeitpunkt von und mit der richtigen Ressource
(Person/Gerät) ausgeführt wird.
Für das Prozessmanagement von stark strukturierten informationsverarbeitenden
Prozessen, die durch Arbeitsteilung und einen hohen Anteil an personeller Arbeitskraft
gekennzeichnet sind, stellt Workflowmanagement eine relevante Basistechnologie dar
(vgl. [Reife 2003]).
2.1.5. Workflowmanagement
Workflowmanagement umfasst alle Aufgaben, die bei der Modellierung, der Simulation
sowie bei der Ausführung und Steuerung von Workflows erfüllt werden müssen (vgl.
[Nastansky et al. 2000]).
Das Workflowmanagement beinhaltet zunächst die Lösung eines alten Problems.
Geschäftsprozesse sollen abgewickelt und dabei rechentechnisch unterstützt werden.
Dies erlaubt die Überwachung (Monitoring), sowie darauf basierend die Verbesserung
des Prozesses. Der neue Aspekt ist allerdings, dass die Logik der Geschäftsprozesse
explizit dargestellt wird. Dies ermöglicht, die gesamten Geschäftsprozesse durch IT zu
unterstützen. Wurden bisher nur Teilbereiche oder Teilaktivitäten von Unternehmen
automatisiert und schließlich die automatisierten Teile miteinander verknüpft, soll jetzt
zuallererst Wert auf die Zusammenhänge des Geschäftsprozesses gelegt werden, und
erst anschließend wird über die Automatisierung einzelner Teilprozesse nachgedacht.
Ziel ist also eine automatisierte Prozess-Steuerung (vgl. [Hagen/Stucky 2004]).
Workflow-Anwendungen werden auf der Basis von WfMS (Workflow Management
Systemen) realisiert und unterstützen den Informationsfluss sowie die Ablaufsteuerung
eines abgegrenzten betrieblichen Prozesses. Ein WfMS soll diese Abläufe durch IT-
Systeme unterstützen und teilweise automatisieren.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 20
2.2. Projektmanagement
Es gibt keine einheitliche, universell anerkannte Definition des Projektbegriffes.
Die verschiedenen Definitionen umfassen jedoch zumeist alle oder die meisten der
folgenden Eigenschaften (vgl. [VirtualUniversity]):
• Zeitliche Befristung: Projekte sind zeitlich begrenzt.
• Zielvorgabe: Für Projekte existieren bestimmte spezifische Zielvorgaben, die
sich u. U. nicht mit allgemeinen Zielen, etwa des Unternehmens decken bzw.
diese erweitern.
• Neuartigkeit: Projekte umfassen zumeist neuartige Aufgaben.
• Komplexität: Das Gesamtprojekt besteht aus einer Mehrzahl von Einzelaufgaben.
Der Begriff „Projektmanagement“ kann auf verschiedene Art und Weise verstanden
werden (vgl. [Zingel 2000-2004]):
• Institutional: Einordnung des Projektes in die Aufbauorganisation, d.h., die
Kommunikations- und Machtstruktur des Unternehmens,
• Funktional: Einordnung des Projektes in die Ablauforganisation des
Unternehmens, d.h. Planung, Steuerung und Kontrolle der einzelnen zum
Projekt gehörenden Arbeitsschritte und
• Instrumental: Methoden und Verfahren, die der Erreichung des Projektzieles
dienen.
Auf jeweils institutionaler, funktionaler und instrumentaler Ebene lassen sich die zuvor
skizzierten Teilbereiche des Management-Begriffes unterscheiden. Im institutionalen
Bereich hingegen überwiegt die interpersonelle Management-Komponente, während im
instrumentalen Bereich eher das Sachmittelmanagement überwiegt, sofern die
Erreichung von Projektzielen hierdurch gefördert werden soll.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 21
3. Unterstützung durch XML-Standards
3.1. XML-Standards
3.1.1. XML
XML (Extensible Markup Language) ist eine Metasprache zum Definieren von
Dokumenttypen, beschreibt eine Klasse von Datenobjekten, genannt XML-Dokumente,
und beschreibt teilweise das Verhalten von Computer-Programmen, die solche
Dokumente verarbeiten.
XML ist ein Anwendungsprofil (application profile) oder eine eingeschränkte Form von
SGML, der Standard Generalized Markup Language. Durch ihre Konstruktion sind
XML-Dokumente konforme SGML-Dokumente. XML wurde von einer XML-
Arbeitsgruppe (ursprünglich bekannt als das SGML Editorial Review Board) entwickelt,
die 1996 unter der Schirmherrschaft des World Wide Web Consortium (W3C)
gegründet wurde (vgl. [Mintert 2002]). Die Sprachfamilie XML wird in Abbildung 2
angezeigt.
Abbildung 2: Übersicht über die Sprachfamilie XML (vgl. [Thränert 2004])
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 22
All diese Sprachen bestehen aus Elementen, welche durch so genannte
„Tags“ gekennzeichnet werden, deren Verschachtelungsregeln, und aus Attributen mit
erlaubten Wertzuweisungen. Daneben gibt es Regeln, wie solche Sprachen - in XML
auch Namensräume genannt - in andere Sprachen importiert und somit eine Sprache
innerhalb einer anderen Sprache benutzt werden kann.
Die Tags in XML treten paarweise als Start- und End-Tags auf und geben an, welche
Bedeutung der dazwischen liegende (eventuell durch weitere Tags unterteilte) Text hat
(vgl. [Partl, T. 2000]):
In Abbildung 3 wird ein Beispiel eines XML-Dokuments gezeigt.
<?xml version ="1.0"?> <Vistenkarte> <Name> <Vorname>Baden</Vorname> <Nachname>Sonntag</Nachname> </Name> <Firma> <Firmenname>PAVONE GmbH</Firmenname> <Straße>Mayerhofgasse 1/15</Straße> <Ort>Paderborn</Ort> <Plz>33033</Plz> </Firma> <Kontakt> <Telefon>05251168168</Telefon> <Fax>05251188188</Fax> <Email>b.sonntag@pavone</Email> </Kontakt> </Visitenkarte>
Abbildung 3: Beispiel eines XML-Dokuments
So wie HTML festgelegt und normiert ist und daher für den weltweiten Austausch und
die Übertragung und Verwendung von Web-Seiten zwischen vielen verschiedenen
Web-Servern und Web-Browsern geeignet ist, können mit XML eigene Datei-
Strukturen für verschiedene Zwecke definiert und normiert werden, die dann ebenfalls
von vielen Personen mit vielen verschiedenen Programmen und auf vielen
verschiedenen Rechnern verwendet werden können.
Ein wesentlicher Grundsatz von XML ist die strikte Trennung von Inhalt und Struktur
der Daten vom Layout und Präsentation. Dokumente können unabhängig von ihrem
späteren Einsatzzweck erstellt und verwendet werden. Die Art der Darstellung (Layout
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 23
und Präsentation) und die Sicht auf ein Dokument können dabei vom jeweiligen
Benutzer selbst bestimmt werden. Dazu stehen Technologien wie z.B. XSL (Extensible
Stylesheet Language) zur Verfügung.
XML bietet die Möglichkeit standardisierte Dokumententypen zu vereinbaren. Diese
konkretisieren, ähnlich einer EDIFACT (Electronic Data Interchange For
Administration Commerce and Transport) Nachrichtenbeschreibung, den Inhalte und
die Struktur eines Dokuments. In einfacher Form kann dies mit Hilfe von DTD
(Document Type Definition) geschehen.
Die DTD legt fest, wie in einer Datei des entsprechenden Typs die Daten organisiert
werden (vgl. [Dünhölter 1998]). Man kann sich also leicht klarmachen, dass es für die
Dokument-Typ-Definitionen, die im Rahmen von XML geschaffen werden, allerhand
Konkurrenz gibt. Die bekannten Definitionen von Datei-Formaten leisten Ähnliches.
Eine Weiterentwicklung der DTD stellen Schemata dar. Ein Schema beschreibt die
Struktur und Inhalte einer XML-Nachricht vollständig. Dadurch wird es XML-
Anwendungen ermöglicht, XML-Nachrichten auf formale und syntaktische Richtigkeit
zu überprüfen.
3.1.2. XSLT
XSLT wurde entwickelt, um als ein Bestandteil von XSL, einer Stylesheet-Sprache für
XML, genutzt zu werden. Neben XSLT enthält XSL ein XML-Vokabular, um eine
Formatierung zu spezifizieren. XSL spezifiziert das Layout eines XML-Dokuments, um
unter Benutzung von XSLT zu beschreiben, wie das Dokument in ein anderes XML-
Dokument, welches das Formatierungsvokabular benutzt, transformiert wird (vgl.
[Clark 2002]).
XSLT ist auch entworfen worden, um unabhängig von XSL benutzt zu werden. Jedoch
ist XSLT nicht als vollständig universelle XML-Transformationssprache konzipiert.
Vielmehr ist sie primär für die Arten von Transformationen entwickelt worden, die
benötigt werden, wenn XSLT als Teil von XSL benutzt wird.
Eine in XSLT ausgedrückte Transformation beschreibt Regeln für die Transformation
eines Quellbaums in einen Ergebnisbaum. Diese Transformation wird durch die
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 24
Assoziation von Mustern mit Templates erreicht. Ein Muster wird gegen Elemente des
Quellbaumes getestet. Ein Template wird instanziiert, um einen Teil des
Ergebnisbaumes zu erstellen. Der Ergebnisbaum ist unabhängig vom Quellbaum. Die
Struktur des Ergebnisbaums kann sich von der Struktur des Quellbaums komplett
unterscheiden. Bei der Konstruktion des Ergebnisbaums können Elemente des
Quellbaumes gefiltert und umgeordnet sowie beliebige Struktur hinzugefügt werden.
Eine in XSLT ausgedrückte Transformation wird ein Stylesheet genannt, da die
Transformation im Fall der Transformierung von XSLT in das XSL-
Formatierungsvokabular als Stylesheet fungiert. Die Verarbeitungssequenz ist in
Abbildung 4 dargestellt.
Abbildung 4: XSLT Verarbeitungssequenz (vgl. [Klute, T.; Thiemann 2002])
XSLT-Prozessoren müssen den XML-Namensraum-Mechanismus benutzen, um
Elemente und Attribute aus diesem Namensraum zu erkennen. Elemente des XSLT-
Namensraums werden nur im Stylesheet, nicht aber im Quelldokument erkannt.
Das xsl:stylesheet-Element kann die folgenden Elementtypen beinhalten:
• xsl:import
• xsl:include
• xsl:strip-space
• xsl:preserve-space
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 25
• xsl:output
• xsl:key
• xsl:decimal-format
• xsl:namespace-alias
• xsl:attribute-set
• xsl:variable
• xsl:param
• xsl:template
Als ein Beispiel kann eine rekursive Verarbeitung bei Nicht-Vorhanden-Sein eines
erfolgreichen Mustertests zu einer expliziten Template-Regel in dem Stylesheet
fortgesetzt werden. Diese Template-Regel wird sowohl auf die Elementknoten, als auch
auf den Wurzelknoten angewandt. Folgendes zeigt die Äquivalenz der eingebauten
Template-Regel:
<xsl:template match="*|/">
<xsl:apply-templates/>
</xsl:template>
3.2. Standards des Prozessmanagements
3.2.1. Wf-XML 2.0
Wf-XML 2.0
Bekannt seit Oktober 2003
Organisation WfMC (Workflow Management Coalition)
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 26
Kommerzielle
Anbieter
IBM, CARNOT, SAP
Kommerzielle
Tools
CARNOT: CARNOT eProcess Engine
IBM: MQ Series message-oriented middleware product
SAP: SAP WebFlow
Versata: Versata Logic Server
Schnittstelle Wired Protocol: AWSP (Asynchronous Web Services Protocol)
Message Wrapper: SOAP (Simple Object Access Protocol)
Tabelle 1: Überblick des Standards Wf-XML 2.0
Wf-XML ist ein Industriestandard, der von der Workflow Management Coalition
festgelegt wurde, einem unabhängigen Gremium von Workflow-Anwendern.
Wf-XML basiert auf dem XML Standard. Innerhalb des Standards ist die
Unterscheidung zwischen den folgenden Operationskomponenten vorhanden (vgl. [Volz
2002]):
• ProcessDefinition: Beschreibung der Funktionalität eines Dienstes.
• ProcessInstance: Instanziierung einer Process Definition.
• Observer: überwacht und kommuniziert mit der Process Instance.
Process InstanceProcess Definition Observer
CreateProcessInstanceGetProcessInstanceData
ChangeProcessInstanceStateProcessInstanceStateChanged
Abbildung 5: Wf-XML Operationskomponenten
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 27
Wf-XML bietet eine message-basierte Architektur für die Kommunikation von
Workflow Engines und dient zur Unterstützung der Interoperabilität zwischen mehreren
Workflow Management Systemen in der Internet-Umgebung.
Grundlegendes Prinzip von Wf-XML ist ein Ressourcenmodell, welches die Interaktion
zwischen einem Workflow-„Dienstleister“ und einem Workflow-„Nutzer“ regelt.
Das Ressourcenmodell des Wf-XML-Standards umfasst die Rolle eines Service-
Requesters, der einen Workflow auf einem entfernten System initiiert. Dazu sendet
dieser eine Nachricht an einen Process Manager („CreateProcessInstance“), der
daraufhin eine Instanz des angeforderten Prozessmodells anlegt und deren Adresse an
den Requester zurückmeldet. Der Requester hat die Option, einen Observer zu
benennen, der im weiteren Verlauf über den Fortschritt des instanziierten Workflows
informiert wird. Requester und Observer können eine logische Einheit bilden (wenn der
Starter eines Workflows auch der Empfänger der Resultate ist). Denkbar ist jedoch auch
eine Trennung von Requester und Observer, wenn beispielsweise ein Unternehmen im
Auftrag eines Kunden einen Sub-Workflow über das Wf-XML Protokoll instanziiert,
die Ergebnisse dieses Workflows aber direkt an den Kunden gemeldet werden sollen
(vgl. [Becker/Muehlen 2001]). Nachfolgend wird ein Beispiel in Abbildung 6 gezeigt:
Abbildung 6: Wf-XML Interoperation Beispiel
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 28
3.2.2. BPML (BPMN, BPQL)
BPML (BPMN,BPQL)
Bekannt seit März 2001
Organisation Bpmi.org
Kommerzielle
Anbieter
IBM, Intalio, SAP, SUN, Versata, CSC, SeeBeyond, Popkin Software
Kommerzielle
Tools
Popkin Software & System: System Architect
Schnittstelle Query Language: BPQL (Business Process Query Language)
Interoperation: WSCI (Web Service Choreography Interface)
Tabelle 2: Überblick des Standards BPML
BPML (Business Process Modeling Language) ist eine XML-basierte, direkt
ausführbare und plattformunabhängige Metasprache, die von der Organisation bpmi.org
entwickelt wurde, um Geschäftsprozesse einheitlich und umfassend zu beschreiben (vgl.
[Russmann, o. J.]). Tools zur Modellierung von Prozessen, die BPML unterstützen,
ermöglichen es, graphisch modellierte Prozesse unmittelbar in ausführbaren Code zu
transformieren, der von einer Prozess-Engine interpretiert werden kann. Zur Ergänzung
wurde mit BPMN (Business Process Modelling Notation) ein Standard für die
graphische Notation dieser Modelle geschaffen und mit BPQL (Business Modeling
Query Language) eine vom Ziel her mit SQL (Structured Query Language)
vergleichbare Sprache zum Aufruf von Funktionen konzipiert.
BPMN ist ein Standard zur Notation von internen und externen Geschäftsprozessen, der
von verschiedenen Unternehmen und den unterschiedlichsten Werkzeugen zur
Prozessmodellierung verstanden und verarbeitet werden kann.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 29
BPQL ist eine Abfragesprache, die von bpmi.org als Ergänzung zu BPML entwickelt
wird. So wie SQL dazu dient, Datenbanken basierend auf Standards mit Hilfe eines
DBMS (Data Base Management System) zu verwalten, hat BPQL zum Ziel, die
Verwaltung von Prozessen mittels eines BPMS (Business Process Management System)
zu erleichtern.
<package>
<feature> <import> <identity> <prozess> <property><schedule>
<compensation><value>
<parameters> <event> <activitySet> <context>
<input> <output> <exception> <signal> <faults><activityList>
<action>
<all>
<assign>
<choice>
<call> <compensate> <delay> <empty> <fault> <foreach> <raise> <sequence>
<spawn>
<synch>
<unit>
<while>
Abbildung 7: BPML Elemente (XML Schema)
3.2.3. BPEL4WS
BPEL4WS
Bekannt seit August 2002
Organisation OASIS WSBPEL Technical Committee
WebServices.Org
Kommerzielle
Anbieter
BEA, IBM, Microsoft, Oracle, SAP, Siebel
Kommerzielle
Tools
BEA: Weblogic Integration 8.1
Collaxa: Collaxa BPEL Server 2.0
IBM: WebSphere Business Integration Server Foundation (WBISF)
Microsoft: BizTalk Server 2004
Oracle: Oracle BPEL Process Manager
PolarLake: PolarLake Integration Suite v4.0
SAP: NetWeaver XI
Siebel: Universal Application Network
Tibco: Tibco Business Works
Schnittstelle Registry and Agreements: UDDI
Private Process Description: BPEL4WS (Executable Process)
Public Process Description: BPEL4WS (Abstract Process)
Service Description: WSDL
Message Wrapper: SOAP
Transport Layer: HTTP, SMTP, FTP
Tabelle 3: Überblick des Standards BPEL4WS
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 31
BPEL4WS (Business Process Execution Language for Web Services) ist eine Sprache
zur Modellierung von Prozessen, die gemeinsam von den Unternehmen BEA,
IBM(WSFL) und Microsoft (XLANG) entwickelt wurde. Ihr Zweck ist es, einzelne
Web Services zu einer Abfolge von lose gekoppelten Prozessschritten zu verbinden.
Dies wird auch als Orchestrierung bezeichnet. Das dabei verwendete Modell ist dem
von BPML sehr ähnlich und bereitet damit den Weg für die Schaffung eines
einheitlichen Standards in der BPM-Industrie. Beide Sprachen habe ihre Wurzeln in
Web Services (SOAP, WSDL, UDDI), verwenden dieselben XML-Technologien
(XPath, XSDL) und verbessern die Möglichkeiten anderer Spezifikationen wie z.B.
WS-Security und WS- Transactions.
Abbildung 8: BPEL4WS Elemente (XML Schema)
Zur Modellierung des Prozessmodells nutzt BPEL4WS die folgenden Elemente (vgl.
[Andrews/Curbera/Dholakia 2003]):
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 32
• Geschäftsprozess: Die Abarbeitung eines orchestrierten Service wird als
Geschäftsprozess bezeichnet.
• Partner: Partner können Systeme sein, die Funktionen des Geschäftsprozesses
nutzen wollen, oder Web-Services, deren Funktionen ein Geschäftsprozess
nutzen möchte.
• Variablen: Innerhalb eines Geschäftsprozesses werden Nachrichten zwischen
den definierten Partnern ausgetauscht. Zur Speicherung dieser Nachrichten dient
dem Element variables.
• Aktivitäten: Der Ablauf eines Geschäftsprozesses wird über Aktivitäten gesteuert,
die sich in Basisprimitive und strukturierende Aktivitäten unterscheiden lassen.
Basisprimitive sind z. B. das Element receive, das durch den Empfang einer Nachricht
einen Geschäftsprozess initialisiert, oder als Gegenstück die reply-Aktivität. Diese
sendet eine Antwort an den Service Requestor. Ein weiteres wichtiges Element ist
invoke. Es dient zum Aufruf von Web Services, die von den externen Partnern des
Netzwerks angeboten werden (vgl. Abbildung 9).
Abbildung 9: Abarbeitung eines BPEL4WS Prozesses (vgl. [Cubera et al. 2003, S.9])
3.2.4. ebXML
ebXML
Bekannt seit November 1999
Organisation OASIS (develops the technical foundations of ebXML)
UN/CEFACT (ebtwg.org) (develops the ebXML business Processes)
ebXML.org (The ebXML web site with all important documents and
links
freeXML.org
Kommerzielle
Anbieter
Unternehmen aus 14 Ländern, eigentlich alle außer Microsoft
Kommerzielle
Tools
BEA Systems Inc.: BEA WebLogic
Bind Systems Ltd.: BindStudio
Sun Microsystems: Sun ONE Integration Server
Sybase Inc.: Business Process Integrator, PowerDesigner
Schnittstelle Contracts and Agreements: CPA (Collaboration Protocol Agreement)
Registry and Discovery: ebXML Registry and Repository, ebRIM -
Registry Information Model, ebRS - Registry Services
Private/Public Process Description: ebBPSS (Business Process
Specification Schema)
Service Description: ebBPSS (Business Process Specification Schema),
ebCPP (Collaboration Protocol Profile)
Message Wrapper: SOAP
Transport Layer: HTTP, SMTP, FTP
Tabelle 4: Überblick des Standards ebXML
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 34
ebXML (Electronic Business XML) ist eine Spezifikationen, die ein modulares
elektronisches Framework anbietet, durch welches ortsunabhängig zwischen beliebigen
Partnern Geschäfte abgewickelt werden können. Ziel ist die Bereitstellung einer offenen
XML-basierten Infrastruktur, welche die weltweite Nutzung von Information über
electronic Business in einer interoperablen, sicheren und konsistenten Art für alle
Beteiligten gewährleistet.
In ebXML bilden Schemata die Verknüpfung der E-Business-Prozessmodellierung mit
der Spezifikation der E-Business-Softwarekomponenten und zeigen den
Informationsfluss von Geschäftstransaktionen. Die Spezifikation des
Verhandlungsprozesses (Business Process Specification) definiert den Austausch von
Geschäftsdaten in Form von Dokumenten, welche im Rahmen von Transaktionen von
einem Geschäftspartner zum anderen transportiert werden. Datei können mehrere
Einzeltransaktionen zusammen komplexe Kollaborationen bilden. Ein weiterer Teil der
ebXML-Spezifikationsfamilie ist das BPSS. Der Fokus liegt hier auf
Geschäftsprozessen zwischen mehreren Unternehmen (vgl. [Barham/Boseman/
McCarthy et al. 2003]).
3.3. Standards im Projektmanagement
3.3.1. MS Project XML
MS Project XML
Bekannt seit 2003
Organisation Microsoft
Kommerzielle
Anbieter
Microsoft
Kommerzielle
Tools
Microsoft Office Project 2002/2003
Schnittstelle Keine
Tabelle 5: Überblick des Standards MS Project XML
Microsoft Project XML ist ein Software-Werkzeug für die Projektplanung und ist ein
Defacto-Standard im Projektmanagement. Seit der Version 2003 verwendet Microsoft
Project ein XML Format zum Datenaustausch. Damit ist es möglich die Daten aus
Microsoft Project in andere Systeme zu exportieren bzw. Daten aus anderen Systemen
zu importieren.
<Project>
<OutlineCode>
<WBSmask>
<ExtendedAttribute>
<Calendar>
<Task>
<Assignment>
<Resource>
Abbildung 10: MS Project XML Elemente (XML Schema)
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 36
3.3.2. PMXML
PMXML(Project Management XML)
Bekannt seit 2000
Organisation PMXML Konsortium
BizTalk.Org
Kommerzielle
Anbieter
Pacific Edge Software, eProject.com, Primavera Systems, Welcom,
Great Plains, PlanView, Onyx Software, u.s.w.
Kommerzielle
Tools
Pacific Edge Software: Project Office Connector
Schnittstelle HRXML
ERP
Tabelle 6: Überblick des Standards PMXML
PMXML (Project Management XML) ist eine XML-basierte Datendefinition für
Projektmanagementsysteme, eine Erweiterung des XML-Schemas. Das PMXML
Konsortium pflegt den Standard. Dieses dient zum Datenaustausch zwischen
verschiedenen Projektmanagementwerkzeugen.
Die PMXML Datendefinition, Version 2, beinhaltet Definitionen für vier wichtige
Datentypen des Projektmanagements und einige unterstützende Datentypen (vgl. [Volz
2002]). Die vier wichtigen Definitionen sind: Projekt, Ressource, Aufgabe und
Aufgabenzuordnung.
Die Definition beginnt mit dem ProjectManagementSchema als Wurzelelement.
Es beinhaltet (vgl. [Volz 2002]):
• InstanceData, eine Menge von benutzer- und anwendungsspezifischen Daten
• PoolResources, eine Menge von Ressourcen-Definitionen
• Projects, eine Menge von Projekt-Definitionen
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 37
3.4. Weitere Standards
3.4.1. DSML v2
DSML v2
Bekannt seit April 2002
Organisation OASIS
W3C
BizTalk
Kommerzielle
Anbieter
Bowstreet, IBM, Microsoft, Novell, Oracle, Sun-Netscape
Alliance,Aspire Technology, C-bridge Solutions, Credit Suisse Group,
Critical Path, CSC, DataChannel, Haht Software, Lotus, Mission
Critical Software, NetVision, Netegrity, Network Decisions, Nortel
Networks, Oblix, Ontology.org, Process Software, Red Hat, TSI
Software, Vtopia, Xevo.
Kommerzielle
Tools
Bowstreet: Bowstreet™ Business Web Factory.
Microsoft: Active Directory
Novell: eDirectory
IBM: IBM Tivoli Directory Integrator, IBM Tivoli Directory Server
Critical Path: Critical Path™ Identity Management Solutions, Critical
Path Data and Directory Integration Solution
Jamcracker: Pivot Path
Schnittstelle JDNI ( Java Naming and Directory Interface)
LDAP ( Light Directory Access Protocol)
SOAP ( Simple Object Access Protocol)
Tabelle 7: Überblick des Standards DSML v2
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 38
DSML v2 (Directory Services Markup Language version 2.0) ist eine XML Anwendung,
durch welche Informationen aus einem Verzeichnis über XML für E-Business und E-
Commerce verfügbar gemacht werden. Sie dient dem Zugriff auf Verzeichnisdienste
(z.B. durch query, update, result) um die Verzeichnisinformationen von XML-basierten
Anwendungen wirksam als XML einzusetzen.
Mit einem anerkannten Standard wie DSML können Anwendungen entwickelt werden,
welche die Vorteile Skalierbarkeit, Replikation, Sicherheitsfunktionen und umfassender
Managementfunktionalitäten eines Verzeichnisdienstes nutzen. Mit dem DSML
Standard kann jede XML-basierte Anwendung die Vorteile eines Verzeichnisdienstes
nutzen, der ebenfalls XML basiert ist.
Im Folgenden ist ein Beispiel von DSML angegeben:
<dsml:dsml xmlns:dsml="http://www.dsml.org/DSML"> <dsml:directory-entries> <dsml:entry dn="uid=jtang,dc=pavone,dc=com"> <dsml:objectclass> <dsml:oc-value>top</dsml:oc-value> <dsml:oc-value>account</dsml:oc-value> </dsml:objectclass> <dsml:attr name="cn"> <dsml:value>Jing Tang</dsml:value> </dsml:attr> <dsml:attr name="loginShell"> <dsml:value>/bin/bash</dsml:value> </dsml:attr> </dsml:entry> </dsml:directory-entries> </dsml:dsml>
Abbildung 11: Beispiel von DSML
3.4.2. HRXML
HRXML
Bekannt seit Mai 2002
Organisation HR-XML Konsortium
Kommerzielle
Anbieter
Microsoft, IBM, Sun, Oracle, PeopleSoft, SAP, Novient
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 39
Kommerzielle
Tools
Novient: eServices system
SAP: eRecruitment
Oracle: Human Resources Management System, iRecruitment
Ultimate Software: UltiPro ( HRMS/Payroll)
Schnittstelle Unicru and HireCheck HR-XML Background Check Interface
MERit Systems Creates HR-XML Link to Credit Bureaus
Resume Mirror Offers Customers Easy Integration Via HR-XML and
Web Services
Oracle iRecruitment Leverages HR-XML To Aid Partner Integration
TriZetto Enables Easy Enrollment Integration Using HR-XML
Allegis Group´s Thingamajob.com Connects to Internet Career Sites
Via HR-XML
SAP and BrassRing Systems: Fast and Flexible Partnering Via HR-
XML
Cisco Systems Implements HR-XML
Tabelle 8: Überblick des Standards HRXML
HRXML (Human Ressource XML) beinhaltet über 75 unabhängige XML Schemata.
Diese dienen dem allgemeinen Datenaustausch von E-Commerce und HR Daten.
XML Standards:
Strategic HR/Cross-Process Objects:
• Competencies, Version 1,0 (2001-10-16)
• ContactMethod, Version 1.0 (2002-01-31)
• Date Time Data Types, Version 1.1 (2001-10-16)
• Effective Dating, Version 1.0 (2001-07-17)
• Entity Identifiers, Version 1.0 (2002-05-01)
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 40
• Job and Position Header, Version 1.0 (2002-01-31)
• Person Name, Version 1.2 (2001-10-16)
• Postal Address, Version 1.2 (2001-10-16)
• Provisional Envelope Specification, Version 1.0 (2000-11-08)
• User Area, Version 1.0 (2002-05-01)
• Work Site and Environment, Version 1.0 (2002-01-31)
Risk Management:
• Background Checking, Version 1.0 (2002-05-01)
3.5. PAVONE-spezifische XML-Standards
3.5.1. Workflowmodellierung (ProcessModeler XML)
ProcessModeler XML
Bekannt seit 2000
Organisation PAVONE AG
Kommerzielle
Anbieter
PAVONE AG, CommerceQuest
Kommerzielle
Tools
Traxion Workflow Engine
Schnittstelle Keine
Tabelle 9: Überblick des Standards ProcessModeler XML
Der ProcessModeler XML ist ein von der PAVONE AG entwickeltes XML-Schema um
eine Schnittstelle zu anderen Workflowmodellierungs-Tools oder Workflow Engines
herzustellen.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 41
Abbildung 12: ProcessModeler XML Elemente (XML Schema)
3.5.2. Organisationsmodellierung (OrganizationModeler XML)
OrganizationModeler XML
Bekannt seit 2000
Organisation PAVONE AG
Kommerzielle
Anbieter
PAVONE AG, CommerceQuest, MultiSupport
Kommerzielle
Tools
PAVONE OrganizationModeler,
Traxion
Schnittstelle Keine
Tabelle 10: Überblick des Standards OrganizationModeler XML
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 42
OrganizationModeler XML ist ein von der PAVONE AG entwickeltes XML-Schema.
Es dient zur Speicherung von Organisationsstrukturen in einem XML Format.
Abbildung 13: OrganizationModeler XML Elemente (XML Schema)
3.5.3. PAVONE ProcessModeler Einordnung
Die PAVONE AG hat seit dem Jahr 2000 ein eigenes spezifisches XML für
Workflowmanagement und Organisationsmanagement entwickelt. Es ist faktisch nicht
durchführbar und sehr aufwändig, alle vorhandenen XML Schemata in einem
standardisierten XML neu zu definieren. Deshalb ist es aus der Sicht von PAVONE AG
sinnvoll, Datenaustausch mit Standard XML zu ermöglichen. Um diese Ziele zu
realisieren soll im Rahmen dieser Arbeit eine effiziente Methode entwickelt werden.
Die Methode besteht aus der Entwicklung einer Schnittstelle zur Transformation
zwischen PAVONE spezifischen XML und das Standard XML. Hierdurch ergibt sich
der Vorteil, dass ein einfacher Datenaustausch mit anderen Anwendungen per Standard
XML möglich wird. Dadurch wird ein Mehraufwand vermieden und die Realisierung
von Web Services stark erleichtert.
Der Schwerpunkt der Implementierung der Diplomarbeit liegt auf dem ProcessModeler,
einem Produkt der PAVONE AG. Der ProcessModeler ist ein Visualisierungswerkzeug
für die Modellierung des Prozess Designs, Simulation und Analysieren in WfMS (vgl.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 43
[Zhang 2001]). Für das Geschäftsprozessmanagement existieren bereits zwei Standards:
BPML und BPEL4WS.
BPEL4WS wird von kommerziell marktbeherrschender Software wie IBM WebSphere,
Microsoft Biztalk, SAP NetWeaver und ARIS usw. gut unterstützt. Darüber hinaus
verfolgt die Industrie-Initiative OASIS die Weiterentwicklung BPEL4WS zu einem
lizenzfreien offenen Industriestandard für die Orchestrierung von Web Services. Es
erscheint deshalb sinnvoll innerhalb des ProcessModeler auch BPEL4WS zu
unterstützen.
Ein anderer Vorteil ist, dass die PAVONE AG ein Business Partner von IBM ist,
vorhandene Software (IBM WebSphere) bereits zur Verfügung steht. Deswegen wird
sich die weitere Untersuchung auf BPEL4WS konzentrieren, und zwar für die folgenden
Bereiche:
• Die Möglichkeit und Lösung für den PAVONE ProcessModeler daraufhin zu
untersuchen, ob der neuste Workflow Standard benutzt werden kann.
• Sowie ob mit dem existierenden PAVONE ProcessModeler BPEL4WS
kompatible Workflow Werkzeuge (z. B. IBM WebSphere, Microsoft Biztalk)
genutzt und angebunden werden können. Sofern dies möglich ist, soll eine
prototypische Implementierung umgesetzt werden.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 44
4. Konzept einer generischen Schnittstelle
BPEL4WS ist eine Sprache, um mit Workflow-Technologien aus vorhandenen Web
Services neue, kombinierte Web Services zusammenzustellen. Das Upgrade, welches
den PAVONE ProcessModeler um BPEL-Unterstützung erweitert, wurde in der Arbeit
aus Sicht von zwei Vorgehensweisen untersucht und wird in den beiden folgenden
Architekturgrafiken dargestellt.
Die Abbildung 14 beschreibt, dass der ProcessModeler die Laufzeitumgebung für einen
BPEL-basierten Geschäftsprozess ist. Der Geschäftsprozess kann im Gegenzug auch auf
andere Anwendungen von PAVONE zugreifen. Dieses Verfahren findet vor allem bei
der Transformation von BPEL in das native Format des ProcessModelers Anwendung.
PAVONE ProcessModeler
BPEL
Concrete function wrapped by Web Service interface
Database
Web Service Interface
EJB
Web Service InterfaceWeb Service Interface
Legacy Program
MS .NET
Abbildung 14: Architektur von BPEL und ProcessModeler (1)
Die zweite Architekturgrafik verdeutlicht den Vorteil von Web Services. Die
Bereitstellung der konkreten Funktionen des BPEL-Prozesses wird von Web Service-
Instanzen durchgeführt. Implementierungsdetails der BPEL-Prozesse sind unterhalb der
Web Service Schnittstelle versteckt. Damit ist es möglich, dass der ProcessModeler bzw.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 45
andere PAVONE Anwendungen als Legacy Systeme in Web Service Schnittstellen
verpackt werden, um danach von BPEL Prozess aufgerufen werden zu können. Der
Fokus dieser Architektur liegt auf der Verwendung von Web Services.
IBM WebSphereBPEL
Database
Web Service Interface
EJB
Web Service Interface
PAVONEProcessModeler / Excel
Web Service Interface
MS .NET
Abbildung 15: Architektur von BPEL und ProcessModeler (2)
4.1. Ausführen BPEL Process
Der ProcessModeler unterstützt das eigene Prozess Definition Format - ProcessModeler
XML, welches ein XML Dialekt ist. Es ist bedeutungsvoll für den ProcessModeler,
einen öffentlichen XML Standard wie BPEL4WS zu unterstützen und den von BPEL
abgebildeten Prozess ausführen zu können. Deshalb wird die Transformation von
BPEL4WS in das ProcessModeler XML untersucht. Es gibt 3 Möglichkeiten dies zu
implementieren. Diese werden in Abbildung 16 dargestellt und im Folgenden
ausführlich erläutert.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 46
Abbildung 16: Nutzungsansätze von BPEL XML im ProcessModeler
4.1.1. VB Parser für BPEL XML
Im ProcessModeler gibt es bereits einen VB Parser für ProcessModeler XML. Es ist
auch möglich, einen VB Parser für BEPL manuell zu schreiben.
Im ProcessModeler ist das Prozessmodell im XML Format gespeichert. Dies wird von
einem in VB implementierten XML Parser unterstützt. Die MSXML ActiveX
Komponente kann angewendet werden, um eine DOM (Document Object Model)
Schnittstelle zu liefern, und somit die Aufgabe leichter zu machen. Um BPEL zu
unterstützen, sollte die Transformationslogik auf vorhandenen XML Parsing Code
implementiert werden.
Vorteile:
• Für den ProcessModeler wird eine neue Funktion hinzugefügt, d.h.
Export/Import Funktionen werden durch Visual Basic implementiert.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 47
• Transformation zu/von BPEL kann eine neue Funktion sein, die im
ProcessModeler fest integriert ist. Weitere Prozesse können nach dem
Importieren/Exportieren der BPEL Prozess ausgelöst werden.
• Nicht-XML formatierte Informationen wie die Zweigbedingungen können durch
umfangreiche Funktionalitäten der Hochsprache Visual Basic leichter
gehandhabt werden.
• Einheitliche Entwicklungsumgebung des Prozessmodells, die gleiche Sprache
und Werkzeuge verwendet. Dies reduziert den Wartungsaufwand und potentielle
Fehler sowie einen Leistungsrückgang der Komponenteintegration.
Nachteile:
• Es muss eine DTD oder XSD für BPEL als Standard XML neu definiert werden.
Daher muss ein neuer Parser in Visual Basic geschrieben werden.
• Die vorhandene ProcessModeler DTD und der entsprechende alte Parser für
ProcessModeler XML können in diesen Fall nicht für die Transformation weiter
verwendet werden.
4.1.2. Transformation durch XSLT
Die zweite Möglichkeit ist, dass durch XSLT vom ProcessModeler XML nach BPEL
und umgekehrt transformiert wird. Die Transformation des BPEL kann mit XSLT durch
den unterstützten XML Parser implementiert werden.
Vorteile:
• XSL ist eine Standard XML-Prozess Methode und eine weit verbreitete
Programmiersprache.
• Die Strukturen und Elemente von ProcessModeler XML können eingehalten
werden.
• Das Transformieren von XML durch XSL ist unabhängig von
Programmiersprachen. Durch diesen großen Vorteil ist der Quellcode flexibel
für Modifikationen. Daher können die entwickelten XSLT Programme für
weiteren XML Daten mit geringem Aufwand wieder verwendet werden.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 48
Nachteile:
• Die XSL Syntax ist kompliziert. Der funktionelle Programmierstil (vgl.
[Novatchev]) ist schwerer zu erlernen als die weit verbreiteten, allgemein
akzeptierten, imperativen Sprachen wie Basic, C/C++, und Java. Dies führt zu
höheren Personalkosten für Entwicklung und Wartung.
• XSLT ist dediziert für die Verarbeitung von XML-Dokumenten. Nicht-XML
formatierte Informationen, wie die Zweigbedingungen, sind schwierig zu
handhaben.
• XSLT ist nicht im ProcessModeler integriert, d. h. es gibt keinen XSLT Parser
im ProcessModeler, deswegen kann XSLT nicht direkt vom ProcessModeler
gelesen werden. Der ProcessModeler kann nur die transformierte XML Datei
importieren.
4.1.3. Transformation durch JAVA
Eine weitere Variante ist DOM oder SAX (Simple API for XML) in Java. DOM und
SAX sind die Programmierschnittstellen (API) für verschiedene Sprachen zur XML
Verarbeitung. Die beiden Standards sind in der Java Standard Plattform integriert. Bei
DOM erfolgt der XML-Zugriff sehr einfach über einen Objektbaum. Diese Methode ist
jedoch für große Dokumente weniger gut geeignet, da sehr viel Speicherplatz benötigt
wird. Anders als bei DOM wird bei SAX das XML-Dokument sequentiell durchlaufen,
so dass auch große Dokumente effizient bearbeitet werden können.
Vorteil:
• Die Syntax der Programmiersprache Java ist einfach.
Nachteil:
• Eine Modifikation ist aufwendig zu realisieren.
4.1.4. Analyse und Lösung
MSXML ActiveX Komponente bietet eine DOM Schnittstelle, welche in Visual Basic
benutzt werden kann. Mit Hilfe dieser DOM Schnittstelle in VB ist es möglich, XML
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 49
als DOM-Objekt zu bearbeiten. Die Java Lösung ist ähnlich. Java unterstützt DOM gut
und bietet ebenfalls eine Schnittstelle. Die Klasse DOM kann direkt importiert werden
um XML in Java zu bearbeiten. Daher sind bezüglich der Programmierung zwei
Lösungen möglich. Der Unterschied ist, dass die VB-Lösung eine Erweiterung des
PAVONE ProcessModelers ist, die BPEL zusätzlich unterstützt. Da der ProcessModeler
eine DOM Schnittstelle benutzt und in VB ein Parser geschrieben wird, um BPEL zu
unterstützen. Demgegenüber stellt die Java-Lösung eine Erweiterung der
Entwicklungsumgebung dar. Mit dieser Entwicklungsumgebung, die BPEL unterstützt,
wird der PAVONE ProcessModeler erweitert.
Die XSLT Lösung ist zwar auf Grund der komplizierten Syntax von XSL technisch
aufwändiger als die anderen Lösungen. Aber die Strukturen und Elemente der
ProcessModeler XML können eingehalten werden und die Funktionalität des
ProcessModelers kann ohne zusätzlichen Aufwand benutzt werden. Die Popularität und
Programmiersprachenunabhängigkeit der XSLT in Bereich XML ist auch ein
entscheidender Punkt für diese Arbeit. Mit XSLT kann man die allgemeinen Probleme
im Gebiete XML-Transformation untersuchen ohne Beschränkungen von
Programmiersprachen.
Daher wird XSLT als Lösung ausgewählt, um eine generische Schnittstelle zu
implementieren. Die Umsetzung dieser Lösung wird im nächsten Kapitel vorgestellt.
4.2. Choreographierung von BPEL Prozess
Außerhalb des Ausführens des BPEL4WS Prozesses ist es für das PAVONE AG
Produkt eine wertvolle Erweiterung, wenn der vom ProcessModeler abgebildete
Business Prozess in den BPEL Prozess integriert werden kann.
Wie in obigem Kapitel erörtert, können die Web Services von BPEL4WS aufgerufen
werden. Für Legacy Programme wird deshalb eine Schnittstelle benötigt, durch die eine
Web Service Schnittstelle angeboten wird, damit diese Funktionen von einem BPEL
Prozess aufgerufen werden können.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 50
Die zweite Hauptaufgabe der Diplomarbeit besteht darin, eine mögliche
Implementierung einer Web Services Schnittstelle in einem Legacy Programm zu
untersuchen.
4.2.1. Web Services
Web Services im engeren technischen Sinn bedeuten automatisierte Kommunikation
zwischen Applikationen über das Internet. Es werden also nicht HTML-Seiten zu einem
Webbrowser geschickt, die von einem Menschen betrachtet werden, sondern
Programme tauschen Daten aus und starten auf entfernten Rechnern Funktionen
(Remote Procedure Call) (vgl. [Horn]).
Während bisher bei verteilter Kommunikation über Rechnergrenzen hinweg meistens
per CORBA, RMI oder DCOM erfolgte, nutzen Web Services einfaches XML, welches
meistens per HTTP übertragen wird.
Ein großer Vorteil gegenüber klassischer Middleware ergibt sich aus dem
Serviceorientierten Ansatz der Web Services. Dies hat zur Folge, dass ein potenzieller
EAI-Server, der als zentraler Informationsbroker einzelne Anwendungen miteinander
verbindet, seine Dienste auch beschreiben kann. Das können bestimmte
Funktionalitäten sowie benötige Übergabe und gelieferte Rückgabeparameter sein.
Diese technische Beschreibung erfolgt mithilfe von WSDL-Dateien. Der angebotene
Dienst kann nun unter Zuhilfenahme von öffentlichen oder auch firmeninternen UDDI-
Verzeichnisservern publiziert werden. Der Datenaustausch zwischen Servicenutzer und
Serviceanbieter findet über SOAP statt.
Abbildung 17 zeigt diesen Ablauf anhand des WebServices-Modells.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 51
ServiceRegistrierung
ServiceBenutzer
ServiceAnbieter
UDDI ServiceBeschreibung
Service
ServiceBeschreibung
Publizieren:UDDI, WSDL
Auffinden:UDDI
Kommunikation:SOAP
Rückgabe:WSDL
Abbildung 17: Das WebServices-Modell (vgl. [Kolb 2005])
Web Services basieren auf den Standards SOAP, WSDL und UDDI. Diese Standards
werden im Folgenden beschrieben.
4.2.1.1 SOAP (Simple Object Access Protocol)
SOAP ist ein Protokollstandard des W3C (vgl. http://www.w3.org/TR/soap). Durch
SOAP werden Applikationen webfähig und Kommunikation zwischen verteilten
Applikationen und Objekten ermöglicht und standardisiert (vgl. [Horn, T 2005]).
SOAP ist ein Remote Procedure Call (RPC)-Mechanismus, der mit dem
Datendarstellungsprotokoll XML die Anfrage (Request) und das Ergebnis (Response)
verschlüsselt.
Informationen, die nicht in XML-ASCII-Text übersetzt werden sollen, wie zum Beispiel
Bild- und andere Binärdateien, werden per MIME (Multipurpose Internet Mail
Extensions) an die Anfrage als Attachement angehängt.
SOAP kann mit verschiedenen Transportprotokollen verwendet werden. HTTP wird
jedoch bevorzugt gewählt, aber SOAP-Anfragen können beispielsweise auch per E-Mail
über die SMTP/POP3-Protokolle versandt werden. Durch die Nutzung dieser Standard-
Internetprotokolle (HTTP, FTP, SMTP) wird der Betrieb auch über Firewalls hinweg
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 52
ermöglicht. Bei den bisherigen Standards CORBA, RMI und DCOM war dies ein
wesentliches Problem wegen der Kommunikation über Unternehmensnetze hinweg.
SOAP ist unabhängig von Betriebssystemen, Programmiersprachen und
Objektmodellen. Es kann verschiedene Plattformen verbinden (z.B. .NET und Java) und
ist leichter zu implementieren als CORBA und DCOM.
Der Bestandteil „Object“ im „Simple Object Access Protocol“ bedeutet nicht wirklich
Objektorientiertheit. SOAP kann hervorragend in objektorientierten
Programmiersprachen umgesetzt werden. Es kann aber auch in nicht-objektorientierten
Programmiersprachen realisiert werden. Eine Übermittlung von Objekt-Referenzen ist
in SOAP nicht definiert. Die per SOAP aufrufbaren Funktionen sind mit statischen
Methodenaufrufen vergleichbar.
Eine Besonderheit von SOAP ist seine Zustandslosigkeit. Dies bietet Vorteile, zum
Beispiel der besseren Skalierung, hat aber auch Nachteile, wenn beispielsweise Session-
Daten zugeordnet werden müssen (z.B. innerhalb eines Warenkorb).
Die wichtigsten Vorteile von SOAP sind:
• allgemein akzeptierte Standardisierung innerhalb der IT-Industrie
• Plattformunabhängigkeit
• Offenheit
• Robustheit
• Skalierbarkeit
Der gravierendste Nachteil von SOAP ist jedoch der erhöhte Aufwand zur Übermittlung
der Daten als XML gegenüber der binären Kodierung, da dies eine höhere Datenmenge
und Verarbeitung (Parsing des XML) verursacht.
4.2.1.2 WSDL (Web Services Decription Language)
WSDL ist ein XML-Derivat zur Beschreibung der Schnittstellen von Web Services, in
der Nachrichtenstrom-Formate und Funktionsaufrufe definiert werden. WSDL kann für
die Beschreibung von Webdiensten verwendet werden und ist eine XML basierte
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 53
Notation, deren XML-Schema unter http://schemas.xmlsoap.org/wsdl bezogen werden
kann. Um das Zusammenspiel von Web Services, die auf unterschiedlichen Plattformen
ausgeführt werden, zu erleichtern, wurde WSDL von Ariba, IBM und Microsoft beim
W3C zur Standardisierung eingereicht.
Das Prinzip lässt sich einfach skizzieren: Eine WSDL-Beschreibung ist hierarchisch
aufgebaut und enthält fünf Abschnitte, die durch die XML-Elemente <types>,
<message>, <portType>, <binding> und <service> gekennzeichnet sind.
Die ersten drei Abschnitte (<types>, <message>, <portType>) nennt man den
„abstrakten“ Teil. Die beiden letzten Abschnitte (<binding>, <service>) werden
als „konkreter“ Teil einer WSDL-Beschreibung bezeichnet (vgl. Abbildung 18).
<definitions> <types> … hier werden die verwendeten Datentypen beschrieben </types> <message name=”KontoAnfrage”> … hier werden die Parameter einer Nachricht beschrieben </message> <message name=”KontoAuskunft”> ... </message> <portType name=”KontoZugriffsPort”> <operation name=”KontoZugriff”> <input message=”KontoAnfrage” /> <output message=”KontoAuskunft” /> </operation> </portType> <binding name=”KontoAuskunftSoap”> ... </binding> <service name=”KontoAuskunftsService”> ... </service> </definitions>
Abbildung 18: Beispiel von WSDL
Im abstrakten Teil werden unabhängig von einem Protokoll oder einem Service die
Operationen und verwendeten Datentypen beschrieben. Im konkreten Teil wird
beschrieben, über welche URI (Uniform Resource Identifier) und Protokolle ein Web
Service erreicht werden kann und wie die Daten serialisiert und codiert werden.
Das <types>-Element folgt unmittelbar auf das Wurzelelement <definitions> und
enthält jene Datentypen, die später in den Nachrichten (<message>) verwendet
werden. Eine WSDL-Beschreibung hat immer nur ein einziges <types>-Element,
kann aber mehrere <message>-Elemente enthalten.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 54
Im Abschnitt <portType> werden Operationen beschrieben. Eine Operation
(<operation>) besteht aus bis zu zwei Nachrichten. Soll eine Antwort an den Sender
zurückgesendet werden, so wird die eingehende Nachricht (<input>) mit einer
ausgehenden Nachricht (<output>) zu einer Operation zusammengefasst. Es werden
natürlich nur die im Abschnitt <message> beschriebenen Nachrichten verwendet.
Mehrere Operationen bilden schließlich einen Port-Typ. Eine WSDL-Beschreibung
kann mehrere <portType>-Elemente enthalten.
Der Abschnitt <binding> beschreibt, welches Transportprotokoll (z.B. SOAP und
HTTP) verwendet werden soll und wie die Daten der einzelnen Operationen kodiert
werden sollen. Für jedes unterstützte Transportprotokoll gibt es ein eigenes
<binding>-Element. Das <service>-Element beschreibt, unter welcher URI und
über welches Protokoll ein Service erreicht werden kann.
4.2.1.3 UDDI (Universal Description Discovery and Integration)
UDDI ist ein webbasiertes Informationssystem für Web Services. Es bietet ein
Verzeichnis von Adress- und Produktdaten sowie von Anwendungs-
Programmierschnittstellen (vgl. [Horn]). Eine Organisation, die Webdienste anbieten
möchte, kann eine UDDI-Registrierung auf UDDI-Server (UBR = UDDI Business
Registry Nodes) erstellen.
Hierbei handelt es sich um ein XML-Dokument, dessen Format in einem von UDDI
definierten Schema festgelegt ist. Danach werden die Registrierungen in einer
replizierten Datenbank gespeichert, welche UDDI Business Registry genannt wird.
Ein Eintrag in einer UDDI Business Registry kann auf zweierlei Arten erzeugt werden:
• entweder elektronisch mit speziellen "Publish-API"-URLs durch bestimmte
Funktionsaufrufe (z.B. "save_business()", "save_service()",
"save_tModel()")
• oder interaktiv im Webbrowser.
Eine Kopie der Business Registry wird von jeder UDDI-Operatorsite gepflegt. Diese
Sites kommunizieren miteinander, um die Konsistenz der gespeicherten Informationen
zu gewährleisten.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 55
Das XML-Schema für UDDI legt die gemeinsame Struktur für Registrierungs-
dokumente fest. Die folgende Skizze macht die Struktur einer UDDI-Definition deutlich
(vgl. [Software Kompetenz]):
<businessEntity businessKey=”…”> <name> … </name> <description> … </ description> <contacts> … </ contacts> <businessServices> <businessService serviceKey=”…”> … </businessService> </businessServices> </ businessEntity>
Abbildung 19: Beispiel von UDDI
Das Element <businessEntity>, der Container für alle anderen Elemente, enthält
das Attribut „businessKey“ (ein global eindeutiger Bezeichner für das jeweilige
Unternehmen) sowie weitere Informationen über die im Registrierungseintrag
beschriebene Organisation. Hierfür stehen Elemente wie <name>, <description> und
<contacts> zur Verfügung.
Schließlich enthält jedes <businessEntitity>-Element ein
<businessServices>-Element, das die von dieser Organisation bereitgestellten
Webdienste beschreibt. Das Element <businessServices> enthält mehrere
<businessService>-Elemente, die jeweils einen bestimmten Dienst beschreiben.
Ein Eintrag in einer UDDI-Registry kann auf zweierlei Arten gesucht werden:
• entweder elektronisch mit speziellen "Inquiry-API"-URLs durch bestimmte
Funktionsaufrufe (z.B. „find_business()“, „find_service()",
„find_tModel()“)
• oder interaktiv im Webbrowser.
Um auf die Daten einer UDDI-Registry zuzugreifen, verwendet die Clientsoftware stets
SOAP über HTTP. Dies bedeutet, dass UDDI selbst ein Webdienst ist. Dieser stellt ein
Inquiry-API und ein Publishing-API zur Verfügung.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 56
Die Aufrufe für Anwendungen, welche die Business Registry durchsuchen müssen,
bilden das Inquiry-API. Dazu gehören Aufrufe wie „find_business“ und
„find_service“, mit deren Hilfe man Informationen über bestimmte Unternehmen in
der Registry bzw. bestimmte Dienste innerhalb einer gegebenen
„businessEntity“ finden kann (vgl. [Software Kompetenz]).
Auf der anderen Seite müssen Anwendungen auch in der Lage sein, diese Informationen
zu erstellen und zu verändern. Hierfür stehen entsprechende Aufrufe wie
„save_business“ und „save_service“ zur Verfügung, mit deren Hilfe werden
Informationen für ein <businessEntity> bzw. für einen <businessService>
erstellt oder aktualisiert.
4.2.2. Legacy Programme als Web Service einbinden
Um von BPEL4WS aufgerufen werden zu können, muss der PAVONE ProcessModeler
als ein Web Service angepasst werden.
Wie viele andere Legacy Systeme wurde PAVONE ProcessModeler mit VB entwickelt,
eine der nativen Programmiersprachen wie z.B. auch C/C++, Object Pascal etc.
Microsoft ersetzt VB6 durch ein neues .NET basiertes VB. Diese neue Version ist
inkompatibel zu vorherigen Versionen. Alte Programme in früheren Versionen in der
neuen Version zu kompilieren scheitert deshalb regelmäßig.
Die Entwicklung von Web Services wird durch Entwicklungswerkzeuge des .NET
Frameworks unterstützt, aber Werkzeuge aus der Zeit vor .NET funktionieren nicht
mehr. Es muss deshalb ein Weg abseits von .NET verfolgt werden, um das Ziel,
PAVONE ProcessModeler einzubinden, zu erreichen.
Genau wie VB haben andere native Programmiersprachen wie C/C++ das gleiche
Problem. Die existierenden, mit Web Services verwandten ActiveX Komponenten und
Werkzeuge, die von Microsoft bereitgestellt werden (Office Web Services Toolkit (vgl.
[Microsoft])), werden verwendet, um Web Services als Client aufzurufen. Sie stellen
ihre Web Services jedoch als Server zur Verfügung. Deshalb ist die Bedeutung der
Aufgabe nicht auf PAVONE ProcessModeler und VB limitiert. Sie könnte vielmehr
bedeutungsvoll für das allgemeine Problem sein, beliebige Legacy Systeme mit
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 57
Technologie aus der Zeit vor Java/.NET in die Windowsplattform einzubinden. Der
Aufwand z.B., große Mengen von Desktop Software Web Service-fähig zu machen,
muss als sehr groß eingeschätzt werden.
Besonders klein- und mittelständische Unternehmen (KMU) nutzen nach einer
Untersuchung der Yahkee Group (vgl. [Mckie 2004]) Microsoft Excel für die
Buchhaltung, um die Software- Hardware-, und Schulungskosten zu senken. 11% der
KMU in den USA setzen nach dieser Studie diese Software ein.
Die Hauptaufgaben, um eine Web Service Schnittstelle zu implementieren, schließen
den Parsen von XML, sowie SOAP- und HTTP-Protokollimplementierungen mit ein.
Die ersten zwei Aufgaben sind nicht besonders kompliziert. Bei der letztgenannten ist
zu berücksichtigen, dass normale Web Services von einem Web Server abhängen, der
das HTTP Protokoll implementiert.
Dieser Ansatz hat den Vorteil, die Leistung und Skalierbarkeit von normalerweise gut
konfigurierten Web-Servern wie Apache verwenden zu können.
Overheads der HTTP-Protokollhandhabung können dadurch minimiert werden, dass der
Web Server von mehreren Web Services verwendet wird. Trotzdem ist die Aufgabe des
Deployment und der Implementierung kompliziert.
Es wird in dieser Lösung ein anderer Ansatz verwendet, um einen Web Server Thread
in jeden der Web Services Prozesse zu verpacken. Daraus resultiert eine Minimierung
der Änderungen bei Konfiguration und Wartung des Legacy Systems.
Die beiden vorgestellten Ansätze verwenden die aktuellsten Konzepte von XML und
Web Service Technologien. Sie besitzen generische Schnittstellen zu Komponenten von
Prozessmanagement, die von vielen EAI Anwendungen genutzt werden. Im nächsten
Kapitel wird die Implementierung der vorgestellten Technologien anhand eines
konkreten Beispiels erörtert.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 58
5. Beschreibung der Implementierung
5.1. PAVONE ProcessModeler und sein
Eigenschaftsformat
Der PAVONE ProcessModeler ist ein intuitiv nutzbares grafisches
Modellierungswerkzeug, mit dem Geschäftsprozesse leicht grafisch erstellt und
abgebildet werden können. Solche Prozesse können einfach sein, wie z.B. ein
Anleiheantrag (Abbildung 20) oder auch aus hunderten von verschiedenen Aufgaben
bestehen. Prozesse können neu erstellt oder bereits bestehende können angepasst
werden.
Abbildung 20: Einen Prozess in PAVONE ProcessModeler definieren
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 59
Die einzelnen Aufgaben werden in Form von Objekten angelegt und durch verschiedene
Attribute beschrieben. Attribute können sein: Personen- und Gruppennamen,
Aufgabentypen und Beschreibungen, Zeiten und Ressourcen.
Um die Weiterleitung zwischen den einzelnen Aufgaben darzustellen, werden
Verbindungslinien angelegt. Spezielle Bedingungen bei der Weiterleitung wie Oder-,
Und- sowie Entweder-oder-Verknüpfungen können zusätzlich festgelegt werden. Die
Gesamtheit all dieser Informationen, welche die Abwicklung eines Prozesses durch die
einzelnen Instanzen beschreibt, wird als Prozessdefinition bezeichnet und in einer
Prozessdefinitions-Datenbank abgespeichert. Für die Modellierung eines neuen
Prozesses kann auf existierende Prozessdefinitions-Datenbanken zurückgegriffen
werden, die als Baustein-Bibliotheken dienen. Auf ihrer Basis können im PAVONE
ProcessModeler einfach neue Strukturen erstellt werden (vgl. [PAVONE]).
Der ProcessModeler verfügt über ein natives XML Format, um Prozess-Informationen
zu speichern, inklusive dem Layout des Prozessdiagramms, Routing-Zuständen,
Simulationsparameter, etc.
5.2. Überblick der Implementierungswerkzeuge von
IBM WebSphere
Die WebSphere Business Integration Server Foundation (WBISF) setzt auf IBM
WebSphere Application Server Network Deployment (ND) auf, um eine auf Standards
basierende Integrationsplattform zur Erstellung und Implementierung von Business
Process Execution Language for Web-Services-Anwendungen (BPEL-Anwendungen)
und modularen web-service-basierten Anwendungen zur Verfügung zu stellen (vgl.
[IBM Software 2004]).
Kernstück der Prozesssteuerung ist der auf WebSphere basierende Process
Choreographer, eine Laufzeitumgebung für BPEL-1.1-konforme Prozessdefinitionen.
Der Choreographer läuft als J2EE-Anwendung auf dem genannten WebSphere
Application Server (WAS). Er kennt neben kurzlebigen, meist synchron aufgerufenen
Prozessinstanzen (Microflows) im flüchtigen Speicher auch solche, deren Aktivitäten
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 60
jeweils als Einzeltransaktionen aufgefasst und deren aktueller Status nach jedem Schritt
in einer zentralen Datenbank gespeichert wird. Somit kehren abgebrochene Instanzen
nach einem Neustart des WAS in einen definierten Zustand zurück, was insbesondere
für langlebige Prozesse, Macroflows genannt, von großer Bedeutung ist.
Mit der WebSphere Studio Application Developer Integration Edition 5.1 liefert IBM
die passende Entwicklungsumgebung auf Basis der Eclipse Plattform 2.1.2 sowie
zahlreiche Erweiterungen in Form von Plug-ins und bietet den grafischen Prozesseditor
an, um die Workflows zu kontrollieren. Der grafische Prozesseditor erscheint, der eine
umfangreiche Palette für alle BPEL-konformen sowie IBM-eigenen Aktivitäten anbietet,
die per Drag & Drop dem Prozessdesign hinzugefügt werden können. Der Editor zeigt
alle darin verwendeten Variablen und Partner-Links (Nachrichten- und Port-Typen bei
den Interaktionen mit anderen Web Services) und referenziert diese entsprechend. Für
komplexere Prozesse stellt der Choreographer eine so genannte Transformer-Funktion
zur Verfügung, mit der sich über XPath-Ausdrücke umfangreiche Datenmanipulationen
realisieren lassen. Unterstützung bei deren Formulierung gibt der dialoggestützte XPath
Expression Builder. Er beruht auf XPath 1.0 und kennt derzeit noch nicht den Sprach-
und Funktionsumfang von XPath 2.0.
Das Wizard-gesteuerte Deployment erstellt ein EAR (Enterprise Archive), das für den
ausgewählten Prozess neben der BPEL-Datei eine generierte Process EJB (Enterprise
Java Beans) enthält, die das Interface javax.ejb.SessionBean implementiert. Weiterhin
entstehen dabei WSDL-Dateien für die gewählten Protokolle und Nachrichtenformate
(Inbound Bindings) des durch den BPEL-Prozess neu eingerichteten Web Service. Zur
Auswahl stehen EJB/RMI (Default), SOAP/HTTP für Microflows sowie JMS (Java
Message Service) als Standard für asynchron aufzurufende Prozesse oder langlebige
Macroflows. Über den JNDI-Namen der Process EJB kann jede Java-Anwendung einen
im Choreographer installierten.
Ein Prozess kann über sein lokales oder fernes Interface wie jede andere Session Bean
instanziiert und gestartet werden. Andere Clients nutzen beispielsweise das
sprachneutrale SOAP-Binding.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 61
5.3. Entwicklung eines BPEL4WS Prozesses mit
WSAD-IE
Wie im Abschnitt 5.2 erwähnt wurde, bietet die WebSphere Business Integration Server
Foundation eine gute Unterstützung für BPEL4WS an. Die Entwicklungsumgebung
integriert die grafische Prozess-Modellierung Entwicklungsumgebung. Der BPEL
Prozess ist eine Vereinigung mehrerer Web Services. Jeder Web Service, der in einen
BPEL Prozess integriert wird, wird als „Partner“ bezeichnet. Der BPEL Prozess selbst
könnte auch als ein Web Services für anderen BPEL Prozesse zur Verfügung stehen.
Um einen BPEL Prozess zu definieren, editiert man die WSDL Datei, erstellt neue Web
Services und importiert existierende Web Services.
Die WSAD-IE übernimmt diese Aufgabe für:
• Teilweise automatische Generierung der WSDL Datei und abschließendes
Editieren mit einem interaktiven GUI.
• Automatisches Erstellen des Java-Quellcode für die Schnittstellen der Web
Services
• Automatische Generierung der von Aufrufen benötigten Messages und des
Quellcodes für die Behandlung der SOAP-Protokolle für externe Web Services
• Automatische Generierung des Quellcodes für Web-Client für den Zugriff des
BPEL Prozesses
• Automatisches Packen der EAR/WAR Dateien und deren Deployment
Dadurch erhöht sich die Effizienz beim Erstellen, Testen und Einsetzen der Web
Services.
Für die weitere Untersuchung wird ein BPEL Prozess Beispiel unter WSAD-IE
aufgebaut. Dieses Modell stellt den Prozess einer Lagerverwaltung dar. Und wird in
folgendem Flussdiagramm (Abbildung 21) beschrieben.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 62
1. Start
2. Get Stock
3. Stock-Request>10
4. Manager Approve
5. Print Note 6. Send Notify
7. End
Comment=true
Yes
No
No
Yes
Abbildung 21: Der Approve Prozess
1) Start: Der Start des Prozesses ist die Eingabe von Daten zu Material und Menge.
2) Get Stock: Der Prozess ruft automatisch die Services der Bestandsabfrage auf, und
überprüft dann die Bestandsmenge des Materials.
3) Stock Request: Je nach Bestandsmenge verzweigt sich der Prozess in einen der
folgenden Fälle:
Wenn die gebrauchte Menge des Materials größer als 10 ist, wird zum Schritt 4
verzweigt.
Sonst wird zum Schritt 5 verzweigt.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 63
4) Manager Approve: Der Abteilungschef überprüft die Bestellungsanfrage:
Genehmigt er sie, wird zum Schritt 5 verzweigt.
Lehnt er sie ab, verzweigt der Prozess zu Schritt 6.
5) Print Note: Ausdrucken der Bestellungsliste, dann zu Schritt 7.
6) Send Notify: Senden der Absagemeldung, dann zu Schritt 7.
7) End: Ende des Prozesses.
Get Stock, Print Note und Send Notify ist jeweils ein Web Service. Sie können beim
Editieren der Prozess mittels WSAD-IE in Java-Sprache implementiert und dann mit
approveProcess zusammen in WebSphere Application Server eingesetzt werden.
Es ist einfach den Web Service in WSAD-IE mit Java zu implementieren. Es muss nur
die Klasse definiert werden, die als Web Service exportierte Methoden ausgewählt
werden, der Quellecode für die Verarbeitung der Nachrichten und WSDL Dateien
werden automatisch generiert.
Die Funktion getStock() wird folgendermaßen als Web Service exportiert:
Zurerst wird die Java Klasse definiert: public class RetrieveStock { public int getStock(String serial) { System.out.println("Get Our Stock!"+serial); return 50; } }
Die getStock() Methode in der Klasse RetrieveStock ist ein Web Service. Dann wird die
WSDL Datei von WSAD-IE automatisch generiert, wie nachfolgend gezeigt: …… <binding name="RetrieveStockJavaBinding" type="interface1:RetrieveStock"> <java:binding xmlns:java="http://schemas.xmlsoap.org/wsdl/java/" /> <format:typeMapping encoding="Java" style="Java"> <format:typeMap formatType="int" typeName="xsd:int"/> <format:typeMap formatType="java.lang.String" typeName="xsd:string"/> </format:typeMapping> <operation name="getStock"> <java:operation methodName="getStock"parameterOrder="serial" returnPart="result"/> <input name="getStockRequest"/>
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 64
<output name="getStockResponse"/> </operation> </binding> …… <service name="RetrieveStockService"> <port binding="binding1:RetrieveStockJavaBinding" name="RetrieveStockJavaPort"> <java:address className="jingtang.process.RetrieveStock"/> </port> </service> ……
Der Quellcode zeigt, dass anstelle von SOAP ein Java Binding Protokoll benutzt wurde.
Wenn das System nur mit Java entwickelt wurde, vermeidet das Java Binding den
Übertragungsaufwand (Overhead) von SOAP.
In Abbildung 22 ist der Business Process, welcher in WSAD-IE realisiert wurde
abgebildet.
Abbildung 22: Definieren des Approve Prozesses in WebSphere
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 65
5.4. Transformieren der BPEL4WS Prozessdefinition
5.4.1. Durch XSL automatisch generieren
IBM WebSphere bietet eine grafische Umgebung an, um XML zu transformieren. Diese
ist zwar leicht zu bedienen, bietet aber nur einfache Möglichkeiten, zwischen Knoten zu
transformieren. Für komplex-logische Ausdrücke und Zusammenhänge im Kontext sind
die Möglichkeiten begrenzt, die Aufgaben zu übernehmen. Da gerade die
Transformation von BPEL Prozess nach PAVONE PM XML sehr komplex ist, wird der
XSLT Code für die Transformation manuell geschrieben.
5.4.2. Die Transformation mit XSLT
Sowohl BPEL4WS als auch ProcessModeler XML beschreiben gerichtete Graphen.
Jedoch sind die Beschreibungsmethoden anders. Es kann wie folgt beschrieben werden.
Abbildung 23: Transformieren der Aktivitätsbeziehungen von BPEL ins PAVONE
ProcessModeler Format
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 66
Der „Task“ im Prozess wird als Knoten in einem gerichteten Graph dargestellt. Die
logische Verbindung zwischen „Task“ wird als Kante bezeichnet. Zur Erklärung werden
diese beiden Begriffe weiter in folgendem Text benutzt.
Im BPEL Prozess gehören „Invoke“, „Receive“ und „Assign“ zu dem „Task“. Die
konkrete Bedeutung von „Invoke“, „Receive“ und „Assign“ wird in der Spezifikation
BPEL4WS Version 1.1 (vgl. [Andrews/Curbera/Dholakia 2003]) definiert. Es gibt keine
direkten Verbindungen der Kante zwischen „Task“. Die Elemente „Invoke“,
„Receive“ und „Assign“ enthalten die Kinderelemente „Source“ oder „Target“. Statt
der Markierung der Vorgänger- oder Nachfolgeaufgabe werden in den Elementen
„Source“ und „Target“ nur durch den Name des „Partner Link“, welche in dem Prozess
enthaltet, gekennzeichnet. Der logische Zusammenhang zwischen „Task“ ist nicht
direkt zu sehen. Zum Beispiel, in Abbildung 23 enthält die Aktivität „Invoke1“ ein
„Target“, das auf „Link1“ zeigt. Um die Nachfolgeaufgabe zu finden, muss in anderen
Elementen wie „Invoke“, „Receive“ oder „Assign“ gesucht werden, ob sie ein Element
„Source“, das auf „Link1“ zeigt, enthalten. In diesem Fall hat „Invoke3“ das Element
„Source“, so weiß man, dass „Invoke3“ der Nachfolger von Invoke1 ist.
In PAVONE PM XML ist jeder Task eine Aktivität. Jede Aktivität hat eine eindeutige
Seriennummer. Die Verbindung zwischen Aktivitäten ist direkt, weil jeder Aktivität die
„Destination“, welche die Seriennummer der nächsten Aktivität kennzeichnet, hat.
Das Transformationsdiagram zwischen den beiden XML Schema wird in Abbildung 24
dargestellt.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 67
Abbildung 24: BPEL4WS in PAVONE ProcessModeler XML transformieren
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 68
PAVONE PM XML hat viele prozess-relevante Informationen definiert, z.B. Autor,
Darstellung und Prozess Simulation usw. Diese Informationen werden im ersten
Kinderelement <PDGeneral> unter Element <PAVONEProcessDefinition>
definiert. Diese spezifische Definition kann nicht durch BPEL4WS erkannt werden.
Deswegen wird das Element <PDGeneral> bei der Transformation um den
vorgegebenen Inhalt ergänzt, und alle PAVONE PM XML spezifischen Informationen
werden mit der gleichen Methode behandelt.
Für alle Elemente „receive”, “invoke“ und „assign“ unter /process/flow in BPEL4WS
wird ein Element <ActivityDefinition> in PAVONE PM XML erzeugt. Dieses
kann durch folgendes XSLT im BPEL Source Dokument lokalisiert werden:
<xsl:template match="bpel:receive | bpel:invoke | bpel:assign">
Das Kinderelement <ADBasic> unter den Element <ActivityDefinition> enthält
die Kerninformation der Aktivität, zum Beispiel die Seriennummer. Diese
Informationen können durch das Zählen auf der transformierten Elementen aus Source
BPEL Datei erhalten werden, und zwar mit folgendem XSLT:
<ActivityNo><xsl:number count="bpel:receive | bpel:invoke | bpel:assign" /></ActivityNo>
Der Name der Aktivität in PAVONE PM XML kann direkt aus BPEL gelesen und
benutzt werden:
<name><xsl:value-of select="@name" /></name>
Da eine Task in PAVONE PM XML immer auf den nächsten Task zeigt, muss der
ersten Task aus BPEL Prozess gefunden werden. Das Element <IsStartProcess> in
PAVONE PM XML kennzeichnet das Startelement, falls es „true“ als Wert beinhaltet.
Um dieses Element zu finden, wird folgendes XSLT benutzt.
<xsl:if test="bpel:source"><IsStartProcess>false</IsStartProcess></xsl:if>
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 69
<xsl:if test="not(bpel:source)"><IsStartProcess>true</IsStartProcess></xsl:if>
Die Logik ist, wenn ein Element (Task) in BPEL ein Element „Source“ hat, dann kann
dieses Element nicht als Startelement genommen werden. Sonst wird das Element als
Startelement ausgewählt.
Der schwierigste Teil der Transformation ist, das Element <ADLinks> zu generieren.
Es sollten alle Nachfolger des aktuellen Tasks gefunden werden. Wie am Anfang dieses
Abschnitts erwähnt wurde, gibt es keine direkte Verbindung über die nächste Task in
BPEL. Es wird eine Suche durchgeführt, bei der alle Source Elemente von Tasks
gesucht werden, wobei „Source Partner Link“ zu dem „Target Partner Link“ dem
aktuellen Task identisch sind. Hier wird die For-Schleife in XSLT für die zweite Suche
benutzt. Zur konkreten Implementierung ist folgendes notwendig:
Zuerst wird eine Schleife gebaut, um den „Target Partner Link“ aller Tasks aus BPEL
Prozess durchlaufen zu lassen. Für jedes „Target“ wird eine entsprechende <ADLink>
erzeugt.
<xsl:for-each select="bpel:target"><ADLink>
Das „Target Partner Link” wird dann in einer Variable gespeichert.
<xsl:variable name="thisLinkName"><xsl:value-of select="@linkName" /></xsl:variable>
In nächsten Durchlauf werden die „Source“ Element aller Tasks, deren „Partner
Link“ gleich ist, wie der vorgespeichert, gesucht.
<xsl:for-each select="/bpel:process/bpel:flow/*/bpel:source[@linkName=$thisLinkName]">
Das Element <Destination> wird erzeugt und deren Seriennummer und Name des
Nachfolgers durch das Suchergebnis ergänzt.
<Destination> <ActivityNo>
<xsl:number count="/bpel:process/bpel:flow/bpel:receive | /bpel:process/bpel:flow/bpel:invoke | /bpel:process/bpel:flow/bpel:assign" /> </ActivityNo> <Name>
<xsl:value-of select="parent::node()/@name" /> </Name>
</Destination>
Mit obigen Methoden wird die BPEL Prozess in PAVONE PM XML transformiert.
Bei der weiteren Untersuchung taucht folgendes Problem auf:
Um IF-Bedingung in BPEL Prozess in PAVONE PM XML zu transformieren, existiert
eine technische Schwierigkeit, welche in Tabelle 11 aufgeführt ist.
BPEL PAVONE PM XML
<wpc:transitionCondition>
<wpc:otherwise/>
</wpc:transitionCondition>
<RoutingOption>Conditional</RoutingOption>
<RoutingCondition>else</RoutingCondition>
<wpc:transitionCondition>
<wpc:javaCode><![CDATA[
boolean result=true;
…
if (getGetStockResponse().getResult() -
getApproveRequest().getNumber() >
10)
result= false;
return result;
]]></wpc:javaCode>
</wpc:transitionCondition>
<RoutingOption>Conditional</RoutingOption>
<RoutingCondition>
Expression in VB syntax
</RoutingCondition>
Tabelle 11: Routing-Bedingungen in BPEL und PAVONE ProcessModeler XML
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 71
Der erste Teil in der Tabelle zeigt die erfolgreiche Transformation. Im zweiten Teil
sieht man, dass im BPEL Prozess Java-Quellcode benutzt wird. Aber das PAVONE PM
XML kann nur mit einem Boolean-Ausdruck mit der VB-Grammatik benutzt werden.
Das Ergebnis der Transformation ist in Abbildung 25 veranschaulicht.
Abbildung 25: Transformierte BPEL Prozess in ProcessModeler
5.5. Integration IBM WebSphere und Microsoft Excel
mit BPEL4WS
Ein wichtiges Ziel von BPEL4WS ist es, alle existierenden Web Services zu integrieren,
um dann Schnittstellen für die Anwendung anzubieten. In Abschnitt 5.3 wird ein
Beispiel für Web Services mittels BPEL4WS in WebSphere Studio Application
Developer Integration Edition vorgestellt. Alle Web Services in diesem Beispiel wurden
mit Java geschrieben und zusammen unter WebSphere Business Integration Server
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 72
Foundation eingesetzt. Dies ist eine vereinfachte Annahme für die Entwicklung von
Web Services, da nicht immer die gesamte Entwicklung in einer vordefinierten
Umgebung durchgeführt werden kann. Die Realität ist, dass es eine Menge externer
Web Services gibt, die nicht in WSAD-IE entwickelt worden sind. Die zentrale Frage
ist, wie unterschiedliche externe Web Services in BPEL4WS unter WBISF integriert
werden können. Deshalb wird im nächsten Schritt eine Verifikation über die Integration
der externen Web Services für BPEL4WS stattfinden.
Im Folgenden wird für die Lösung eine AnyWS.dll mit C entwickelt. Für jede
Programmiersprache, die DLLs unterstützt und aufrufen kann, können auch die internen
Funktionen als Web Services exportiert werden. Die Abkürzung DLL steht für Dynamic
Link Library.
Der ProcessModeler von PAVONE ist mit Visual Basic implementiert, bietet aber
derzeit keine Skriptsprache für den Benutzer als Erweiterung. Das in Abschnitt 5.3
vorgestellte Web Service Beispiel ist aber vollständig in Java implementiert. Die Frage
ist, ob Visual Basic auch den Web Services in BPEL Prozess anbieten kann. Hier wird
die Funktion getStock() mit VB in Excel neu implementiert und mit der AnyWS.dll
wird diese Funktion als Web Services realisiert. Damit wird getestet, ob die in Visual
Basic geschriebenen Funktionen als Web Services exportiert werden können. In der
Abbildung 26 ist diese Vorgehensweise veranschaulicht.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 73
ApprovingProcess in BPEL4WS
WSDL:Int getStock(string) Address:Http://localhost:9080/...
public class RetrieveStock {public int getStock(String serial) {System.out.println("Get Our Stock!"+serial);return 50;}
}
Running in
Running in
WSDL:Int getStock(string) Address:Http://localhost:1041/...
getStock-server.xls
In VBA with AnyWS.DLL
Running in
Switch to
WebSphereExcel
Abbildung 26: Modifizierung von BPEL Prozess zur Integration in Excel
Der getStock Web Service, der mit Java implementiert wurde, wird nun mit VB neu
geschrieben. Mit Hilfe der AnyWS.dll wird sie dann als ein Thread in dem Excel-
Prozess gelaufen lassen. Das heißt, der Prozess läuft, bis die Anfrage an den Bestand
des Lagers gestellt wird. Dann wird eine neue getStock() Funktion, die den Web
Service anbietet, aufgerufen. Der Wert aus Excel wird dann zurückgegeben.
5.5.1. Änderung des BPEL Prozess
Der in 5.3. beschriebene BPEL4WS Prozess wird wie folgt geändert:
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 74
Abbildung 27: Definition einer BPEL Process Instance in WebSphere
GetStock ist eine neue „invoke“ Funktion. Statt einem internen Java-Prozess werden
externe Web Services, die nicht in WSAD-IE entwickelt worden sind, aufgerufen. Zur
Implementierung braucht man nur den „Partner Link“ dem Web Services zuzuweisen,
die restlichen Aufgaben werden von WSAD-IE übernommen. Sie generieren z. B. den
Quellcode für die Behandlung der SOAP-Nachrichten. Die Abbildung 28 zeigt den
generierten Quellcode und die Dateien.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 75
Abbildung 28: Automatisch generierter Code nach WSDL
Der vollständige Quellcode ist im Anhang aufgeführt. Im nächsten Abschnitt wird die
Implementierung der Schnittstelle mit VBA in Excel dargestellt.
5.5.2. AnyWS.dll Tool
In einer DLL sind Funktionen innerhalb einer Bibliothek zusammengefasst, die bei
Bedarf innerhalb einer Anwendung aufgerufen werden. Hierzu wird die DLL vor dem
Aufruf der gewünschten Funktion in den Arbeitsspeicher geladen. Die AnyWS.dll wird
implementiert als ein Werkzeug, durch welches jede Funktion als Web Services
exportiert werden kann. Der weitere Vorteil ist, dass die AnyWS.dll alle entsprechenden
Details für die Implementierung der Web Services versteckt hat, damit die Änderung
der Legacy Systeme vereinfacht durchgeführt werden können. Die DLL kann von
unterschiedlichen Programmiersprachen (z.B. VB) genutzt werden.
Der Quellcode für die Implementierung der SOAP-Nachrichten-Processing und HTTP-
Protokoll, welches gSOAP (Generator Tools for Coding SOAP/XML Web Services in
C and C++) enthält, wird weiter genutzt. Wie andere Entwicklungswerkzeuge für Web
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 76
Services, bietet gSOAP statische Methoden um einen Server aufzubauen. Es wird
hierbei der Code für die Schnittstellen nach einer vordefinierten Web Service
Schnittstelle entwickelt. Dies passt nicht zum Konzept der AnyWS.dll. Als ein
universelles Werkzeug realisiert die AnyWS.dll den dynamischen Aufruf von
Funktionen, weil die Anzahl der Funktionen und deren Parameter zuvor nicht definiert
sind. Das heißt, je nach Aufruf der Funktion wird mit unterschiedlichen Parametern ein
entsprechender Web Services angeboten. Dieser Aufruf von Funktionen kann nicht vor
der Implementierung der AnyWS.dll festgelegt werden. Deswegen ist es für die
AnyWS.dll wichtig, dass eine beliebige Anzahl von Funktionen mit beliebigen
Parametern übergeben werden kann, durch welche die entsprechenden SOAP-
Nachrichten generiert werden.
5.5.2.1 AnyWS.dll Schnittstelle
Die AnyWS.dll bietet folgenden Funktionsaufruf an:
__declspec(dllexport) int registerFunction(const char* operationName, void* func, char resultType, const char* parameterTypes, const char* parameterNames[]); /** return thread handle */ __declspec(dllexport) HANDLE startWebService(const char *host, int port, const char* soapAction);
• Durch die Methode registerFunction wird die Funktion, welche als Web
Services angeboten werden soll, registriert.
• Der Parameter operationName gibt den Name des Web Services an, welcher
der als Web Services angebotene Funktion entspricht.
• Der Parameter func ist ein Zeiger, durch den die Web Services-Funktion
übergegeben wird.
• resultType entspricht dem Rückgabetyp der Funktion.
• Der Parameter parameterTypes ist eine Eingabeliste des Datentyps des
Parameters für die Funktion, die als Web Services angeboten wird.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 77
• Das Array parameterNames [] übergibt den Name der Element der SOAP-
Nachrichten.
Die exportierte Funktion muss folgendermaßen angepasst werden:
• Die Calling Convention muss in Form stdcall sein. Dies ist eine
Standard-Win32API-Methode. Dies wird in den nächsten Abschnitten konkret
diskutiert.
• Der letzte Parameter von ParameterType muss ein Zeiger sein, durch den die
Rückgabewerte der Funktion zu übergeben werden. Der Typ der Rückgabewerte
passt zu dem Typen, der in resultTyp angegeben wurde. Die aufgerufene
Funktion hat Integer als Rückgabetyp, durch welchen der Erfolg der Ausführung
übergeben wird.
Nach der Registrierung kann die Methode startWebServices() gestartet werden. Es
wird hierdurch ein Webserver-Thread gestartet, der auf den Anruf von Web Services
Funktionen auf dem vorgegeben host:port wartet.
Das vollständige Beispiel ist in der Implementierung der Web Services in VBA erhalten.
5.5.2.2 Dynamic Function Calls
Da die Anzahl der Funktionen und deren Parameter während der Implementierung der
AnyWS.dll nicht bekannt ist, kann eine statische Implementierung als C/C++ Funktion
nicht umgesetzt werden.
Die Lösung erfolgt in x86 Assembler durch das dynamische Konstruieren der
Anweisungen um die registrierte callback Funktion zur Laufzeit aufzurufen.
Nachfolgend wird die Vorgehensweise dargestellt:
• Der (Web Server) Thread von AnyWS. dll wird von SOAP aufgerufen.
• Anhand der Namen der XML-Elemente in einer SOAP-Nachricht wird in der
registrierten Funktionsliste, die durch registerFunction erzeugt wurde, der
Adresse-Zeiger auf die Funktion und deren Parameter ermittelt.
• Nachdem die Informationen der Funktion gefunden wurden, wird innerhalb
eines Speicherblocks in unsigned char inst[] eine Folge x86 Assembler
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 78
Anweisungen, welche die PUSH- und JUMP-Anweisung beinhaltet, dynamisch
erzeugt. Bei PUSH wird der Parameter auf den Stack gelegt und bei JUMP
erfolgt der Aufruf der Funktion.
• Nachdem der x86 Assembler Code erzeugt wurde, kann dieser Block in C/C++
eingefügt werden und die registrierte Funktion aufgerufen werden.
Der Prozess wird in Abbildung 29 dargestellt:
Abbildung 29: Sequenzdiagramm Funktionsaufruf
Der C++ Quellcode ist nachfolgend dargestellt. unsigned char inst[256]; //storing the assembly instructions void *jmp_to=&inst; int call_any_function(const char* op, void* pParameters, void *pRes){ //called by web server thread int ret; unsigned char *p; DWORD dwAdr; int j,k,i=0; j=getOperationIndexByName(op); if (j<0) return SOAP_ERR; //push pRes, the result returning address inst[i++]=0x68; //machine code of instruction push *(DWORD*)&inst[i]=(DWORD)pRes; i+=sizeof(DWORD); //push parameters p=(unsigned char*)pParameters; for (k=0;k<strlen(operationParameters[j]);k++){ switch (operationParameters[j][k]){
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 79
case 'd': //double type p+=sizeof(double); break; case 's': //string type p+=sizeof(char *); break; … } for (k=strlen(operationParameters[j])-1;k>=0;k--){ switch (operationParameters[j][k]){ case 'd': p-=sizeof(double); inst[i++]=0x68; *(DWORD*)&inst[i]=*(DWORD*)(p+4); i+=4; inst[i++]=0x68; *(DWORD*)&inst[i]=*(DWORD*)(p); i+=4; break; case 's': p-=sizeof(char *); inst[i++]=0x68; *(DWORD*)&inst[i]=*(DWORD*)(p); i+=4; break; … } } //call registered user callback function inst[i++]=0xe8; dwAdr = (DWORD)operationFunctions[j] - (DWORD)&inst[i] - sizeof(dwAdr); *(DWORD*)&inst[i]=dwAdr; i+=sizeof(DWORD); //The calling target assumes to be with calling convention of __stdcall, it will restore stack. //restore stack for this call_any_function manually because the compiler generated instructions will be never reached. //mov dword ptr [ebp-4],eax //mov eax,dword ptr [ebp-4] //pop edi //pop esi //pop ebx //mov esp,ebp //pop ebp //ret inst[i++]=0x89; inst[i++]=0x45; inst[i++]=0xFC; inst[i++]=0x8B; inst[i++]=0x45; inst[i++]=0xFC; inst[i++]=0x5F; inst[i++]=0x5E; inst[i++]=0x5B; inst[i++]=0x8B; inst[i++]=0xE5; inst[i++]=0x5D; inst[i++]=0xC3;
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 80
__asm{ jmp jmp_to //jump to above instructions } //never reach here return ret; }
Die wichtigste Aufgabe der DLL ist die Generierung des Quellcodes für den
dynamischen Aufruf der Funktionsliste. Dies bedeutet, dass die Generierung des Codes
durch den Compiler für die obige Funktion cal_any_function bis zur Laufzeit
aufgeschoben wird. Bei VB und anderen Programmierersprachen, in denen der Aufruf
von Funktionen mittels stdcall (calling convention) genutzt wird, wird durch die
DLL sichergestellt, dass nach Ausführung der Stack wieder bereinigt wurde. Die
Einbindung von den registrierten Funktionen ist auch dynamisch möglich, und muss zur
Compilezeit nicht bekannt sein.
5.5.2.3 Implementation „getStock” Web Service in VBA für Excel
Durch die AnyWS.dll wird die Umsetzung als Web Service von der Anwendung
verborgen, hierdurch wird die Implementierung der Funktion getStock als Web
Service in VBA vereinfacht. Der Quellcode getStock-Server.bas ist in List4
dargestellt.
Die Methode gestockfunc wird als getStock Web Service exportiert und steht für
den BPEL Prozess zur Verfügung. In den nachfolgend dargestellten Ergebnissen,
werden die Rückgabewerte in A3 anzeigt. Wenn man dieser Werte editiert, verändert
sich auch der entsprechende Wert in dem BPEL Prozess. Das Ergebnis in Excel ist in
Abbildung 30 dargestellt.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 81
Abbildung 30: Bereitstellung eines Web Services Request in Excel
Die Verbindung von getStock nach TransInput3Check ist wie folgt: boolean result=true; System.out.println("getStock result:"+getGetStockResponse().getResult().getResult()); System.out.println("input number:"+getInput().getNumber()); System.out.println("minus(if<10,to manager):"+(getGetStockResponse().getResult().getResult() - getInput().getNumber())); if (getGetStockResponse().getResult().getResult() - getInput().getNumber() > 10) result= false; return result;
Wird Number=100 als Parameter angegeben, kommt aus WebSphere folgendes
Ergebnis: [05-3-24 23:01:26:609 CET] 57da1127 SystemOut O getStock result: 104.1 [05-3-24 23:01:26:609 CET] 57da1127 SystemOut O input number: 100.0 [05-3-24 23:01:26:625 CET] 57da1127 SystemOut O minus (if<10, to manager):4.099999999999994
In Excel wird die Werte 104.1 erfolgreich zurückgegeben, der Thread wartet auf den
nächsten Aufruf.
5.6. Bewertung
Wie beschrieben, wurden die beiden Ansätze erfolgreich implementiert.
Dazu wurde zunächst der XSLT Code für die Transformation geschrieben und Teile des
BPEL Prozess erfolgreich in PAVONE PM XML transformiert. Die Transformation
erfordert umfangreiches Wissen über XML/XSL, Prozessmanagement und
Programmierenstechnik. Aber aufgrund der Syntax-Unterschiede zwischen VB und
Java ist die vollständige Transformation sehr zeitaufwändig.
Danach wurde eine mit Visual Basic entwickelte Integrationsmethode erfolgreich
eingeführt, welche einen Web Service anbietet, um Legacy Systeme in den BPEL
Prozess unter WSAD-IE zu integrieren. Durch AnyWS.dll wird die Programmierung
von Desktopsoftware und Web Service erheblich erleichtert, da zur Erstellung von
Legacy Desktop Software kein detailliertes Wissen über die zugrunde liegenden
Protokolle benötigt wird.
Zwar wird der benötigte Aufwand durch die Verwendung von gSOAP erheblich
minimiert, trotzdem müssen nach wie vor grundlegende Infrastrukturmechanismen wie
HTTP- und SOAP-Processing manuell implementiert werden.
Es besteht auch die Möglichkeit, dass Kompatibilitätsprobleme mit anderen Web
Services auftreten. Zum Beispiel, wenn die Implementierung nur das Datenformat
„Integer“ unterstützt. Der Aufwand um alle Datenformate in SOAP zu unterstützen ist
sehr hoch. Falls der Aufwand erneuter Entwicklung des Legacy Systems akzeptabel ist,
kann mit der Unterstützung der Frameworks von Java oder Microsoft .Net das System
neu entwickelt werden. Damit wird das Kompatibilitätsproblem vermieden und auch die
Implementierung der Infrastrukturmechanismen der Protokolle gespart.
Durch die Einbettung des Webservers in das Programm sind das Deployment und die
Konfiguration der Anwendung erheblich vereinfacht. Allerdings bietet der integrierte
Webserver keine Unterstützung für erweiterte Verfahren wie SSL oder User Certificates.
Bei großer Last ist es auch unvermeidlich mit schlechterer Performance zu rechen.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 83
6. Schluß und Ausblick der Arbeit
Web Services und XML haben sich in den vergangenen Jahren zu einer wichtigen
Technologie im Bereich der EAI entwickelt. Ausgehend von dieser Entwicklung
wurden in dieser Diplomarbeit unterschiedliche XML Standards untersucht.
In dieser Arbeit wurden zuerst verschiedene Standards bzw. PAVONE spezifische
Standards, im Rahmen von XML Schemas, Anwendungsbereich, kommerzielle Tools
untersucht und verglichen.
Die Standards sind meistens ausreichend gut entwickelt, so dass die Anwendung derzeit
sehr gut angepasst werden kann. Es wurden jedoch Beschränkungen erkannt. Die
Standards stellen zum Teil sehr neue Technologie dar und haben noch nicht für alle
Anwendungszwecke eine ausreichende Reife erreicht. Deshalb stellt die Erstellung
eines umfangreichen Standards weiterhin ein großes Problem dar. Andererseits ist die
Verbesserungsaufgabe wegen der Erweiterbarkeit von XML Standard relativ einfacher
geworden.
Die Weiterentwicklung der XML Technologien ist durch den Standardisierungsprozess
innerhalb der W3C Organisation langwierig und teilweise nicht marktkonform. Die
XML Standards werden zur Anwendung im Bereich Web Services durch
unterschiedliche Firmen und Organisation vorangetrieben, dass die Zusammenführung
zum jeweils aktuellen XML Standard auf Grund von Übereinanderstapeln und
Inkompatibilität nicht immer lückenlos möglich ist. So existieren verschiedene Ansätze
mit eigenen Schwerpunkten, so dass kleine Unterschiede existieren können.
Auf dem Gebiet des Prozessmanagements hat es sich herausgestellt, dass die Standards
der alten Technologie nicht ausreichend für die neuen, lose gekoppelten Applikationen
im EAI sind.
Aber solche neuen XML Standards, wie z.B. BPEL4WS sind viel weiter entwickelt und
für lose gekoppelte Entwicklung gut geeignet. Also wurde das Ziel der Arbeit auf
dieses Thema konzentriert. Ein Ziel der Arbeit war die Verknüpfung des PAVONE
ProcessModeler mit dem BPEL4WS Standards. Dies erfolgte durch Implementierung
einer Schnittstelle.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 84
In der ersten Phase der Implementierung wurde ein Parser mittels XSLT entwickelt,
durch den eine BPEL4WS Prozessdarstellung in den PAVONE ProcessModeler
spezifische Standard umgewandelt wird. Diese Implementierung ist sehr sinnvoll für die
Anwendungen, die selbst XML definiert haben, um schrittweise in den neuen Standard
zu portieren.
Der Stand des Entwicklungsprozess der standardisierten XML liegt hinter dem
Entwicklungsstand der Applikationen zugrunde liegender XML Technologien. Es
existiert auch viel Software, wie z.B. dem PAVONE ProcessModeler, die zuerst die
grundlegende XML Technologie genutzt haben, die zu einem späteren
Entwicklungsstand jedoch auf standardisierte XML Technologie umsteigen möchten.
Die in dieser Arbeit gemachten Erfahrungen können in andere Projekte einfließen.
Als weitere Schritte der Implementierung wurde versucht, den PAVONE
ProcessModeler in den BPEL Prozess zu integrieren. Der BPEL Prozess wird im IBM
WSAD-IE ausgeführt, der BPEL Prozess seinerseits ruft die PAVONE Applikation als
Web Service auf.
Zum Aufrufen der Web Service aus einem BPEL Prozess, wurde eine Schnittstelle vom
Web Service an den PAVONE ProcessModeler gefordert. Deswegen wurde versucht,
für den PAVONE ProcessModeler und andere Applikationen, welche mit VB
entwickelt wurden, eine einheitliche Web Service Schnittstelle zu implementieren.
Hierzu wurde anhand eines kleinen Beispiel Programms unter Microsoft Excel gezeigt,
wie über eine Schnittstelle ein Web Service arbeitet und dieser Web Service erfolgreich
in einen BPEL Prozess unter IBM WSAD-IE integriert und aufgerufen werden kann.
Das Ergebnis bedeutet, dass die Anwendungsgebiete von BPEL4WS nicht nur für
Backend Server Side Software, sondern auch Desktop Software betreffen, unabhängig
davon, ob es sich um eine neue entwickelte Software oder ein verpacktes Legacy
System handelt.
Ausgehend von diesen Ergebnissen können weitere Entwicklungen implementiert
werden.
Weitere zu untersuchende Themen sind Performance, Sicherheit und Management-
Fähigkeit.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 85
Es ist z.B. zu fragen, wie viele Web Service Client Verbindungen könnten von Excel,
der einen Web Server integriert hat, pro Minute behandelt werden? Oder wie viele Web
Service Client können gleichzeitig verbunden werden? Solche Performanceprobleme
hängen nicht nur von der Web Service Schnittstelle ab, sondern auch von Excel. Zu der
Ermittelung ist ein weiteres Testen erforderlich. Ebenfalls sollte untersucht werden,
welche Probleme bei durch VBA geschriebener Web Service Funktion unter
gleichzeitigem Zugriff auftreten können.
Außerdem ist das Verbindungsprotokoll von Web Service relativ einfach im Vergleich
zu anderen Protokolle (z.B. Anmeldeprozedur von Skype) aufgebaut. Deswegen ist es
mit Hilfe von Web Services möglich viele gleichzeitige Zugriffe zu behandeln. Aus
diesem Grund ist es wichtig Benchmarking und Profiling durchzuführen.
Die Zugriffskontrolle und Sicherheit sind auch wichtige Punkte für Web Services. Die
Entwicklung der Web Service Schnittstelle sollten kein Angriffspunkt werden und so
der Sicherheit des Systems entgegen wirken. Es ist sinnvoll weiter zu untersuchen,
welche Standard und Technologie zur Sicherheit von Web Service benutzt werden
können.
Web Service Verzeichnis und Auffindensmechanismus von UDDI können auch in EAI
untersucht werden. Ein Punkt-zu-Punkt-System anstatt eines zentralen
Verzeichnisdienstes wie UDDI erleichtert eine selbstorganisierende Struktur und könnte
bedeutende Verbesserungen bringen wenn mehr und mehr Anwendungen und
Komponenten verwaltet werden müssen.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 86
Anlagen
List 1: getStock.wsdl
<?xml version="1.0" encoding="UTF-8"?> <definitions name="anyws" targetNamespace="urn:anyws" xmlns:tns="urn:anyws" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:anyws" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:MIME="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:DIME="http://schemas.xmlsoap.org/ws/2002/04/dime/wsdl/" xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetNamespace="urn:anyws" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:anyws" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/"/> <!-- operation request element --> <element name="getStock"> <complexType> </complexType> </element> <!-- operation response element --> <complexType name="getStockResponseType"> <sequence> <element name="result" type="xsd:double"/> </sequence> </complexType> <element name="getStockResponse" type="ns:getStockResponseType"> </element> </schema> </types>
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 87
<message name="getStockRequest"> <part name="parameter" element="ns:getStock"/> </message> <message name="getStockResponse"> <part name="result" element="ns:getStockResponse"/> </message> <portType name="anywsPortType"> <operation name="getStock"> <documentation>Service definition of function getStock</documentation> <input message="tns:getStockRequest"/> <output message="tns:getStockResponse"/> </operation> </portType> </definitions>
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 88
List 2: getStockBinding.wsdl
<?xml version="1.0" encoding="UTF-8"?> <definitions name="anyws" targetNamespace="urn:anyws" xmlns:tns="urn:anyws" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:anyws" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:MIME="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:DIME="http://schemas.xmlsoap.org/ws/2002/04/dime/wsdl/" xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <import location="getStock.wsdl" namespace="urn:anyws"/> <binding name="anyws" type="tns:anywsPortType"> <SOAP:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="getStock"> <SOAP:operation soapAction=""/> <input> <SOAP:body use="literal" namespace="urn:anyws"/> </input> <output> <SOAP:body use="literal" namespace="urn:anyws"/> </output> </operation> </binding> </definitions>
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 89
List 3: getStockService.wsdl
<?xml version="1.0" encoding="UTF-8"?> <definitions name="anyws" targetNamespace="urn:anyws" xmlns:tns="urn:anyws" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:anyws" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:MIME="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:DIME="http://schemas.xmlsoap.org/ws/2002/04/dime/wsdl/" xmlns:WSDL="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <import location="getStockBinding.wsdl" namespace="urn:anyws"/> <service name="anyws"> <port name="anyws" binding="tns:anyws"> <SOAP:address location="http://localhost:1041/"/> </port> </service> </definitions>
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 90
List 4: getStock-server.bas
Declare Function registerFunction Lib "D:\work\C\AnyWS\Debug\AnyWS.dll" _ (ByVal opName As String, _ ByVal func As Long, _ ByVal resType As Byte, _ ByVal paramTypes As String, _ ByVal paramNames As Long) As Long Declare Function startWebService Lib "D:\work\C\AnyWS\Debug\AnyWS.dll" _ (ByVal host As String, _ ByVal port As Long, _ ByVal soapAction As String) As Long Public Function getstockfunc(ByRef r As Double) As Long Dim x As Object On Error Resume Next Set x = ActiveWorkbook.Sheets("Sheet1") If Err = 0 Then r = x.Range("A3") MsgBox "return Sheet1.A3=" & r Else r = 104.1 MsgBox "return " & r End If getstockfunc = 0 End Function Sub AnyWS() registerFunction "getStock", AddressOf getstockfunc, Asc("d"), "", 0 startWebService "", 1041, "" MsgBox "Service thread is running" End Sub
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 91
Literaturverzeichnis
[Actional 2002] Actional, o. V. (2002): Shrinking Application Backlog: Using Web Services to Access Enterprise Applications, By Actional, Corp. for ITtoolbox CRM. 2002; aus http://crm.ittoolbox.com/browse.asp?c=CRMPeerPublishing&r=%2Fpub%2FJW103002%2Epdf am 01.04.05 [Andrews/Curbera/Dholakia 2003] Andrews, T.; Curbera, F.; Dholakia, H.; et al. (2003): Business Process Execution Language for Web Services version 1.1, BEA Systems, IBM, Microsoft, SAP AG and Siebel Systems. Aus http://ifr.sap.com/bpel4ws/BPEL%20V1-1%20May%205%202003%20Final.pdf am 02.03.05 [Barham/Boseman/McCarthy 2003] Barham, C.; Boseman, A.; McCarthy, M; et al. (2003): ebXML Glossary, http://www.ebxml.org/specs/ebGLOSS.doc, Zugriff 22. Aug. 2003. [Becker/Kugeler/Rosemann 2003] Becker, J., Kugeler, M., Rosemann, M.(2003): Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Berlin 2003 [Becker/Muehlen 2001] Becker, J.; Muehlen, M. (2001): Workflowmanagement im Zeitalter des e-Business. Münster 2001; aus http://www.workflow-research.de/Publications/PDF/JOBE.MIZU-DSK(2000).pdf am 03.03.05 [Clark 2002] Clark, J. (2002): XSL Transformations (XSLT) Version 1.0, Deutsche Übersetzung, 18. März 2002; aus http://xml.klute-thiemann.de/w3c-de/REC-xslt-20020318/ am 22.02.05 [Cubera et al. 2003] Cubera. F; Leymann, F.; Khalaf, R. (2003): Compsing Web Service using BPEL4WS. February 2003. http://www.omg.org/news/meetings/workshops/webserveurope_manual/05-1_curbera_etal.pdf, Aktualisierungsdatum: 16.07.03 [Dünhölter 1998] Dünhölter, K. (1998): Das Web automatisieren mit XML, Version 2.0 (vom 1.9.98); aus http://members.aol.com/xmldoku/ am 18.01.05 [Eisch-Hagenauer 2001-2005] Eisch-Hagenauer, H. (2001-2005).: Entwurf von EAI-Architekturen; aus http://www.software-kompetenz.de/ am 24.05.05
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 92
[Haas 2005] Haas, H. (2005): Web Services Activity; aus http://www.w3.org/2002/ws/ am 23.04.05 [Hagen/Stucky 2004] Hagen, C. R.; Stucky, W. (2004): Business-Process und Workflow-Management: Prozessverbesserung durch Prozess-Management. 2004 [Horn 2005] Horn, T., o. J.: Web Services mit SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und UDDI (Universal Description, Discovery, and Integration); aus http://www.torsten-horn.de/techdocs/soap.htm am 05.05.05 [IBM Software 2004] IBM Software, o. V., o. J.: WebSphere Business Integration Server Foundation http://www-306.ibm.com/software/info/ecatalog/de_DE/products/S108154G44115D32.html [Kindler 2003] Kindler, E. (2003): Geschäftsprozessmodellierung und Workflowmanagement(SWT), 2003, Paderborn; Aus http://wwwcs.uni-paderborn.de/cs/kindler/Lehre/SS03/Wf/unterlagen.html am 13.12.04 [Klute/Thiemann 2002] Klute, T.; Thiemann, J. (2002): XSL Transformations (XSLT) Version 1.0 Deutsche Übersetzung 18. März 2002; aus http://xml.klute-thiemann.de/w3c-de/REC-xslt-20020318/#XMLNAMES#XMLNAMES am 23.03.05 [Kolb 2005] Kolb, M.(2005): Infomationsdrehscheibe, EAI unter Zuhilfenahme von Middleware und Web Services [Mckie 2004] Mckie, S. (2004): SMB Excel-eration; aus http://www.intelligententerprise.com/showArticle.jhtml?articleID=50500787 am 16.02.05 [Microsoft Corporation] Microsoft Corporation, o. V, o. J.: Office XP and Web Services. Aus http://www.microsoft.com/office/previous/xp/webservices/default.asp am 15.02.05 [Mintert 2002] Mintert, S. (2002): Extensible Markup Language (XML) 1.0 (Zweite Auflage) Deutsche Übersetzung; aus http://edition-w3c.de/TR/2000/REC-xml-20001006/ am 21.02.05 [Nastansky et al. 2000] Nastansky, L. et al. (2000) Büroinformations- und Kommunikationssysteme: Groupware, Workflow-Management, Organisationsmodellierung und Messaging-Systeme.
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 93
[Nastansky 2002] Nastansky, L. et al. (2002): Bausteine der Wirtschaftsinformatik: Grundlagen, Anwendungen, PC-Praxis, 3., überarbeitete Auflage, Berlin, 2002 [NorCom Information Technology AG 2005] NorCom Information Technology AG (2005): Erfolg steigern durch konsequentes Management der Geschäftsprozesse – ein ganzheitlicher Ansatz; aus http://www.norcom.de/druck/consulting/business.htm am 15.02.05 [Novatchev 2001] Novatchev, D. (2001): The Functional Programming Language XSLT- A proff through examples; aus http://www.topxml.com/xsl/articles/fp/ am 21.02.05 [Partl 2000] Partl, T. (2000): XML - Extensible Markup Language, Version September 2000; aus http://www.boku.ac.at/htmleinf/xmlkurz.html am 16.12.04 [PAVONE AG 2003] PAVONE AG, o. V. (2003): PAVONE ProcessModeler Hilfe; aus http://www.pavone.de/web/de/support/hilfe/es_hpm_d.nsf am 23.02.05 [Prozessmanagement 2004] o. V. 2004: Prozessmanagement, was ist das? aus http://www.fh-steyr.at/fileadmin/user_upload/studiengaenge/pmg/symposium/01_Prozessmanagement_was_ist_das.pdf am 21.11.04 [Reife 2003] Reife, R. (2003): Erweitertes Workflow-Management : ein Ansatz zur Unterstützung des Prozessmanagements in Workflow-Anwendungen. Berlin, Logos, 2003 [Russmann] Russmann, I., o. J.: bpml, Net-Market GmbH; aus http://www.bpml.de/bpml.htm am 12.08.04 [Software Kompetenz] Software Kompetenz, o. V., o. J.: Web Web Services UDDI; aus http://www.software-kompetenz.de am 02.03.05 [Thränert 2004] Thränert, M. (2004): eBusiness I, Universität Leipzig; aus http://ais.informatik.uni-leipzig.de/studium/vorlesungen/2004_ss/eb1/2004s_eb1_v_10.pdf am 02.12.04 [Volz 2002] Volz, R.(2002): PMXML - ein XML-Standard für Projektmanagement; aus http://www.vrtprj.de/content/istandards/pmxml_de.html am 21.09.04
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 94
[VirtualUniversity] VirtualUniversity o. V o. J.: Projektmanagement: Einführung und Grundlagenwissen zur Projektführung; aus http://www.virtualuniversity.ch/management/project/2.html am 15.11.04 [Yager 2002] Yager, T (2002): The Future of Application Integration, 2002; aus http://www.computerworld.com/printthis/2002/0,4814,71198,00.html am 13.03.05 [Zingel 2000-2004] Zingel, H. (2000-2004): Grundzüge des Projektmanagements, Version 3.2; aus http://www.zingel.de/pdf/10proj.pdf am 22.11.04 [Zhang 2001] Zhang, H. (2001): Process Design, Verification and Simulation – An Implementation in a Visual Modeling Tool for a Workflow Management System. Paderborn 2001
XML Standards im Umfeld des kollaborativen Prozess- und Projektmanagement Seite 95
Eidesstattliche Erklärung
Eidesstattliche Erklärung
Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbständig und nur
unter Verwendung der angegebenen Hilfsmittel angefertigt habe; die aus fremden
Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich
gemacht.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Paderborn, den 30.05.2005 _______________________
Jing Tang