Dokumentation

Transcription

Dokumentation

Markus Schmitt
Entwurf und Implementierung einer Workflowbasierten Anwendung zur Auswertung
mathematischer Formeln
Vertiefung
Verteilte Systeme
Wintersemester 2005/06
Vertiefung Verteilte Systeme WS05/06
MATHworkflows
Inhaltsverzeichnis
Einführung und Grundlagen................................................................................................................. 4
Service Oriented Architecture......................................................................................................... 5
Beschreibung...............................................................................................................................5
Services....................................................................................................................................... 5
Rollen.......................................................................................................................................... 6
Merkmale.................................................................................................................................... 6
Weiterführende Links................................................................................................................. 7
Web Services................................................................................................................................... 8
Einführung in Web Services....................................................................................................... 8
Anwendung von Web Services................................................................................................... 8
Weiterführende Links............................................................................................................... 10
Business Process Execution Language.......................................................................................... 11
Geschäftsprozesse, Workflow (Management) und BPEL........................................................ 11
Die „BPEL-Sprache“................................................................................................................ 12
Aufruf von Web Services..........................................................................................................13
BPEL Engines und Deployment............................................................................................... 13
Graphische Orchestrierung....................................................................................................... 13
Weiterführende Links............................................................................................................... 14
Analyse und Entwurf.......................................................................................................................... 15
Anforderungen............................................................................................................................... 15
Mathematische Web Services................................................................................................... 15
Workflows.................................................................................................................................15
Aufruf der Web Services und Workflows.................................................................................15
Grobentwurf...................................................................................................................................16
Mathematische Web Services................................................................................................... 16
Workflows.................................................................................................................................17
Implementierung.................................................................................................................................19
Infrastruktur und Komponenten.....................................................................................................19
Entwicklungsumgebung............................................................................................................19
JBoss......................................................................................................................................... 19
Tomcat...................................................................................................................................... 20
Umsetzung der Web Services........................................................................................................ 20
Generierung mit XDoclet..........................................................................................................20
Exceptions................................................................................................................................. 22
Packaging.................................................................................................................................. 22
Umsetzung der Workflows............................................................................................................ 23
Orchestrierung...........................................................................................................................23
BPEL Engines........................................................................................................................... 23
Beispiel: Ackermannfunktion................................................................................................... 24
Umsetzung des Clients für die Ackermannfunktion......................................................................25
Java Swing Client......................................................................................................................25
Bewertung...........................................................................................................................................26
Probleme........................................................................................................................................ 26
Markus Schmitt
2
MATHworkflows
Java 5.........................................................................................................................................26
jBPM BPEL.............................................................................................................................. 26
Axis-generierte Stubs................................................................................................................ 26
Leistungsumfang............................................................................................................................27
jBPM BPEL.............................................................................................................................. 27
ActiveBPEL.............................................................................................................................. 27
Zusammenfassung......................................................................................................................... 28
„Viel Code – Kleine Wirkung“................................................................................................. 28
Literaturverzeichnis............................................................................................................................ 29
Abbildungsverzeichnis....................................................................................................................... 31
Anhang............................................................................................................................................... 32
Markus Schmitt
3
MATHworkflows
Einführung und Grundlagen
Im Zuge der Globalisierung und der damit verbundenen immer weitreichenderen Nutzung des
Internet ist für viele Unternehmen die Service-orientierte Architektur (SOA) immer wichtiger
geworden.
Diese spezielle Art der Softwarearchitektur legt ihr Augenmerk auf die Applikationsintegration.
Dies ist für jeder Art von Unternehmen, egal ob dienstleistungsorientiert oder produzierend,
sinnvoll, da die Software des Unternehmens mit der Software eines Kunden, Zulieferers oder
Partners verbunden werden kann, ohne eine "menschliche Middleware" zwischen zu schalten.
Eine Implementierung einer SOA stellen Web Services dar, die sich in den letzten Jahren
schlagartig in der IT-Welt verbreiten sollten. Web Services liefern einen Satz von bereits
existierenden Technologien, mit deren Hilfe sich eine vollständige service-orientierte Architektur
bewerkstelligen läßt. Die WS-I, die Web Services Interoperability Organization, ein
Zusammenschluss zur Optimierung des Zusammenspiels verschiedener Web Service
Implementierungen, sah Mitte 2004 die Zukunft noch sehr optimistisch:
Abbildung 1: Einfluss von Web Services auf den (Internet-)Markt [WSI04, S.7]
Doch der Erfolg der Web Services blieb weit hinter den hohen Erwartungen zurück. Einen neuen
Ansatz bietet BPEL, eine XML-Sprache zur Beschreibung und Orchestrierung von
Geschäftsprozessen. Dabei sind die einzelnen Aktivitäten der Prozesse durch Web Services
implementiert. Daß dafür keine neuen Technologien erlernt werden müssen, sondern nur deren
Einsatz, macht die Sache nur noch interessanter...
Markus Schmitt
4
MATHworkflows
Service Oriented Architecture
Service Oriented Architecture, Service-orientierte Architektur, oder kurz: SOA - diese 3
Buchstaben stehen für eine spezielle Art von Softwarearchitektur, die laut Gartner Group die
Client/Server-Architektur ablösen wird. In den meisten Gebieten der Softwareentwicklung hat im
letzten Jahrzehnt die objektoriente die prozeduale Programmierung ersetzt, doch für das Gebiet der
Applikationsintegration war dies nicht ausreichend:
Es wurde eine Lösung benötigt, die Informationen und Dienste (Services) verschiedener
Unternehmen oder Abteilungen in einen durchgängigen Geschäftprozess integiert. Die Idee der
service-orientierten Architektur war geboren.
Beschreibung
Die gemeinschaftlich erstellte deutsche Definition der SOA bei der freien Enzyklopädie Wikipedia
lautet:
"Eine serviceorientierte Architektur ist ein Konzept für eine Systemarchitektur, in
welchem Funktionen in Form von wieder verwendbaren, voneinander unabhängigen
und lose gekoppelten Services implementiert werden. Services können unabhängig von
zugrunde liegenden Implementierungen über Schnittstellen aufgerufen werden, deren
Spezifikationen öffentlich und damit vertrauenswürdig sind. Serviceinteraktion findet
über eine dafür vorgesehene Kommunikationsinfrastruktur statt. Mit einer
serviceorientierten Architektur werden i. d. R. die Gestaltungsziele der
Geschäftsprozessorientierung, der Wandlungsfähigkeit (Flexibilität), der
Wiederverwendbarkeit und der Unterstützung verteilter Softwaresysteme verbunden."
[Wiki05, „Service Oriented Architecture“]
Technisch gesehen lassen sich in der SOA fachliche Dienste in Form von Services flexibel
miteinander kombinieren und auch austauschen. Dies entspricht einer Menge loser gekoppelter
Dienste, die voneinander völlig unabhängig sind und nur durch eine Aneinanderreihung von
Aufrufen (Orchestrierung) zu einem Geschäftsprozess zusammengefasst werden. Aus verteilten
Anwendungen kann dadurch eine sehr komplexe Geschäftlogik abgearbeitet werden.
Die SOA beschreibt nicht die Implementierung von Prozessen und die Kommunikation zwischen
diesen, sondern stellt nur ein Konzept dar, was Prozesse zur Verfügung stellen müssen. Weiter
unterscheidet die SOA drei Rollen, die bei der Inanspruchnahme von Diensten miteinander agieren.
Services
Ein Service im Sinne der SOA ist teilweise vergleichbar mit einem Objekt in der objektorientierten
Programmierung. Er besitzt eine eindeutige ID und klar definierte Schnittstelle, über die er von
aussen aufgerufen werden kann. Allerdings besteht eine klare Trennung zwischen Schnittstelle und
Implementierung, weshalb ein Service in dieser Hinsicht eher mit einer Enterprise Java Bean (EJB)
verglichen werden kann, die ihre Schnittstellen auch in Home- bzw. Local-Interfaces veröffentlicht,
ihre interne Struktur aber kapselt.
Markus Schmitt
5
MATHworkflows
Eine serviceorientierte Architektur trennt demnach einen Service in:
Beschreibung:
Im Wesentlichen beschreibt die Servicebeschreibung die Schnittstellen eines Service. Sie
definiert, welche Operationen ein Dienst anbietet und wie diese aufgerufen werden können.
Dabei ist entscheidend, dass auch das Format von Aufruf und eventueller Antwort
beschrieben wird.
Implementierung:
Die Serviceimplementierung muss lediglich schnittstellenkonform arbeiten. In welcher
Programmiersprache oder auf welchem System der Dienst ausgestaltet wird, ist völlig
irrelevant, solange der Service wie in der Servicebeschreibung dargestellt in Anspruch
genommen werden kann.
Rollen
Die SOA trennt bei der Interaktion drei verschiedene Rollen:
Service Provider:
Der Service Provider (Serviceanbieter) implementiert den Service und stellt ihn zur
Ausführung zur Verfügung. Dabei ist der Begriff "Provider" doppeltdeutig, er bezieht sich
sowohl auf die den Service anbietende Organisation als auch auf das eigentlich
implementierende Programm.
Service Consumer:
Der Service Consumer (Servicekonsument) nimmt einen Dienst eines Service Providers in
Anspruch. Wenn ihm dabei die Servicebeschreibung des Dienstes nicht bekannt ist, kann er
diese über einen Service Broker in Erfahrung bringen.
Service Broker:
Der Service Broker (Verzeichnis) ist ein optionales Element in der SOA. Bei ihm können
Servicebeschreibungen von Service Providern hinterlegt und von Service Consumern
abgefragt werden. Dies ist nur dann wichtig, wenn sich Provider und Consumer nicht direkt
kennen.
Merkmale
Zusammenfassend lassen sich folgende Merkmale serviceorientierter Architektur herausstellen:
Dynamische Lokalisierung und Bindung
Ein Service kann durch einen Consumer bei einem Service Broker dynamisch lokalisiert werden.
Anhand von der vom Broker gelieferten Sevicebeschreibung kann dynamisch, also zur Laufzeit,
eine Bindung zu dem Service hergestellt und der Dienst in Anspruch konsumiert werden.
Eigenständige Module
Jeder Service wird als eigeständiges Modul mit klar definierten Schnittstellen implementiert. Nur
Markus Schmitt
6
MATHworkflows
die Beschreibung, nicht die Implementierung oder die interne Struktur sind für den Konsumenten
sichtbar.
Grobe Granularität
Services sind zumeist grob granular, d.h. sie besitzen im Gegensatz zu verteilten Objekten mit
feiner Granularität keine großen Abhängigkeiten, was einen guten Kompromiß zwischen
Wiederverwendung und Performance darstellt.
Lose Kopplung
Durch die geringen Abhängigkeiten zwischen den Modulen werden Flexibilität und Wartbarkeit des
Systems erhöht.
Netzwerkadressierbarkeit
Die Servicebeschreibung eines Dienstes enthält umfassende Informationen über die Adresse, den
Transportmechanismus und das Transportformat, sodass er von Konsumenten dynamisch gebunden
werden kann. Dadurch kann ein Service beispielsweise im Netzwerk ohne weiteres an einen
anderen Ort verschoben werden.
Interoperabilität
Durch die die Verwendung von Protokollen und Formaten, die unabhängig von
Programmiersprachen und Systemen sind, kann ein Service von einer großen Zahl potenzieller
Konsumenten in Anspruch genommen werden.
Servicekomposition
Services können durch ihre Wiederverwendbarkeit als Basis für neue, größere und gröbere Services
dienen.
Investitionsschutz
Nach einmalig hohem Entwicklungsaufwand führt die Modularität zu geringen Redundanzen und
einer höheren Flexibilität, was wiederum häufig zu niedrigeren Betriebskosten führt. Durch den
hohen Wiederverwendungsgrad lassen sich wiederem neue Applikationen schneller entwickeln und
dadurch weitere Entwicklungskosten senken und der Entwicklungszyklus verkürzen.
Weiterführende Links
•
http://www.soablueprints.com: SOA Blueprints – "Best Practices" für serviceorientierte
Systeme
Markus Schmitt
7
MATHworkflows
Web Services
Es gibt viele Definitionen, was ein Web Service eigentlich ist. Auch das World Wide Web
Consortium hat sich dieser Fragestellung angenommen und definiert den Begriff so:
"A Web service is a software system designed to support interoperable machine-tomachine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in
a manner prescribed by its description using SOAP-messages, typically conveyed using
HTTP with an XML serialization in conjunction with other Web-related standards."
[W3C04, „Definitions: Web Service“]
Streng genommen ist der Web Service Standard eine Ausgestaltung des in der Service-orientierten
Architektur eingeführten Begriffs des Service auf der Basis von offenen Standards.
Einführung in Web Services
Analog zur SOA finden sich auch bei der Verwendung von Web Services die drei Rollen Anbieter,
Konsument und Verzeichnis wieder. Grundlage für die Interaktion zwischen den Rollen bilden bei
Web Services vier festgelegte XML-basierte Standards:
SOAP oder XML-RPC:
Kommunikations-Protokolle zum Nachrichtenaustausch.
WSDL (Web Services Description Language):
Plattform-, programmiersprachen- und
protokollunabhängige Metasprache zur Beschreibung
von Web Services.
UDDI (Universal Description, Discovery and Integration):
Ein Verzeichnisdienst mit einer SOAP-Schnittstelle mit
Informationen zu Unternehmen, ihren Daten und ihren
Services. Dabei wird unterschieden zwischen:
• "White Pages" (Unternehmensregister),
• "Yellow Pages" (Branchenverzeichnis),
Abbildung 2: Funktionsweise von Web
• "Green Pages" (Auskunft über Geschäftsmodell Services [Wiki05, „Web Service“]
und -prozesse).
In der Servicebeschreibung eines Web Service wird für den entsprechenden Service eine eindeutige
URI (Uniform Resource Identifier) festgelegt. Über diese URI ist ein Web Service addressierbar.
Anwendung von Web Services
Die bekanntesten Beispiele für Web Services sind die Anwendungen von Google und Amazon, die
Dienste zur Suchmaschinenabfrage bzw. zur Information über Bücher u.a. anbieten. Dennoch
konzentrieren sich Web Services hauptsächlich auf betriebswirtschaftliche Lösungen:
Markus Schmitt
8
MATHworkflows
Beispiel
Darren Barefoot, ein "Technologie Papst" der vom Web-Service-Hersteller Cape Clear Software
gesponsorten Entwickler Gemeinschaft Cape Science, beschreibt in seinem Web Service Primer
[Bare02] eine Welt vor dem Einsatz von WebServices:
Abbildung 3: Geschäftsprozess vor der Verwendung von Web Services [Bare02, S.2]
Dieser Bestell-Prozess enthält viele manuelle Schritte wie Eingabe der Bestelldaten, Erstellen eines
Produktionsauftrags oder die Finanz-Erfassung. Durch die manuellen Schritte ist der Prozess sehr
fehleranfällig. Die Lösung lautet: Einsatz von Web Services:
Abbildung 4: Geschäftsprozess mit Web Services [Bare02, S.2]
Dabei werden für die jeweiligen Anwendungen wie Buchhaltung oder Produktionssystem Web
Service Schnittstellen geschaffen und in einem Geschäftsprozess automatisch abgearbeitet. Das
integrierte Echtzeit-Bestellsystem hat sich dabei um die Orchestrierung der Service-Aufrufe zu
kümmern. Um den durch die Services implementierten Geschäftsprozess einfach zu beschreiben,
wurde 2003 eine neue XML-basierte Sprache eingeführt: BPEL4WS.
Markus Schmitt
9
MATHworkflows
•
•
•
http://www.jeckle.de/webServices/index.html#def: Web Services – Begriffsdefinitionen
http://www.google.com/apis/: Google Web APIs
http://www.amazon.com/gp/aws/landing.html: Amazon Web Services
Markus Schmitt
10
MATHworkflows
Business Process Execution Language
Die Business Process Execution Language (BPEL) wurde 2003 als BPEL4WS (Business Process
Execution Language for Web Services) eingeführt. Die Sprache basiert auf XML und dient "zur
Beschreibung von Geschäftsprozessen, deren einzelne Aktivitäten durch Webservices implementiert
sind." [Wiki05, „BPEL“]
In der Version 1.1 wurde BPEL4WS in BPEL umbenannt, da die Sprache ausschliesslich
Unterstützung für Web Services bietet und der Zusatz "für Web Services" nicht mehr notwendig
erschien. Eine Version 2.0, die inkompatibel zu den 1.x Versionen sein wird, ist in Bearbeitung und
wird in diesem Release allerdings in WSBPEL umbenannt werden, um mit dem Beginn mit WS in
Einklang mit anderen Web Service Standards wie WSDL, WS-Security u.a. zu gelangen.
Geschäftsprozesse, Workflow (Management) und BPEL
Ein Geschäftsprozess ist ein Geschäftsvorfall in einer Wirtschaftseinheit. Ein Beispiel für einen
Geschäftsprozess ist der Bestellvorgang aus dem Kapitel Web Services. Der Prozess hat einen klar
definierten Start ("Aufgeben der Bestellung") und ein definiertes Ende ("Auslieferung"), kann aber
dazwischen einen unterschiedlichen Verlauf nehmen, wenn beispielsweise für die Produktion
Rohstoffe nachgeordert oder je nach Zahlungsweise auf den Geldeingang gewartet werden muss.
Dieser von internen und externen Ereignissen beeinflusste Verlauf wird bei der Modellierung eines
Geschäftsprozesses bestimmt.
Mit der Optimierung und weitestgehenden Automatisierung eines solchen Prozesses beschäftigt
sich das Business Process Management (BPM). Zum einen wird unter BPM das
Managementkonzept verstanden, das sich mit der Optimierung bzw. der Automatisierung des
Prozesses befasst, zum anderen aber auch die Software, die genau das leistet.
Ein Workflow unterstützt technisch gesehen einen Geschäftsprozess und läuft immer nach dem
selben oder einem ähnlichen Schema ab. Es gibt vier grundlegende Workflow-Typen (nach WfMC,
vgl. [Muel05, S. 8] ):
Ad-Hoc-Workflow:
Unterstützt einmalig oder stark variierende Prozesse, die wenig strukturiert und nicht
vorhersehbar sind.
Collaborative Workflow:
Unterstützt das gemeinsame Erarbeiten eines Ergebnisses, wird auch als Synonym für
Groupware verwendet.
Adminsitrative Workflow:
Unterstützt strukturierte Routineabläufe, die nicht strategisch, selten zeitkritisch und von
geringem Geldwert sind.
Production Workflow:
Unterstützt fest strukturierte und vordefinierbare Vorgänge, die zumeist zeitkritisch und von
strategischer Bedeutung sind.
Markus Schmitt
11
MATHworkflows
Mit allen Aufgaben, die bei einem Workflow anfallen (Analyse, Modellierung, Ausführung und
Steuerung), befasst sich das Workflow Management. Werden die einzelnen Arbeitsschritte dabei
von einem IT-Werkzeug unterstützt, spricht man bei der Software von einem WorkflowManagement-System (WfMS).
Im Prinzip kann also ein Workflow einen einzelnen in der SOA beschriebenen Service innerhalb
eines Geschäftsprozesses darstellen. Dadurch wird auch klar, dass BPM ein um EAI (Enterprise
Application Integration) erweitertes Workflow Management darstellt, da ein durch die
unterschiedlichen Services bestehender Integrationsaspekt hinzukommt.
Wenn in einer SOA also mittels BPEL ein Geschäftsprozess beschrieben wird und die involvierten
Services Workflows darstellen, dann kommt der so genannten BPEL Engine, des zur Ausführung
und Kontrolle des Prozesses zuständigen Programms, die Rolle der BPM-Software zu.
Die „BPEL-Sprache“
BPEL ist blockstrukturiert und bietet damit Unterstützung für lokale Scopes. In diesen lokalen
Umgebungen können lokale Variablen definiert oder Fehlerbehandlungen (Fault Handler),
Kompensationsbehandlungen (Compensation Handler) und Ereignisbehandlungen (Event Handler)
ausgeführt werden.
Unterprozesse kennt BPEL hingegen nicht. So kann nicht sichergestellt werden, dass ein
Unterprozess beendet wird, sobald der Hauptprozess terminiert.
Sprachelemente
BPEL unterscheidet zwischen Basic Activities, grundlegenden Aktivitäten, die nicht aus anderen
Aktivitäten aufgebaut sind, und Structured Activities, die der Strukturierung von anderen
Aktivitäten dienen:
Basic Activities
assign
Wertzuweisung an eine Variable
empty
Leere Anweisung (z.B. um in einer Fehlerbehandlung nichts zu tun)
invoke
Synchroner oder asynchroner Aufruf eines Web Service
receive / reply
throw
wait
Anbieten einer (synchronen oder asynchronen) Web Service Schnittstelle
Explizites "Werfen" eines Fehlers
Warten (auf einen Zeitpunkt oder für eine Zeitspanne)
Structured Activities
flow
Parallele Ausführung von Aktivitäten
pick
Aus Prozesssicht nicht deterministische Wahl durch externe Ereignisse
sequence
Sequenzielle Ausführung von Aktivitäten
switch
Bedingte Ausführung von Aktivitäten
while
Schleife (Ausführung von Aktivitäten solange eine Bedingung erfüllt ist)
Tabelle 1: BPEL Sprachelemente, vgl. [Wiki05, „BPEL“]
Markus Schmitt
12
MATHworkflows
Aufruf von Web Services
Ein BPEL-Prozess selber kann als Web Service beschrieben und genutzt werden.
Um andere Web Services (oder sich selber) aufrufen zu können, müssen diese dem BPEL-Prozess
erst als Partner-Link bekannt gemacht werden. Dabei muss der Partner-Service (Service
Endpoint) zum Zeitpunkt des Deployment nicht verfügbar sein, es genügt, wenn der Ort der
Service-beschreibenden WSDL-Datei angegeben wird. Natürlich muss der Service zur Laufzeit
verfügbar sein und die aufgerufene Operation mit den im Prozess verwendeten Aufruf- und
Rückgabeparametern übereinstimmen.
BPEL Engines und Deployment
BPEL Engines führen den in BPEL-Code vorliegenden Geschäftsprozess aus. Dazu muss der
Prozess erst deployt, also auf dem Zielsystem installiert werden. Neben dem BPEL Code und der
WDSL-Datei für den Prozess werden dazu je nach Engine in unterschiedlichen Formaten ein
Deployment-Deskriptor, die Definitionen der Partner und u.U. ein Katalog der WSDL-Dateien
dieser Service-Endpoints benötigt.
Graphische Orchestrierung
Für viele (kommerzielle) BPEL Engines existieren inzwischen Tools zur graphischen
Orchestrierung eines BPEL-Prozesses. Viele davon sind Plugins für die Eclipse IDE oder fest
integriert in eine eigene Eclipse-basierte IDE, beispielsweise bei IBM.
Abbildung 5: Business Process Modeling Notation Elemente [WfRF04]
Markus Schmitt
13
MATHworkflows
Um eine nahezu einheitliche Gestaltung von (BPEL-)Prozessen zu gewährleisten, wurde BPMN
(Business Process Modeling Notation) geschaffen. Die meisten Orchestrierungs-Werkzeuge
orientieren sich bei der Darstellung an der BPMN-Spezifikation, und es gibt auch freie Schablonen
für beispielsweise Microsoft Visio.
•
•
•
http://www.smartcomps.org/confluence/pages/viewpage.action?pageId=182: Twister WSBPEL Guide – Kurzes englischsprachiges BPEL-Tutorial
http://www.oasis-open.org/committees/wsbpel/: OASIS Web Service Business Execution
Language Technical Committee
http://www.bpmn.org/: Business Process Modeling Notation (BPMN) Information
Markus Schmitt
14
MATHworkflows
Analyse und Entwurf
Anforderungen
Die Anforderungen an das Projekt scheinen recht gering, die Herausforderung liegt in der
Implementierung. Mit JBoss jBPM mit der BPEL-Erweiterung und Apache Tomcat mit
ActiveBPEL sind schon zwei (Applikations-)Server vorgegeben.
Mathematische Web Services
Die mathematischen Web Services für die Grundrechenarten sollen unter jBoss laufen. Da es ein
Paket von JBoss mit Server, Eclipse und jBPM gibt, sollten die Web Services ohne Probleme dafür
implementiert und deployt werden können.
Workflows
Die Workflows sollen sowohl unter JBoss als auch unter Apache Tomcat zur Ausführung gebracht
werden. Für den JBoss Server sollten aufgrund der vorhandenen Entwicklungsumgebung keine
Probleme auftreten, und auch für Tomcat werden kein Probleme erwartet, da es sich bei der dem
jBPM-Paket beigefügten IDE um ein "normales" Eclipse handelt.
Aufruf der Web Services und Workflows
Da sich deployte Workflows bzw. Prozesse in den beiden BPEL Engines wie Web Services
präsentieren und verhalten, ist zum Testen aller Komponenten lediglich ein Tool zum Aufrufen von
Web Services nötig. Im e-Learning-Modul Web Services [WWR04] ist ein mit Java Webstart
implementierter SOAP Client vorhanden, der zum Testen von Web Services völlig ausreicht.
Später kann für die Workflows mittels des im jBPM-Paket vorliegenden WSDL2J auch ein
eigenständiger Client entwickelt werden.
Markus Schmitt
15
MATHworkflows
Grobentwurf
Mathematische Web Services
Um die in der SOA auf verschiedenen Systemen laufenden Services zu simulieren, werden die Web
Services für die Grundrechenarten nicht in einem Web Service mit verschiedenen Operationen,
sondern als fünf verschiedene Services implementiert werden. Da alle zu implementierenden
Rechenarten auch Fließkommazahlen erlauben, soll für die Über- und Rückgabewerte float oder
double verwendet werden.
Gegenüber einer ersten Idee, einige Grundrechenarten wiederum durch Workflows mit der
Verwendung anderer Grundrechenarten zu realisieren (z.B. Subtraktion durch Addition mit
Negierung oder Multiplikation durch wiederholtes Addieren), ist es völlig ausreichend, in den Web
Services die jeweiligen Rechenarten auszuführen.
Additions-Service
float add(float x, float y) {
z := x + y
return z
}
Subraktions-Service
float sub(float x, float y) {
z := x - y
return z
}
Multiplikations-Service
float mul(float x, float y) {
z := x * y
return z
}
Markus Schmitt
16
MATHworkflows
Divisions-Service
Um die Implementierung entsprechend einer Beispiel-Anwendung gering zu halten, wird auf ein
Abfangen einer Division durch Null verzichtet.
float div(float x, float y) {
z := x / y
return z
}
Stackservice-Service
Im Gegensatz zu den Grundrechenarten besitzt der Stack Web Service zwei Operationen, deren
endgültige Implementierung im Entwurf allerdings substanzlos ist.
void push(float x)
float pop() {
return x
}
Workflows
Als Workflows wurde zum einen eine einfache mathematische Rechnung mit sequenziellen und
parallelen Abläufen gewählt, zum anderen eine rekursive Funktion, die Ackermannfunktion.
Bei der späteren Implementierung ist darauf zu achten, dass die Variablem jeweils temporär in die
Nachrichten-Variablen der jeweiligen BPEL-Partner-Links kopiert werden müssen.
Rechnung (a+b)*(c-d)
Der Pseudo-Code für die einfache Rechnung ( a + b ) * ( c - d ) mit Hilfe eines BPEL-Prozesses
lautet:
float rechnung(float a, float b, float c, float d) {
x := add(a, b)
}
y := sub(c, d)
z := x * y
return z
Markus Schmitt
17
MATHworkflows
Ackermannfunktion
Für die 1926 von Wilhelm Ackermann gefundene, schnellwachsende mathematische Funktion
existiert eine teilweise iterative Implementierung (vgl. [Wiki05, „Ackermannfunktion“]):
function ack(m, n)
while m ≠ 0
if n = 0
n := 1
else
n := ack(m, n - 1)
m := m - 1
return n + 1
Umgesetzt als Pseudo-Code für den BPEL-Prozess ergibt das:
int ack(int m, int n) {
while m ≠ 0
switch (m)
case n = 0
n := 1
}
otherwise
t := sub(n, 1)
m := ack(m, t)
m := sub(m, 1)
z := add(n, 1)
return z
Markus Schmitt
18
MATHworkflows
Implementierung
Infrastruktur und Komponenten
Der Labor-Rechner, auf dem das Projekt realisiert wurde, war mit Windows XP Betriebssystem
und Java 5 (JDK 1.5.0) ausgestattet. Die hier aufgezählte Software ist noch einmal im Anhang
detailliert aufgelistet.
Entwicklungsumgebung
Als Entwicklungsumgebung bot sich Eclipse an, da von JBoss mit dem JBoss jBPM Starters Kit
ein Paket verfügbar ist, das jBPM, den JBoss Application Server und die Eclipse IDE mit dem
entsprechenden Prozess-Designer enthält. Für BPEL-Unterstützung muss allerdings die seperat
erhätliche jBPM BPEL Extension kompiliert und installiert werden.
Leider ist der jBPM Prozess Designer nicht in der Lage, BPEL Prozesse zu orchestrieren, so dass
ein geeignetes Eclipse-Plugin gesucht werden musste. Mit dem frei verfügbaren Oracle BPEL
Process Designer for Eclipse ist allerdings ein sehr umfangreiches und einfach zu bedienendes
Tool verfügbar, das eigentlich für den Oracle BPEL Process Manager gedacht ist, aber auch ohne
diesen eine Orchestrierung von BPEL-Prozessen erlaubt.
JBoss
Der im Starters Kit enthaltene JBoss Application Server ist ein abgespeckter JBoss, der nur eine
jBPM-Konfiguration enthält. Um auch Web Services auf dem Server deployen zu können, ist daher
ein Installieren eines vollständigen JBoss Servers über die Version des Pakets notwendig.
Verwunderlich ist auch, dass in dem Starter Kit die JBoss IDE nicht integriert ist. Diese ermöglich
u.a. ein komfortables Starten und Stoppen des Server aus Eclipse und auch das Deployment läßt
sich über ein Kontextmenü auslösen. Da die JBoss IDE ein Eclipse-Plugin ist, läßt sie sich aber
ohne weiteres in Eclipse durch Installation in das Plugin-Verzeichnis integrieren.
Mittels XDoclet lassen sich einfach durch bestimmte Tags aus Stateless Session EJBs Web Services
bauen. In der JBoss IDE ist allerdings eine etwas ältere Version integriert, so dass XDoclet den
Hinweisen in [OSM05] folgend mit einer neueren Version erweitert werden muss.
Markus Schmitt
19
MATHworkflows
jBPM BPEL
Für die Prozess-Ausführung und das Deployment benötigt jBPM eine Datenbank. Hier bietet sich
MySQL an, das auch in den JBPM BPEL Beispielen verwendet wird. Die Installation von MySQL
ist bekannt einfach, für Hibernate wird nur das Anlegen eines neuen Benutzers notwendig, auch ein
JDBC-Treiber muss installiert werden.
Tomcat
Der Apache Tomcat Application Server ist die Alternative zur Ausführung von BPEL-Prozessen.
Dafür ist ActiveBPEL notwendig, das aber genauso einfach wie Tomcat zu installieren ist. Eine
Datenbank ist hier nicht notwendig, könnte aber verwendet werden.
Da viele Beispiele von ActiveBPEL auf der ActiveBPEL Utility Library beruhen, muss diese
allerdings auch erstellt und installiert werden, um eigene Prozesse auf den Beispielen aufbauen zu
lassen.
Umsetzung der Web Services
Die Implementierung der Web Services folgte dem Entwurf.
Generierung mit XDoclet
Nachdem XDoclet entsprechend erweitert wurde (vgl.Kapitel Infrastruktur und [OSM05]), konnten
einfach zu programmierende Stateless Session Beans durch Einfügen von XDoclet-Tags als Web
Services für JBoss erstellt werden.
Die einfache Konfiguration von XDoclet in den jeweiligen Projekt-Einstellungen ermöglichte eine
schnelle Anpassung der verschiedenen Web Services angepasst werden. So blieb der Quellcode für
die Web Services gering, wie an einem Ausschnitt aus der AddServiceBean.java des AdditionsService zu erkennen ist:
Markus Schmitt
20
MATHworkflows
package de.fhwiesbaden.informatik.vvs.mathworkflows.services.addservice.ejb;
[+] import java.rmi.RemoteException;
/**
* @ejb.bean name="AddServiceBean" display-name="AddService" description="Add
*
WebService" jndi-name="ejb/AddService" type="Stateless"
*
view-type="service-endpoint"
*
* @ejb.interface service-endpoint-class="de.fhwiesbaden.informatik.vvs. ↵
mathworkflows.services.addservice.interfaces.AddServiceEndpoint"
*
* @wsee.port-component name="AddService"
*
*/
public class AddServiceBean implements SessionBean {
private static final Logger log =
Logger.getLogger(AddServiceBean.class);
public AddServiceBean() {
super();
}
[...]
/**
* Business method
* @ejb.interface-method view-type = "service-endpoint"
*/
public double add(double x, double y) {
double z = x + y;
log.info("add(" + x + "," + y + ") => " + z);
return z;
}
}
/**
* Create method
* @ejb.create-method view-type = "local"
*/
public void ejbCreate() throws javax.ejb.CreateException {
log.setLevel(Level.DEBUG);
}
Um anhand der Server-Ausgaben auf der Konsole verfolgen zu können, ob ein Web Service
aufgerufen wurde bzw. was er berechnet hat, wurde in den Geschäftsmethoden der Services
Logging-Ausgaben eingebaut. Die Implementierung von Subtraktions-, Multiplikations-,
Divisions- und Stapelspeicher-Service erfolgte analog zu dem Additions-Service nach dem
Grobentwurf in eigenen Projekten.
Markus Schmitt
21
MATHworkflows
Exceptions
Ein eigenes Commons-Projekt enthält eine gemeinsam von den Web Services benutzte
MathServiceException-Klasse:
package de.fhwiesbaden.informatik.vvs.mathworkflows.common.exceptions;
import java.rmi.RemoteException;
public class MathServiceException extends RemoteException {
public MathServiceException(String cause) {
super(cause);
}
}
Diese wird von den entsprechenden Web Services bei einem leeren Stack oder bei einer Division
durch Null benutzt:
package de.fhwiesbaden.informatik.vvs.mathworkflows.common.exceptions;
public class DivDBZException extends MathServiceException {
public DivDBZException() {
super("Division by zero is undefined!");
}
}
Packaging
Durch die eingebaute Packaging-Funktionalität von Eclipse wurden die einzelnen Projekte jeweils
zur Java Archives (JAR) und dann in einem eigenen Projekt für das Deployment in JBoss mit dem
entsprechenden Deskriptor zu einem Enterprise Application Archive (EAR) gepackt.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC
"-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN"
"http://java.sun.com/dtd/application_1_3.dtd">
<application>
<display-name>Math WebServices</display-name>
<module>
<ejb>AddEJB.jar</ejb>
</module>
<module>
<ejb>SubEJB.jar</ejb>
</module>
<module>
<ejb>MulEJB.jar</ejb>
</module>
<module>
<ejb>DivEJB.jar</ejb>
</module>
<module>
<ejb>StackEJB.jar</ejb>
</module>
</application>
Markus Schmitt
22
MATHworkflows
Umsetzung der Workflows
Orchestrierung
Die Orchestrierung der Prozesse gestaltete sich unter dem Oracle BPEL Designer einfach. Auch
Partner Links, also die Verbindungen zu Web Services Endpunkten, konnten zu deployten oder in
WSDL-Beschreibungen vorliegenden Web Services einfach mit dem Tool erstellt werden.
Dabei war es möglich, dem im Kapitel Entwurf gestalteten Pseudocode zu folgen. Der ebenfalls
anzeigbare BPEL-"Code" konnte dann einfach in die BPEL-Dateien der entsprechenden Projekte
für jBPM BPEL und ActiveBPEL kopiert werden.
Bedingt durch den Umstand, dass BPEL eine XML-basierte Sprache ist, wurde dabei ein relativ
umfangreicher Code erstellt.
BPEL Engines
Sowohl jBPM BPEL als auch ActiveBPEL benötigen eine Anzahl von Deskriptoren und weiteren
XML-Dateien, um mit den erstellten Prozessen arbeiten zu können.
Dabei sind unter anderem die für die Darstellung des BPEL-Prozesses als Web Service
notwendigen WSDL-Dateien zu erstellen. ActiveBPEL benötigt dafür sogar zusätzlich noch eine
konkretere Ausgestaltung des Web Services.
Beide Engines bieten auf ihren Homepages eine große Zahl von Beispielen. Auf diesen konnten die
beiden zu implementierenden Prozesse aufgesetzt werden. Mit kleinen Änderungen konnte dafür
der in den Projekten für den Oracle BPEL Process Manager orchestrierte BPEL-Code verwendet
werden.
Die "Packetierung" und das Deployment gestaltete sich bei den beiden Engines durch bei den
Beispielen mitgelieferte Ant-Build-Skripts entsprechend leicht. Da beide Engines die Prozesse wie
erwartet nach aussen als Web Service präsentierten, lies sich die Ausführung wie geplant durch den
SOAP Client testen. Die für den Web Service Aufruf notwendigen Informationen waren über
WSDL-Beschreibungen zu beziehen, die beiden Engines für die auf ihnen deployten Prozesse
präsentierten.
Markus Schmitt
23
MATHworkflows
Beispiel: Ackermannfunktion
Alle Deskriptoren aufzuzeigen, würde den Umfang dieser
Dokumentation sprengen. Daher verweise ich hier auf die
entsprechenden Archive auf der Projekt-CD. Hier
dennoch ein Ausschnitt aus dem erzeugten BPEL-Code:
<process name="ackermann" [...]">
<partnerLinks>
<partnerLink name="client" partnerLinkType="tns:mathPLT"
myRole="service"/>
<partnerLink name="AckPL" partnerLinkType="tns:AckServiceLink" ↵
partnerRole="AckServiceProvider"/>
<partnerLink name="AddPL" partnerLinkType="tns:AddServiceLink" ↵
partnerRole="AddServiceProvider"/>
[...]
</partnerLinks>
<variables>
<variable name="input" messageType="tns:inputMessage"/>
<variable name="output" messageType="tns:outputMessage"/>
<variable name="ack-params" messageType="tns:inputMessage"/>
<variable name="ack-result" messageType="tns:outputMessage"/>
<variable messageType="ads:AddService_add" name="add-params"/>
<variable messageType="ads:AddService_addResponse" name="add-result"/>
[...]
</variables>
<sequence>
<receive operation="compute" partnerLink="client" portType="tns:mathPT" ↵
variable="input" createInstance="yes" name="compute_begin"/>
<assign name="assign-temp-vars">
<copy>
<from variable="input" part="m"></from>
<to variable="temp-m"/>
</copy>
<copy>
<from variable="input" part="n"></from>
<to variable="temp-n"/>
</copy>
</assign>
<while name="while" condition="bpel:getVariableData('temp-m')!= '0.0'">
<sequence>
<switch name="switch-recursive">
<case name="mIsNull" condition="bpel:getVariableData('temp-n')↵
= '0.0'">
<assign name="assign-n-to-one">
<copy>
<from expression="1.0"></from>
<to variable="temp-n"/>
</copy>
</assign>
</case>
<otherwise>
[...]
</otherwise>
</switch>
<assign name="assign-sub-for-while">
<copy>
<from variable="temp-m"></from>
<to variable="sub-params" part="x"/>
</copy>
<copy>
<from expression="1.0"></from>
<to variable="sub-params" part="y"/>
</copy>
</assign>
<invoke name="invoke-sub-for-while" partnerLink="SubPL" ↵
portType="sus:SubService" operation="sub" inputVariable="sub-params" ↵
outputVariable="sub-result"/>
<assign name="assign-m-to-sub-result">
<copy>
<from variable="sub-result" part="result"></from>
<to variable="temp-m"/>
</copy>
</assign>
</sequence>
</while>
[...]
<reply operation="compute" partnerLink="client" portType="tns:mathPT" ↵
variable="output" name="compute_end">
<bpeld:annotation xmlns:bpeld="http://schemas.oracle.com/bpel/eclipse/↵
designer">
<bpeld:meta map.label="compute (caller)"/>
</bpeld:annotation>
</reply>
</sequence>
</process>
Markus Schmitt
Abbildung 6: Prozess "Ackermannfunktion"
24
MATHworkflows
Umsetzung des Clients für die Ackermannfunktion
Ausgehend von der WSDL-Beschreibung des im Tomcat deployten Ackermann-Prozesses, wurden
mittels Axis WSDL2J Stubs zum Aufruf des Prozesses generiert. Dies führte wiederholt zu
Fehlern, die aber mit einer zu diesem Zeitpunkt neuen Version 4.0.3 des JBoss Application Servers
behoben werden konnte.
Java Swing Client
Die Ausführung des Ackermann-Prozesses sollte mit einer kleinen Anwendung demonstriert
werden können. Nach einem ersten Kommandozeilen-Client wurde eine Applet-Lösung erstellt, die
allerdings aufgrund der Sicherheitsbeschränkungen der Internet Browser nur unter Eclipse lauffähig
war.
Daher wurde als dritte und endgültige Lösung ein einfacher Java Swing Client zum Aufruf des als
Web Services gekapselten Workflows entwickelt.
Abbildung 7: Ackermann Java Swing Client
Der Client befriedigt zwar alle Ansprüche, besitzt aber keine besonders hervorzuhebende
Implementierung und soll deshalb nur der Vollständigkeit halber hier erwähnt werden.
Markus Schmitt
25
MATHworkflows
Bewertung
Probleme
Neben dem Problem, geeignete Quellen zu finden, die in BPEL-Prozessen nicht nur das Aufrufen
von Web Services aus dem gleichen Beispiel, sondern auch von entfernten Services beschreiben,
sind bei der Duchrführung des Projekts vor Probleme in folgenden Punkten aufgetreten:
Java 5
Ein großes Handicap war die Verwendung von Java 5. Neben dem Umstand, dass auf dem LaborRechner nur ein JDK 1.5 vorhanden war, benötigte auch XDoclet zur Generierung der Web
Services für JBoss Java 5. Einige Software war damit allerdings überhaupt nicht ausführbar, andere
mussten um einige Blibliotheken erweitert werden.
Da Java 5 allerdings der zukünftige Standard in diesem Gebiet ist, war dessen Verwendung aus
praktischen Gesichtspunkten durchaus sinnvoll. Allerdings war die jeweilige Hilfestellung nur in
den entsprechenden Internet-Foren, und manchmal nur tagesaktuell, zu finden.
jBPM BPEL
Bis zum Ende des Projekts ließ sich jBPM BPEL nicht "überrreden", auch entfernte Web Services
aufzurufen. Lediglich Prozesse ohne die Benutzung "fremder" Partner Links, also beispielsweise
nur mit dem Kopieren von Variablen, liessen sich ohne Fehlermeldung ausführen. Die
Fehlermeldung "unitialized partner role" wurde regelrecht zum Fluch.
Ein Eintrag im JBoss JIRA (http://jira.jboss.com/jira/browse/BPEL-41?page=all) läßt allerdings
vermuten, dass das Problem in der nächsten Version der BPEL Extension behoben sein wird.
Axis-generierte Stubs
Anfangs liessen sich die Web Services und Prozesse nicht mit dem Axis-generierten Stub aufrufen.
Das betraf auch die bei Beispielen vorhandenen Clients. Zwar waren die Web Services durch
Verwendung des SOAP Clients testbar, dennoch behinderte der AxisFault mit
java.lang.NullPointerException die spätere Entwicklung des Test-Clients.
Auch hier war ein Hinweis nur über ein Forum im JBoss JIRA
(http://jira.jboss.com/jira/browse/JBWS-187?page=all) zu finden, der den – ebenfalls auf Java 5
beruhenden – Fehler behebende JBoss Application Server 4.0.3 war rechtzeitig verfügbar.
Markus Schmitt
26
MATHworkflows
Leistungsumfang
Neben dem Leistungsumfang des Oracle BPEL Process Designer, der seine Hauptbestimmung,
die Orchestrierung von Prozessen, meisterte und damit alle ihm anvertrauten Aufgaben erfüllte, ist
vor allem ein Vergleich der beiden BPEL Engines interessant.
jBPM BPEL
Die jBPM BPEL Extension hat einen zwiespältigen Eindruck hinterlassen. Bis auf den bereits
erwähnten Fehler beim Aufruf von Web Services – der zugebenerweise Hauptaufgabe von BPEL ist
– schien jBPM BPEL die volle BPEL 1.1 Spezifikation einzuhalten und damit auch alles zu
ermöglich, was der Standard erlaubt. Mehr ist eigentlich nicht notwendig.
Beim Vergleich mit ActiveBPEL ist jBPM BPEL allerdings deutlich der Verlierer. Dazu tragen vor
allem die umständliche Erstellung von Web Services als Prozess-Frontend, das damit verbundene
aufwendigere Deployment und die ebenfalls dadurch komplizierteren Deskriptoren bei.
ActiveBPEL
Wie jBPM BPEL erfüllte ActiveBPEL die volle BPEL 1.1 Spezifikation.
Allerdings glänzte ActiveBPEL mit einer eigenen Administrations-Oberfläche, die
Fehlermeldungen beim Deployen eines Prozesses im Klartext und ohne umständliches Suchen in
der Konsole anzeigt. Das Goodie, auch den aktuellen Stand eines laufenden Prozesses – allerdings
auch vereinzelt mit Fehlermeldungen beim Erstellen der Grafiken –, ist ein weiterer Pluspunkt.
Vor allem aber überzeugen bei ActiveBPEL die wöchentlichen Releases und der Umstand, dass
BPEL-Prozesse direkt als Web Service verfügbar gemacht werden.
Markus Schmitt
27
MATHworkflows
Zusammenfassung
„Viel Code – Kleine Wirkung“
Mit diesem Satz läßt sich auf den ersten Blick der gezeigte Einsatz von BPEL zusammenfassen. Für
eine kleine Funktionalität war umfangreicher initialer Code notwendig. Ruft man sich aber das
Beispiel im Kapitel Web Services ins Gedächtnis, wird eines klar:
Für Applikationsintegration im SOA-Umfeld ist BPEL sicher eine interessante Technologie und
Alternative. Auch ein Geschäftsprozess wie der angerissene Bestellvorgang besteht im Endeffekt
nicht aus mehr Aktionen oder Services wie die im Projekt bearbeiteten Prozesse. Eine Meldung an
die Buchhaltung, den Auftrag an das Produktionssystem und das Warten auf die Bestätigung,
vielleicht noch das Warten auf einen Geldeingang, und schon ist der Prozess fast beendet.
Dies zeigt mir, dass BPEL wirklich eine interessante Sache ist. Würde ich es aber selber einsetzen
wollen, würde ich noch ein wenig warten. WSBPEL 2.0 steht kurz bevor und wird mit
entscheidend veränderter Spezifikation verabschiedet werden. Und bis dann alle BPEL Engines
diese auch voll unterstützen, wird noch einige Zeit ins Land gehen...
Markus Schmitt
28
MATHworkflows
Literaturverzeichnis
[Acti05]
ACTIVEBPEL, LLC (Hrsg.): ActiveBPEL Engine Documentation.
http://www.activebpel.org/docs/, Stand 05.11.2005
[Back02]
BACKSCHAT, Martin ; GARDON, Otto: Enterprise JavaBeans: Grundlagen - Konzepte Praxis. Berlin: Spektrum, Akad. Verlag, 2002. - ISBN 3-8274-1322-2
[Bare02]
BAREFOOT, Darren: Web Services Primer.
http://www.capescience.com/education/primer/, 09.09.2002. - Stand 09.12.2004
[Beng04]
BENGEL, Günther: Verteilte Systeme. 3. Aufl.
Wiesbaden: Vieweg, 2004. - ISBN 3-528-25738-5
[Cape02]
CAPE CLEAR SOFTWARE: Salesforce.com Flash Presentation.
http://www.capeclear.com/salesforce/, 2002. - Stand 09.12.2004
[CIO05]
CIO ONLINE / IDG BUSINESS VERLAG GMBH (Hrsg.) ; MIEDL, Wolfgang: Dynamische
Service-Architekturen.
http://cio.de/index.cfm?pid=170&pk=808886, 04.04.2005. - Stand 04.11.2005
[Daum05]
DAUM, Berthold ; FRANKE, Stefan ; TILLY, Marcel: Webentwicklung mit Eclipse.
Heidelberg: dpunkt.verlag, 2005. - ISBN 3-89864-282-8
[dNET03]
MICROSOFT .NET: See What Web Services Can Do for You.
http://www.microsoft.com/net/basics/webservicesoverview.asp, 13.06.2003.
[Grim05]
GRIMM, Bernd: Service-orientierte Architektur - Das nächste große Ding?.
http://www.it-motive.de/home.cfm?division=eci&navikey=ECI-SOAVeroeffentlichungen, 12.07.2005.
[Jane01]
JANETZKE, Philipp: Flexibles und Regelbasiertes Workflow-Management an
Universitäten. Hamburg: Dr. Kovac Verlag, 2001. - ISBN 3-8300-0429-X
[JBos05]
JBOSS INC. (Hrsg.): JBoss jBPM Documentation Library.
http://www.jboss.com/products/jbpm/docs, Stand 05.11.2005
[Jeck04]
JECKLE, Mario: Web Services.
http://www.jeckle.de/webServices/index.html, 11.06.2004. - Stand 04.11.2005
[Kroe04]
KROEGER, Reinhold: Verteilte Systeme: Folien der Vorlesung.
http://wwwvs.informatik.fh-wiesbaden.de/lehre/vs04ws/material.html,
Wintersemester 2004/05.
Markus Schmitt
29
MATHworkflows
[Kroe05]
KROEGER, Reinhold: Verteilte Systeme: Folien der Vorlesung.
http://wwwvs.informatik.fh-wiesbaden.de/lehre/vs05ws/material.html,
Wintersemester 2005/06.
[Muel05]
MÜLLER, Joachim: Workflow-based Integration.
Berlin: Springer, 2005. - ISBN 3-540-20439-3
[OSM05]
OPERATING SYSTEMS AND MIDDLEWARE GROUP AT HPI (Hrsg.): Web Service Development
with J2EE.
http://www.dcl.hpi.uni-potsdam.de/research/asg/ws4ejb/, Stand 05.04.2005
[Sun05]
SUN MICROSYSTEMS (Hrsg.) ; BADANI, Ashesh: Service Oriented Architecture: Sun's
Pragmatic Approach.
http://see.sun.com/, 01.06.2005
[W3C04]
W3C (Hrsg.) ; HAAS, Hugo: Web Services Glossary.
http://www.w3.org/TR/ws-gloss/, 11.02.2004. - Stand 04.11.2005
[Wang04]
WANG, Dapeng (Hrsg.) BAYER, Thomas ; FROTSCHER, Thilo ; TEUFEL, Marc: Java Web
Services mit Apache Axis.
Frankfurt: Software & Support Verlag, 2004. - ISBN 3-935042-57-4
[WfR04]
WORKFLOW RESEARCH (Hrsg.): Visio Templates for BPMN.
http://www.workflow-research.de/Downloads/BPMN/, Stand 27.11.2005
[WfRF04]
WORKFLOW RESEARCH FORUMS (Internet-Forum): Process Modeling.
http://www.workflow-research.de/Forums/index.php?act=ST&f=2&t=30&st=0,
Stand 27.11.2005
WIKIPEDIA (Hrsg.):
- Ackermannfunktion. http://de.wikipedia.org/wiki/Ackermannfunktion,
Stand 09.10.2005
- BPEL. http://de.wikipedia.org/wiki/BPEL, Stand 19.10.2005
- Service Oriented Architecture.
http://de.wikipedia.org/wiki/Service_Oriented_Architecture, Stand 15.11.2005
- Web Service. http://de.wikipedia.org/wiki/Web_Service, Stand 26.10.2005
[Wiki05]
[WSI04]
WS-I (Hrsg.) ; COTTON, Paul: Ensuring Web Services Security.
http://www.ws-i.org/docs/presentations/wsi_netsec_preso_final.ppt, 15.06.2004.
[WWR04]
WISSENSWERKSTATT RECHENSYSTEME (Hrsg.) ; WALDHART, Tina: Verteilte Systeme: Web
Services.
http://wwwvs.informatik.fh-wiesbaden.de/e-learning/ws.html, 12.07.2004.
[ZDNet]
ZDNET / CNET NETWORKS (Hrsg.) ; MCKENDRICK, Joe ; MANASCO, Britton: SOA:
Service-Oriented Architecture Weblog.
http://blogs.zdnet.com/service-oriented/, online seit 27.10.2004. - Stand 04.11.2005
Markus Schmitt
30
MATHworkflows
Abbildungsverzeichnis
Abbildung 1: Einfluss von Web Services auf den (Internet-)Markt [WSI04, S.7].............................. 4
Abbildung 2: Funktionsweise von Web Services [Wiki05, „Web Service“]....................................... 8
Abbildung 3: Geschäftsprozess vor der Verwendung von Web Services [Bare02, S.2]..................... 9
Abbildung 4: Geschäftsprozess mit Web Services [Bare02, S.2]........................................................ 9
Abbildung 5: Business Process Modeling Notation Elemente [WfRF04]......................................... 13
Abbildung 6: Prozess "Ackermannfunktion"..................................................................................... 24
Abbildung 7: Ackermann Java Swing Client..................................................................................... 25
Markus Schmitt
31
MATHworkflows
Anhang
–
Verwendete Software
–
Installations- und Benutzeranleitung
Markus Schmitt
32
MATHworkflows
Verwendete Software
Prozess-Design
Entwicklungsumgebung und graphische Orchestrierung.
•
JBoss jBPM Starters Kit 3.0.1 [link]
Eclipse IDE mit jBPM Process Designer Plugin und JBoss-Server in jBPM-Konfiguration,
entgegen der Angaben mit Eclipse 3.1.
•
JBoss jBPM BPEL Extension 1.0 alpha 3 [link]
JBoss jBPM BPEL Erweiterung.
•
Oracle BPEL Designer for Eclipse 3.0 (Version 0.9.13) [link]
Graphische Orchestrierung von BPEL-Prozessen, eigentlich für Oracle BPEL Process
Manager.
Benötigte Update auf dem Labor-Rechner unter Windows XP:
• Microsoft XML Basisdienste [link]
MSXML 4.0 Service Pack 2
JBoss Server
JBoss Application Server zur Ausführung der Web Services und jBPM BPEL Prozesse.
•
JBoss Application Server 4.0.3 SP1 [link]
Ursprünglich im Projekt 4.0.2, später Update auf 4.0.3 wegen Ausführungsfehlern.
•
JBoss Eclipse IDE 1.5 Release Candidate 1 [link]
JBoss IDE Eclipse-Plugins zur Steuerung des Application Server über Eclipse etc.,
Version 1.5 benötigt wegen Java 5 und Eclipse 3.1.
Tomcat Server
Application Server zur Ausführung der ActiveBPEL Prozesse.
• Apache Tomcat 5.0.28 [link]
Jakarta Tomcat Core Version.
•
ActiveBPEL 2.0.0_7 [link]
Active BPEL Weekly Release.
Um eigene Prozesse auf den Beispielen von ActiveBPEL aufbauen zu können:
• ActiveBPEL Utility Library [link]
ActiveBPEL Beispiel util.
Markus Schmitt
33
MATHworkflows
Sonstige Software
•
MySQL 4.1.14 [link]
Benötigt von Hibernate für jBPM BPEL Prozesse. Dafür Anlegen eines Benutzers
notwendig:
Username:
jbpm_user
Password:
hopesystems
•
MySQL Connector/J 3.1.11 [link]
MySQL JDBC Treiber.
•
JWSDP 1.6 [link]
Sun Java Web Services Developer Pack.
•
Axis 1.3 [link]
Apache Axis.
•
XDoclet 1.2.3 [link]
Erweiterung von XDoclet innerhalb der JBoss IDE zur Generierung von Web Services für
JBoss aus EJB-SLSBs notwendig, siehe [OSM05].
Markus Schmitt
34
MATHworkflows
Installations- und Benutzeranleitung
Umgebungsvariablen
Folgende Umgebungsvariablen müssen in der Systemsteuerung gesetzt werden:
AXIS_HOME =
H:\axis-1_3
AXIS_LIB =
%AXIS_HOME%\lib
AXISCLASSPATH =
%AXIS_LIB%\axis.jar;%AXIS_LIB%\commons-discovery.jar; ↵
%AXIS_LIB%\commons-logging.jar;%AXIS_LIB%\jaxrpc.jar; ↵
%AXIS_LIB%\saaj.jar;%AXIS_LIB%\log4j-1.2.8.jar; ↵
%AXIS_LIB%\xml-apis.jar;%AXIS_LIB%\xercesImpl.jar
CATALINA_HOME =
C:\jakarta-tomcat-5.0.28
CLASSPATH =
.;H:\jbpm-starters-kit-with-eclipse-3.0\mysql-connector-java-3.1.11\ ↵
mysql-connector-java-3.1.11-bin.jar
JAVA_HOME =
C:\Programme\Java\jdk1.5.0_02
JBOSS_HOME =
H:\jbpm-starters-kit-with-eclipse-3.0\jbpm-server
MYSQL_HOME =
C:\mysql-4.1.14-win32
PATH =
H:\Sun\jwsdp-1.6\jwsdp-shared\bin;H:\jbpm-starters-kit-with-eclipse-3.0\ ↵
jbpm-designer\eclipse\plugins\org.apache.ant_1.6.5\bin;%PATH%
Starten der Software
Ein Starten der Software und Server in der folgenden Reihenfolge hat sich als optimal erwiesen:
•
•
•
•
MySQL: Start mit
C:\mysql-4.1.14-win32\bin\mysql_start_nt.bat
Eclipse: Start mit
H:\jbpm-starters-kit-with-eclipse-3.0\jbpm-designer\start.bat
JBoss: Start unter Eclipse mit:
• In dem View Server Navigator
• Kontextmenü (Rechtsklick) von JBoss 4.0.2 default
• Start
Tomcat: Start mit
C:\jakarta-tomcat-5.0.28\bin\startup.bat
Markus Schmitt
35
MATHworkflows
Eclipse läßt sich wie eine normale Windows-Anwendung beenden, Tomcat mit C:\jakartatomcat-5.0.28\bin\shutdown.bat und MySQL mit C:\mysql-4.1.14win32\bin\mysql_stop_nt.bat. JBoss wird durch über gleiche Kontextmenü wie zum
Starten durch Auswahl von Shutdown anstelle von Start herunter gefahren.
Adressen der Application Server
Nach dem Starten der Application Server befinden sich
•
•
JBoss unter: http://localhost:8080
Tomcat unter: http://localhost:8088
Generierung und Deployment der Web Services
•
•
Auf alle Web Service Projekte (AddService, SubService, MulService, DivService,
StackService) im Kontextmenü:
• Run XDoclet (Ctrl+Shift+F1)
• Run Packaging (Ctrl+Shift+F2)
Dann auf MathService:
• Run Packaging (Ctrl+Shift+F2)
• Refresh Project (F5)
• Kontextmenü von MathApp.ear im Projekt-Hauptverzeichnis
• Deployment → Deploy To... → JBoss 4.0.2 default
Generierung und Deployment der jBPM BPEL Prozesse
Wenn nicht vorhanden, im dem View Ant die build.xml des Projekts BPEL_Test_Math
hinzufügen, dann:
•
Im dem View Ant innerhalb des zugehörigen Buildfiles
• Bei erstmaliger Ausführung zum Anlegen des MySQL-Datenbankschemas für
jBPM:
Doppelklick auf create-schema
• Doppelklick auf deploy-definition
• Doppelklick auf generate-service
• Doppelklick auf wscompile
• Doppelklick auf deploy-application
Danach Meldungen der Konsole des gestarteten JBoss im entsprechnden View von Eclipse
beachten. Undeployment mit Doppelklick auf undeploy-application.
Markus Schmitt
36
MATHworkflows
Generierung und Deployment der ActiveBPEL Prozesse
Wenn nicht vorhanden, im dem View Ant die build.xml des jeweilige Projekts
(ActiveBPEL_Test_Math oder ActiveBPEL Ackermann) hinzufügen, dann:
•
Im dem View Ant innerhalb des zugehörigen Buildfiles
• Doppelklick auf deploy-bpel
Danach Meldungen in der Konsole des gestarteten Tomcat oder im Deployment-Log unter
http://localhost:8088/BpelAdmin/ beachten. Undeployment mit Doppelklick auf
undeploy.
Testen des Ackermann-Prozesses
Zum Starten des Clients für die Ackermannfunktion aus Eclipse heraus:
•
•
Entweder:
• Kontextmenü von Projekt AckermannClient
• Run as → Java Application → AckermannApp
oder:
• Im Projekt AckermannClient
• Im Package
de.fhwiesbaden.vvs.mathworkflows.ackermann.swing
• Kontextmenü von AckermannApp.java
• Run as → Java Application (Alt+Shift+X,J)
Dann im Client Werte eingeben (Beispiele für mögliche Werte in der Wertetabelle in [Wiki05]),
empfehlenswert sind m := 2 und n := 4, danach Betätigen von compute. Dann die Info-Ausgaben
der Web Services in der JBoss-Konsole verfolgen und auf das Ergebnis warten...
Markus Schmitt
37

Dokumentation

Transcription

Documents pareils

Ulrike Höhne / Rainer Volkert - Bautagebuch

Weibliche Geschlechtsorgane

Plugin for JBoss - Redeker Consulting

r Betriebswirt/-in (Louis-Baare

Friedrich-Schiller-Universität - Fakultät für Mathematik und Informatik

Das Wohnzimmer im Freien - Mediendienst

AVID-Übung 3 - Institut für Verteilte Systeme

VR Bank-Seminar für Existenzgründer Die VR Bank Pinneberg eG

Germany`s Next Top-Model

Anleitung zum Arbeiten mit Microsoft Visual Studio 2008 im