SOA in Kundenprojekten

935 Aufrufe

Veröffentlicht am

Anwendungslandschaften großer Unternehmen
Enterprise Application Integration
SOA: Domänen, Services und Operationen
SOA: Beispiele aus Projekten
Was kommt nach SOA?

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
935
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
14
Aktionen
Geteilt
0
Downloads
8
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

SOA in Kundenprojekten

  1. 1. SOA in Kundenprojekten Sankt Augustin, 21.05.2014, Jewgenij Moldawski
  2. 2. 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. 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. 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. 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. 6. Dieser Vortrag auf Slide Share Copyright © Capgemini 2013. All Rights Reserved 6SOA in Kundenprojekten.pptx
  7. 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. 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).
  9. 9. Komplexe Anwendungslandschaften heute Copyright © Capgemini 2013. All Rights Reserved 9SOA in Kundenprojekten.pptx
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. EAI: eine einfache Austauschdatei als ESB Copyright © Capgemini 2013. All Rights Reserved 18SOA in Kundenprojekten.pptx
  19. 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. 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. 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
  22. 22. Warum SOA? Copyright © Capgemini 2013. All Rights Reserved 22SOA in Kundenprojekten.pptx Warum SOA?
  23. 23. SOA: Serviceorientierte Architektur Copyright © Capgemini 2013. All Rights Reserved 23SOA in Kundenprojekten.pptx
  24. 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. 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.
  26. 26. Domäne: Organisationsklammer Copyright © Capgemini 2013. All Rights Reserved 26SOA in Kundenprojekten.pptx  Die Formen der dicken Pfeile stellen die Kommunikationsarten dar
  27. 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. 28. SOA: Service Registry, Beispiel Copyright © Capgemini 2013. All Rights Reserved 28SOA in Kundenprojekten.pptx
  29. 29. SOA: Übersicht wichtiger Begriffe Copyright © Capgemini 2013. All Rights Reserved 29SOA in Kundenprojekten.pptx
  30. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41. Beispiel: Service = Anwendung Copyright © Capgemini 2013. All Rights Reserved 41SOA in Kundenprojekten.pptx
  42. 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. 43. Beispiel: Service = Anwendung Copyright © Capgemini 2013. All Rights Reserved 43SOA in Kundenprojekten.pptx
  44. 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!
  45. 45. Beispiel: „Durchschleuser“ Copyright © Capgemini 2013. All Rights Reserved 45SOA in Kundenprojekten.pptx
  46. 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. 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. 48. Beispiel: ein zu „schlauer“ Service Provider Copyright © Capgemini 2013. All Rights Reserved 48SOA in Kundenprojekten.pptx
  49. 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. 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.
  51. 51. Beispiel: Zeit-Cache Copyright © Capgemini 2013. All Rights Reserved 51SOA in Kundenprojekten.pptx
  52. 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. 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. 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. 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.
  56. 56. Beispiel Idempotenz: Copyright © Capgemini 2013. All Rights Reserved 56SOA in Kundenprojekten.pptx
  57. 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. 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. 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. 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. 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. 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. 63. Was kommt als Nächstes? Copyright © Capgemini 2013. All Rights Reserved 63SOA in Kundenprojekten.pptx
  64. 64. Was kommt als Nächstes? Copyright © Capgemini 2013. All Rights Reserved 64SOA in Kundenprojekten.pptx
  65. 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. 66. Danke für Ihre Aufmerksamkeit! Copyright © Capgemini 2013. All Rights Reserved 66SOA in Kundenprojekten.pptx
  67. 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. 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

×