Bauinformatik Bauinformatik Vertiefte Grundlagen Graphentheorie 6. Semester Webservice - Orchestrierung Webservice Orchestrierung Prof. Dr.-Ing. RJSh Nürnberger Str. 31a 2 OG R 204 TU Dresden - Institut für Bauinformatik 1 R. J. Scherer 2. OG, Raum 204
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Vom Konzept zum ausführbaren ProzessAusführbarer Prozess
Softwaretechnische Umsetzung der Prozesslogik
SystemmodellTop-Down von der
obersten Ebene bis ins
ProzessmodellLogische Abhängigkeiten zwischen Ereignissen und
Input
obersten Ebene bis ins Detail
Informationsfluss
gFunktionenProzesslogik
Webservice
Webservice
TU Dresden - Institut für Bauinformatik
Output
2
Servicekomposition• Für eine Vielzahl von Problemen werden von unterschiedlichen Herstellern
Services entwickelt• Ein wesentlicher Mehrwert wird dann erreicht, wenn diese einzelnen Services
flexibel zu einer größeren Anwendung kombiniert werden könnenDi K iti f d t di K di ti d S i• Die Komposition erfordert die Koordination der Services
• Zwei Arten der Servicekomposition:– OrchestrierungOrchestrierung – Choreographie
TU Dresden - Institut für Bauinformatik 3
Orchestrierung= Prozessorientierte Komposition verschiedener Services zu einem ausführbaren Prozess• Beschreibt, wie mehrere Services durch Nachrichten miteinander interagieren• Orchestrierte Services können an einer beliebigen (öffentlichen) Stelle in einem Netzwerk
liegen (intern und extern)• Der Prozessfluss (zeitliche Reihenfolge), die Prozesslogik (Bedingungen der Serviceaufrufe)
und die Kommunikation (Übergabe und Zwischenspeicherung von Daten zwischen Services) werden zentral durch ein Prozessmodell gesteuertg
• Die Aktivitäten (Anwendungslogik) der benutzten Services bleiben verborgen (Blackbox)• Der orchestrierte Prozess ist selbst wieder ein Service kann als Subprozess in einen
größeren Prozess eingebettet werden• Kann auf einer Workflowmaschine zum Einsatz gebracht (engl deployed) und ausgeführt• Kann auf einer Workflowmaschine zum Einsatz gebracht (engl. deployed) und ausgeführt
werden• Beispiel für Orchestrierungssprache: BPEL (Business Process Execution Language)
Webservice
ProzesssteuerungProzesssteuerung
TU Dresden - Institut für Bauinformatik4WebserviceWebservice
4
Choreographie= Interaktion von „gleichberechtigten“ Services
• jeder Dienst beschreibt seine eigene Aufgabe in der gesamten Komposition• Es gibt keinen zentralen Punkt, der die Korrektheit und Aufgabenerfüllung kontrolliert. • Dezentrale Prozesssteuerung muss letzten Endes die gleiche Lösung wie zentrale
Prozesssteuerung ergeben• Der Fokus liegt auf dem Nachrichtenaustausch zwischen den Diensten. • Services können an einer beliebigen (öffentlichen) Stelle in einem Netzwerk liegen• Die Aktivitäten (Anwendungslogik) der benutzten Services bleiben verborgen (Blackbox)
Webservice
• Die Aktivitäten (Anwendungslogik) der benutzten Services bleiben verborgen (Blackbox)• Beispiel für Choreographiesprache: WS-CDL (Web Services Choreography Description
Language)Webservice
WebserviceWebservice
Kollaboration
TU Dresden - Institut für Bauinformatik 5
WebserviceWebservice
Vorteile der komponentenbasierten verteilten Softwareentwicklung
• Modularisierbarkeit (Bildung von Systemen und Sub-Systemen)• Schnellere Modifizierbarkeit komplexer Anwendungen
L f i i R d i K• Langfristig Reduzierte Kosten• Qualitätssteigerung• Reduktion der KomplexitätReduktion der Komplexität• Mehr Flexibilität (Anpassung an die Unternehmensprozesse)
TU Dresden - Institut für Bauinformatik 6
Nachteile und Risiken der komponentenbasierten verteilten Softwareentwicklung
• zu Beginn erhöhte Entwicklungskosten• höherer Zeitaufwand
ä li h P l h l• zusätzliche Personalschulungen • kurzfristig keine Kosteneinsparung• bei engen Zeitplänen keine Entwicklung aufbei engen Zeitplänen keine Entwicklung auf
Bausteinbasis möglich
TU Dresden - Institut für Bauinformatik 7
WS-BPEL Einführung• Web Services Business Process Execution Language
Version 2.0, ehemals BPEL4WS (BPEL for
Input
(Webservices)
• Verbindung der Ideen der kalkülbasierten Sprache XLANG von Microsoft und der Graph basierten Sprache
Webservice
XLANG von Microsoft und der Graph-basierten Sprache WSFL von IBM.
• baut auf dem Dienstmodell von WSDL aufWebservice
• Weitere benutzte Standards: XMLSchema, XPath und WS-Adressing
• Ziel: Programmieren im Großen“ mit verteilten
Webservice
• Ziel: „Programmieren im Großen mit verteilten Ressourcen
BPEL Historie• 2002: BPEL4WS 1.0 von Microsoft, IBM & BEA• IBM: Web Services FlowLanguage WSFLIBM: Web Services FlowLanguage WSFL• Microsoft: XLANG• 2003: Beitritt von SAP und Siebel Systems• Weiterentwicklung von OASIS• Offizieller offener Standard
2007 WS BPEL 2 0• 2007: WS-BPEL 2.0• Stand 2009: WS-BPEL Extension for People (BPEL4People) befindet sich bei
OASIS Technical Committee zur Standardisierung
TU Dresden - Institut für Bauinformatik 9
BPEL Sprachelemente• Prozessdefinition
– Prozess & ImportV i bl– Variablen
– Partner Links• Basis-Aktivitäten
i l– Receive & Reply– Invoke– Throw– Assign
• Strukturierende Aktivitäten– Sequence & Flow– if elseif else– ForEach
Das BPEL Prozess Datenmodellhttp://docs.oasis-open.org/wsbpel/2.0/OS/process/executable/ws-bpel_executable.xsd
Attribute, die den Prozess b h ib d t S hbeschreiben, verwendete Sprachen festlegen und globale Einstellungen setzen
Dokumentation des Prozesses
Import von BPEL-Spracherweiterungen und externer Referenzen (z B WSDL der zuexterner Referenzen (z.B. WSDL der zu orchestrierenden Webservices)
Kommunikationspartner
Prozessvariablen
Menge von Eigenschaften, die durch mehrere Nachrichten (messages) genutzt werdenNachrichten (messages) genutzt werdenFehler- und Ereignisbehandlung: Aktivität, die bei Fehler oder best. Ereignisausgeführt werden soll
TU Dresden - Institut für Bauinformatik 12
werden soll
Aktivitäten
Standardattribute für AktivitätenJoin Condition Eine “join condition” erlaubt die Definition komplexer
Ausführungsbedingungen auf Basis des Linkstatus. Wenn eine odermehrere Links mit einer Aktivität verbunden sind, kann die Join Condition so gesetzt werden, dass die Ausführung der Aktivität vomZustand der eingehenden Links abhängig ist.
Wenn die Auswertung der “Join Condition” den boolschen Wert “true” ib i d d l f ib di dergibt, wird der Prozess normal fortgesetzt. Ergibt die Auswertung den
boolschen Wert “false”, kann eine Fehlermeldung ausgegeben und derProzess abgebrochen oder eine zuvor festgelegte Fehlerbehandlungausgeführt werden.
Suppress Join Failure Wenn das Attribut “suppressJoinFailure” auf “yes” gesetzt ist, wird auchim Fall einer “Join Condition”, die den Wert “false” ausgibt, keineFehlermeldung ausgegeben und der Prozess normal fortgesetzt.
Comment Optionales Attribut zum Hinzufügen von html-Annotationen zu einem<process> Element, sowie zu einer Aktivität, einem Link oder einemContainer.
i l ib i f i iDocumentation Optionales Attribut zum Hinzufügen von Annotationen zu einem<process> Element, sowie zu einer Aktivität, einem Link oder einemContainer.
Extension Attributes und Elements Erweiterungen der Basis-BPEL-Sprache auf mehereren Wegen, inklusive
TU Dresden - Institut für Bauinformatik
Extension Attributes und ElementsErweiterungs-Elemente und Erweiterungsattribute für BPEL-Konstrukte
Attribute− createInstance: legt fest, ob beim Empfang eines Webservice-
Aufrufs eine Prozessinstanz erstellt werden soll, oder nicht,− Operation: SOAP-Aktion, die das Gegenüber verwenden wird− partnerLink: Kommunikationspartner, von dem empfangen wird− portType: Service, der angeboten wird− Variable: Prozessvariable, in die die empfangenen Daten
A ibAttribute− Operation: SOAP-Aktion, die das Gegenüber verwendet hat− partnerLink: Kommunikationspartner, von dem empfangen wurde− portType: Service den der Prozess angeboten hatportType: Service, den der Prozess angeboten hat− Variable: Prozessvariable, aus der die zu sendenden Daten gelesen werden
sollen− faultName: Definition der Fehlermeldung, die im Fall eines Fehlers ausgegeben
− partnerLink: definiert, WAS bei WELCHEM Kommunikationspartner aufgerufen werden sollwerden soll
− portType: Service, den der Kommunikationspartner anbietet− Operation: SOAP-Aktion, die verwendet werden muss− inputVariable: Variable, aus der die zu sendenden Daten gelesen werden
outputVariable: Variable in die die zurückkommenden Daten geschrieben− outputVariable: Variable, in die die zurückkommenden Daten geschrieben werden
Basis-AktivitätenAssign: Aktualisiert den Inhalt von Variablen:• Kopiert Daten von einer Variablen in eine anderep• Erzeugt neue Daten durch Xpath-Ausdrücke oder andere Sprachen• Erzeugt neue Daten durch erweiterte WS-BPEL-Funktionen
Attribute
− copy: definiert, welche Daten kopiert werden sollen, sowie Quell- und Zielvariabley− Weitere optionale Attribute
<bpel:assign><bpel:copy>
<bpel:from>$momentResponse.parameters/ns3:return div $fltmResponse.parameters/ns4:return * ($fltmRequest.parameters/ns4:h * 0.5)</bpel:from>
<bpel:to part="parameters" variable="EinSpannResponse"><bpel:query>sigma</bpel:query>p q y g / p q y
</bpel:to></bpel:copy>
</bpel:assign>
TU Dresden - Institut für Bauinformatik 17
Basis-AktivitätenWait: Warten für eine Zeitdauer oder auf einen Zeitpunkt.
Attribute
− Wait Expression: Wert für Zeitpunkt (Datum) oder DauerWait Type: Wahlmöglichkeiten zwischen den Optionen “Duration” (for) und− Wait Type: Wahlmöglichkeiten zwischen den Optionen Duration (for) und “Deadline” (until)
Scope: Sichtbarkeitsbereich von Variablen, lokale Umgebung zur Blockstrukturierung
• bündelt Aktivitäten und fasst sie zu einer transaktionalen Einheit zusammen• Möglichkeit zur Einführung lokaler Variableng g• Assoziation von Fehlerbehandlung (Fault Handler), Kompensationsbehandlung
(Compensation Handler) und Ereignisbehandlung (Event Handler)
Att ib tAttribute
− Isolated: YES oder NO. Bestimmt, ob von mehreren Scopes gleichzeitig auf eine gemeinsam genutzte Variable zugegriffen werden darfgemeinsam genutzte Variable zugegriffen werden darf.
− Nur Optionale Attribute
TU Dresden - Institut für Bauinformatik 21
Strukturierende Aktivitäten
Pick: Triggern enthaltener Aktivitäten durch Nachricht oder AlarmPick: Triggern enthaltener Aktivitäten durch Nachricht oder Alarm• Aus Prozesssicht nicht-deterministische Wahl durch externe Ereignisse
(Messages, Zeitpunkt oder Zeitspanne)
Attribute
Bei Trigger durch onMessage:Partner LinkOperationVariable or From Part
Bei Trigger durch onAlarm:Alarm ExpressionAlarm TypeAlarm Type
TU Dresden - Institut für Bauinformatik 22
Strukturierende Aktivitäten
Validate: Validierung von Variablen anhand der XML und WSDL Daten-DefinitionErzeugung einer Fehlermeldung (bpel:invalidVariables), falls eine Variable einen
falschen Wert enthält
Att ib tAttribute
− variables: Definition der Variablen, die validiert werden sollen
While: Wiederholtes Ausführen von Aktivitäten solange eine boolesche Bedingung füllt i terfüllt ist
Attribute
− condition: Definition der Bedingung
<while><condition>
$orderDetails > 100</condition><scope>
...</scope>
</while>
TU Dresden - Institut für Bauinformatik 24
Strukturierende Aktivitäten
repeatUntil: Die “repeatUntil” Aktivität führt Aktivitäten wiederholt aus, bis ihre B di “t ” i t I G t Whil Akti ität füh t di S hl if diBedingung=“true” ist. Im Gegensatz zur While-Aktivität führt die Schleife die enthaltenen Aktivitäten mindestens 1 mal aus.
Attribute
<repeatUntil>
Attribute
− condition: Definition der Bedingung<repeatUntil>
If: Ausführung von Aktivitäten auf der Basis einer oder mehrerer Bedingungen, die d h i if“ d fi i t i d d ti l d h i l if“ f l t idurch ein „if“ definiert sind oder optional durch ein „else if“, gefolgt von einem optionalen „else“-Element
Strukturierende AktivitätenforEach: Die forEach-Aktivität enthält einen Scope, der mit einer
definierten Anzahl an Durchläufen ausgeführt wird.Die iterative Ausführung kann parallel oder sequenziell erfolgen. DieDie iterative Ausführung kann parallel oder sequenziell erfolgen. Die Anzahl der Iterationen wird durch Ausdrücke mit Start- und Endwertfestgelegt. Diese Werte sind inklusiv, d.h. bei einem Startwert=1 und Endwert=10 wird der Scope 10 mal ausgeführt.
EinfSpannBPEL.wsdlDiese WSDL wurde nach dem Contract-First-Ansatz manuell erzeugt. Dieser Ansatz vereinfacht bei der Erstellung von BPEL-Prozessen die Definition von Ein- und Ausgangsparametern. Diese WSDL wird beim Deployment in eine ergänzende WSDL die insbesondere das Service-Binding enthält importiertDeployment in eine ergänzende WSDL, die insbesondere das Service Binding enthält, importiert.
Ein partner link ist die exakte Beschreibung der Beziehungen (der Kommunikation) zweier Partner untereinander (des BPEL-Prozesses zu anderen Webservices). Ein Partner Link definiert die Rolle des Prozesses und die Rolle des Partnerservice für einen bestimmten Austausch von Daten.Der Partner Link wird über einen Partner Link Type definiert. Ein partner link type beschreibt die Art des Nachrichtenaustauschs, den zwei WSDL Services vollziehen sollen. Er charakterisiert diesen Austausch durch die Definition der Rollen, die jeder Service einnimmt und durch die Spezifikation des port types, der durch den Service angeboten wird, um für den Austausch taugliche Nachrichten