(C) Prof. E. Rahm, R. Müller 94 OR OR

Web Services and Service Flows

■ Service Oriented Archi-tecture (SOA):

■ Web Services - sollen die einfache Nutzung

bzw. Integration von An-wendungsdiensten über dasWeb ermöglichen

- umfassen ggf. mehrere Op-erationen, für deren Aus-führung gewisse Restriktion-en (z.B. Aufrufreihenfolgen)gelten können

- sollen in beliebigen Programmiersprachen implementiert und unter verschiedenen Systemumgebun-gen ablaufen können

- sollen anspruchsvolle E-Business-Anwendungen durch (prozessorientierte) Komposition der Oper-ationen eines oder mehrerer Web Services ermöglichen

Service Broker

Service Requester

Service Provider

Deploy

Bind

Find

Services

(C) Prof. E. Rahm, R. Müller 95 OR OR

Komponenten

■ Entwicklungs- und Laufzeitumgebung für die Implementierung bzw. Ausführungvon Web Services (Service Bus) (siehe Kap. 3)

■ Sprache(n) zur Beschreibung von Web Services - Service Description + (abstrakte) Beschreibung des Service-Typs (sog. Porttype), z.B. angebotene

Operationen sowie deren Input-, Output- und Fehlernachrichten - Transport Binding + Bindung an konkrete Aufrufprotokolle (z.B. HTTP, SMTP), Nachrichtenfor-

mate (z.B. MIME, SOAP) und Endpunkte (z.B. URL, E-Mail) - öffentlich zugängliches Verzeichnis für die Registrierung bzw. den Zugriff auf Web-Services- Prozessdefinitionssprache zur Verknüpfung der Operationen eines oder mehrerer Web Services (für

Public Flow und Private Flow)

■ In diesem Umfeld zahlreiche, teilweise konkurrierende Standards und Standardvor-schläge

(C) Prof. E. Rahm, R. Müller 96 OR OR

SOAP, UDDI und WSDL

■ Zusammenspiel von SOAP,UDDI und WSDL

■ SOAP (Simple Object AccessProtocol):

- XSD-/XML-basiertes Protokoll für denAustausch von Nachrichten zwischenService Requester und Service Provider

- Service Requester / Provider undUDDI-Broker

- verwendet als Aufrufprotokoll HTTP

■ UDDI (Universial Descritpion, Discovery and Integration) - Dienst für das Publizieren und Auffinden von Web-Services in öffentlich zugänglichen Verzeichnis-

sen (Public UDDI)- Entwicklerschnittstellen: Publisher-API + Inquiry-API- UDDI-Business-Registry (White/Yellow/Green Pages)- von den Firmen Ariba, IBM und Microsoft forciert- auch als "private UDDI" nutzbar (mit z. T. erweiterbaren Funktionen)

UDDI Broker

Web Service Requester

Web Service Provider

Deploy

Bind

Find

SOAP WSDL

(C) Prof. E. Rahm, R. Müller 97 OR OR

WSDL (Web Service Description Language)

■ Standardisierte XML-basierte Beschreibungssprache für Web Services

■ Vergleichbar mit IDL in Corba

■ Protokoll- und Programmiersprachenunabhängig

