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.

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. 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. 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. 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. 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. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

7. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

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. 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. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

11. SOA-Service = Webservice?

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. ??? Wie funktioniert das?
Deskriptive, lokale
Schnittstelle
mit Konventionen

14. Konkret sieht das so aus…

15. Am Beispiel eines Antadapters

16. Geppi Stack so far
Service = Programm + ServiceDeskriptor + (Adapter)

17. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

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. (K)ein Enterprise Service Bus
Das wurde doch als
Waschmaschinen Steuerung
erfunden !?

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. (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. (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. 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. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

25. Business Process Management
 Flexible Kombination (Orchestrierung) von Services dank
Workflow-Engine
 Entscheidung für JBPM, da flexibel erweiterbar (XML-Basis)

26. Business Processes Management
 Vertrag zwischen Workflow-Knoten und ServiceDeskriptor
 Die Prozesssteuerungsdaten werden über den Workflow
ausgetauscht

27. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

28. Architektur-Überblick

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. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

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. 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. 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. Service-Kategorienmatrix
Geschäftsprozesse Process
Service
Geschäftsregeln
Visible/SOA
Business
Service
Objects
Integration Adapter
Invisible/Local
Systems Software

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. Inhalt
 Ausgangssituation
 Services: Lose Kopplung via Agent
 (K)ein Enterprise Service Bus
 Business Process Management
 Architekturübersicht
 Service Kategorien
 SOA und Organisation

37. Governance SOA

38. Governance SOA

39. Governance SOA

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. 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. Pragmatic SOA
Noch Fragen