Pragmatic SOA - Beschränken auf das Wesentliche

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