Service - Sascha-alda.de
Service - Sascha-alda.de
Service - Sascha-alda.de
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Hochschule<br />
Bonn-Rhein-Sieg<br />
<strong>Service</strong>-Orientierte Architekturen<br />
Kapitel 2: Einführung in <strong>Service</strong>-Orientierte<br />
Architekturen<br />
Vorlesung im Masterstudiengang Informatik<br />
Sommersemester 2010<br />
Prof. Dr. <strong>Sascha</strong> Alda<br />
(sascha.<strong>alda</strong>@h-brs.<strong>de</strong>)
(Vorläufiger) Aufbau <strong>de</strong>r Vorlesung<br />
Kapitel<br />
Thema<br />
<br />
1 Organisation, Einführung in Software-Architekturen<br />
2 Einführung in <strong>Service</strong>-Orientierte Architekturen<br />
3 Design Prinzipien von <strong>Service</strong>-Orientierten Architekturen<br />
4 Web <strong>Service</strong>s I (SOAP, WSDL)<br />
5 Web <strong>Service</strong>s II (UDDI, WS-Policies, Axis2)<br />
6 Mo<strong>de</strong>llierung von Geschäftsprozessen (BPEL, BPMN)<br />
7 Vertiefung Web <strong>Service</strong>s (BAM, BPEL4People, ...)<br />
8 OSGi <strong>Service</strong> Plattform<br />
9 Einführung in Swordfish<br />
10 REST Architekturen<br />
11 (22.6.) Exception Handling in SOA (Gastvortrag)<br />
12 (29.6.) SOA Point of View von Accenture (Gastvortrag)<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 2
Ziele dieser Veranstaltung<br />
<br />
Vermittlung <strong>de</strong>r Grundlagen von <strong>Service</strong>-Orientierten Architekturen ohne<br />
Fokus auf eine bestimmte Technologie zur Umsetzung<br />
<br />
<strong>Service</strong>-Orientierung: Small View vs. Big View<br />
<br />
Kennenlernen von wichtigen Entwurfsprinzipien<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 3
Definition Software-Architektur<br />
<br />
Eine Software-Architektur beschreibt die Dekomposition eines Software-<br />
Systems, die <strong>de</strong>n Vorgaben eines zugehörigen Architekturstils genügt. Die<br />
Architektur-Beschreibung umfasst folgen<strong>de</strong> Bestandteile:<br />
<br />
<br />
<br />
<br />
die grundlegen<strong>de</strong>n Architektur-Elemente<br />
die Interaktionsbeziehungen zwischen <strong>de</strong>n Architektur-Elementen<br />
die strukturellen und operativen Architektur-Direktive <strong>de</strong>r<br />
Gesamtarchitektur<br />
die charakterisieren<strong>de</strong>n Kennzahlen <strong>de</strong>r Gesamtarchitektur<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 4
Erläuterung <strong>de</strong>s Begriffs Software Architektur<br />
Architektur-Elemente – Meta-Mo<strong>de</strong>ll<br />
<br />
<br />
Die Architektur-Elemente einer Architektur bestehen im Wesentlichen aus<br />
Subsystemen sowie Modulen, Interfaces und Interface-Objekten.<br />
Meta-Mo<strong>de</strong>ll eines Architekturstil:<br />
Subsystem<br />
System Design<br />
1 0..n<br />
Module<br />
System Design<br />
1<br />
0..n<br />
0..n<br />
Interface<br />
System Design<br />
isImplementedBy<br />
Interface-Objekt<br />
System Design<br />
Ein Metamo<strong>de</strong>ll ist ein Mo<strong>de</strong>ll, das<br />
beschreibt, wie Mo<strong>de</strong>lle gebaut<br />
wer<strong>de</strong>n.<br />
Hier: ein Architekturstil !<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 5
Glie<strong>de</strong>rung dieser Veranstaltung<br />
Kapitel 2: Einführung in <strong>Service</strong>-Orientierte Architekturen<br />
<br />
1 Kurze Wie<strong>de</strong>rholung<br />
2 <strong>Service</strong>-Orientierung als Architekturstil (Small View)<br />
3 <strong>Service</strong>-Orientierung aus Unternehmenssicht (Big View)<br />
4 Klassifizierung von <strong>Service</strong>s<br />
5 Qualitätsmerkmale von <strong>Service</strong>s<br />
6 Enterprise <strong>Service</strong> Bus<br />
7 Zusammenfassung und Ausblick<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 6
Was ist eigentlich SOA?<br />
SOA (<strong>Service</strong>-Oriented Architectures) ist ein Architekturstil für<br />
Software-Architekturen, mit <strong>de</strong>m Ziel, komplexe Systeme, Software-<br />
Anwendungen, betriebliche Funktionen und Prozesse zu integrieren<br />
(Enterprise Application Integration, EAI)<br />
• SOA umfasst eine Reihe von Richtlinien,<br />
Best Practices, Standards, Tool-<br />
Empfehlungen, Frameworks und<br />
Entwicklungsprozesse<br />
• Kapselung von Ressourcen als<br />
<strong>Service</strong>s, die über das Netzwerk<br />
(Internet und Intranet) verfügbar sind<br />
( Verteilte Architektur)<br />
• Achtung: SOA ist kein Produkt, das<br />
man (ver)kaufen kann<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010
Definition einer <strong>Service</strong>-Orientieren Architektur<br />
<br />
„SOA ist ein Architektur-Paradigma für <strong>de</strong>n Umgang mit Geschäftsprozessen,<br />
die über eine große Landschaft von existieren<strong>de</strong>n und neuen heterogenen<br />
Systemen verteilt wer<strong>de</strong>n, wobei die Systeme unterschiedliche Eigentümer<br />
haben“<br />
[Josuttis, 2008]<br />
<br />
„SOA ist ein Architekturmuster, das <strong>de</strong>n Aufbau einer Anwendungslandschaft<br />
aus einzelnen fachlichen, d.h. geschäftsbezogenen Komponenten beschreibt.<br />
Diese sind lose miteinan<strong>de</strong>r gekoppelt, in<strong>de</strong>m sie einan<strong>de</strong>r ihre Funktionalität in<br />
Form von <strong>Service</strong>s anbieten“<br />
[Hess et al., 2006]<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 8
Definition <strong>de</strong>s Begriffs „<strong>Service</strong>“<br />
<br />
„<strong>Service</strong>s sind eine IT-Repräsentation von fachlicher Funktionalität, die<br />
durch eine wohl<strong>de</strong>finierte Schnittstelle beschrieben wer<strong>de</strong>n (...).<br />
[Josuttis, 2008]<br />
<br />
„<strong>Service</strong>s realisieren Geschäftsfunktionen, die sie über eine<br />
implementierungsunabhängige Schnittstelle kapseln. Zu je<strong>de</strong>r Schnittstelle<br />
gibt es einen <strong>Service</strong>vertrag, <strong>de</strong>r die funktionalen und nicht-funktionalen<br />
Merkmale (Meta-Daten) <strong>de</strong>r Schnittstelle beschreibt. Die Nutzung (und<br />
Wie<strong>de</strong>rverwendung) von <strong>Service</strong>s geschieht über „entfernte“ Aufrufe“<br />
[Starke und Tilkov, 2007]<br />
<br />
<strong>Service</strong>s wer<strong>de</strong>n durch <strong>Service</strong>-Beschreibungen (service <strong>de</strong>scription)<br />
syntaktisch und semantisch beschrieben und können dadurch in einer<br />
Infrastruktur veröffentlicht wer<strong>de</strong>n.<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 9
Architekturstil einer <strong>Service</strong>-Orientieren Architektur<br />
Return<br />
“possible-<br />
<strong>Service</strong>s”<br />
<strong>Service</strong><br />
Registry<br />
Discover<br />
“a<strong>Service</strong>”<br />
Publish<br />
“a<strong>Service</strong>”<br />
<strong>Service</strong><br />
Consumer<br />
[RequestDescription “a<strong>Service</strong>”]<br />
<strong>Service</strong> Bind / Interaction<br />
<strong>Service</strong><br />
Provi<strong>de</strong>r<br />
<strong>Service</strong><br />
“a<strong>Service</strong>”<br />
<br />
<br />
<br />
Ein <strong>Service</strong> Provi<strong>de</strong>r (Anbieter) ist ein Subsystem, das einen <strong>Service</strong> implementiert, so<br />
dass an<strong>de</strong>re Systeme diesen aufrufen können<br />
Ein <strong>Service</strong> Consumer (Nutzer) ist ein Subsystem, das einen <strong>Service</strong> aufruft und diesen<br />
nutzt (z.B. im Kontext eines Geschäftsprozesses)<br />
Eine <strong>Service</strong> Registry (Verzeichnis) ist ein Subsystem, welches <strong>Service</strong>s zwischen<br />
einem <strong>Service</strong> Provi<strong>de</strong>r und <strong>Service</strong> Consumer vermitteln kann<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 10
Definition <strong>de</strong>s Begriffs „<strong>Service</strong>“<br />
Erweiterung <strong>de</strong>s Meta-Mo<strong>de</strong>lls eines Architekturstils<br />
<br />
<strong>Service</strong>s knüpfen an das Interface eines Subsystems an:<br />
Subsystem<br />
System Design<br />
1 n<br />
Module<br />
System Design<br />
1<br />
n<br />
Interface<br />
System Design<br />
isImplementedBy<br />
0..n<br />
InterfaceObject<br />
System Design<br />
<strong>Service</strong><br />
isSpecifiedBy<br />
isImplementedBy<br />
<strong>Service</strong>Handle<br />
isDescribedBy<br />
isPublishedWith<br />
<strong>Service</strong>Description<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 11
Definition <strong>de</strong>s Begriffs „<strong>Service</strong>“<br />
Erweiterung <strong>de</strong>s Meta-Mo<strong>de</strong>lls eines Architekturstils<br />
<br />
<strong>Service</strong>s knüpfen an das Interface eines Subsystems an (Java):<br />
Subsystem<br />
Module<br />
1 n<br />
System (= Package) Design<br />
System (= Class) Design<br />
1<br />
n<br />
Interface<br />
InterfaceObject<br />
isImplementedBy<br />
System Design<br />
(= Interface) System Design<br />
(= Class, Handle)<br />
<strong>Service</strong><br />
isSpecifiedBy<br />
(= kein direktes Pendant,<br />
z.B. Web <strong>Service</strong>s)<br />
isImplementedBy<br />
isDescribedBy<br />
isPublishedWith<br />
<strong>Service</strong>Handle<br />
<strong>Service</strong>Description<br />
(= kein direktes Pendant,<br />
z.B. WSDL)<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 12
Aufbau eines <strong>Service</strong><br />
<br />
<br />
Die Architektur-Elemente Subsysteme, Module, Interfaces und <strong>Service</strong> wer<strong>de</strong>n<br />
oft durch die Verwendung <strong>de</strong>s Faca<strong>de</strong> Pattern [Gamma, 1996] realisiert:<br />
Beispiel: Subsystem eines Compiler<br />
<strong>Service</strong><br />
<strong>Service</strong>: “Compiler”<br />
Method: compile<br />
Description: This is a<br />
compiler<br />
<strong>Service</strong>Description<br />
Subsystem<br />
Compiler<br />
Interface<br />
Compiler<br />
compile()<br />
InterfaceObject = <strong>Service</strong> Handle<br />
Co<strong>de</strong>Generator<br />
create()<br />
Lexer<br />
getToken()<br />
Module<br />
Parser<br />
createParseTree()<br />
Optimizer<br />
create()<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 13
Aufbau eines <strong>Service</strong><br />
<br />
<br />
In <strong>de</strong>r Praxis wer<strong>de</strong>n <strong>Service</strong>s meist auf Basis von Software-Komponenten<br />
realisiert<br />
Beispiel: Subsystem eines Compiler<br />
Komponente<br />
<strong>Service</strong><br />
(Provi<strong>de</strong>d) Interface<br />
Compile-Interface<br />
<strong>Service</strong>: “Compiler”<br />
Method: compile<br />
Description: This is a<br />
compiler<br />
<strong>Service</strong>Description<br />
<br />
Compiler<br />
Compile-Interface<br />
<br />
Compiler<br />
<br />
Lexer<br />
InterfaceObject =<br />
<strong>Service</strong> Handle<br />
<br />
Co<strong>de</strong>Generator<br />
<br />
Parser<br />
<br />
Optimizer<br />
Module<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 14
Mo<strong>de</strong>llierung eines <strong>Service</strong><br />
<br />
<br />
UML bietet keine Möglichkeiten, <strong>Service</strong>s zu direkt mo<strong>de</strong>llieren<br />
Häufig mit <strong>de</strong>r Verwendung von Stereotypen. Beispiel:<br />
<br />
Compiler<br />
Provi<strong>de</strong>d Interface („Compile-Interface“):<br />
public Co<strong>de</strong> compileCo<strong>de</strong>( Co<strong>de</strong> );<br />
Komponente<br />
<br />
Compiler<br />
Compile-Interface<br />
<br />
Compiler<br />
<br />
Lexer<br />
InterfaceObject =<br />
<strong>Service</strong> Handle<br />
<br />
Co<strong>de</strong>Generator<br />
<br />
Parser<br />
<br />
Optimizer<br />
Module<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 15
Glie<strong>de</strong>rung dieser Veranstaltung<br />
Kapitel 2: Einführung in <strong>Service</strong>-Orientierte Architekturen<br />
<br />
<br />
1 Kurze Wie<strong>de</strong>rholung<br />
2 <strong>Service</strong>-Orientierung als Architekturstil (Small View)<br />
3 <strong>Service</strong>-Orientierung aus Unternehmenssicht (Big View)<br />
4 Klassifizierung von <strong>Service</strong>s<br />
5 Qualitätsmerkmale von <strong>Service</strong>s<br />
6 Enterprise <strong>Service</strong> Bus<br />
7 Zusammenfassung und Ausblick<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 16
Typisches Szenario einer verteilten Architektur in einem<br />
Unternehmen<br />
Oracle<br />
DB2<br />
SAP 2.0<br />
FI System<br />
Billing<br />
System<br />
Siebel<br />
System<br />
Archive<br />
System<br />
SAP R3<br />
CO System<br />
Mail Server<br />
Siebel<br />
System FI<br />
Banking<br />
Software<br />
SAP R3<br />
MM System<br />
Billing<br />
System 2<br />
Web<br />
Frontend<br />
Intercompany<br />
Module<br />
Sub-Tochter (eignes Intranet)<br />
SAP<br />
Netweaver<br />
BI Solution<br />
SAP R3<br />
System FI<br />
Workflow<br />
System<br />
External Partner<br />
(Bank)<br />
Banking<br />
Software<br />
Externe Betreiber<br />
External Partner<br />
(Kun<strong>de</strong>)<br />
CR<br />
Software<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 17
Typisches Szenario einer verteilten Architektur in einem<br />
Unternehmen<br />
Oracle<br />
DB2<br />
SAP 2.0<br />
FI System<br />
Billing<br />
System<br />
Siebel<br />
System<br />
C++<br />
Archive<br />
System<br />
C<br />
FTP<br />
SAP R3<br />
CO System<br />
Mail Server<br />
HTTP<br />
Siebel<br />
System FI<br />
Java<br />
Banking<br />
Software<br />
Java<br />
TCP-IP<br />
RMI<br />
SAP R3<br />
MM System<br />
Billing<br />
System 2<br />
Web<br />
Frontend<br />
Java<br />
Cobol<br />
Intercompany<br />
Module<br />
C++<br />
Sub-Tochter (eigenes Intranet)<br />
SAP<br />
Netweaver<br />
BI Solution<br />
HTTP<br />
SAP R3<br />
System FI<br />
Workflow<br />
System<br />
C<br />
External Partner<br />
(Bank)<br />
Banking<br />
Software<br />
External Partner<br />
(Kun<strong>de</strong>)<br />
CR<br />
Software<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 18
Ziel einer verteilten Architektur aus Unternehmenssicht<br />
<br />
Ziel einer verteilten Architektur aus Unternehmenssicht: IT-seitige<br />
Unterstützung von (möglichst vielen!) Geschäftsabläufen:<br />
Integration einzelner Tätigkeiten wie Buchungen, Archivierung von Daten,<br />
Weiterleitung von Dokumenten und Arbeitsanweisungen, Verifikation ...<br />
<br />
Ansatz SOA:<br />
<br />
<br />
Kapselung von bestehen<strong>de</strong>n (technischen) Applikationen durch (fachlich<br />
<strong>de</strong>finierte) <strong>Service</strong>s<br />
Formulierung von höherwertigen Geschäftsprozessen auf Basis von<br />
fachlichen <strong>Service</strong>s<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 19
Ziel: Flexible Integration <strong>de</strong>r verschie<strong>de</strong>nen Subsysteme<br />
über fachlich <strong>de</strong>finierte <strong>Service</strong>s und Prozesse<br />
Business Processes<br />
(IT-unterstützte<br />
Geschäftsprozesse)<br />
Prozess „Archivierung von<br />
Rechnungen“<br />
Business <strong>Service</strong>s (Geschäftsfunktionen, fachliche <strong>Service</strong>s)<br />
<strong>Service</strong> „Pflege von Rechnungen“<br />
<strong>Service</strong> „CRM“<br />
„Archiv“ <strong>Service</strong><br />
PDF : printInvoice( Invoice) Invoice: getInvoice( Client ) removeClient( ID ) getClient( ID )<br />
savePDF( pdf)<br />
Applikationen<br />
(Alt-Systeme, Legacy)<br />
SAP 2.0<br />
FI System<br />
SAP R3<br />
CO System<br />
Sub-Tochter (eignes Intranet)<br />
SAP<br />
Netweaver<br />
Oracle<br />
Siebel<br />
System<br />
Siebel<br />
System FI<br />
SAP R3<br />
MM System<br />
SAP R3<br />
System FI<br />
Mail Server<br />
Web<br />
Frontend<br />
Billing<br />
System<br />
CRM-Solution<br />
DB2<br />
Risk<br />
System<br />
Banking<br />
Software<br />
Billing<br />
System 2<br />
Archiv<br />
System<br />
Intercompany<br />
Module<br />
External Partner<br />
(Bank)<br />
Banking<br />
Software<br />
External Partner<br />
(Kun<strong>de</strong>)<br />
CR<br />
Software<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010<br />
Folie 20
Ziel: Flexible Integration <strong>de</strong>r verschie<strong>de</strong>nen Subsysteme<br />
über fachlich <strong>de</strong>finierte <strong>Service</strong>s und Prozesse<br />
Benutzerinterfaces (User Interfaces)<br />
IT-unterstützte<br />
Geschäftsprozesse<br />
(Business Processes)<br />
Prozess „Archivierung von<br />
Rechnungen“<br />
Fachliche <strong>Service</strong>s (Business <strong>Service</strong>s)<br />
„SAP FI“ <strong>Service</strong><br />
„CR“ <strong>Service</strong><br />
„Archiv“ <strong>Service</strong><br />
PDF : printInvoice( Invoice) Invoice: getInvoice( Client ) removeClient( ID ) getClient( ID )<br />
savePDF( pdf)<br />
Applikationen<br />
(Alt-Systeme, Legacy)<br />
SAP 2.0<br />
FI System<br />
SAP R3<br />
CO System<br />
Sub-Tochter (eignes Intranet)<br />
SAP<br />
Netweaver<br />
Oracle<br />
Siebel<br />
System<br />
Siebel<br />
System FI<br />
SAP R3<br />
MM System<br />
SAP R3<br />
System FI<br />
...<br />
Web<br />
Frontend<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010
Komponenten- und Domänensicht nach Hess<br />
Interaktionskomponenten<br />
Prozesskomponenten<br />
Prozess „Archivierung von<br />
Rechnungen“<br />
Funktionskomponenten<br />
„SAP FI“ <strong>Service</strong><br />
„CR“ <strong>Service</strong><br />
„Archiv“ <strong>Service</strong><br />
„SAP FI“ Komponente „CR Komponente “<br />
PDF : printInvoice( Invoice) Invoice: getInvoice( Client ) removeClient( ID ) getClient( ID )<br />
„Archiv“<br />
Komponente<br />
savePDF( pdf)<br />
Bestandskomponenten<br />
(Alt-Systeme, Legacy)<br />
SAP 2.0<br />
FI System<br />
SAP R3<br />
CO System<br />
Sub-Tochter (eignes Intranet)<br />
SAP<br />
Netweaver<br />
Oracle<br />
Siebel<br />
System<br />
Siebel<br />
System FI<br />
SAP R3<br />
MM System<br />
SAP R3<br />
System FI<br />
...<br />
Web<br />
Frontend<br />
Domäne 1<br />
Domäne n<br />
Prof. Dr. <strong>Sascha</strong> Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010
Change language