soa in kundenprojekten
Post on 07-Dec-2014
374 Views
Preview:
DESCRIPTION
TRANSCRIPT
SOA in Kundenprojekten
Sankt Augustin, 21.05.2014, Jewgenij Moldawski
2SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
www.capgemini.com
Über CapgeminiMit rund 120.000 Mitarbeitern in 40 Ländern ist Capgemini einer der weltweit führenden Anbieter von Management- und IT-Beratung, Technologie-Services sowie Outsourcing-Dienst-leistungen. Im Jahr 2011 betrug der Umsatz der Capgemini-Gruppe 9,7 Milliarden Euro.
Gemeinsam mit seinen Kunden erstellt Capgemini Geschäfts- wie auch Technologielösungen, die passgenau auf die individuellen Anforderungen zugeschnitten sind. Auf der Grundlage seines weltweiten Liefermodells Rightshore® zeichnet sich Capgemini als multinationale Organisation durch seine besondere Art der Zusammenarbeit aus – die Collaborative Business ExperienceTM.
Rightshore® ist eine eingetragene Marke von Capgemini
Die in der Präsentation enthaltenen Informationen sind Eigentum.Copyright © 2013 Capgemini. Alle Rechte vorbehalten.
Kurzvorstellung Capgemini
4SOA in Kundenprojekten.pptx
Über mich
Copyright © Capgemini 2013. All Rights Reserved
• Jahrgang 1971
• Studierte Informatik an der Nationalen Technischen Universität in Kiew, Ukraine
• Seit 1997 bei Capgemini, ehemals sd&m.
• Kunden Telko, Krankenversicherung, Logistik, Bundesbehörden
• Aufgaben: technisches Design, Implementierung, Wartung, generell technische Themen
• Schwerpunkte: Datenbaken, Performancetuning, Server-Programmierung, Java, SOA
• https://www.xing.com/profile/Jewgenij_Moldawski
5SOA in Kundenprojekten.pptx
Allgemeines zum Vortrag
Copyright © Capgemini 2013. All Rights Reserved
• Dieser Vortrag basiert auf meiner persönlichen Erfahrung aus den großen Software-Projekten, an denen ich mit gearbeitet hatte
• Ich versuche, die wichtigen Begriffe so zu verwenden, wie sie in Büchern und im Web verwendet werden.
• Alle Beispiele sind real, ich habe sie allerdings „anonymisiert“
• Ich habe mich bei den Grafiken an die BMPN-Notation gehalten [BPMN], und die Grafiken mit Microsoft Office Visio und einer BPMN-Vorlage erstellt.
• Ich bitte Sie, Fragen direkt zu stellen. Ich werde sie dann entweder sofort oder am Ende beantworten. Auch gerne im später per Mail
6SOA in Kundenprojekten.pptx
Dieser Vortrag auf Slide Share
Copyright © Capgemini 2013. All Rights Reserved
7SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
8SOA in Kundenprojekten.pptx
Komplexe Anwendungslandschaften heute
Copyright © Capgemini 2013. All Rights Reserved
Große und mittlere Unternahmen betreiben seit Jahren große Anzahl der EDV-Anwendungen. Dabei sind 3-stellige Anwendungszahlen keine Seltenheit.
Diese Anwendungen wurden meistens seit Jahrzenten weiterentwickelt:• Sie verwenden verschiedene Techniken• Sie wurden in den unterschiedlichen „EDV-Zeitaltern“ entwickelt• Sie werden unterschiedlich gut gewartet und haben verschiedene Wartungszyklen• Sie laufen auf verschiedenen Plattformen
Die meisten Anwendungen kommunizieren mit den internen Anwendern, untereinander, mit den externen Anwendern (B2C) und externen Anwendungen (B2B).
9SOA in Kundenprojekten.pptx
Komplexe Anwendungslandschaften heute
Copyright © Capgemini 2013. All Rights Reserved
10SOA in Kundenprojekten.pptx
Frühere Sicht auf eine typische Anwendungslandschaft
Copyright © Capgemini 2013. All Rights Reserved
Bei meinen älteren Kundenprojekten, dann stand immer die Anwendung im Mittelpunkt
11SOA in Kundenprojekten.pptx
Frühere Sicht auf eine typische Anwendungslandschaft
Copyright © Capgemini 2013. All Rights Reserved
Der Kunde hat mehrere Anwendungen, die sein Business unterstützen.
Der Ablauf jeder einzelnen Anwendung wird entweder durch den Benutzer oder durch die Hintergrundprozesse (Batches) bestimmt.
Anwendungen tauschen untereinander Daten aus. Das Client/Server war damals das gängige Model, um diesen Austausch zu beschreiben
Dabei kommen verschiedene Protokolle FTP, HTTP, (schon) SOAP … und Datenformate ASCII, (schon) XML, HTML usw. zum Einsatz.
Jede Anwendung hat:• Eine zuständige Fachabteilung • Ein Entwicklerteam (oder auch nicht)• Einen Support• usw.
12SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
13SOA in Kundenprojekten.pptx
EAI: ein Schritt in Richtung SOA
Copyright © Capgemini 2013. All Rights Reserved
Viele Kunden haben festgestellt, dass die IT-Anwendungen und vor allem ihre Vernetzung, das Business inzwischen nicht nur unterstützen, sondern auch bestimmen. Diese Erkenntnis förderte eine verstärkte Vernetzung einzelner Anwendungen.
Um dabei nicht die Kommunikation für jedes Anwendungspaar neu zu regeln, wurde das Bus-Konzept angewandt, was das wesentlich Bestandteil der EAI darstellt:• Die Anwendungen tauchen Nachrichten mit Hilfe einer zentralen Komponente (Bus)
aus.• Jede Anwendung ist durch spezifische Adapter mit dem Bus verbunden.
Alle große SW-Hersteller haben Busse und Adapter für Standardanwendungen angeboten. Einige unserer Kunden haben jedoch auch eigene Implementierungen eingesetzt.
Wichtig: bei den EAI-Konzepten bleiben die Anwendungen weiterhin im Mittelpunkt.
14SOA in Kundenprojekten.pptx
EAI: ein wichtiger Schritt in die Richtung SOA
Copyright © Capgemini 2013. All Rights Reserved
So könnte die früher erwähnte Anwendungslandschaft aussehen!
15SOA in Kundenprojekten.pptx
EAI: Der Bus
Copyright © Capgemini 2013. All Rights Reserved
Sorgt für die Adressierung und für den Transport der Daten zwischen den Anwendungen
Unterstützt verschiedene Kommunikationsarten
Transformiert die Datenformate (z.B XML->ASCII)
Unterstützt die Bus-Adapter
Bietet Transaktion-Services (mit Unterstützung durch die teilnehmende Anwendungen): z.B. wird die Übertragung allen oder keinem Adressaten bestätigt.
Bietet Infrastruktur-Services an, wie Monitoring, Archivierung usw.
Der Bus kann reell oder virtuell sein -> später
16SOA in Kundenprojekten.pptx
EAI: Kommunikationsarten
Copyright © Capgemini 2013. All Rights Reserved
In den Zeiten vor der EAI war die Kommunikation zwischen den Anwendungen eine Nebenerscheinung, die irgendwie sinnvoll stattfinden sollte.
EAI stellt die Kommunikation an sich stärker in den Fokus. Ein wichtiger Aspekt dabei sind die Kommunikationsarten.
Die gängige Kommunikationsarten kann man beschreiben durch:
• ihre Topologie: Wie viele Sender/Empfänger sind an einer Kommunikation beteiligt• ihr Protokoll: Wer fängt an, gibt es immer einer Antwort, eine Empfangsbestätigung
usw.• ihr Modus: synchron oder asynchron
17SOA in Kundenprojekten.pptx
EAI: Wichtige (aber nicht alle!) Komminikationsarten
Copyright © Capgemini 2013. All Rights Reserved
ProtokollTopologie
Requst-Response
Fire-and-Forget oder One-Way Pub/Sub
Point-to-Point Beispiel? FILO schickt Umsätze des letzten Monats zum ARCHIV
Beispiel?
Point-to-Multipoint Beispiel? Beispiel Beispiel?
Hausaufgabe! Ergänzt bitte fehlende Beispiele. Tipp: Denkt dabei an bekannte Internet-Dienste sowie an die Social Media.
Wichtige Protokolle: Request/Response One-Way Pub/Sub
Wichtige Topologien: Point-to-Point Point-to-Multipoint
Zusammen mit Modi synchron und asynchron ergibt es rein rechnerisch:
3x2x2=12 Kommunikationsarten Nicht alle von Ihnen sind allerdings
sinnvoll.
Die Lösungen bitte per Mail an mich. Die erste Lösung wird mit einem kleinen Geschenk prämiert!
18SOA in Kundenprojekten.pptx
EAI: eine einfache Austauschdatei als ESB
Copyright © Capgemini 2013. All Rights Reserved
19SOA in Kundenprojekten.pptx
EAI: Bus-Adapter
Copyright © Capgemini 2013. All Rights Reserved
Die Bus-Adapter vermitteln entweder zwischen den Anwendungen und dem Bus (reeler Bus) oder direkt zwischen den Anwendungen (virtueller Bus). Der virtuelle Bus ist vollständig durch die Adapter implementiert, ein reeller Bus hat außerdem eigene Prozesse.
Sie sorgen für die passende Protokolle und Datenformate
Sie unterstützen verschiedene Kommunikationsarten
Ausgereifte EAI-Produkte bringen viele fertige Adapter für Standard-Anwendungen wie SAP, Oracle, usw. oder für Datenquellen wie ODBC, SQL Net, XLS, usw. mit.
Für die Anbindung der älteren bzw. individuellen Anwendungen stehen Toolkits zur Verfügung.
20SOA in Kundenprojekten.pptx
Was ist nun SOA?
Copyright © Capgemini 2013. All Rights Reserved
Fachliche Konzepte (Domänen, Services, Geschäftsprozesse)
Technische Konzepte (ESB, Service Registry, EAI)
Management Konzepte (SLAs, unternehmensweite Einführung, Konflikte)
Produkte und Werkzeuge
Im Fokus der Betrachtung steht der Service
21SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
22SOA in Kundenprojekten.pptx
Warum SOA?
Copyright © Capgemini 2013. All Rights Reserved
Warum SOA?
23SOA in Kundenprojekten.pptx
SOA: Serviceorientierte Architektur
Copyright © Capgemini 2013. All Rights Reserved
24SOA in Kundenprojekten.pptx
Service: der Mittelpunkt einer SOA
Copyright © Capgemini 2013. All Rights Reserved
Ein Service beschreibt eine DV-Funktion aus fachlicher Sicht, z.B. „Rechnungsverwaltung“
Ein gut konzipierter Service ist ein eindeutig: es gibt z.B. keine zweite „Rechnungsverwaltung“.
Ein Service ist verschiedenen fachlichen Abläufen verwendbar, z.B. kann sowohl ein Online-Portal, als auch CRM die „Rechnungsverwaltung“ nutzen.
Ein Service wird von mindestens einer, oft aber mehreren Anwendung, (genannt Service Provider) implementiert. Es können mehrere Service Provider für einen Service, z. B. für „Rechnungsverwaltung“ geben.
Ein Service wird von anderen Anwendungen (genannt Service Consumer) genutzt
Ein Service bietet mehrere Service Operationen
25SOA in Kundenprojekten.pptx
Service Domäne: Organisationsklammer für Services
Copyright © Capgemini 2013. All Rights Reserved
... entspricht oft einer Organisationseinheit (z.B. einer Fachabteilung)
… „besitzt“ bestimmte Datenarten, z. B. Kundenstammdaten. Sie ähnelt dabei der Domäne im etwas altmodischen Konzept des „Enterprise Data Model“
… bietet mehrere Services an, die fachlich zusammengehören, z.B. kann die Domäne „Kunden“ die Services „Kundenkarten“ und „CRM“ anbieten
… stellt im Bezug auf diese Datenarten und Services ein „Single Point of Truth“ dar: Anwendungen müssen entsprechende Datenarten (in unserem Beispiel Kundenstammdaten) über die Services dieser Domäne beziehen oder zumindest dagegen abgleichen. Die Festlegung der Single Points of Truth birgt oft ein großes Konfliktpotential und muss deswegen sorgsam durchgeführt werden.
26SOA in Kundenprojekten.pptx
Domäne: Organisationsklammer
Copyright © Capgemini 2013. All Rights Reserved
Die Formen der dicken Pfeile stellen die Kommunikationsarten dar
27SOA in Kundenprojekten.pptx
SOA: Service Registry
Copyright © Capgemini 2013. All Rights Reserved
Das Service Registry ist die zentrale Komponente einer SOA
Das Service Registry:• sorgt für sogen. lose Kopplung der Services. Es ist zwar möglich ein SOA ohne Service
Registry zu haben, wenn man auf lose Kopplung verzichten wil• speichert Informationen über Services• registriert Service Providers• stellt find und lookup Operationen bereit
Ähnlich wie DNS ist das Service Registry ist ein absoluter „Single Point Of Failure“ und muss daher gegen Ausfälle und gegen Angriffe geschützt werden.
Meistens ist das Service Registry redundant ausgelegt.
28SOA in Kundenprojekten.pptx
SOA: Service Registry, Beispiel
Copyright © Capgemini 2013. All Rights Reserved
29SOA in Kundenprojekten.pptx
SOA: Übersicht wichtiger Begriffe
Copyright © Capgemini 2013. All Rights Reserved
30SOA in Kundenprojekten.pptx
SOA: Wie komme ich zu einem Service?
Copyright © Capgemini 2013. All Rights Reserved
Bei der SOA spricht man nicht mehr über Anwendungs- sondern über die Service-Landschaften.
Ein Aufbau der Service-Landschaft erfolgt selten auf der „grünen Wiese“: meistens hat der Kunde schon Anwendungen im Betrieb und möchte eine Service-Landschaft „einziehen“.
Folgende Varianten sind oft anzutreffen:• bestehende Anwendung = ein Service = Service Provider• bestehende Anwendung = ein Service Provider = mehrere Services (häufiger Fall)• mehrere bestehende Anwendungen (oder Services) = ein Service (BPM-Ansatz)• erweiterte Anwendung -> neuer Service
31SOA in Kundenprojekten.pptx
SOA: Eine Anwendung -> mehrere Services
Copyright © Capgemini 2013. All Rights Reserved
Oft implementiert eine Anwendung einen „lesenden“ und einen „schreibenden“ Service:
Vorteile: diese Servicearten haben oft jeweils verschiedene Anforderungen an Sicherheit, Performanz, generell an NFA. So lassen sich diese Unterschiede schon auf der Service-Ebene definieren.
32SOA in Kundenprojekten.pptx
SOA: Komposition mehrerer Anwendungen
Copyright © Capgemini 2013. All Rights Reserved
Ein Service wird von einer „zwischen“-Anwendung implementiert, die je nach Daten (hier: Produkt) auf verschiedene Anwendungen weiterleitet.
Vorteil: Der Aufruf ist für den Service Consumer unabhängig vom Produkt-> Wiederverwendbarkeit.
Ein BPM - Ansatz
33SOA in Kundenprojekten.pptx
SOA: Kombination bestehender Services
Copyright © Capgemini 2013. All Rights Reserved
Ein Service wird von einer „zwischen“-Anwendung implementiert, die bestehenden Services um eine fachliche Logik (hierWarteschleife) erweitert.
Vorteil: Die Services müssen nicht geändert werden. Nachteil: Die Fachlichkeit wird „fremd“ implementiert: die Zwischenanwendung muss das
Statusmodel des Auftrags kennen. Ebenso ein BPM - Ansatz
34SOA in Kundenprojekten.pptx
Hauptakteure: Service Provider und Consumer
Copyright © Capgemini 2013. All Rights Reserved
Der Schritt find entfällt oft, da die Services des Unternehmens den Service-Consumern bekannt sind.
35SOA in Kundenprojekten.pptx
SOA: Service Provider und Consumer
Copyright © Capgemini 2013. All Rights Reserved
Der Service Provider:• verbindet sich mit ESB durch den bind-Aufruf• wird nicht direkt sondern unter der Vermittlung des ESB aufgerufen: call• Verschiedene Service Provider können verschiedene SLAs erfüllen.
Der Service Consumer:• sucht den passenden Service durch den find-Aufruf• verbindet sich über ESB mit einem passenden Service Provider durch den bind-Aufruf.• ruft den Service auf, nicht direkt den Service Provider ->lose Kopplung
Das Service Registry:• ist in diesem Beispiel auch ein (technischer) Service• stellt die lookup Service Operation zur Verfügung
36SOA in Kundenprojekten.pptx
SOA: Was wurde versprochen?
Copyright © Capgemini 2013. All Rights Reserved
Den Fachabteilungen in den Unternehmen:
• Guten Überblick über bestehende Services• Wiederverwendbare Services• Konzentration auf die Entwicklung fachlich motivierter Services, statt schwer zu
überblickenden Anwendungen.• Schnellere Entwicklung neuer Services aus bestehenden (BPM). • Eine bessere Kontrolle über Services, während bei Anwendungen andere „fachfremde“
mitreden und es außerdem enge Rahmenbedingungen gibt• Einen „festen“ Platz (Domäne) in der Service-Landschaft.• Services als eine „Sprache“ für den Austausch zwischen den Fachabteilungen• Lösung des Wiederspruchs „Stabile Anwendungen vs. Flexible Prozesse“
und…
37SOA in Kundenprojekten.pptx
SOA: Was wurde versprochen?
Copyright © Capgemini 2013. All Rights Reserved
Der IT-Abteilung:• Neues modernes Konzept, neue Werkzeuge • Bessere Wartbarkeit und die SLA-Kontrolle durch die lose Kopplung
Dem gesamten Unternehmen Kostenreduzierung durch z.B. – Wiederverwendung eigener Services – Nutzung der Fremdservices, – Verwendung des standard ESB
38SOA in Kundenprojekten.pptx
SOA: Schwierigkeiten in der Praxis beachten
Copyright © Capgemini 2013. All Rights Reserved
Fachabteilungen:• Fremden Services wird oft misstraut• Die Änderungswünsche anderer Domänen werden nicht schnell genug berücksichtigt,
weil z.B. Fachbereiche um Budgets streiten.• Durch Reorganisationen des Unternehmens entfernt sich die Realität von der Service-
Landschaft
IT-Abteilung:• ESB könnte zu einem weiteren „Single Point of Failure“ werden.
Management:• Wenn die SOA-“Supporter“ nicht mehr aktiv sind, kann SOA schnell zu einem reinen
Kostenfaktor degradiert werden.• SOA kann Konflikte aufzeigen. Z.B. stellt sich heraus, dass es zwei Service Provider
mit einer fast gleichen Funktion existieren: wer soll überleben?
39SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
40SOA in Kundenprojekten.pptx
Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
Ein neuer Service „Bankverbindung“ muss entwickelt werden. Dieser Service muss eine Bankverbindung überprüfen und ggf. den Banknamen ermitteln können.
Es existiert bereits eine Anwendung, die folgende Funktionen hat und intern nutzt:• Überprüfung der BLZ• Überprüfung der Kontonummer• Ermittlung des Banknamen
Das Team, das diese Anwendung betreut, wurde beauftragt, sie als Service anzubieten. Im Ergebnis bildet der Service diese Anwendung nach: die entworfenen Service Operationen entsprechen den Anwendungsfunktionen.
41SOA in Kundenprojekten.pptx
Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
42SOA in Kundenprojekten.pptx
Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
Die Benutzung des Services ist jedoch unbequem, da die Service Consumer immer alle drei Service Operationen nach einander aufrufen müssen und diese Aufrufe durch eine Geschäftslogik zu verbinden.
Nach ersten Erfahrungen stellt sich heraus, dass der Service zwar alle notwendigen Informationen liefert, aber zu „feingranular“ ist: alle Service Consumer wünschen sich eine Service Operation, die sowohl die Prüfung als auch die Ermittlung des Banknamen durchführt.
Da der Service Provider auch in diesem Fall nicht geändert werden darf, werden die bereits bestehenden Service Operationen zu einer neuen Operation „Bankverbindung validieren “ zusammen gefügt *.
* Diese Lösung wurde am Ende doch aus organisatorischen Gründen verworfen.
43SOA in Kundenprojekten.pptx
Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
44SOA in Kundenprojekten.pptx
Beispiel: „Durchschleuser“
Copyright © Capgemini 2013. All Rights Reserved
Für die Domäne „Versand“ muss ein Service „Tracking & Tracing“ erstellt werden, der den aktuellen Standort einer Sendung ermittelt. Die Daten können aus den öffentlichen Webservices im Internet ermittelt werden, die Paketdienste anbieten.
Dabei müssen unterschiedliche Datenformate zusammen geführt werden
In der Domäne „Versand“ gibt es bisher keine Anwendung, die so erweitert werden kann, dass sie diesen Service implementieren könnte. Eine Entwicklung der neuen Anwendung ist zu teuer.
Der Service Provider AUFTAKT aus einer anderen Domäne kann bereits auf Webservices zugreifen und wird um die Implementierung des Dienstes „Tracking & Tracing“ erweitert.
Nachteil: für die Logik ist nun „fremde“ Domäne zuständig!
45SOA in Kundenprojekten.pptx
Beispiel: „Durchschleuser“
Copyright © Capgemini 2013. All Rights Reserved
46SOA in Kundenprojekten.pptx
Beispiel: „Durchschleuser“
Copyright © Capgemini 2013. All Rights Reserved
Besser ist eine Implementierung in eigener Domäne bspw. mit Hilfe eines BPM-Tools . Voraussetzung: ESB ermöglicht allen Domänen Zugriff auf Webservices
47SOA in Kundenprojekten.pptx
Beispiel: ein zu „schlauer“ Service Provider
Copyright © Capgemini 2013. All Rights Reserved
Für die Domäne „Filiale“ muss der Service „Verkauf am Schalter“ konzipiert und implementiert werden. Unter anderem müssen daraus Aufträge für die Produktion erstellt werden.
Die Geschäftslogik besteht ursprünglich darin, dass je nach gekauftem Produkt entweder neue Aufträge erstellt werden oder laufende „Daueraufträge“ ergänzt werden.
Für die Erstellung der Aufträge wird der Service „Verwaltung“ der Domäne „Aufträge“ um diese Geschäftslogik erweitert.
Nachteil: Die Geschäftslogik erwies sich doch als komplexer, da nicht nur das Produkt, sondern auch die gekaufte Menge eine Rolle spielt. Dies ist den Zuständigen der Domäne „Aufträge“ bis zur Implementierung nicht bekannt. Der Service Provider AUFTAKT muss noch einmal entsprechend geändert werden. Die Zuständigen für die Domäne „Filialen“ müssen beteiligt werden
48SOA in Kundenprojekten.pptx
Beispiel: ein zu „schlauer“ Service Provider
Copyright © Capgemini 2013. All Rights Reserved
49SOA in Kundenprojekten.pptx
Beispiel: ein zu „schlauer“ Service Provider
Copyright © Capgemini 2013. All Rights Reserved
Besser ist auch hier eine Implementierung in eigener Domäne. Vgl mit „Service=Anwendung“
50SOA in Kundenprojekten.pptx
Beispiel: Zeit-Cache
Copyright © Capgemini 2013. All Rights Reserved
Die Services der Domäne „Kunde“ fallen oft technisch bedingt aus. Um diese Ausfälle zu überbrücken hat der Service Provider FILO ein Kunden-Cache eingerichtet.
Fällt der „Kunden“-Service aus, so prüft FILO, ob die notwendigen Kundendaten im Cache nicht älter als N Stunden sind und nutzt sie dann.
Nachteil: ist N niedrig, so ist die Wahrscheinlichkeit, die notwendigen Daten im Cache zu treffen gering, ist N hingegen hoch, so steigt die Wahrscheinlichkeit, auf inzwischen veränderten Daten zu stoßen.
Bessere Lösung: Nutzung der pub/sub-Operation „Kunde geändert“. Dadurch kann der Service Provider FILO den Cache genau dann aktualisieren, wenn sich die Kundendaten geändert haben.
51SOA in Kundenprojekten.pptx
Beispiel: Zeit-Cache
Copyright © Capgemini 2013. All Rights Reserved
52SOA in Kundenprojekten.pptx
Beispiel: Zeit-Cache
Copyright © Capgemini 2013. All Rights Reserved
Besser ist hier eine Nutzung der pub/sub-Notification. Deswegen wichtig, das pub/sub vom ESB unterstützt ist.
53SOA in Kundenprojekten.pptx
Beispiele: Zusammenfassende Tipps
Copyright © Capgemini 2013. All Rights Reserved
Folgende Punkte sollte beim Implementieren der Services beachtet werden:
1. Implementiere immer nur die Logik, die zu Deiner Domäne gehört
2. Mache die Services genau möglichst „schlau“, wie es dem Punk 1 nicht wiederspricht
3. Verwende immer die passende Kommunikationsarten, wähle einen ESB, die diese Kommunikationsarten anbietet, programmiere sie nicht nach.
54SOA in Kundenprojekten.pptx
Eine Service Operation ist:
Copyright © Capgemini 2013. All Rights Reserved
Fachlich motiviert:• Auftrag anlegen• Kunden suchen• Bestellung abrechnen• Aber nicht: Kunden-Cache leeren
Grobgranular („schlau“), z.B.:• Auftragspreis berechnen• Aber nicht: MwSt für den Auftrag ermitteln
Zustandsunabhängig• Auftrag ändern• Aber nicht: letzten Auftrag ändern
Idempotent (wiederholbar)
55SOA in Kundenprojekten.pptx
Beispiel Idempotenz:
Copyright © Capgemini 2013. All Rights Reserved
Ist-Situation:• Der Service Provider der Operation „Auftrag anlegen“ ist manchmal unzuverlässig.• Es gibt keine Erfolgs-/Fehlerbestätigung (Fire-And-Forget).
Anforderung:• Eine neuer Service Operation „Auftrag erteilen“ soll für die Anlage eines Auftrages
garantieren. Eine Erweiterung des bestehenden Service Providers ist aus verschiedenen Gründen nicht möglich.
Lösung:• Es wird ein neuer Service „Produktion“ implementiert, der mit Hilfe eines Retry-
Mechanismus die temporären Ausfälle kompensiert.
56SOA in Kundenprojekten.pptx
Beispiel Idempotenz:
Copyright © Capgemini 2013. All Rights Reserved
57SOA in Kundenprojekten.pptx
Beispiel Idempotenz:
Copyright © Capgemini 2013. All Rights Reserved
Lösung im Detail:
• Der Service Provider ruft die Service Operation „Auftrag anlegen“ auf.• Da mit einem Ergebnis nicht (zuverlässig) gerechnet werden kann, fragt der Service
Provider den Service „Auftragsinformation“ ab, ob der Auftrag schon angelegt wurde• Falls der Auftrag nach 5 min. noch nicht angelegt wurde, wird die Anlage noch einmal
versucht usw.
Voraussetzungen für diese Lösung• Der die Service Operation „ Auftrag anlegen“ soll maximal einen Auftrag anlegen, wenn
sie mehrmals mit gleichen Parametern aufgerufen wird.• Insbesondere soll dies auch gelten, wenn mehrere Aufrufe sich überlappen, denn die
Auftragsanlage kann bei komplexen Aufträgen länger als 5 min dauern.• Diese Eigenschaften der Service Operation werden unter dem Begriff Idempotenz
zusammen gefasst.
58SOA in Kundenprojekten.pptx
Idempotenz: Allgemeines
Copyright © Capgemini 2013. All Rights Reserved
Der Kunstbegriff Idempotenz bezeichnet in unserem Beispiel eine Eigenschaft einer Service Operation, dass ihre mehrfache Aufrufe (mit gleichen Parametern) nicht mehr als eine Änderung am System produzieren, in unserem Beispiel nicht mehr als ein neuer Auftrag.
Manchmal findet man andere Definition, z.B., dass: „Ergebnisse aller Aufrufe ab dem zweiten sollen identisch sein“. Oder wird einfach Idempotenz gefordert.
Deswegen…
59SOA in Kundenprojekten.pptx
Idempotenz: In der Praxis
Copyright © Capgemini 2013. All Rights Reserved
… muss die Forderung der Idempotenz einer Service Operation immer konkretisiert
werden! Was ist in jedem konkreten fall gemeint?
Glücklicherweise wird die Idempotenz in der Praxis weniger streng interpretiert, z.B:• es dürfen keine doppelten Daten entstehen und/oder• es dürfen keine Nummernlücken entstehen und oder• der Auftragsstatus darf sich in der Response nicht ändern usw.
60SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
61SOA in Kundenprojekten.pptx
SOA: Was ist der Schlüssel zum Erfolg und die Schwachstellen?
Copyright © Capgemini 2013. All Rights Reserved
Der Hauptschlüssel zum Erfolg einer SOA sind die fachlichen Konzepte: je besser die Domäne und Services die Realität eines Unternehmens abbilden, desto mehr Nutzen wird man daraus ziehen können. Beispielsweise soll eine Fachabteilung für ein Service zuständig sein.
Der nächste Schlüssel ist das Management: da SOA große Teile des Unternehmens betrifft, treten oft Konflikte zwischen den Beteiligten auf, wer z.B. soll für ein Service zuständig sein? Das Management hat die Aufgabe, diese Konflikte konstruktiv zu lösen und nicht SOA an sich in Frage zu stellen.
Ein weiterer Schlüssel ist die Technik: ein ESB, dass alle Kommunikationsarten unterstützt, lädt zum Ausbau der SOA ein. Andersrum werden ein instabiler ESB oder eine langsame Service Registry, als Vorwand gegen die SOA aufgeführt.
62SOA in Kundenprojekten.pptx
Was kommt als Nächstes?
Copyright © Capgemini 2013. All Rights Reserved
EAI, SOA und BPM waren zu jeweils ihren Zeiten eindeutige Trends, sogar Hypes.
Inzwischen sind entsprechende Konzepte und Tools ausgereift und bei den Unternehmen als selbstverständlich angesehen, auch schon old-fashioned.
Interessanterweise wird der Begriff „SOA“ trotzdem bei vielen Unternehmen inzwischen nicht gern verwendet. Über die Gründe kann man lange diskutieren. Möglicherweise hat es mit den Anfangsschwierigkeiten und hohen Kosten bei Starts der SOA-Projekte zu tun. Man spricht aktuell lieber über Business Process Management, was SOA-Konzepte integriert.
* Nach Gartner
63SOA in Kundenprojekten.pptx
Was kommt als Nächstes?
Copyright © Capgemini 2013. All Rights Reserved
64SOA in Kundenprojekten.pptx
Was kommt als Nächstes?
Copyright © Capgemini 2013. All Rights Reserved
65SOA in Kundenprojekten.pptx
Copyright © Capgemini 2013. All Rights Reserved
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
66SOA in Kundenprojekten.pptx
Danke für Ihre Aufmerksamkeit!
Copyright © Capgemini 2013. All Rights Reserved
67SOA in Kundenprojekten.pptx
Literatur
Copyright © Capgemini 2013. All Rights Reserved
Beinhauer, W. u.a.: SOA für agile Unternehmen, Düsseldorf, Symposien Publishing GmbH, 2008
BPMN, http://de.wikipedia.org/wiki/Business_Process_Modeling_Notation
Hype-Zyklus, http://de.wikipedia.org/wiki/Hype-Zyklus
68SOA in Kundenprojekten.pptx
Contact information
Copyright © Capgemini 2013. All Rights Reserved
Jewgenij Moldawski
yevgen.moldawski@capgemini.com
Capgemini Office TroisdorfMülheimer Str. 9a53840 Troisdorf
Insert contact picture
top related