Embed Size (px)
DESCRIPTION
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.
Citation preview
Pragmatic SOA
Beschränken auf das Wesentliche
M. Wittum | 1& 1 Internet AG
D. Schmid | 1& 1 Internet AG
Dr. T. Breitkopf | Netviewer AG
Service Oriented Architecture
ESB - Adapters
BPM – Orchestration
Registry Repository
Business ServicesComposite ServicesTechnical Services
WSDL, SOAP, UDDI, BPEL, XML, Java, …
aus www.javaworld.comSOA for the real world
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)
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
SOA - The pragmatic way
Matthias
Wittum1&1 Internet AG
SOA - The pragmatic way…
Dirk
Schmid1&1 Internet AG
Dr. Thomas
BreitkopfNetviewer AG
…am Beispiel GEPPI(General Enterprise Process and Planning Infrastructure)
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
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
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
Ausgangssituation
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
SOA-Service = Webservice?
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
??? Wie funktioniert das?
Deskriptive, lokale Schnittstelle
mit Konventionen
Konkret sieht das so aus…
Am Beispiel eines Antadapters
Service = Programm + ServiceDeskriptor + (Adapter)
Geppi Stack so far
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
(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
(K)ein Enterprise Service Bus
Das wurde doch als Waschmaschinen Steuerung
erfunden !?
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
(K)ein Enterprise Service Bus
Jini RegistryJini
Service Provider
Jini Service Consumer
registriertInterface
suchtInterfaceImplementierung
benutzt Servicevia Service-Proxy
(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
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
(K)ein Enterprise Service Bus
Distributed Enterprise Service Bus
Message Bus
AdresscheckKundendaten
Web-Service EJBs SAPServer
Anbindung über Web-Services
TransportReliability Routing Discovery Mapping
Bestellprozess
Aufgaben eines Enterprise Service Bus:
Konnektivität herstellen Daten transformieren Daten routen Sicherheit
Zuverlässigkeit Service Verwaltung Überwachen, Protokolieren und
Debuggen
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
Business Process Management
Flexible Kombination (Orchestrierung) von Services dank Workflow-Engine
Entscheidung für JBPM, da flexibel erweiterbar (XML-Basis)
Business Processes Management
Vertrag zwischen Workflow-Knoten und ServiceDeskriptor
Die Prozesssteuerungsdaten werden über den Workflow ausgetauscht
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
Architektur-Überblick
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 kanndas GEPPI-System erfragen, „wer“ eine benötigteDienstleistung erbringen kann.
ExecutionUnit (Arbeitsuchender)Die ExecutionUnit (Agent) bietet die Dienstleistungen(Services) an, die sie von den ServiceDeskriptorenangeboten bekommt.
Ant-Adapter (Eurostecker mit Mehrwert)Ein Ant-Adapter ist eine Art Vermittler, welcher GEPPI an die Anforderungen und Belange von zu steuerndenSoftwarekomponenten anpasst.
Architektur-Überblick (Management)
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
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
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
Service-Kategorienmatrix
nach Maier, Normann, Trops, Utschig-Utschig, Winterberg
(S&S SOA-Spezial 2009)Systems
Integration
Business
Objects
Geschäftsprozesse
Geschäftsregeln
Business ProcessService
Integration Process
Business Object Service
Business Activity Service
Business Rule Service
Decision
Business Rule Service
Validation
Adapter
System A Service A
Adapter
System B
private
public
Service-Kategorienmatrix
Systems
Integration
Business
Objects
Geschäftsprozesse
Geschäftsregeln
Adapter
Software
Invisible/Local
Visible/SOA
ProcessService
Service
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
Inhalt
Ausgangssituation
Services: Lose Kopplung via Agent
(K)ein Enterprise Service Bus
Business Process Management
Architekturübersicht
Service Kategorien
SOA und Organisation
Governance SOA
Governance SOA
Governance SOA
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
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.
Noch Fragen
Pragmatic SOA
