Service-Orientierte Architekturen
|
|
- Andrea Salzmann
- vor 2 Jahren
- Abrufe
Transkript
1 Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 6: Web Services III Business Process Execution Language (BPEL) Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda
2 (Vorläufiger) Aufbau der Vorlesung Kapitel Thema 1 Organisation, Einführung in Software-Architekturen 2 Einführung in Service-Orientierte Architekturen 3 Design Prinzipien von Service-Orientierten Architekturen 4 (11.5.) Web Services I (SOAP, WSDL) 5 (18.5.) Web Services II (Axis2, WS-Adressing) 6 (25.5.) Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 (1.6.) Web Services IV 8 (8.6.) REST Architekturen 9 (15.6.) Einführung in Swordfish 11 (22.6.) Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Folie 2
3 Ziele dieser Unterrichtseinheit Grundlagen des Web Services Framework erweitern Grundlagen der Geschäftsprozessmodellierung verstehen Den Standard BPEL zur Implementierung von Workflows verstehen und anwenden Einordnung BPEL zu den Grundprinzipien einer SOA Folie 3
4 Aufbau dieser Veranstaltung Kapitel 6: Web Services III, Einführung in BPEL 1 Wiederholung: Workflow Services 2 Grundlegender Aufbau eines BPEL-Workflow 3 Asynchrone Implementierung eines BPEL-Workflow 4 Fehlerbehandlung in einem BPEL-Workflow 5 Benutzerinteraktionen in einem BPEL-Workflow 6 Bewertung des BPEL-Ansatzes 7 Zusammenfassung und Ausblick Folie 4
5 Ziel: Flexible Integration der verschiedenen Subsysteme über fachlich definierte Services und Prozesse Benutzerinterfaces (User Interfaces) Business Processes (IT-unterstützte Geschäftsprozesse, Workflow) Services Prozess Archivierung von Rechnungen Business Services (Geschäftsfunktionen, fachliche Services) SAP FI Service CR Service Archiv Service PDF : printinvoice( Invoice) Invoice: getinvoice( Client ) removeclient( ID ) getclient( ID ) savepdf( pdf) Applikationen (Alt-Systeme, Legacy) SAP 2.0 FI System SAP R3 CO System Sub-Tochter (eignes Intranet) SAP Netweaver Oracle Siebel System Siebel System FI SAP R3 MM System SAP R3 System FI... Web Frontend
6 Abgrenzung Fachliche Services und Workflow Service Aus der Referenz-Architektur einer SOA ergeben sich zwei Typen von Services: Business Services (Fachliche Services) Business Process Services (Workflow Services) Fachliche Services repräsentieren eine zusammengefasste Funktionalität innerhalb einer Service-Orientierten Architektur Zugriff auf Backend und andere Services möglich, jedoch kein Prozess-Charakter erkennbar Konstante Implementierung, Änderung erfolgen über die Laufzeit einer Architektur nur selten Workflow Services fassen eine Menge von Services in einer vom Anwender definierten Reihenfolge zur Abarbeitung zusammen Prozess-Charakter erkennbar und explizit beschrieben Volatile Implementierung, wird über die Laufzeit einer Architektur potentiell oft verändert (z.b. wenn sich Prozesse in einer Firma ändern) Folie 6
7 Implementierung eines Workflow Services Wie lässt sich ein Workflow Service implementieren? Prozess Archivierung von Rechnungen Programmierung des Prozesses in einer Programmiersprache wie Java innerhalb eines Web Service (z.b. AXIS2) Vorteil: rasche, kostengünstige Entwicklung Nachteil: keine standardisierten Programmierkonstrukte, schlechte Portierbarkeit, schlechte Anpassbarkeit In einer deklarativen Prozesssprache (wie z.b. BPEL) Einführung von einfachen, programmiersprachneutralen Standardkonstrukten zur Beschreibung von Prozessen Besserer Tool-Support Bessere Portierbarkeit, bessere Anpassbarkeit Folie 7
8 Aufbau dieser Veranstaltung Kapitel 6: Web Services III, Einführung in BPEL 1 Wiederholung: Workflow Services 2 Grundlegender Aufbau eines BPEL-Workflow 3 Asynchrone Implementierung eines BPEL-Workflow 4 Fehlerbehandlung in einem BPEL-Workflow 5 Benutzerinteraktionen in einem BPEL-Workflow 6 Bewertung des BPEL-Ansatzes 7 Zusammenfassung und Ausblick Folie 8
9 Business Process Execution Language (BPEL) BPEL erlaubt die einfache Beschreibung von Workflows, deren einzelne Aktivitäten auf Web Services verzweigen Standardisiert von der OASIS, aktuelle Version 2.0 Hervorgegangen durch die Vorgängerstandards WSFL und XLANG Link: Basiert auf der Metasprache XML, kompatibel zum Web Services BP 1.1: Ein Workflow wird selber wieder als ein Web Services mittels WSDL beschrieben Zugriff auf einen Workflow mittels SOAP BPEL-Workflows werden, wie einfache Web Services auch, in einer speziellen Laufzeitumgebung ausgeführt BPEL-Beschreibungen sind ausführbar Keine graphische (Standard-)Notation vorhanden Alternative: Business Process Management Notation (BPMN) Folie 9
10 Literatur und Quellen Generell nur wenige gute Bücher auf dem Markt vorhanden über BPEL Gute Online Tutorials: https://blueprints.dev.java.net/bpcatalog/ee5/soa/ Folie 10
11 Grob-Aufbau eines BPEL-Workflow (High-Level) Business Process (als Web Service) activity1 invoke Service Provider A Web Service a Service User uses Consumer Application Interaktionskomponente oder fachliche Komponente request response activity4 activity2 Parallel flow activity5 activity3 invoke Service Provider B Web Service b Service Provider C Beschrieben durch invoke Web Service c <process> <sequence> <receive> <invoke> </invoke> <flow> </flow> <reply> </sequence> </process> BPEL file
12 Beispiel-Workflow für dieses Kapitel Der ChangePartnerService (Kapitel 5/6) soll als Workflow erweitert werden Konzentration auf die Änderung von Daten eines Partners (Operation changepartner) Die zu ändernden Daten werden auf einem externen Datenbank-Server abgespeichert Web Service als Schnittstelle vorhanden Nach der Abspeicherung der Daten eines soll der Vorgesetzter über diese Änderungen benachrichtigt werden Falls der Partner ein Manager ist: Benachrichtigung mit allen Daten an den Vorstand Falls der Partner kein Manager ist: Benachrichtigung an seinen Manager ohne Übermittlung der Daten Kapselung des ganzen Workflow durch einen Web Service Folie 12
13 Vorgehensweise bei der Entwicklung eines BPEL-Workflow Suche nach den relevanten Web Services (Analyse der Anforderungen) Definition der Schnittstelle des BPEL-Prozesses WSDL-Beschreibung Identifikation / Definition der Partner Link Types zu den relevanten Web Services Entwicklung des BPEL-Prozesses (.bpel File) Grundsätzliche Eigenschaften des BPEL-Prozesses Definition der Partner Links Einbindung aller Web Services Deklaration der internen Variablen Definition Workflow-Logik (Abfolge von Aktivitäten) [Ausnahmebehandlung] Deployment des BPEL-Workflow Abhängig von Laufzeitumgebung Meist zusammenfassendes Deployment des.bpel und des.wsdl Files Folie 13
14 Aufbau eines BPEL-Workflow Ein Workflow in BPEL ist hierarchisch durch XML beschrieben. Grob-Aufbau: <process name = PartnerChangeWorkflow > <import location = Service.WSDL.../> <partnerlinks>... </partnerlinks> <variables>... <variables> <sequence> // Grundlegende Aktivitäten (invoke, receive, reply, wait..) // Strukturierende Aktivitäten (if... else, Switch,...) </sequence> </process> Folie 14
15 Definition der Namespaces und Import von WSDLs Im Tag <process> werden alle zu referenzierenden Namespaces definiert Im Tag <import> werden alle notwendigen WSDLs in den BPEL-Prozess import. Im Einzelnen: Namespaces aller intern verwendeten Web Services Namespace der WSDL-Beschreibung des BPEL-Prozesses (= Sicht Client) <process name = PartnerChangeWorkflow xmlns:chs = "http:/myserver.com/bpel/change/" xmlns:dbs = "http:/myserver.com/services/dbsave/" xmlns:nos = "http:/myserver.com/services/dbsave/" > <import location = file://... ChangeService.wsdl... /> <import location = DatabaseService.wsdl.../> <import location = NotificationService.wsdl.../>... </process> Folie 15
16 Partner Link Types Partner Link Types repräsentieren die abstrakten Verbindungen zwischen einem BPEL Prozess und allen involvierten Web Services: Web Services (Client), der den BPEL Prozess aufruft Web Services, die der BPEL Prozess selbst intern aufruft Partner Link Types referenzieren innerhalb von WSDL auf PortTypes Jeder Partner Link Type wird in dem WSDL-File des Web Service beschrieben: <<Client>> Application Service Provider (BPEL-Workflow als Web Service) PartnerChangeWorkflow Service Provider B Database Service WSDL-File <partnerlinktype name = DB-Access > WSDL-File WSDL-File Service Provider C Notification Service Folie 16
17 Partner Link Types in WSDL Ein Partner-Link Type referenziert durch eine Rolle einen PortType innerhalb eines WSDL-Files um den Aufruf des Web Service zu definieren Synchroner Aufruf: Rückgabe erfolgt über die gleiche Operation eines PortType Asynchroner Aufruf: Zusätzlicher Rolle / PortType notwendig (später mehr dazu...) <definitions name = DatabaseService > <types>... </types> <porttype name = DatabaseWrite >... <porttype> </porttypes> <bindings>... </bindings> <plnk:partnerlinktype name= DB-Access"> <plnk:role name= savedataforchange"> <plnk:porttype name="tns:databasewrite" /> </plnk:role> </plnk:partnerlinktype>... <definitions> WSDL-Auszug zur Definition des Web Service DatabaseService Folie 17
18 Partner Links Partner Links repräsentieren konkrete Verbindungen zu Web Services, die mit dem BPEL Prozess interagieren Jeder Partner Link bezieht sich zu einem konkreten Partner Link Type (aus importierten WSDL-Files) Zu einem Partner Link Type kann es mehrere Partner Links geben <process name = PartnerChangeWorkflow > <partnerlinks> <partnerlink name = client partnerlinktype = chs:changeservice partnerrole = ChangeServiceClient /> <partnerlink name = managernotification // vorstandnotifcation partnerlinktype = nos:notificationservice partnerrole = notificationservice /> <partnerlink name = databaseconnection partnerlinktype = dbs:db-access partnerrole = savedataforchange />... </partnerlinks>... BPEL-Auszug zur Definition der Partner Links Folie 18
19 Variablen innerhalb eines BPEL-Workflow Variablen werden eingesetzt, um Nachrichten innerhalb eines BPEL- Workflow zwischenzuspeichern und ggf. zu ändern Eine Variable pro Nachricht, die von einem Web Services empfangen wird bzw. die verschickt wird. Angabe eines Nachrichtentyps ist notwendig: Übernahme aus dem WSDL-Files der Web Services Eigene Typ-Definition z.b. aus einem XML-Schema <variables> <variable name = changerequest messagetype = chs:changerequest /> <variable name = changeresponse messagetype = chs:changeresponse /> <variable name = notificationrequest messagetype = nos:notificationrequest /> <variable name = notificationresponse messagetype = nos:notificationresponse />... </variables> Folie 19
20 Grundlegende Aktivitäten in BPEL Ein BPEL-Prozess besteht aus besteht aus einzelnen Schritten, auch Aktivität bezeichnet. Grundlegende Aktivitäten (primitive activities) repräsentieren einfache, atomare Aktivitäten innerhalb eines Workflows. Aufruf eines externen Services (<invoke>) (Rück-)Aufruf des Workflow durch einen Client (<receive>) Rückantwort an einen Client bei synchronem Aufruf (<reply>) Manipulation, Umkopieren von Werten in den Prozess-Variablen (<assign>) Ausweisung von Fehlern und Ausnahmen (<throw>) Anhalten (Wartestellung) des Prozesses (<wait>) Terminierung des Prozesses (<terminate>) Folie 20
21 Strukturierende Aktivitäten in BPEL Ein BPEL-Prozess besteht aus besteht aus einzelnen Schritten, auch Aktivität bezeichnet. Strukturierende Aktivitäten (structure activities) repräsentieren komplexe Aktivitäten innerhalb eines Workflows Sequentieller Ablauf von Aktivitäten (<sequence>) Paralleler Ablauf von Aktivitäten (<flow>) Einführung von Branches (Verzweigungen) (<if>) Definition von Loops (Schleifen) <while>, <repeat>...<until> Auswahl von Pfaden (<pick>) Bildung von Scopes (<scope>) Fehlerbehandlung (<compensate>) Folie 21
22 Aufruf eines Workflow (<receive>) <receive> spezifiziert den initialen Aufruf des Workflow durch einen Client und somit die erste eingehende Nachricht in dem Prozess Die erste Aktivität innerhalb der Top-Level Sequenz eines Workflow Nur eine Operation bzw. ein Message-Type kann aufgerufen / übergeben werden (Alternative: Pick) BPEL Workflow wartet auf den ersten Aufruf, befindet sich bis dahin in einem Wartezustand <process>... <sequence> <receive> partnerlink = client > porttype = chs:partnerchange operation = changepartner variable = ChangeRequest createinstance = yes </>... </sequence> </process> Folie 22
23 Aufruf eines Workflow (<pick>) <pick> spezifiziert den initialen Aufruf des Workflow durch einen Client und somit die erste eingehende Nachricht in dem Prozess Mehrere unterschiedliche Operationen bzw. Nachrichten-Typen können initial empfangen werden, Unterscheid mit <onmessage> Auch innerhalb des Workflow verwendbar (z.b. innerhalb einer <flow> Aktivität) <sequence> <pick> <onmessage partnerlink= client" porttype="chs:partnerchange" operation="changepartner" variable="changerequest">... // Subprozess für das Ändern eines Partners </onmessage> <onmessage partnerlink= client porttype="chs:partnerchange" operation= deletepartner" variable= DeleteRequest">... // Subprozess für das Löschen... <onmessage> </pick> Folie 23
24 Umkopieren von Variablen-Werten (<assign>, <copy>) Durch die <assign>... <copy> Aktivität werden Variablenwerte umkopiert Dient der Vorbereitung von weiteren Aktivitäten innerhalb des BPEL Workflow (z.b. Aufruf eines Web Service) Erweitere Kopier- und Transformationsoptionen mit XPATH möglich <process>... <assign> < Normales Kopieren > <copy> <from variable = changerequest part = name > <to variable = databaserequest part name > </copy> < Transformation mit XPATH > <copy> <from expression = concat( Gehalt:, $changerequest.payload/gehalt) /> <to variable = databaserequest part gehalt > </copy> </assign>... </sequence> </process> Folie 24
25 Synchroner Aufruf eines Web Service (<invoke>) Mit der Aktivität <invoke> wird ein externer Web Service aufgerufen Input wird in der Regel durch ein vorhergehendes Assign-Statement zugewiesen (siehe letzte Folie) <process>... <sequence>... <assign>... </assign> <invoke partnerlink= databaseconnection" porttype= dbs:databasewrite" operation= savedata" inputvariable="databaserequest" outputvariable="databaseresponse" />... </sequence> </process> Folie 25
26 Sequenz und Flow von Aktivitäten In der Top-Level Sequenz können weitere sequentielle Abfolgen (<sequenz>) sowie parallele Aktivitäten (<flow>) definiert werden: <process>... <sequence> <flow> <sequence> <assign>... </assign> <invoke partnerlink= databaseconnection... />... </sequence> <sequence> <assign>... </assign> <invoke partnerlink= databaseconnection2... />... </sequence> </flow> </process> Folie 26
27 Verzweigungen in einem BPEL-Workflow Mit der <if>.. <else> Aktivität können bedingte Verzweigungen in einem Workflow eingeführt werden Die Bedingung wird in dem Tag <condition> spezifiert... <if name = FallsPersonManagerIst> <condition> bpws:getvariabledata( changerequest, payload, /type ) = Manager </condition> <assign> <copy>... </copy> </assign> <invoke partnerlink = notificationvorstand porttype= nos:notificationfunctions" operation= notifypartner" inputvariable= notificationrequest" outputvariable="notificationresponse" /> </if> <else> <assign>...</assign> <invoke partnerlink = notificationmanager </else>... Folie 27
28 Versenden der Response an den Client Mit der Aktivität <reply> wird die Response an den aufrufenden Client zurücksendet (repräsentiert durch PartnerLink) Eine <receive>... <reply> Sequenz realisiert einen synchronen Aufruf des BPEL-Prozesses Client ist während der Abarbeitung des Aufrufs geblockt <process>... <sequence> <receive> partnerlink = client porttype = chs:partnerchange operation = changepartner variable = ChangeRequest createinstance = yes />.... <reply partnerlink = client operation = changepartner variable = changepartnerresponse /> </sequence> </process> Folie 28
29 Visualisierung des synchronen Workflow in BPEL* *erstellt mit Eclipse BPEL Designer unter Eclipse 3.4 Folie 29
30 Konkretisierung des synchronen BPEL-Workflow AntwortClient Folie 30
31 Einbettung eines BPEL-Workflow in eine service-orientierte Architektur <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<BPEL-Workfllow Komponente>> <<Web Service>> <<client>> DatabaseAccess <<Web Service>> Notification Service AntwortClient Folie 31
32 Laufzeitumgebungen für BPEL-Workflow Ein BPEL Workflow wird in einer speziellen Laufzeitumgebung deployed und ausgeführt Servlet-Anwendung in einem Servlet-Container (z.b. Tomcat) Kommerzielle Anbieter: WebSphere Process Server SAP Netweaver Oracle BPEL Process Manager Microsoft BizTalk Server OpenSource: ActiveBPEL jbpm Apache ODE Folie 32
33 Aufbau dieser Veranstaltung Kapitel 6: Web Services III, Einführung in BPEL 1 Wiederholung: Workflow Services 2 Grundlegender Aufbau eines BPEL-Workflow 3 Asynchrone Implementierung eines BPEL-Workflow 4 Fehlerbehandlung in einem BPEL-Workflow 5 Benutzerinteraktionen in einem BPEL-Workflow 6 Bewertung des BPEL-Ansatzes 7 Zusammenfassung und Ausblick Folie 33
34 Asynchroner Aufruf eines BPEL-Workflow Ein BPEL-Workflow kann als Web Service auch asynchron aufgerufen werden Client ist nach dem initialen Aufruf nicht geblockt Client muss selber eine Schnittstelle (porttype) zur Verfügung stellen, damit BPEL-Workflow einen Callback durchführen kann: <<client>> <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<BPEL-Workfllow Komponente>> <<Web Service>> PartnerChange ServiceResponse (porttype ChangeResponse, operation callback) Folie 34
35 Abbildung eines asynchronen Aufrufs als Partner Link Type Bei einem asynchronen Aufruf eines BPEL-Workflow werden beide notwendigen Schnittstellen (porttypes) innerhalb eines Partner Link Types in der WSDL-Schnittstelle des BPEL-Workflows definiert (neue Rolle) Die Schnittstelle für den Callback-Aufruf muss auf Seiten des Client implementiert werden (also ein Regelwerk für den Client) <definitions name = ChangePartnerService > <types>... </types> <porttype name = PartnerChange >... <porttype> <porttype name = PartneChangeResponse >... <porttype> </porttypes> <plnk:partnerlinktype name= ChangeServiceLT"> <plnk:role name= receivepartnerforchange"> <plnk:porttype name= chs:partnerchange" /> </plnk:role> <plnk:role name= callbackresultofchange"> <plnk:porttype name= chs:partnerchangeresponse" /> </plnk:role> </plnk:partnerlinktype>... <definitions> WSDL-Auszug zur Definition des Web Service ChangePartnerService Folie 35
36 Abbildung eines asynchronen Aufrufs als Partner Link Type Innerhalb der BPEL-Spezifikation muss auf die neue Rolle innerhalb der zutreffenden Partner Link Definition verwiesen werden Rollentyp myrole spezifiziert die Rolle in dem Partner Link aus Sicht des BPEL Workflow <process name = PartnerChangeWorkflow > <partnerlinks> <partnerlink name = client partnerlinktype = chs:changeservicelt, myrole = receivepartnerforchange partnerrole = callbackresultofchange />... </partnerlinks>... BPEL-Auszug zur Definition der Partner Links Folie 36
37 Rückgabe des Ergebnisses in einem asynchronen Aufruf Anstelle der <reply> Aktivität wird bei einem asynchronen Aufruf das Ergebnis mittels einer <invoke> Aktivität zurückgeliefert: <process>... <sequence> <receive> partnerlink = client porttype = chs:partnerchange operation = changepartner variable = ChangeRequest createinstance = yes />.... <invoke partnerlink = client porttype = PartnerChangeResponse operation = sendbackresult variable = changeresponse /> </sequence> </process> Folie 37
38 Konkretisierung des BPEL-Workflow Folie 38
39 Asynchroner Aufruf von Web Services aus einem BPEL-Workflow Ein BPEL-Workflow kann selber Web Services auch asynchron aufrufen BPEL-Workflow ist nach dem Aufruf nicht geblockt BPEL-Workflow muss selber eine Schnittstelle (porttype) zur Verfügung stellen, damit BPEL-Workflow einen Callback durchführen kann: <<BPEL-Workfllow Komponente>> NotificationRequest <<Web Service >> <<Web Service>> Notification Service (porttype Notification, operation send) <<Web Service>> Notification ServiceResponse (porttype NotificationRespo, operation callback) NotificationResponse Folie 39
40 Optimierung der Asynchronität Eine Optimierung der Asynchronität kann mit einer <Flow> Aktivität (parallele Ausführung von Aktivitäten ermöglicht werden: Ein Prozess horcht auf die reinkommende Callback-Nachricht Folie 40
41 Aufbau dieser Veranstaltung Kapitel 6: Web Services III, Einführung in BPEL 1 Wiederholung: Workflow Services 2 Grundlegender Aufbau eines BPEL-Workflow 3 Asynchrone Implementierung eines BPEL-Workflow 4 Fehlerbehandlung in einem BPEL-Workflow 5 Benutzerinteraktionen in einem BPEL-Workflow 6 Bewertung des BPEL-Ansatzes 7 Zusammenfassung und Ausblick Folie 41
42 Fault Handler Bei der Ausführung eines BPEL-Prozesses können Fehler (faults) auf verschiedenen Wegen auftreten Fachliche Fehler: Explizit aus einem BPEL-Prozess (<throw> Aktivität) Nach dem Aufruf eines Web Services über <invoke> (Rückgabe eines Fault- Wertes des Web Services) Technische Fehler Fehler aus der BPEL-Laufzeitumgebung (z.b. Timeouts, syntaktische Fehler) Explizites Melden von fachlichen Fehlern durch <throw> Definition mit einem Namen Optional: Angabe einer FaultVariable <throw faultname="dbaccessnotsuccesfull" faultvariable= DBFault" /> Meist eingebettet in einer konditionalen Abfrage (<if>... <else>) FaultVariable muss im Bereich <Variables> definiert sein. Folie 42
43 Standardwerte für technische Faults in BPEL Folie 43
44 Fault Handler Signalisierte Fehler werden in Fault Handler (<faulthandler>) Abfolge von Aktivitäten innerhalb eines BPEL-Prozesses, um einen Fehler zu beheben Delegation von Fehler an andere Web Services Benachrichtigung des aufrufenden Client Fault Handler werden vor der ersten Aktivität des BPEL-Prozesses definiert: <partnerlinks>... </partnerlinks> <variables>... <variables> <faulthandlers> <catch faultname = DBAccessNotSuccesfull > <!-- Perform an activity --> </catch> <catch all> <!-- Perform an activity --> </catch>... </faulthandlers> <sequence>... </sequence> Folie 44
45 Beispiel: Fehlerbehandlung nach Datenbankzugriff <process>... <sequence> <receive...> <assign>... </assign> <invoke partnerlink= databaseconnection" porttype= dbs:databasewrite" operation= savedata" inputvariable="databaserequest" outputvariable="databaseresponse" /> <if> <condition> bpws:getvariabledata( databaseresponse, payload, /result ) = false </condition> <assign> <copy> <from variable = databaseresponse part = reason > <to variable = DBFault part reason > </copy> <assign> <throw faultname="dbaccessnotsuccesfull" faultvariable= DBFault" /> </if>.. Definition der <throw> Aktivität in BPEL (Auszug) Folie 45
46 Beispiel: Fehlerbehandlung nach Datenbankzugriff <process>... <faulthandlers> <catch faultname = DBAccessNotSuccesfull > <assign> <copy> <from variable = DBFault part = reason > <to variable = changepartnerresponse part comment > </copy> </assign> <reply partnerlink = client operation = changepartner variable = changepartnerresponse /> </catch> <catch faultname = NotificationNotSuccesfull > <!-- Perform an activity --> </catch>... </faulthandlers> Definition der Faulthandler in BPEL (Auszug) Folie 46
47 Scopes in BPEL Mit Scopes können BPEL-Prozesse hierarchisch unterteilt werden Scopes können eigene Variablen und FaultHandler definieren, die nur innerhalb des Scope sichtbar sind Dedizierte Startaktivität muss vorhanden sein (meist eine <sequence>), in dem ein normaler Ablauf spezifiziert wird Vorteile: Bessere Strukturierung und Lesbarkeit des Prozesses <process>... <scope name = PartnerChangeScope > <variables> <!-- Variables definitions local to scope --> </variables> <faulthandlers> <!-- Fault handlers local to scope --> </faulthandlers> Startaktivität <scope name = SubProzess >... </scope> </scope> </process> Folie 47
48 Compensation Handler Compensation Handler dienen der Rückgängigmachung von bereits erfolgreich ausgeführten Aktivitäten mittels einer Gegenaktion Bsp.: Hotel buchen Hotel stornieren Bsp.: Partner-Daten abgespeichert Partner-Daten wieder auf alten Stand bringen Bewahrung der Konsistenz von langläufigen Transaktionen Bei Workflows mit Benutzerinteraktion oft der Fall Optimistischer Ansatz: normaler Ablauf ist die Regel, Fehler sind Ausnahme BPEL kennt kein automatisches Rollback, Compensation muss explizit definiert werden Transaktionsgrenzen werden durch Scope dargstellt Folie 48
49 Definition von Compensation Handler Compensation Handlers werden im Rahmen eines Scope definiert: <process>... <scope name = PartnerChangeScope > <variables> <!-- Variables definitions local to scope --> </variables> <faulthandlers> <!-- Fault handlers local to scope --> </faulthandlers> <compensationhandler>... </compensationhandler> </scope> </process> Folie 49
50 Aufruf eines Compensation Handler Ein Compensation Handler zur Rückgängigmachung einer Aktivität wird immer in einem <catch> oder <catch all> Block aus einem Fault Handler oder aus einem <compensationhandler> Block aufgerufen Der Befehl <compensatescope> ruft den Compensation Handler eines Kind-Scope auf. <process> (oder <scope>) <faulthandlers> <catch faultname = NotificationNotSuccesfull > <compensatescope target = PartnerChangeScope /> </catch>... <faulthandlers> <scope name = PartnerChangeScope > <compensationhandler>... </compensationhandler> </scope> <sequence>... <throw faultname="notificationnotsuccesfull" > </sequence> Folie 50
51 Compensation ein Beispiel In unserem Beispiel wird die Änderung des Partners rückgängig gemacht, falls ein Vorgesetzter oder ein Manager die Änderung ablehnt Denkbare Begründung: zu hohes Gehalt <scope name = PartnerChangeScope > <compensationhandler>... <invoke partnerlink= databaseconnection" porttype= dbs:databasewrite" operation= restoredata" inputvariable="databaserequest" outputvariable="databaseresponse" />... </compensationhandler> </scope> Folie 51
52 Behandlung eines Fehlers mit <rethrow> Mit der Aktivität <rethrow> kann ein Fehler innerhalb eines Scope zu dem Vater -Scope weiterdelegiert werden Separate Fehlerbehandlung dann möglich <process> (oder <scope>) <faulthandlers> <catch faultname = BadNotification > <compensatescope target = PartnerChangeScope />... <faulthandlers> <scope name = PartnerChangeScope > <compensationhandler>... </compensationhandler> </scope> <scope name = NotificationScope > <faulthandlers> <catch faultname = NotificationNotSuccesfull >... <rethrow faultname = BadNotification /> </catch> </scope> Folie 52
53 Aufbau dieser Veranstaltung Kapitel 6: Web Services III, Einführung in BPEL 1 Wiederholung: Workflow Services 2 Grundlegender Aufbau eines BPEL-Workflow 3 Asynchrone Implementierung eines BPEL-Workflow 4 Fehlerbehandlung in einem BPEL-Workflow 5 Benutzerinteraktionen in einem BPEL-Workflow 6 Bewertung des BPEL-Ansatzes 7 Zusammenfassung und Ausblick Folie 53
54 Benutzerinteraktion in BPEL BPEL definiert selber keine Sprachkonstrukte, um eine Benutzerinteraktion zuzulassen Annahme: rein automatisierter Ablauf des Workflow ohne Benutzerinteraktion Feststellung: Viele Szenarien fordern die Interaktion mit einem Benutzer vor / während / nach der Ausführung eines Workflow: Mögliche Formen: Manuelle Abnahme von wichtigen Aktivitäten / Entscheidungen Durchführung von komplexen Aufgaben mit einem dedizierten Ziel Eingabe von komplexen Daten (Initialisierung des Workflow) Anzeige von Zwischenergebnissen Status-Anzeige Blockierung des BPEL-Prozesses zum Teil möglich bis Benutzerinteraktion erfolgt ist Synchrone vs. asynchrone Ausführung Folie 54
55 Normale Anbindung einer Interaktionskomponente an eine Workflow-Komponente Aufruf eines Workflow aus einer Interaktionskomponente <<BPEL-Workfllow Komponente>> <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<Interaktionskomponente>> <<Servlet>> oder <<Java Server Page>> Folie 55
56 Anbindung einer Interaktionskomponente an eine Workflow-Komponente (Pattern Arbeitsspeicher ) Asynchrone Übermittlung einer Aktivität für einen Benutzer (oder eine Benutzergruppe) an die Interaktionskomponente (Arbeitsspeicher) <<BPEL-Workfllow Komponente>> <<Web Service>> PartnerChange Service (porttype PartnerChange, operation changepartner) <<Interaktionskomponente>> <<Servlet>> oder <<Java Server Page>> <<Web Service>> Arbeitsspeicher (porttype Arbeits speicher, operation setzeinteraktion) <<component>> Arbeitsspeicher Folie 56
57 Anbindung einer Interaktionskomponente an eine Workflow-Komponente (Pattern Arbeitsspeicher ) Darstellung des Arbeitsspeichers mit den aktuellen ToDos beim Einloggen des Benutzers (z.b. über Startseite) Zusätzliche Benachrichtigung über Mail ist üblich BPEL-Prozess kann von da an weiter ausgeführt werden (z.b. über callback) <<Interaktionskomponente>> <<Servlet>> oder <<Java Server Page>> Browser <<Web Service>> Arbeitsspeicher (porttype Arbeits speicher, operation setzeinteraktion) <<component>> Arbeitsspeicher Vorgesetzter Folie 57
58 BPEL4People BPEL4People ist eine Erweiterung des BPEL-Standards zur Abbildung und Integration von menschlichen Aktivitäten in einem BPEL-Workflow Spezifikation von OASIS (2007, ongoing) In vielen Laufzeitumgebungen bereits integriert (z.b. ActiveVOS, Oracle) Spezifikation sehr vage, oberflächlich, Implementierung somit immer noch herstellerabhängig Infos unter: Folie 58
59 BPEL4People Grundlegende Konzepte Einführung einer neuen Aktivität: <peopleactivity> Benachrichtigung (ohne Ergebnis) Abarbeitung einer Aufgabe (mit Ergebnis) Zuweisung von Personen (People) zu einer Aktivität Wer muss eine Aktivität ausführen? Wer kann einen neuen (Sub-)Workflow starten? Welche Rolle besitzt eine Person (z.b. Entscheider, Mitarbeiter, Besitzer) Zuordnung von Personen und Rollen über <peoplelinks> Referenzieren auf Directories (z.b. LDAP) um spezifische Informationen über Personen zu erhalten Folie 59
60 BPEL4People Mögliche Szenarien Zuweisung und Ausführung von Aufgaben an eine Gruppe von Personen Zuweisung, welche Personen einen Prozess starten dürfen Management von langlaufenden Prozessen (z.b. Involvierung bei Timeout oder Fehler) 4-Augen Prinzip bei der Abschließung von wichtigen Aktivitäten Eskalation von Prozessen Nominierung von Zuständigkeiten für unklare Aufgaben Lifecycle Management (Delegation von Zuständen von Tasks zu Prozess) Folie 60
Service-Orientierte Architekturen
Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha
Service-Orientierte Architekturen
Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda
9. Business Process Execution Language
1 9. Business Process Execution Language Beobachtung: häufige Änderungen der Geschäftsprozesse dies erfordert leichte und schnelle Software-Anpassung Idee: Software in (Web-)Services gliedern ( SOA) diese
Business Process Execution Language. Christian Vollmer Oliver Garbe
Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?
Konzepte und Anwendung von Workflowsystemen. Kapitel 8: Workflow Ausführungssprache BPEL
Vorlesung Wintersemester 2011/12 Konzepte und Anwendung von Workflowsystemen Kapitel 8: Workflow Ausführungssprache BPEL Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen
Geschäftsprozessmodellierung essmodellierung mit BPEL
Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution
Business Process Execution Language for Web Services (BPEL4WS)
Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher
Model-Driven Software Development
Model-Driven Software Development BPEL 2.0 Robert Siebert Das Forschungs- und Entwicklungsprojekt OrViA wird mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) gefördert, die innerhalb
Analyse von Sicherheitaspekten in Service-orientierten Architekturen
Analyse von Sicherheitaspekten in Service-orientierten Architekturen Vortragende: Jia Jia Betreuer: Dipl.-Inf. Matthias Lehmann Dresden,10.12.2009 10.12.2009 Analyse von Sicherheitaspekten in SOA 1 Gliederung
Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL
Enterprise Applikation Integration und Service-orientierte Architekturen 11 BPEL Prozesse und Services Prof. Dr. Holger Wache 2 Problem: Prozesssteuerung mit WSDL Jeder Prozess ist zustandsbehaftet. Dieser
Möglichkeiten der Orchestrierung von Grid Web Services mit BPEL. Uschi Beck Marko Brosowski
Möglichkeiten der Orchestrierung von Grid Web Services mit BPEL Uschi Beck Marko Brosowski Gliederung Motivation BPEL Entstehung/Ziele ein kurzes Beispiel Basiskonzepte Probleme BPEL Engines BPEL im Grid
Web Services Composition (BPWS4J )
Web Services Composition (BPWS4J ) Hager Markus, Kober Christoph, Linde Kai, Ott Florian, Erdmann Dennis Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße
Vertiefte Grundlagen Graphentheorie
Bauinformatik Vertiefte Grundlagen Graphentheorie 6. Semester 9. Übung BPEL Webservice-Orchestrierung i Technische Umsetzung am Beispiel Biegespannung eines Einfeldträgers Nürnberger Str. 31a 2. OG, Raum
Entwurf und Implementierung einer Workflow-basierten Anwendung zur Auswertung mathematischer Formeln
Entwurf und einer Workflow-basierten Anwendung zur Auswertung mathematischer Formeln Object 14 Service Orientated Architecture (SOA) Web Services Business Process Execution Language (BPEL) SOA [1/3] Service
Tutorial zu WS-BPEL. Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008
Tutorial zu WS-BPEL Veranstaltung: Entwicklung verteilter Softwaresysteme mit Webservices im Sommersemester 2008 Universität Hamburg Department Informatik Arbeitsbereich VSIS Gruppe 01: Johannes Kuhlmann,
Modellierung von Geschäftsprozessen mit BPEL4WS
Seminararbeit von Abstract Die Business Process Execution Language for Web Services (BPEL4WS) ermöglicht es, sowohl Geschäftsprozesse zu beschreiben, welche Web Services nutzen, als auch Geschäftsprozesse
3. Web Service Security 3.1 WS-Security. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit
XML- und Webservice- Sicherheit 3. Web Service Security 3.1 WS-Security Gliederung 1. SOAP 2. WS-Security: Der SOAP Security Header 3. Security Tokens in WS-Security S 4. XML Signature in WS-Security 5.
Geschäftsprozessmodellierung mit BPEL4WS: Aufbau und Beispiel
Seminar Service Orientierte Architektur Geschäftsprozessmodellierung mit BPEL4WS: Aufbau und Beispiel SOA-Seminar 2006 - BPEL4WS - Christoph Forster (Winf 2370) 1 Agenda (1) Überblick (2) Der Geschäftsprozess
Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung
IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation
Programmierhandbuch SAP NetWeaver* Sicherheit
Martin Raepple Programmierhandbuch SAP NetWeaver* Sicherheit Galileo Press Bonn Boston Inhalt Vorwort 13 2.1 Sicherheit und serviceorientierte Architekturen 24 2.1.1 Sicherheitsziele der Informationssicherheit
Using Workflows to Coordinate Web Services in Pervasive Computing Environments
Using Workflows to Coordinate Web Services in Pervasive Computing Environments Vortrag im Rahmen des Seminars SOA 2005 im Fachbereich Informatik angefertigt von Volker Henke Agenda 1. Ubiquitous Computing
POIS-Praktikum 2007. Prozessimplementierung, RosettaNet PIPs 3A
POIS-Praktikum 2007 Prozessimplementierung, RosettaNet PIPs 3A Manuel Blechschmidt, David Foerster, Michael Leben, Mike Nagora, Jonas Rogge, Paul Römer Gliederung 2 Einleitung Was war unsere Aufgabe? Was
SOA secure Sicherheitsaspekte Serviceorientierter Architekturen
CM Network e.v. 7. Symposium: IT-Sicherheit SOA secure Sicherheitsaspekte Serviceorientierter Architekturen Dipl.-Wirtsch.-Inf. Stefan Krecher stefan@krecher.com Übersicht Service Orientierte Architekturen
A Comparison of BPML and BPEL4WS
A Comparison of BPML and BPEL4WS Wirtschaftsinformatik Universität Trier Seite 1 Ziele des Vortrags 1. Heterogenität der Business Process Modelling Initiativen für Web Services erkennen 2. Beschreibungsmöglichkeit
Web Service Security
Informatik Masterstudiengang SS 2005 Anwendungen I Web Service Security Thies Rubarth Übersicht Einleitung Secure Socket Layer XML Encryption & XML Signature WS-* WS-Security WS-Policy WS-Trust Angebot
Sicherheitsaspekte in Service Orientierten Architekturen. Eike Falkenberg Sommersemester 2006 Anwendungen I
Sicherheitsaspekte in Service Orientierten Architekturen Eike Falkenberg Sommersemester 2006 Anwendungen I Agenda SOA? Web Services? Sicherheitsrisiko Web Services Web Services & Sicherheit Sichere SOAs
Bachelorarbeit. Modellierung interaktiver Web Service Workflows. Thema: Benjamin Koch. von
Bachelorarbeit Thema: Modellierung interaktiver Web Service Workflows von Benjamin Koch Gliederung Beispiel Interaktive Workflows Komponenten o BPEL o Web Service o Web-Interface o Eclipse-Plugin Vorführung
Inhalt. Vorwort 13. L.., ',...":%: " j.
Inhalt Vorwort 13 L.., ',...":%: " j. 1. '-.:. ' " '.!. \, : - '. - * T '. ; - J A '.. ' I '",. - ' :'. ",..! :'. " ','. '.. ' t i ' ~ J \ I -.. I. j ' - ' V "!» " J f i " 1 1 * V. " ^ ' ' ' -.» ; ' ',
Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste
Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene
Web Service Security
Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de
Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar?
Sind Prozessmanagement-Systeme auch eingebettete Systeme einsetzbar? 12. Symposium Maritime Elektrotechnik, Elektronik und Informationstechnik, 8.-12. Oktober 2007 Rostock, Deutschland Rostock, Deutschland
Sicherheit in Workflow-Management-Systemen
Sicherheit in Workflow-Management-Systemen Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation KIT University of the State of Baden-Wuerttemberg and National Research Center of
Federated Identity Management
Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung
... Einleitung... 15. 3... Prozessintegration und Integrationsszenarien... 127 3.1... Integrationsszenariomodelle... 128
... Einleitung... 15 1... Grundlagen der Modellierung von Enterprise Services... 23 1.1... Serviceorientierte Architekturen... 26 1.1.1... Merkmale serviceorientierter Architekturen... 27 1.1.2... SOA
Business Process Management und Workflow-Technologien: Grundlagen, Produkte, Forschung Seminar
Thema : BPM und Workflow-Technologien - Eine Einführung Bearbeiter : Andreas Brückner Überblick/Motivation/Ziele Hintergründe, Historische Entwicklung der Prozessorientierung Terminologien, Klassifikation,
BPEL Business Process Execution Language
BPEL Business Process Execution Language Dr. Martin Bartonitz Product Manager SAPERION AG Vorsitzender des Aufsichtsrates: Dieter Matheis Vorstand: Rudolf Gessinger (Vorstandsvorsitzender), Andreas Kunze
Die Open Source SOA-Suite SOPERA
Architektur, Komponenten und Realisierung Jörg Gerlach Technische Universität Dresden Fakultät Informatik Institut für Angewandte Informatik Lehrstuhl Technische Informationssysteme 11. Juni 2009 Gliederung
BPEL als Eckpfeiler einer Serviceorientierten Architektur
BPEL als Eckpfeiler einer Serviceorientierten Architektur Stand der Technik und hands-on Demonstration 1. Dez. 2005 Marc Pellmann www.inubit.com inubit AG = Standardsoftware für integrierte Geschäftsprozesse
SAX-basierte Validierung von WS-Security-angereicherten SOAP- Nachrichten gegen eine Security Policy
SAX-basierte Validierung von WS-Security-angereicherten SOAP- Nachrichten gegen eine Security Policy Ralph Herkenhöner Arbeitsgruppe Kommunikationssysteme Institut für Informatik Christian-Albrechts-Universität
BPEL. Business Process Execution Language. Andre Rein. 21. August 2010. Serviceorientierte Architekturen
Business Process Execution Language Serviceorientierte Architekturen 21. August 2010 Inhalt 1 Einführung Allgemeine Beschreibung von Geschichtliches 2 Probleme Lösungen 3 process partner links sequence/receive/reply
SECTINO. Security for Inter-Organizational Workflows
SECTINO Security for Inter-Organizational Workflows Framework zur Modellierung und Realsisierung sicherheitskritischer organisationsübergreifender Workflows Kooperation Research Group Quality Engineering
5. Übung zur Vorlesung Service-orientierte Architekturen
5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter
Inhalt I. Blick zurück II. Was sind WebServices? III. Rahmenwerk für edienstleistungen IV. Verwendete WebServices
WebServices Applikationen und Services Ralf Günther Consultant HP Services April, 2003 Ralf.Guenther@hp.com DECUS Symposium 2003, Vortrag 2L06 9.04.2003 Inhalt I. Blick zurück II. Was sind WebServices?
1. Wie können Forms und SOA integriert werden?
Forms goes SOA Jüssen, Stefan Senior Consultant 03.02.2011 Jede Änderung im Geschäftsprozess muss umgehend in der unterstützenden Software abgebildet werden können. Professionelle Systementwicklung basiert
SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen
Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen
Sicherheitsaspekte von Web Services. Hauptseminar Rechnernetze
Sicherheitsaspekte von Web Services Hauptseminar Rechnernetze Stefan Hennig sh790883@inf.tu-dresden.de 21. Januar 2005 Gliederung Einführung Überblick Sicherheit auf Netzwerk- und Transportebene XML-Sicherheit
XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF
XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut
d.velop AG Bremer Archivtage
d.velop AG Service Orientierte Architekturen (SOA) und zukunftsorientierte Standards als Basis für die Entwicklung von Dokumentenmanagement- und Archivierungssystemen Ralf Bönning, Entwicklungsleiter,
Error-Hospital für Oracle SOA Suite
Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ
Wiederholung: Beginn
B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben
Semtation GmbH SemTalk
Semtation GmbH SemTalk Christian Fillies Was ist SemTalk? Prozessmodellierung mit Visio2003 Viele Methoden (EPK, PROMET, FlowChart, KSA ), einfach an Kundenbedürfnisse anzupassen und zu erweitern HTML
Seminarvortrag Serviceorientierte Softwarearchitekturen
Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?
Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.
Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung
Thema: Web Services. Was ist ein Web Service?
Willkommen zum Component Ware Seminar Thema: Achim Grimm & Fabian Unterschütz Folie 1 Was ist ein Web Service? Web Services sind selbstbeschreibende, modulare Softwarekomponenten im Internet, die sich
Nutzung und Erweiterung von IT-Standards zur Realisierung von Authentifizierung und Zugriffsschutz für Geo Web Services
Nutzung und Erweiterung von IT-Standards zur Realisierung von Authentifizierung und Zugriffsschutz für Geo Web Services Universität der Bundeswehr München Was erwartet Sie in diesem Vortrag? Thema 4 Thema
arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek
arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis
Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java
Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java von Christian Brand Kennnummer: 09376 November 2005 Abkürzungen Abkürzungen API - Application Programming Interface
Company. Sicherheit und WebServices CORISECIO CORISECIO. Dr. Bruno Quint CORISECIO. BESEQURE gegründet 2002 in Darmstadt Germany
Corporate Information Security Sicherheit und Webs Dr. Bruno Quint GmbH. Uhlandstr. 9. D-64297 Darmstadt. Germany. www.corisecio.com Company BESEQURE gegründet 2002 in Darmstadt Germany umbenannt 2007
SOA. Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik
SOA Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik Laderampen müssen passen Modularisieren Softwarearchitektur Modul A Modul B Modul C Modul D Große Anwendung im Unternehmen Modul
Seminararbeit Einbindung von Webservices über BPEL
Seminararbeit Einbindung von Webservices über BPEL Julian Harrer IBB4B Hochschule München Sommersemester 2008 Seminar: Integration von Geschäftsprozessen Prof. Dr. Zimmer Torsten München 10.07.2008 I.
Gliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)
Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,
Komplexe dokumentenbasierte Prozesse mit Oracle Technologien umsetzen
Komplexe dokumentenbasierte Prozesse mit Oracle Technologien umsetzen Johannes Michler, PROMATIS software GmbH DOAG Development; Bonn, 19. Mai 2013 1 Agenda Einführung Ausgangssituation Anforderungen Ansätze
SOAP und WSDL in der Praxis. Wie wird SOAP/WSDL verwendet? Heutige Vorlesung. .net. und Apache Axis
Heutige Vorlesung SOAP und WSDL in der Praxis Aufbau von WSDL-Beschreibungen Protokoll-Bindungen in WSDL Google-WSDL lesen und erweitern können Vor- und Nachteile von WSDL heute Wie wird SOAP/WSDL verwendet?.net,
Technische Konzeption der Bürgerportale
Technische Konzeption der Bürgerportale Armin Wappenschmidt (secunet) Weitere Informationen unter www.buergerportale.de www.bmi.bund.de 1 Agenda Technische Übersicht über Bürgerportale Postfach- und Versanddienst
Serviceorientierte Architektur Komplexitätsmanagement durch Integration
Serviceorientierte Architektur Komplexitätsmanagement durch Integration Feldafinger Kreis Dr. Uwe Bath, Deutsche Post Bad Honnef, 17. Januar 2005 Die neue Struktur der DPWN BRIEF EXPRESS / LOGISTIK FINANZ
Flexibilität im Prozess mit Oracle Business Rules 11g
Flexibilität im Prozess mit Oracle Business Rules 11g Michael Stapf ORACLE Deutschland GmbH Frankfurt Schlüsselworte: Geschäftsregeln, Business Rules, Rules Engine, BPEL Process Manager, SOA Suite 11g,
Fachliche Prozessmodellierung BPMN 2.0. HU Berlin, 27. Mai 2009
Fachliche Prozessmodellierung BPMN 2.0 HU Berlin, 27. Mai 2009 Die zwei Seiten des BPM Organisationslehre Ablauforganisation bis 1990 Business Process Reengineering - BPR (Orga-) Geschäftsprozess- Management
Sicherheit in Web Services. Seminar Service-orientierte Software Architekturen Melanie Storm
Sicherheit in Web Services Seminar Service-orientierte Software Architekturen Melanie Storm Agenda Motivation Fallbeispiel WS-Security XML Encryption XML Signature WS-Policy WS-SecurityPolicy WS-Trust
Entwicklung von Web-Anwendungen auf JAVA EE Basis
Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages
Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen
Enterprise Applikation Integration und Service-orientierte Architekturen 08 Einführung Service-Orientierte Architekturen Ist SOA immer noch aktuell? Prof. Dr. Holger Wache http://bhc3.files.wordpress.com/2009/07/gartner-emerging-technologies-hype-cycle-2009.png?w=552&h=451
Grundlagen des Grid Computing
Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery
BPEL for People - Human Tasks in Action
BPEL for People - Human Tasks in Action Stefan Kühnlein DOAG Konferenz 2007 SerCon GmbH München Agenda 2 Agenda 1 Deutsche Patent- und Markenamt 2 Projekt Elektronische Schutzrechtsakte ElSA 3 Workflow
Zustandsgebundene Webservices
Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite
Softwareentwicklung mit Enterprise JAVA Beans
Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung
Enterprise Java Beans Einführung
Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse
Neuerungen bei Shibboleth 2
Neuerungen bei Shibboleth 2 Shibboleth-Workshop BW Stuttgart, 7. Februar 2008 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Aktueller Status Kommunikation IdP
Architektur von SOAP basierten Web Services
Architektur von SOAP basierten Web Services André Homeyer 28.11.2005 Worst-Case einer verteilten Anwendung TravelTime Client Benutzerinterface WackyWing Server Flüge suchen TravelTime Server Flüge suchen
Die nächste Revolution in der modelgetriebenen Entwicklung?
Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF
!"#$"%&'()*$+()',!-+.'/',
Soziotechnische Informationssysteme 7. OAuth, OpenID und SAML Inhalte Motivation OAuth OpenID SAML 4(5,12316,7'.'0,!.80/6,9*$:'0+$.;.,&0$'0, 3, Grundlagen Schützenswerte Objekte Zugreifende Subjekte Authentifizierung!
Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant
Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden
Geschäftsprozesse SOA-gerecht modellieren mit BPMN und UML. München, 28. Januar 2010
Geschäftsprozesse SOA-gerecht modellieren mit BPMN und UML München, 28. Januar 2010 INHALT Warum BPMN? Prozesse modellieren mit BPMN 2.0 Fachliche Services identifizieren BPMN-Prozesse mit UML ergänzen
Java Web Services mit Apache Axis2 Entwickler
Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum
BPMN Kategorien und Elementgruppen. Flussobjekte
BPMN Kategorien und Elementgruppen Flussobjekte Business Process BP... Activity1 Activity Eine Activity ist die generischer Ausdruck für in Unternehmen anfallende Tätigkeiten. Das Element Activity kann
Software Engineering II (IB) Serviceorientierte Architektur
Serviceorientierte Architektur Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Webservices Ziel: flexible programmatische Zusammenarbeit zwischen Servern Bereitstellung
Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011
Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen OOP München, 26.01.2011 I N H A L T 1. SOA das erste Projekt 2. Prozesse Ergebnisse aus dem Fachbereich 3. Der Business Analyst und BPMN
Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 18.09.2002 J.M.Joller 1
Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 18.09.2002 J.M.Joller 1 Architektur von Web Services und ergänzende Technologien Inhalt Sicherheit WS-License und WS-Security Prozessfluss
Securing SOAP e-services
Securing SOAP e-services Nilson Reyes Sommersemester 2004 aus: E. Damiani, S. De Capitani di Vermercati, S. Paraboschi, P. Samarati, Securing SOAP e-sservices, IJIS, Ausgabe 1 (2002), S.110-115. Gliederung
Integration von Oracle Forms in Service Oriented Architecture (SOA) Jürgen Menge Oracle Deutschland
Integration von Oracle Forms in Service Oriented Architecture (SOA) Jürgen Menge Oracle Deutschland The following is intended to outline our general product direction. It is intended for information purposes
Verteilte Systeme: Übung 4
Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist
Fachbereich Informatik
Diplomarbeit Strategien zur Prozessorchestrierung und Workflow-Integration in Web-Applikationen Andreas Kümpel Dezember 2004 Betreuer: Prof. Dr. Paul Müller Dipl.-Wirtsch.-Ing. Jochen Müller Fachbereich
ActiveBPEL. Leif Goltermann Hai-Minh Le Benjamin Pennig Stephan Schirmer. Projekt: Entwicklung Verteilter Softwaresysteme Mit Web Services
ActiveBPEL Leif Goltermann Benjamin Pennig Hai-Minh Le Stephan Schirmer WSBPEL Überleitung Motivation mehreren Aktivitäten organisieren Kommunikation und Datenfluss kontrollieren Workflow Vordefinierte
Christoph Mathas. SOA intern. » Praxiswissen zu Service-orientierten IT-Systemen HANSER
Christoph Mathas SOA intern» Praxiswissen zu Service-orientierten IT-Systemen HANSER Inhalt Vorwort XI 1 Einleitung 1 1.1 Wem nützt dieses Buch? 2 1.2 Weshalb dieses Buch? 3 1.3 Die Kapitelstruktur 4 1.4
Ausblick auf Shibboleth 2.0
Ausblick auf Shibboleth 2.0 4. Shibboleth-Workshop Berlin, 28. Februar 2007 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht OpenSAML 2.0 Stand der Entwicklung Shibboleth
Containerformat Spezifikation
Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...
Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de
s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful
WS-Security. Thies Rubarth. Sicherheitskonzepte in global verteilten Anwendungen. 21. Sep 2007 ACM/GI Localgroup #216
WS-Security Sicherheitskonzepte in global verteilten Anwendungen Thies Rubarth 21. Sep 2007 ACM/GI Localgroup #216 Thies Rubarth, M.Sc. (Informatik) IT Berater Jahrgang 1979 Anwendungsentwicklung seit
R016 Beilage 5: SOA-Glossar
Eidgenössisches Finanzdepartement EFD Informatiksteuerungsorgan des Bundes ISB R016 Beilage 5: SOA-Glossar Ausgabedatum: 2015-02-25 Version: 2.01 Status: Genehmigt Ersetzt: 2.0 Verbindlichkeit: Weisung
SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven
SOA Serviceorientierte Architektur Definition, Marktpotenzial und Perspektiven SO A Fraunhofer-Institut für Softwareund Systemtechnik ISST Dr. Ulrich Springer Dr. Bernhard Holtkamp Dortmund, 20.01.2009
TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL
1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen
Service-Orientierte Architekturen
Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda