Pragmatic SOA - Beschränken auf das Wesentliche

2,485 views

Published on

SOA ist mittlerweile ein weit bekanntes Paradigma. Leider bleibt es oftmals zu abstrakt, um greifbar zu sein, oder es wird auf einzelne Technologien reduziert. Darüber geraten leicht die eigentlichen Ziele für den Einsatz einer SOA aus dem Blickfeld. Diese Session stellt eine pragmatische Herangehensweise bei Aufbau und Einführung einer SOA vor und geht dazu auf Theorie und Praxis ein.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,485
On SlideShare
0
From Embeds
0
Number of Embeds
31
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Pragmatic SOA - Beschränken auf das Wesentliche

  1. 1. M. Wittum | 1& 1 Internet AG D. Schmid | 1& 1 Internet AG Dr. T. Breitkopf | Netviewer AG Pragmatic SOA Beschränken auf das Wesentliche
  2. 2. Service Oriented Architecture ESB - Adapters BPM – Orchestration Registry Repository Business Services Composite Services Technical Services WSDL, SOAP, UDDI, BPEL, XML, Java, … aus www.javaworld.com SOA for the real world
  3. 3. Geht’s auch einfach?  Simplicity: Extreme Programming encourages starting with the simplest solution. Extra functionality can then be added later (XP principle related to "you ain't gonna need it" (YAGNI) approach)  In agilen Entwicklungsprozessen werden Einfachheit und Schlichtheit zu einer grundlegenden Maxime erhoben. (Kapitel 6.3.1: Das So-einfach-wie-möglich-Prinzip aus „Effektive Software- Architekturen“ - Gernot Starke)  Es gibt nicht die SOA und es gibt auch nicht das Tool für SOA … sondern nur mögliche Deutungen und mögliche Pfade, wie man eine SOA umsetzen könnte (Einführung in SOA –theserverside.de)
  4. 4. SOA - The pragmatic way Was ist Pragmatic SOA? ..... Das Wesentliche zuerst: • Schritt für Schritt vom Wesentlichen zum Add-on • eine konkrete Ausprägung auf Basis von konkreten Anforderungen • SOA-Paradigma an die Umwelt anpassen nicht umgekehrt • notfalls Verzicht auf Funktionsumfang/Flexibilität
  5. 5. SOA - The pragmatic way… …am Beispiel GEPPI (General Enterprise Process and Planning Infrastructure) Matthias Dirk Dr. Thomas Wittum Schmid Breitkopf 1&1 Internet AG 1&1 Internet AG Netviewer AG
  6. 6. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  7. 7. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  8. 8. Ausgangssituation  Beschränkte Mittel − wenig Spielraum für Kauf von Fremdprodukten  Was gibt es an Open Source? − kleines Team  Start mit 2 Entwicklern  Metaanforderungen − Schnell muss es gehen  Frühzeitige Produktivität und einfache Nutzung − Es muss in die Organisation passen  Teams müssen ohne ‚Bremse‘ eigenverantwortlich arbeiten können
  9. 9. Ausgangssituation  Heterogene IT-Landschaft − Betriebssysteme: Linux, AIX, Solaris, Windows − Unterschiedlichste Technologien:  Eigenentwicklungen und Third-Party-Software  Java, C/C++, .NET, Grails, Python, Perl, Shell, …  Anbindung bestehender Software als Service an die SOA − Mit wenig Technik-/SOA-Knowhow für die Service-Verantwortlichen durchführbar − Einfach, schnell, geringer Aufwand  Einfacher Betrieb − Wenig Detailkenntnisse erforderlich − Jedes Team betreibt die Prozesse seines Verantwortungsbereichs
  10. 10. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  11. 11. SOA-Service = Webservice?
  12. 12. SOA-Service != Webservice  Bestehende Software kennt Webservices (meist) nicht  Jede Software hat eine Laufzeitumgebung  Software ist meist auf das lokale System fokussiert  Lösung: Nicht das Programm zum Service machen, sondern die Umgebung des Programms anreichern  Lokale Schnittstelle (meist CLI)  Service-Deskriptor beschreibt diese (design by contract)  Notfalls wird ein Adapter verwendet  Ein Agent bildet die Brücke ins Netz
  13. 13. ??? Wie funktioniert das? Deskriptive, lokale Schnittstelle mit Konventionen
  14. 14. Konkret sieht das so aus…
  15. 15. Am Beispiel eines Antadapters
  16. 16. Geppi Stack so far Service = Programm + ServiceDeskriptor + (Adapter)
  17. 17. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  18. 18. (K)ein Enterprise Service Bus Aufgabe  Services müssen redundant vorhanden sein  Kompensation von Ausfällen, Wartbarkeit  Installation und Verwaltung eines Services darf nicht kompliziert sein  agiles, marktgetriebenes Anwendungsszenario erzwingt häufige Änderungen  Services sollen „lose“ gekoppelt werden  Änderungen beherrschbar machen Lösung
  19. 19. (K)ein Enterprise Service Bus Das wurde doch als Waschmaschinen Steuerung erfunden !?
  20. 20. (K)ein Enterprise Service Bus  Jini ist ein Framework und Programmiermodell zum Aufbau von service- orientierten, verteilten Anwendungen  In Jini ist alles ein Services und kann mittels Lookup an der integrierten Registry angesprochen werden  Verfügbarkeit durch Redundanz ist fester Bestandteil des Programmiermodells sucht registriert Interface Interface Implementierung Jini Jini Registry Jini Service Service Provider Consumer benutzt Service via Service-Proxy
  21. 21. (K)ein Enterprise Service Bus  Zuverlässigkeit  JINI-Infrastruktur => Ausfallsicherheit eingebaut  Transport  Service Verwaltung  Keine zentrale Konfiguration der Services notwendig  Discovery  Services können anhand ihrer Beschreibung eindeutig zugeordnet werden  lose Kopplung  Überwachung
  22. 22. (K)ein Enterprise Service Bus  SOA-Services werden über ihre Eigenschaften adressiert  Der Service Finder nimmt intelligentes Routing vor  Service-Calls werden immer Punkt zu Punkt ausgeführt  Sowohl für den Service- Provider als auch für den Service-Consumer bleiben die technischen Details verborgen
  23. 23. Distributed Enterprise Service Bus Aufgaben eines Enterprise Service Bus:  Konnektivität herstellen  Zuverlässigkeit  Daten transformieren  Service Verwaltung  Daten routen  Überwachen, Protokolieren und  Sicherheit Debuggen Kundendaten Bestellprozess Adresscheck Reliability Transport Discovery Routing Mapping Message Bus Anbindung über Web-Services Web-Service EJBs SAP Server
  24. 24. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  25. 25. Business Process Management  Flexible Kombination (Orchestrierung) von Services dank Workflow-Engine  Entscheidung für JBPM, da flexibel erweiterbar (XML-Basis)
  26. 26. Business Processes Management  Vertrag zwischen Workflow-Knoten und ServiceDeskriptor  Die Prozesssteuerungsdaten werden über den Workflow ausgetauscht
  27. 27. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  28. 28. Architektur-Überblick
  29. 29. Architektur-Überblick (Management) JBPM Workflowengine (Arbeitgeber mit Plan) Die Workflowengine arbeitet Prozessablaufpläne ab. Sie kennt die Reihenfolge und Art der Aufgaben, welche nötig sind, um einen Usecase zu bearbeiten. Jini-Registry (Arbeitsamt) Verwaltet die vorhanden ExecutionUnits. Bei ihr kann das GEPPI-System erfragen, „wer“ eine benötigte Dienstleistung erbringen kann. ExecutionUnit (Arbeitsuchender) Die ExecutionUnit (Agent) bietet die Dienstleistungen (Services) an, die sie von den ServiceDeskriptoren angeboten bekommt. Ant-Adapter (Eurostecker mit Mehrwert) Ein Ant-Adapter ist eine Art Vermittler, welcher GEPPI an die Anforderungen und Belange von zu steuernden Softwarekomponenten anpasst.
  30. 30. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  31. 31. Service-Kategorien  SOA-Services − Deskriptor und Adapter machen SW zum Service  Technische Services / Utility-Services − Teil der SOA-Infrastruktur, keine SOA-Services − für SOA-Services transparent
  32. 32. Service-Kategorien  Distributed ESB − verteilte ESB-Funktionalität − Punkt-zu-Punkt-Kommunikation − Protokoll für Services transparent − Service Provider sind ausschließlich Provider − Service Consumer sind ausschließlich Consumer
  33. 33. Service-Kategorienmatrix Business Process Business Rule Service Service Decision Geschäftsprozesse Business Activity Business Rule Service Service Validation Geschäftsregeln Business Business Object Service Objects public private Integration Process nach Maier, Normann, Trops, Integration Adapter Adapter Utschig-Utschig, Winterberg (S&S SOA-Spezial Systems System A System B Service A 2009)
  34. 34. Service-Kategorienmatrix Geschäftsprozesse Process Service Geschäftsregeln Visible/SOA Business Service Objects Integration Adapter Invisible/Local Systems Software
  35. 35. Service-Kategorien  Notwendige Funktionalität − GEPPI Process Management − GEPPI Services  Verzicht auf nicht benötigte Flexibilität − Nur Public Services – private Services sind nicht Teil der SOA − Keine Composite Services möglich – nur eine Service-Hierarchieebene
  36. 36. Inhalt  Ausgangssituation  Services: Lose Kopplung via Agent  (K)ein Enterprise Service Bus  Business Process Management  Architekturübersicht  Service Kategorien  SOA und Organisation
  37. 37. Governance SOA
  38. 38. Governance SOA
  39. 39. Governance SOA
  40. 40. Governance SOA  SOA ausgerichtet an bestehender Organisation des Unternehmensbereichs und nicht umgekehrt  Projektteams verantworten ihre Fachdomäne: − Technik und − Fachlichkeit (Businessprozesse)  SOA/IS-Team als Dienstleister der Projektteams  Übergreifende Geschäftsprozesse werden durch schlanke Superworkflows geklammert
  41. 41. Pragmatic SOA GEPPI ist keine SOA passend für alle Anwendungsfälle, sondern die optimale Software für genau diese Anforderungen und genau diese Organisation.
  42. 42. Pragmatic SOA Noch Fragen

×