■ Derzeit in Version 1.2 (März 2003; http://www.w3.org/TR/wsdl12/)

■ Präsentiert ein Interface zu einem Dienst

■ von Ariba, IBM und Microsoft bei der W3C eingereicht

(C) Prof. E. Rahm, R. Müller 98 OR OR

WSDL (2)

■ Elemente- Message: Abstrakte

Definition der auszu-tauschenden Daten(typischerweise inForm von XML Ele-menten)

- Operation: AbstrakteAktionen, die ein Ser-vice unterstützt (in an-deren Worten: Mengevon Input und OutputMessages)

- Port Type: Menge vonOperationen

- Binding: BeschreibtAbbildung eines Port Types auf konkretes Datenübertragungsprotokoll wie SOAP, HTTP etc.

- Port: Einzelner individueller „Endpunkt“ mit konkretem Binding, identifiziert durch eine Netzw-werkadresse

- Service: Sammlung zusammengehöriger Ports

Protokolle SMTP, HTTP, JMS, RMI, IIOP, SQL Call, ...

Porttype

Port

Web Service Operation

Binding

Endpunkt-Adresse:E-Mail-Adresse, URL, ... (abhängig von verwendetem Protokoll)

Message

Message-Struktur IN-Parameter, OUT-Parameter, Fehlerparameter

XSD

Message-Format z.B. MIME-Encoded, ASCII, SOAP

Interaction Style RPC style / message style

SMPT (Simple MailTransfer Protocol), JMS(Java Messaging Service),RMI (Remote Method In-vocation), IIOP (InternetInter-ORB Protocol)

(C) Prof. E. Rahm, R. Müller 99 OR OR

WSDL-Definition - Beispiel

(C) Prof. E. Rahm, R. Müller 100 OR OR

Sprachen für E-Service (Web-Service) Workflows

■ Trend: Realisierung von E-Anwendungen durch prozessorientierte Kompositionvon Web Services • Einbindung von Web Services eines oder mehrerer Provider• Wahl des konkreten Providers entweder statisch zur Entwicklungszeit oder dynamisch zur Laufzeit• Prozessorientierte Anwendungen können ihrerseits wieder als Web Service gekapselt werden

■ Prozessorientierte Verknüp-fung der Operationen einesoder mehrerer Web-Serviceserfordert Berücksichtigungvon• Constraints einzelner Web Services

(z.B. Einhaltung bestimmter Au-frufreihenfolgen für Operationen eines Service)

• Constraints des Service Providers (z.B. Service-übergreifende Aufru-freihenfolgen für Operationen)

A B

C

D

E

Service Flow

ServiceProvider 1

ServiceProvider 2

Service

ServiceOperation

(C) Prof. E. Rahm, R. Müller 101 OR OR

Sprachtypen

■ Derzeit mehrere Vorschläge bzw. Implementierungen für Service Flow Languages- Web Service Flow Language (WSFL); IBM WebSphere- XLANG, Microsoft Biztalk- Business Process Execution Language for Web Services (BPEL4WS), Microsoft, IBM und Bea Sys-

tems- Business Process Modeling Language (BPML)

■ Allerdings noch einige Fragen offen, etwa in Bezug auf- Transaktionen- Sicherheit- Lizensierungspolitik

- ...

(C) Prof. E. Rahm, R. Müller 102 OR OR

BPEL4WS

■ XML-basierte Sprache zur Spezifikation des Verhaltens von Geschäftsprozessenim E-Service Kontext

■ Basiert auf WSDL, XMLSchema und XPath

■ Spezifikation vorgeschlagen von IBM, Microsoft, BEA

■ BPEL4WS = IBM WSFL + Microsoft XLANG

■ Derzeitige Version 1.1 (März 2003)

■ Block-strukturierte Programmiersprache (Definitionen und Deklarationen aufoberste Ebene beschränkt)

(C) Prof. E. Rahm, R. Müller 103 OR OR

BPEL4WS: Basiselemente

■ Elemente für Nachrichtenaustausch (receive/reply)

■ Activities als grundlegende Bestandteile einer Prozessdefinition

■ Structured Activities spezifizieren Reihenfolge der Aktivitäten

■ Basissteuerung durch- sequence- switch- while

■ Parallelität und Synchronisierung (flow)

■ Non-deterministische Wahl (gesteuert durch externe Ereignisse) (pick)

■ Instanzspezifische Prozessdaten werden in containers gespeichert

■ Mechanismen für Fehlerbehandlung (catching and handling faults)

(C) Prof. E. Rahm, R. Müller 104 OR OR

BPEL4WS: Abstrakte Prozesse

(C) Prof. E. Rahm, R. Müller 105 OR OR

BPEL4WS: Prozesskommunikation

(C) Prof. E. Rahm, R. Müller 106 OR OR

BPEL4WS: “Top-Level”-ProzessattributeLegende:

A? - 0..1 Mal

A+ - 1..n Mal

A* - 0..n Mal

Alternative: XQuery

JoinFailure: DieBedingungbeim Zusam-menführenvon Aktiv-itäten ist nichterfüllt

(C) Prof. E. Rahm, R. Müller 107 OR OR

BPEL4WS: Nachrichtenaustausch

Warten dass Part-ner “ncname”die Operation“ncname” mitentsprechenderOutput-Mes-sage aufruftt

Schicken einerReply-Nach-richt vom Vari-ablentyp“ncname” anPartner

(C) Prof. E. Rahm, R. Müller 108 OR OR

BPEL4WS: Korrelationen

■ Konstrukt zur Identifikation des Vorgangs, Kunden etc.

(C) Prof. E. Rahm, R. Müller 109 OR OR

BPEL4WS: Aktivitätsaufrufe

(C) Prof. E. Rahm, R. Müller 110 OR OR

BPEL4WS: Kontrollflusselemente

(C) Prof. E. Rahm, R. Müller 111 OR OR

BPEL4WS: Kontrollflusselemente (2)

(C) Prof. E. Rahm, R. Müller 112 OR OR

BPEL4WS: Kontrollflusselemente (3)

■ Aktivitäten in einem Flow werden nebenläufig ausgeführt

■ Zusätzliche Ausführungs-Constraints durch- Sequence-Konstrukt (strikte Reihenfolge)- Links (Synchronisation)

(C) Prof. E. Rahm, R. Müller 113 OR OR

BPEL4WS: Links

■ Jede Aktivität, die Ziel eines Links ist, hat ein implizites oder explizites joinCondi-tion-Attribut (auch wenn nur ein eingehender Link vorhanden ist)

■ Ohne Link-Spezifikation: - Aktivität startet, wenn ihre Vorgängeraktivität innerhalb der Sequenz beendet ist, oder wenn switch-

, while-, oder pick-Bedingung erfüllt sind- Falls kein(e) Sequenz/Auswahl/Schleife/Pick definiert: Aktivität startet direkt nach Eintritt in <flow

...

■ Bei eingehenden Links: - Die Bedingungen an allen eingehenden Kanten müssen erfüllt sein

(C) Prof. E. Rahm, R. Müller 114 OR OR

BPEL4WS: Beispiel

(C) Prof. E. Rahm, R. Müller 115 OR OR

BPEL4WS: Assoziierte WSDL-Definition - Beispiel

(C) Prof. E. Rahm, R. Müller 116 OR OR

BPEL4WS: Prozess-Definition - Beispiel (1)

(C) Prof. E. Rahm, R. Müller 117 OR OR

BPEL4WS: Prozess-Definition - Beispiel (2)

Shipper

(C) Prof. E. Rahm, R. Müller 118 OR OR

BPEL4WS: Prozess-Definition - Beispiel (3)

Shipper

(C) Prof. E. Rahm, R. Müller 119 OR OR

E-Service Flow Sprachen: Zusammenfassung

■ Spezifikationssprachen für die Beschreibung des Kontroll- und Datenflusses bzgl.E-Services

■ Vertreter: BPEL4WS

■ Aufsplitterung des Kontrollflusses durch Skriptbasierte Notation

■ Weiterführende LiteraturLiteraturauswahl

F. Leymann, D. Roller, M.-T. Schmidt: Web services and business process management. IBM Systems Journal, 41(2):198-211, 2002.

S. Aissi, P. Malu, K, Srinivasan: E-Business Process Modeling: The Next Big Step. IEEE Computer, Mai 2002, S. 55 - 62.

http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

T. Frotscher: Komposition von Web-Services mit WSFL. JavaSpectrum, Heft 1, 2002, S. 28-33.

http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm (aktuell implementiert im Microsoft Bizztalk Server)

F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, S. Werawarana: Business Process Execution Language for Web Services (V 1.0), Ini-tial Public Draft Release, 2002 (siehe http://www.ibm.com/developerworks/library/ws-bpel)

http://www.bpmi.org/bpml.esp

(C) Prof. E. Rahm, R. Müller 120 OR OR

Flowmark Definition Language (FDL)

■ Workflow-Definitionssprache des IBM Workflow-Management-Systems Web-Sphere MQ Workflow

■ Programm-Aktivitäten, Prozeß-Aktivitäten, Blöcke

■ Kontrollfluß- Kontrollfluß-Kanten mit Bedingungen, Default-Konnektoren- Schleifen nur über EXIT-Bedingungen (Repeat-Until Semantik)

■ Datenmodellierung - Input- und Output-Container als logische Datenbehälter- geschachtelte Strukturen

■ (Architektur von WebSphere MQ Workflow später)

(C) Prof. E. Rahm, R. Müller 121 OR OR

Flowmark Definition Language: Graphische Symbole

Source Sink

Programm-Aktivität

Block Prozeß-Aktivität

Datenfluß Kontrollfluß Default-Konnektor

(C) Prof. E. Rahm, R. Müller 122 OR OR

Fallbeispiel: FDL-Definition für Klärung der Vorbedingungen

(C) Prof. E. Rahm, R. Müller 123 OR OR

Fallbeispiel: FDL-Definition für Bearbeitung SHK-Antrag

(C) Prof. E. Rahm, R. Müller 124 OR OR

Fallbeispiel: FDL-Definition für Bearbeitung Hauptvertrag

(C) Prof. E. Rahm, R. Müller 125 OR OR

Fallbeispiel: FDL-Skript (Auszug)/********************************************************************

* Generated by FlowMark Import/Export at 04/29/99, 09:23:35.

********************************************************************/

/********************************************************************

* DATA-STRUCTURES

********************************************************************/

STRUCTURE ‚Default Data Structure‘

END ‚Default Data Structure‘

STRUCTURE ‚Nachricht‘

‚Bezug_Auf_Nachricht‘: STRING;

‚Gesendet_Am‘: STRING;

‚Inhalt‘: STRING;

‚Antwort‘: STRING;

‚Status‘: STRING;

END ‚Nachricht‘

(C) Prof. E. Rahm, R. Müller 126 OR OR

/********************************************************************

* Description of Process Bearbeitung_Hauptvertrag

********************************************************************/

PROCESS ‚Bearbeitung_Hauptvertrag‘ ( ‚Default Data Structure‘, ‚Default Data Structure‘ )

LAYOUT GIVEN

WINDOW ‚2063 12 152 497 320 4119 0 0 0 0 100 0 -247 4 1 4 ‚

SOURCE XPOS=-851 YPOS=450

SINK XPOS=1001 YPOS=-851

PROCESS_ACTIVITY ‚Process_Prüfung_Unterlagen‘ ( ‚Nachricht‘, ‚Nachricht‘ )

EXIT AUTOMATIC WHEN ‚Status=‘‘Unterlagen sind korrekt‘‘‘

LAYOUT XPOS=-851 YPOS=199

END ‚Process_Prüfung_Unterlagen‘

(C) Prof. E. Rahm, R. Müller 127 OR OR

Workflow-Definitionssprachen: Zusammenfassung

■ Sprachen für die Beschreibung des Kontroll- und Datenflusses bzgl. Aktivitäten

■ Workflow-relevante Sprachklassen u.a.- Petri-Netze, State- und Activity-Charts, Proprietäre Produktsprachen (z.B. IBM FDL), BPEL4WS

■ Bewertungskriterien u.a.- Notation (Skript-basiert und/oder graphisch)- Mächtigkeit bzgl. Kontrollfluß-Elementen (u.a Kantenbedingungen und temporale Aspekte)- Mächtigkeit bzgl. Datenfluß-Elementen- Strukturierung (hierarchische Workflows, Modularisierung), Analysierbarkeit (Verifikation)

■ Weiterführende Literatur zu Workflow-relevanten SpezifikationssprachenSprachklasse Literaturauswahl

Petri-Netze Adam et al.: Modeling and Analysis of Workflows Using Petri Nets. Journal of Intelligent Information Systems 10(2): 131-158, March 1998.

van der Aalst. Verification of Workflow Nets. In: P. Azema and G. Balbo (eds.). Application and Theory of Petri Nets 1997, volume 1248 of LNCS, 407-426. Springer-Verlag, Berlin, 1997.

State/Activity-Charts Wodtke, D.: Modellbildung und Architektur von verteilten WFMS. Dissertation. Universität Saarbrücken, 1996.

Logikbasierte Sprachen Bonner et al.: An Overview of Transaction Logic. Theoretical Computer Science (TCS), 133:205-265, 1994.

Davulcu et al. Logic-based modeling and analysis of workflows. ACM Symposium on Principles of Database Systems (PODS), Seattle, WA, June 1998.

(C) Prof. E. Rahm, R. Müller 128 OR OR

Workflow-Definitionssprachen: Zusammenfassung (2)

Petri-Netze State-Activity Charts FDL BPEL4WS

Notation Graphisch Graphisch Graphisch + Skript Skript

Kontrollfluss-mächtigkeit

Sequenz

Ja Ja Ja JaNebenläufigkeit

KonditionalSchleife

Synchronisation

DatenflussmächtigkeitRel./OO/OR

Datenfluss nicht hierarchisch

RECORDSDatenfluss nicht

hierarchischRECORDS RECORDS

Trennung Kontrollfluss/Datenfluss nur FUNSOFT Strikt Ja Ja

Explizite Zustands-beschreibungen

Datenzustand Ja Nein Nein NeinProzess-

fortschritt Nein Ja Nein Nein

Ereigniskonzept Nein Ja Nein JaOrganigramm-Elemente nur FUNSOFT Nein Ja Ja

Temporale Aspekte Ja Nein Nein JaHierarchien, Modularisierung Ja Ja Ja JaAnalysierbarkeit (Verifikation) Ja Ja Nein Nein