Diplomarbeit XML Standards im Umfeld des kollaborativen ...gcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/0/ce105aeea9bae21ac... · Integrationsbemühungen globaler Unternehmen im Jahr

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


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


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


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


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


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


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


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 Extensible Markup Language

XPath XML Path Language

XSD XML Schema Definition Language

XSL Extensible Stylesheet Language

XSLT XSL Transformations


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.


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-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.


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


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.


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])


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.


• 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


• 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.


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.


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])


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


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


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


• 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)


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


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


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.


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


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]):


• 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


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)


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


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


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


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)


• 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.


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


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.


[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.


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.


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


EJB


PAVONEProcessModeler / Excel


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.


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.


• 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.


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


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.


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.


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


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


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.


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.


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.


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


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.


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


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


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.


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.


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.


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"/>


<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


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


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.


Abbildung 24: BPEL4WS in PAVONE ProcessModeler XML transformieren


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>


<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


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


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.


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:


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.


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


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.


• 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


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]){


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;


__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.


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.


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.


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.


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.


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/"/>  <element name="getStock"> <complexType> </complexType> </element>  <complexType name="getStockResponseType"> <sequence> <element name="result" type="xsd:double"/> </sequence> </complexType> <element name="getStockResponse" type="ns:getStockResponseType"> </element> </schema> </types>


<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>


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>


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>


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


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


[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.


[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

http://www.software-kompetenz.de/

http://www.software-kompetenz.de/


[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


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

Documents

Diplomarbeit XML Standards im Umfeld des kollaborativen ...gcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/0/ce105aeea9bae21ac... · Integrationsbemühungen globaler Unternehmen im Jahr