Contenu connexe Similaire à SOA in Kundenprojekten (20) SOA in Kundenprojekten2. Copyright © Capgemini 2013. All Rights Reserved
2SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
3. www.capgemini.com
Über Capgemini
Mit 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
4. Über mich
Copyright © Capgemini 2013. All Rights Reserved
4SOA in Kundenprojekten.pptx
• 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
5. Allgemeines zum Vortrag
Copyright © Capgemini 2013. All Rights Reserved
5SOA in Kundenprojekten.pptx
• 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
6. Dieser Vortrag auf Slide Share
Copyright © Capgemini 2013. All Rights Reserved
6SOA in Kundenprojekten.pptx
7. Copyright © Capgemini 2013. All Rights Reserved
7SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
8. Komplexe Anwendungslandschaften heute
Copyright © Capgemini 2013. All Rights Reserved
8SOA in Kundenprojekten.pptx
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).
10. Frühere Sicht auf eine typische Anwendungslandschaft
Copyright © Capgemini 2013. All Rights Reserved
10SOA in Kundenprojekten.pptx
Bei meinen älteren Kundenprojekten, dann stand immer die Anwendung im
Mittelpunkt
11. Frühere Sicht auf eine typische Anwendungslandschaft
Copyright © Capgemini 2013. All Rights Reserved
11SOA in Kundenprojekten.pptx
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.
12. Copyright © Capgemini 2013. All Rights Reserved
12SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
13. EAI: ein Schritt in Richtung SOA
Copyright © Capgemini 2013. All Rights Reserved
13SOA in Kundenprojekten.pptx
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.
14. EAI: ein wichtiger Schritt in die Richtung SOA
Copyright © Capgemini 2013. All Rights Reserved
14SOA in Kundenprojekten.pptx
So könnte die früher erwähnte Anwendungslandschaft aussehen!
15. EAI: Der Bus
Copyright © Capgemini 2013. All Rights Reserved
15SOA in Kundenprojekten.pptx
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
16. EAI: Kommunikationsarten
Copyright © Capgemini 2013. All Rights Reserved
16SOA in Kundenprojekten.pptx
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
17. EAI: Wichtige (aber nicht alle!) Komminikationsarten
Copyright © Capgemini 2013. All Rights Reserved
17SOA in Kundenprojekten.pptx
Protokoll
Topologie
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!
18. EAI: eine einfache Austauschdatei als ESB
Copyright © Capgemini 2013. All Rights Reserved
18SOA in Kundenprojekten.pptx
19. EAI: Bus-Adapter
Copyright © Capgemini 2013. All Rights Reserved
19SOA in Kundenprojekten.pptx
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.
20. Was ist nun SOA?
Copyright © Capgemini 2013. All Rights Reserved
20SOA in Kundenprojekten.pptx
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
21. Copyright © Capgemini 2013. All Rights Reserved
21SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
24. Service: der Mittelpunkt einer SOA
Copyright © Capgemini 2013. All Rights Reserved
24SOA in Kundenprojekten.pptx
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
25. Service Domäne: Organisationsklammer für Services
Copyright © Capgemini 2013. All Rights Reserved
25SOA in Kundenprojekten.pptx
... 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.
27. SOA: Service Registry
Copyright © Capgemini 2013. All Rights Reserved
27SOA in Kundenprojekten.pptx
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.
28. SOA: Service Registry, Beispiel
Copyright © Capgemini 2013. All Rights Reserved
28SOA in Kundenprojekten.pptx
30. SOA: Wie komme ich zu einem Service?
Copyright © Capgemini 2013. All Rights Reserved
30SOA in Kundenprojekten.pptx
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
31. SOA: Eine Anwendung -> mehrere Services
Copyright © Capgemini 2013. All Rights Reserved
31SOA in Kundenprojekten.pptx
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.
32. SOA: Komposition mehrerer Anwendungen
Copyright © Capgemini 2013. All Rights Reserved
32SOA in Kundenprojekten.pptx
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
33. SOA: Kombination bestehender Services
Copyright © Capgemini 2013. All Rights Reserved
33SOA in Kundenprojekten.pptx
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
34. Hauptakteure: Service Provider und Consumer
Copyright © Capgemini 2013. All Rights Reserved
34SOA in Kundenprojekten.pptx
Der Schritt find entfällt oft, da die Services des Unternehmens den Service-Consumern
bekannt sind.
35. SOA: Service Provider und Consumer
Copyright © Capgemini 2013. All Rights Reserved
35SOA in Kundenprojekten.pptx
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
36. SOA: Was wurde versprochen?
Copyright © Capgemini 2013. All Rights Reserved
36SOA in Kundenprojekten.pptx
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…
37. SOA: Was wurde versprochen?
Copyright © Capgemini 2013. All Rights Reserved
37SOA in Kundenprojekten.pptx
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
38. SOA: Schwierigkeiten in der Praxis beachten
Copyright © Capgemini 2013. All Rights Reserved
38SOA in Kundenprojekten.pptx
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?
39. Copyright © Capgemini 2013. All Rights Reserved
39SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
40. Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
40SOA in Kundenprojekten.pptx
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.
41. Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
41SOA in Kundenprojekten.pptx
42. Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
42SOA in Kundenprojekten.pptx
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.
43. Beispiel: Service = Anwendung
Copyright © Capgemini 2013. All Rights Reserved
43SOA in Kundenprojekten.pptx
44. Beispiel: „Durchschleuser“
Copyright © Capgemini 2013. All Rights Reserved
44SOA in Kundenprojekten.pptx
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!
46. Beispiel: „Durchschleuser“
Copyright © Capgemini 2013. All Rights Reserved
46SOA in Kundenprojekten.pptx
Besser ist eine Implementierung in eigener Domäne bspw. mit Hilfe eines BPM-Tools .
Voraussetzung: ESB ermöglicht allen Domänen Zugriff auf Webservices
47. Beispiel: ein zu „schlauer“ Service Provider
Copyright © Capgemini 2013. All Rights Reserved
47SOA in Kundenprojekten.pptx
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
48. Beispiel: ein zu „schlauer“ Service Provider
Copyright © Capgemini 2013. All Rights Reserved
48SOA in Kundenprojekten.pptx
49. Beispiel: ein zu „schlauer“ Service Provider
Copyright © Capgemini 2013. All Rights Reserved
49SOA in Kundenprojekten.pptx
Besser ist auch hier eine Implementierung in eigener Domäne.
Vgl mit „Service=Anwendung“
50. Beispiel: Zeit-Cache
Copyright © Capgemini 2013. All Rights Reserved
50SOA in Kundenprojekten.pptx
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.
52. Beispiel: Zeit-Cache
Copyright © Capgemini 2013. All Rights Reserved
52SOA in Kundenprojekten.pptx
Besser ist hier eine Nutzung der pub/sub-Notification.
Deswegen wichtig, das pub/sub vom ESB unterstützt ist.
53. Beispiele: Zusammenfassende Tipps
Copyright © Capgemini 2013. All Rights Reserved
53SOA in Kundenprojekten.pptx
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.
54. Eine Service Operation ist:
Copyright © Capgemini 2013. All Rights Reserved
54SOA in Kundenprojekten.pptx
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)
55. Beispiel Idempotenz:
Copyright © Capgemini 2013. All Rights Reserved
55SOA in Kundenprojekten.pptx
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.
57. Beispiel Idempotenz:
Copyright © Capgemini 2013. All Rights Reserved
57SOA in Kundenprojekten.pptx
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.
58. Idempotenz: Allgemeines
Copyright © Capgemini 2013. All Rights Reserved
58SOA in Kundenprojekten.pptx
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…
59. Idempotenz: In der Praxis
Copyright © Capgemini 2013. All Rights Reserved
59SOA in Kundenprojekten.pptx
… 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.
60. Copyright © Capgemini 2013. All Rights Reserved
60SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
61. SOA: Was ist der Schlüssel zum Erfolg und die
Schwachstellen?
Copyright © Capgemini 2013. All Rights Reserved
61SOA in Kundenprojekten.pptx
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.
62. Was kommt als Nächstes?
Copyright © Capgemini 2013. All Rights Reserved
62SOA in Kundenprojekten.pptx
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
63. Was kommt als Nächstes?
Copyright © Capgemini 2013. All Rights Reserved
63SOA in Kundenprojekten.pptx
64. Was kommt als Nächstes?
Copyright © Capgemini 2013. All Rights Reserved
64SOA in Kundenprojekten.pptx
65. Copyright © Capgemini 2013. All Rights Reserved
65SOA in Kundenprojekten.pptx
Agenda
Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Wie geht es weiter?
Fragen Fragen
66. Danke für Ihre Aufmerksamkeit!
Copyright © Capgemini 2013. All Rights Reserved
66SOA in Kundenprojekten.pptx
67. Literatur
Copyright © Capgemini 2013. All Rights Reserved
67SOA in Kundenprojekten.pptx
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
68. Contact information
Copyright © Capgemini 2013. All Rights Reserved
68SOA in Kundenprojekten.pptx
Jewgenij
Moldawski
yevgen.moldawski@capgemini.com
Capgemini Office Troisdorf
Mülheimer Str. 9a
53840 Troisdorf
Insert
contact
picture