Micro-SOA vs Macro-SOA - OIO€¦ · 1 Orientation in Objects GmbH Weinheimer Str. 68 68309...

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

Micro-SOA vs.Macro-SOA

Von der Ökonomie zweier Architekturstile

1.0

Micro-SOA vs. Macro-SOA© 2011 Orientation in Objects GmbH

Gliederung

• Einleitung– Definitionsversuch– Ursprung und Ziele– These

• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interfaces

• Synthese

2

2


Gliederung



• Synthese

3


Motivation

4

Quelle: http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

3


Architektur

5

„A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.“ (Thomas Roy Fielding)

„Die Gliederung in Subsysteme“


Definitionsversuch einer SOA (1)

• „SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität , die von unterschiedlichen Besitzernverantwortet wird.“

6

OASIS Reference Model for Service Oriented Architecture 1.0,Committee Specification 1, 2 August 2006

4



• “Service Oriented Architecture is an architectural style for building systems based on interacting loosely coupled , coarse grainedautonomous components called services .Each service expose processes and behavior through contracts , which are composed of messages at discoverable addresses called endpoints. Services’ behavior is governed by policies which are externally to the service itself.”

7

SOA Patterns, Arnon Rotem-Gal-Oz, Manning eBook, http://www.manning.com/rotem/



• Service-oriented architecture (SOA) is the dominant architectural style for agile business applications , and is used when enterprises anticipate application sharing and frequent system changes .SOA helps business managers and analysts develop new business processes , and modify processes more quickly and at a lower cost . Gartner coined the term "SOA" and published the first reports in the industry on it in 1996. SOA enables new business models that involve the introduction of new products and services, particularly those that require the online cooperation of multiple business units ....

8

Service-Oriented Architecture, Gartner IT-Glossary

5



• Essentially, SOA is a software architecture that starts with an interface definition and builds the entire application topology as a topology of interfaces , interface implementations and interface calls. SOA would be better-named "interface-oriented architecture “.

9

Service-Oriented Architecture Scenario, Gartner Research Note AV-19-6751


Gemeinsamkeiten der Definitionen

• Architekturstil– Keine Aussage über Technologie

• Lose Kopplung von Diensten– Unabhängigkeit der Dienste

• Soll Flexibilität durch Interoperabilität bieten– Neue Dienste können einfach angebunden werden

• Dienste können zum Abbilden von Prozessen orchestriert werden– Mit Hilfe von Business Process Engines

• Dienste kommunizieren über Nachrichten

10

6


SOA = Prinzipien

• Leverages open standards

• Software as services

• Services are loosely coupled

• Focus on business function not technology

• Platform independence

• ...

11


SOA Manifest

• Geschäftswert über technische Strategie

• Strategische Ziele über projektspezifischen Nutzen

• Immanente Interoperabilität über maßgeschneiderte Integration

• Gemeinsam verwendete Services über zweckgebundene Implementierungen

• Flexibilität über Optimierung

• Evolutionäre Vervollkommnung über Streben nach anfänglicher Perfektion

12

http://soa-manifest.de/

7


Gliederung



• Synthese

13


2003 Flughafenwerbung (Heatrow )

14

8


2003 Herausforderungen an die IT

• Integration heterogener, verteilter Systeme– Zahlreiche inkompatible Hersteller und Protokolle– Keine einheitliche Technologie

• Java, C#, C++, CORBA, RMI, etc.

• Bestehende „Altsysteme“ verbinden (lose Kopplung)– Firmenzukauf, Migration, etc.

• Einfache Anbindung neuer Kunden– Unterstützung von Webclients, mobilen Clients, etc.

• Firewalls müssen überwunden werden– Meist nur Port 80 (HTTP) geöffnet

15


Lösungsansatz 1: Datenintegration

16

System A

DatenB

Daten

System B

Daten

• Replikation• Master / Slave• Datenabgleich

• Userdaten• Redundanz• Konflikte

KopieDaten

B

DatenB

9


Lösungsansatz 2: Funktionale Integration

17

System A

Daten

System B

Daten

Just in Time!

DatenB

Anfrage nach Daten

Antwort

Bitte um Änderung

Antwort


Lösungsansatz 2: Transaktionale Integration?

18

System A

Daten

System B

Daten

DatenB

Anfrage nach Daten

Antwort

Bitte um Änderung

Antwort

TransaktionsKoordinator

10


Probleme von Einzelintegrationen im Unternehmen

19

Eigenes Unternehmen Partner


Probleme der Einzelintegration (1)

• Fest gekoppelt, „zerbrechlich“ und unflexibel– Jeder Dienst ist fest mit einem anderen Dienst verbunden

• Aufwendige Schnittstellenpflege – Viele Point-to-Point Lösungen

• Änderung einer Anwendung aufwendig– Kann sich auf viele andere Anwendungen auswirken

• Logik zum Routing steckt in einzelnen Anwendungen– Welches Ziel hat eine Nachricht / Methodenaufruf?

20

11


Probleme der Einzelintegration (2)

• Kein einheitliches Kommunikationsprotokoll– Jede Anwendung definiert (eigenes) Protokoll

• Kein einheitliches Sicherheitsmodell

• Asynchrone Kommunikation schwer einzubauen

• Eventuell keine zuverlässige Verarbeitung– Reliability nicht gewährleistet

• Keine zentralen Dienste– Monitoring, „Abrechnungslücke“

21


Best Practices Lösungsansätze: EAI Patterns

• Dateiübertragung

• Gemeinsame Datenbank

• Entfernte Methodenaufrufe – Remote Procedure Calls

• Nachrichtendienste

22

http://www.enterpriseintegrationpatterns.com/toc.html

12


SOA 1998?

23

Kunde

CRM

Vertrag

CORBA Proxy

Konto Produkt

Finance Produktion

RMI Proxy X Proxy

CORBA RMI Protocol X

Custom Application


XML als Wegbegleiter von SOA

24

XML Nachrichten

Dave Winer

XML-RPCDon Box

SOAPFinal

REST

HTTP, URL, URI

SOAP 1.2

Einfluß

1.01.1

13


Definition von Services als Web Service (W3C)

• “A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols.“ (W3C)

25


Definition von Services als Web Service (IBM)

• Web Services are self-contained, modular applications that can be described , published , located and invoked over a network , generally the Web to create innovative products, processes, and value chains. Web services can be local, distributed or Web-based . They interact with and/or invoke each other , fulfilling specific tasks and requests that, in turn, carry out specific parts of complex transactions or workflows. (IBM)

26

14


Vorteile von Services als Web Services

• Interoperability– Mit CORBA, DCOM, ...

• Verbreitung– Basiert auf XML

• Niedrige Einstiegsschwelle– Einfache Technik, kostenlose Toolkits, automatische COM und EJB

Anbindung– Nicht auf eine Plattform oder Technologie beschränkt

• Passieren von Firewalls bei Nutzung von HTTP als Übertragungsprotokoll– Offener HTTP Port

27


Was machen Web Services anders als Vorgänger?

• Basiert auf „echten“, weitverbreiteten Standards– TCP/IP, HTTP, XML, ...

• Führende Softwarehersteller unterstützen den Standard– Oracle, IBM, Microsoft, ...

• Bestehende Infrastruktur läßt sich weiternutzen– Internet, Router, Firewalls, Web Server, ...

28

15


Web Service Interoperability

29

Common Internet Protocols (HTTP, TCP/IP)

Extensible Markup Language (XML)

Simple Object Access Protocol (SOAP)

Universal Description, Discovery and Integration (U DDI)

Universal Service Interop Protocols(these layers are not defined yet)

InteropStack


Überlegungen gegen WebServices

• XML Verarbeitung unter Umständen aufwendig– In vielen Anwendungsfällen unkritisch

• Einheitliche Technologie– Keine heterogene Server- und Client-Technologie

• Keine „Internetnutzung“ gewünscht– Intranet: Anwendung muss keine Firewall überwinden

30

16


Vision 2003: Service Oriented Business Application (SOBA)

31

KundeService

CRM

Vertrag Service

WS Proxy

Konto Service

ProduktService

Finance Produktion

WS Proxy WS Proxy

SOAP

SOBA

Security

SecurityService

SOAP SOAP SOAP

WS Proxy


SOA als EAI 2.0?

32

Firew

all

RMI

RMI

WebServer

JAX-RPCServlet Endpoint

Application Server

EIS

EJB

Connector

Firew

all

XML

WebServer


Application Server

EIS

EJB

Connector

Firew

all

XML

Application Server

EIS

EJB

Connector

Application Server

EIS

EJB

Connector

WebServer


RMI

WebServer


Firew

all

XML

Firew

all

XML

XML

17


Integration Unternehmensübergreifend

33



Gliederung

• Einleitung– Definitionsversuch– Ursprung und Ziel– These

• Panoptikum der Micro-SOA– Kanonisches Datenmodell– Domänenservices– Integration, Prozesse und Applikationen– User Interface

• Synthese

34

18


These

35

Macro-SOA

= EAI + XML + WS


Weitergehende Überlegungen zur Macro-SOA

• Schnittstellen werden auf Dienstebene definiert– Klare Trennung zwischen Schnittstelle und Implementierung

• Ermöglicht die Kombination einzelner Dienste– Durch einheitliche Schnittstellenbeschreibung in WSDL erleichtert

• SOA startet(e) meist nicht auf grüner Wiese– Bestehende Systeme müssen integriert werden

• Fachlicher Dienst muss technisch zur Verfügung gestellt werden– Unterstützung einer Vielzahl von technischen Schnittstellen– Bestehende Anwendung besitzt eventuell keine Web Service

Schnittstelle

36

19


Weitergehende Überlegungen zur Macro-SOA

• Anwendungen immer noch fest gekoppelt– Anwendungen sind immer noch Client eines anderen Dienstes

• Prozesslogik steckt immer noch in Anwendung– Keine Trennung von Prozesslogik, Anwendungslogik und Schnittstelle

• „Eigentlich“ SOA nicht gleich SOAP / Web Services?

37


Lösungsansatz Middleware-Plattform

38

MiddlewareStabilität

Zuverlässigkeit

Skalierbarkeit

Fehlertoleranz

Konsistenz

Discovery

Sicherheit

ErweiterbarkeitIntegration proprietärerKomponenten

Ressourcenverbrauch

AdministrationsunterstützungSystemunabhängigkeit

20


Lösungsansatz Standard-Stack

39

WS-TransactionWS-Coordination

WSDL

SOAPAndere Protokolle

XML, Encoding

Transport und Encoding

Quality of Service

Beschreibung

Geschäfts-prozesse

UDDI

WS-Reliable MessagingWS-Security

Choreography WS-CDL

Orchestration WS-BPEL


WS*-Spezifikationen

40

WS-Transaction

WS-SecureConversation

WS-Addressing

WS-SecurityWS-Trust

definiert Erweiterungen

definiert Erweiterungen

WS-Policy

WS-Coordination

verwendet

WS-Atomic Transaction WS-BusinessActivity

verwendetverwendet

empfiehlt

verwendet

WS-BPEL

verwendet

21


Die WS*-Spezifikationen

41


These

42

Micro-SOA

= Macro-SOA+ Improvements?

22


Gliederung



• Synthese

43


Ursprung: EAI 2.0 Interorganisationaler Datentransfer mit XML

44

XMLXML

DBMS DBMS

DTD DTD

validieren

validieren

XSLTransformator

XML

validieren

DTD-AustauschXML-Struktur XML-Struktur

23


Serviceorientierter Datenaustausch zwischen Systemen

45

System ABML

InternesDaten-modell

System BAML


Austausch

Transformation Transformation

Punkt-zu-Punkt


Lösungsansatz Kanonisches Modell

• SOA hat Wiederverwendung zum Ziel– Schnell neue Funktionen– Auf Basis von bestehenden Services

• Services liefern Dokumente– Leichte Austauschbarkeit als Ziel

• Kanonisches Modell als Austauschformat– Transformation in Kanonisches Modell– Wiederverwendbares Dokumentenmodell

• Modellierung– z.B. in UML– Explizite Darstellung und Dokumentation– Möglicher Grad der Wiederverwendung steigt

46

24


Lösungsansatz Kanonisches Modell

47

System AKML


System BKML


Austausch kanonisch

Transformation Transformation


Vorteile eines kanonischen Modells

• Lose Kopplung auf Datenebene– Systeme kennen nur ihr Format und das kanonische

• Transformationen sind nur noch in ein Austauschformat notwendig– Lohnt sich bei steigender Anzahl von Systemen

• Einheitliches Verständnis eines Dokuments

48

25


Micro-SOA: Wiederverwendung des kanonischen Modells in der Anwendungsentwicklung

49

XSD / Kanonisches Modell

DomainService 2

DomainService 1

ProcessService

Data AccessData AccessService 1


e.g. findCustomerByUID(..) e.g. findInvoicesByCustomerUID(..)

e.g. findInvoicesByCustomer(..)

DO

JPA-Klasse

Konverter

DO

DO

JAXB-Klasse


Micro-SOA Support in Java Plattform?

50

JavaKlasse

XMLSchema

JAXB

1 1

*

*

Objekte Dokumente Dokumente

*

Objekte

1

1 1

1

JavaObjekte

XMLDokumente

26


Probleme

• Kanonisches Datenmodell zieht sich durch alle Schichten eines Service bzw. einer Applikation

• Aufwände bei Änderungen

• Interne Repräsentation ist nicht mehr spezifisch für eine Domäne

• Kontext-abhängige Ausprägung ist nicht mehr möglich

51


Macro-SOA: Contract-First, Adaption der Implementierung

52

Applikation

BusinessObjekte

Web Service Adapter

XML

Kanonisches Modell

27


Micro-SOA: Implementation-to-Contract

53

Applikation

BusinessObjekte

Web Service

XML

„Kanonisches Modell“


Probleme

• Inneres Datenmodell als erster Schritt zu kanonischem Modell

• Behauptung: Iterative/imkrementelle Vorgehensweise führt langfristig zu echter kanonischer Form

• Abhängigkeiten entstehen, die dann zum Problem werden (Konsumenten erwarten Stabilität)

• Implementierung(sdetail) kann nicht ohne weiteres geändert werden

• Neue externe Anforderungen an kanonisches Modell wirken direkt auf internes Modell

54

28


Macro-SOA: Kanonisches Datenmodell in XML Schema

55


Lösungsansatz: Formale Modellierung der kanonischen Form

• Komplexität von XML Schema soll durch Werkzeugunterstützung beherschbar werden

• Formale Modellierung z.B. in UML naheliegend

56

XSD

Entity type

D attribute (ERM)

D attribute (ERM)

D attribute (ERM)

D attribute (ERM)

ERM domain

ERM domain

ERM domain

ERM domain

29


Micro-SOA: Modellgetriebene SOA

57

Kanonisches Modell

DomainService 2

DomainService 1

ProcessService



e.g. findCustomerByUID(..) e.g. findInvoicesByCustomerUID(..)

e.g. findInvoicesByCustomer(..)

DO

XSD

JPA-Klasse

Konverter

DO

DO

JAXB-Klasse


Probleme einer modellgetriebenen SOA

• Semantische und syntaktische Mächtigkeit von XSD sollte nicht unterschätzt werden– „Es ist leichter ein Dokumentformat zu modellieren als es in Schema zu

definieren“ stimmt nicht immer

• Generierung weiterer Zielartefakte macht Modell noch komplexer– Aufwand der Modellwartung, z.B. Mappingmodelle

• MDSD befördert iterativ-inkrementelles Denken– Stabilität vs. Evolution

• MDSD befördert Verwendung von Elementen des kanonischen Modells innerhalb der Anwendungsentwicklung

58

30


Gliederung



• Synthese

59


Macro-SOA Vorgehen: Geschäftslogik als Business Services exponieren

60

Service A Service B Service C Service D

Funktionalität

31


Lösungsansatz: Schnittstellendefinition durch WSDL

61

Servicemodell

DomainService 2

DomainService 1

ProcessService

Data AccessData AccessObject

Data AccessData AccessObject

e.g. Invoice service

e.g. Order process

WSDL


Macro-SOA: Business Services technisch mit WSDL spezifizieren

62

WSDL A WSDL B WSDL C WSDL D

Funktionalität

32


WSDL Elemente

• Elemente in WSDL Dokumenten:– Types

Ein Container für Datentypdefinitionen wie XSD

– MessagesÜbertragene Daten

– Port TypeEin Satz von Operationen die von einem oder mehreren Endpunkten unterstützt werden

– BindingKonkretes Protokoll und Datenformat Spezifikation für einen Port Type

– ServiceSammlung von verwandten Endpunkten

– PortEndpunkt bestehend aus Binding und Netzwerkadresse

– OperationOperation die vom Service unterstützt wird

63


Perspektivwechsel: Anwendung als Summe von Business Services

64

Service A Service B

Service C Service D

Anwendung X

33


Micro-SOA: Anwendung als Summe von Web Services (WSDL basiert)

65

WSDL A WSDL B

WSDL C WSDL D

Anwendung X


Probleme

• Performanzanforderungen an applikationsinterne Kommunikation sind höher als in typischen Integrationsszenarien– Lokale Kommunikation– Synchrone Aufrufe– Große Datenmengen– Verarbeitung von Strömen– Nutzung von gemeinsamen Datenkontexten

• Applikationsarchitekturen besitzen dafür spezialisierte Schnittstellentechnologien (CORBA, DCOM, JNI, JSON..)

• WSDL erlaubt zwar unterschiedliche Protokolle aber unterstützt eng gekoppelte bzw. binäre Protokolle nur bedingt

• Macro-SOA Infrastruktur kann nur bedingt genutzt werden

66

34


Problem: Service Lifecycle vs. Application Life Cycle

67

Planned

In Development

In Test

Deployed

Depreciated

Out of Service

Planned

In Development

In Test

Deployed

End of Life


Probleme

• Exponierung interner Schnittstellen verändert deren Lebenszyklus

• Exponierter Service muss Stabilität bieten– Abwärtskompatibilität– Deprecation-Mechanismus

• Exponierter Service unterliegt äußeren Restriktionen

• Interne Schnittstelle unterliegt kürzeren Änderungszyklen– Hat keine Restriktionen, die von außen kommen

68

35


Micro-SOA: Private Services exponieren

69

Servicemodell

DomainService 2

DomainService 1

Data AccessData AccessService

Data AccessData AccessService

e.g. Invoice Service

WSDL


Gefahren

• Exponierung interner Operationen und ihrer Datenstrukturen– Offenlegung der Implementierung– Aufwände bei Änderungen– Interne Repräsentation ist nicht mehr spezifisch für eine Domäne– Kontext-abhängige Ausprägung ist nicht mehr möglich

70

36


Applikationsinterne Abhängigkeiten

71

Service A Service B Service C Service D

a b c g h i

d e j k

l

f


Neuer Service exponiert

72

Service A Service B Service C Service H

a b c g h i

d e j k

l

f

Service D

37


Micro-SOA: Interne Abhängigkeit exponiert

73

Service A Service B Service C Service H

a b c g h i

d e j k

l

f

Service D


Probleme und Gefahren

• Notwendigkeit der Transformation zwischen Dokumenten der (ehemals) privaten und öffentlichen Serviceschicht

• Abhängigkeiten von Services– Unterschiedliche Lebenszyklen– Self-contained?– Loose coupling?– Support füt Dependancy-Management in Macro-SOA?

74

38


Service D

h

Micro-SOA: Getrenntes Service-Deployment

75

Service A Service B Service C

Service H

a b c gi

d e j k

l

f

x Komponente



• Getrenntes Deployment erhöht die Wartungsaufwände– Konfigurationsmanagement– Paketierung– Verteilung– Monitoring

• Getrenntes Deployment wirft die Frage nach sog. Shared Services auf– Paralleler Betrieb von verschiedenen Versionen dieser Services ?– Ist das Ziel der SOA Wiederverwendung oder Redundanzfreiheit?

• SOA als Treiber von MDM?• SOA als Ersatz für Shared Libraries?

76

39


Gliederung



• Synthese

77


Integration mittels einer SOA

78


40


Herausforderung

• Fest gekoppelt, „zerbrechlich“ und unflexibel– Jeder Dienst ist fest mit einem anderen Dienst verbunden– Viele Point-to-Point Lösungen

• Logik zum Routing steckt in einzelnen Anwendungen



79


Lösungsansatz: Integration über ESB

80


41


Micro-SOA: „Abteilungs-ESB“

81


Adapter Adapter

Adapter

ProtocolAdapter(SOAP,FTP)

Partner

ESB


Micro-SOA: „Multi-ESB Szenario“

82


Adapter Adapter Adapter Adapter Adapter Adapter Adapter

Partner

ESB ESB ESB ESB

42



• Verwendung eines ESB bedeutet zusätzlichen Aufwand– Lizenzen– Betrieb– Know How

• Features und Kostenersparnis des ESB nur bei angebundenen Services

• Fehlender Standard für ESBs– Föderation von ESBs als eigenes Integrationsprojekt– Aufwendige Migration zwischen ESB-Produkten

83


Lösungsansatz: Standardisierung eines ESB

• JBI 2.0 (JSR 312, 2010 zurückgezogen)– IBM: SCA ist die bessere Lösung, doppelter Standard verwirrt Markt– BEA: Keine Java-only Lösung

84

JBI Umgebung

Normalized Message Router

SE Weitere SEs

BCWeitere

BCs

Installation

Deployment

Control

Monitoring

External Service Provider

External Service Consumer

43


Lösungsansatz: Standardisierung eines ESB

• SCA 1.0 released 2007 (SCA 1.1 Draft 03, Juni 2011)

85

Service

Service Referenz

Property

Component


Lösungsansatz: SCA

86


44


Micro-SOA: Multilayer ESB innerhalb einer Applikation

87

System A

Prozesse

ESB

Geschäftsobjekte

ESB

Lebenszyklus

Sys

tem

B

Sys

tem

C

ESB

DB


Probleme

• Performance

• Wartung– Konfiguration– Deployment– Monitoring

• Testbarkeit

88

45


SCA: Welche Probleme werden gelöst?

• Fest gekoppelt, „zerbrechlich“ und unflexibel– Jeder Dienst ist fest mit einem anderen Dienst verbunden– Viele Point-to-Point Lösungen

• Logik zum Routing steckt in einzelnen Anwendungen



89


Lösungsansatz: WS-BPEL

90

46


Macro-SOA Plattform: Oracle SOA Suite 11g

91

Oracle 11g Application Server

SCA Runtime

ServiceMediator

BPELEngine

BPELProcess

Notifications

WorklistApplication

Oracle Service Bus

JEE Web EJB 3

ADF EJBService

Rules Engine

Messaging JAX WS

JTA JPA

JDBCJNDI


Micro-SOA: Entity-Update mit BPEL

92

47


Micro-SOA: Entity-Update mit BPEL – Detail 1

93



94

48



95


Probleme

• Benutzung solcher Dienste aus dem UI– Asynchronität

• Eigentlich klassische Applikationsentwicklung

• Performance?

• Transaktionsgrenzen?

96

49


BPEL als Compound-Service

97

Activity

WSDL

Web Service

Activity

WSDL

Web Service

Activity

WSDL

Web Service

WSDL

Zustand(Variablen)

Web Service


Macro-SOA: Integrationsszenario, Orchestrierung mit BPEL

98

PipeFile

Poller

JMXFile

SenderXSLT

/order/position //price[.< 2] //quantity[@unit=‚piece‘]

Router

50


Analyse

Analyse von Integrationsprojekten

Daten / Services

WSDL Kanonisches Modell

Prozesse

Workflow Routing

Userinterfaces

Design Navigation

99


Micro-SOA: BPEL in der fein-granularen Anwendungsentwicklung

100


BPEL Prozesslogik

51



• Lokale Optimierungen in unteren Schichten werden unmöglich– SQL– Objekt-relationale Datenbanken

• Performance– Ständige Transformation in und von XML-Repräsentation droht

• „Dokumenten-orientierte Programmierung“– Analyse folgt oft anderen Paradigmen (strukturiert, OO)– Scheitert bei komplexerer Algebra– Schwierige Zusammenarbeit mit relationalem Paradigma

101


ImplementierungAnalyse

Vorgehen bei Implementierung eines SOA-Projekts

Daten / Services

WSDL Kanonisches Modell

Prozesse

Workflow Routing

Userinterfaces

Design Navigation

Userinterfaces

Java C#

Prozesse

BPEL

Daten / Services

WSDL XSD

102

52


Micro-SOA: „Potemkinsche Dörfer“

103

Eigenes Unternehmen

Adapter Adapter Adapter Adapter Adapter

ESB



• Entwicklungsgeschwindigkeit– Overhead gegenüber klassischer Entwicklung

• Testbarkeit

• Mangelnde Analyse von (Implementierungs-)Details– Fehlende Anforderungen

• Akzeptanz durch Geldgeber schwindet während der Implementierung oder der Wartung– Widerspruch zwischen Werbeversprechen und „Realität“ wird hier sehr

deutlich

104

53


Gliederung



• Synthese

105


Macro-SOA: UI initiiert einen Prozess

• UI sammelt Daten und initiiert damit einen Prozess

• Angezeigt wird evtl. eine Ergebnisseite

• Prozess läuft asynchron

106

UI

Prozess

54


Macro-SOA: Menschliche Interaktion mit langlaufenden Prozessen

107


Lösungsansatz: Interaktion über Taskliste

108

JEE

Worklist Services

PM

Task complete

BPEL Process

Assign task

HumanTasks

UI

ServicesDomainServices

Webframework

APIAPI

Browser

APIAPI

DomainWorklist

55


Lösungsansatz: Interaktion über Taskliste

• Um lose Kopplung zu erreichen– Als Entkopplung von „synchroner UI“ und asynchronem Prozess

• Abarbeiten von Tasks stellt eine Art Paradigmenwechsel dar– Asynchrones Laufzeitverhalten– Ungewohnt für Benutzer– Kennen meist synchrone UIs mit direkter Rückkopplung

• Arbeitsabläufe werden automatisiert,– Prozesssteuerung wandert in das „Backend“

109


Konsequenzen

• Individuelles Prozesswissen wird explizit (Dokumentation)

• Prozessmonitoring wird möglich und damit Optimierung

• Prozesse bestimmen den Arbeitsablauf, nicht der Mensch den Prozess

• Taskliste kann starr und als Korsett wirken

110

56


Micro-SOA: Human Task bildet fein-granulare Entscheidung ab

111

Abfrage in UI

Ja

Nein


Gefahr

• Benutzbarkeit wird von Fachanwendern schnell in Frage gestellt– Fein-granulare Entscheidung in Verbindung mit asynchronem Verhalten

• Aufwand für Anpassungen aufgrund des Stacks oft teurer als bei klassischer Anwendungsentwicklung

112

57


Micro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle

113


Micro-SOA: Mehrere Human Tasks hintereinander innerhalb einer Rolle

114

58


Micro-SOA: Hotspot Detail

115


Probleme

• Lose Kopplung geht verloren– Maskenflüsse im Prozess

• Arbeitsablauf wird fein-granular zerlegt und vorgegeben– Mensch-Maschine-Interaktion wird im Geschäftsprozess modelliert

• Flexibilität und Agilität?– Änderungen häufig, Wartung aufwendig

• Dem Fachanwendern kaum noch vermittelbar– Extrem störend für Arbeitsablauf– Asynchrones Verhalten sorgt für Wartezeiten– Extremform einer Task-basierten Arbeit

116

59


Gliederung



• Synthese

117


Probleme einer Micro-SOA im kanonischen Modell

• Kanonisches Datenmodell zieht sich durch alle Schichten eines Service bzw. einer Applikation– Hohe Aufwände bei Änderungen

• Interne Repräsentation ist nicht mehr spezifisch für eine Domäne– Kontext-abhängige Ausprägung ist nicht mehr möglich

• Inneres Datenmodell soll iterative/imkrementelle zu kanonischer Form führen– Implementierung(sdetail) kann nicht ohne weiteres geändert werden– Neue externe Anforderungen an kanonisches Modell wirken direkt auf

internes Modell

118

60


Probleme einer modellgetriebenen Micro-SOA

• Semantische und syntaktische Mächtigkeit von XSD wird nicht erreicht

• Hoher Aufwand der Modellwartung bzw. Erstellung von Mappingmodellen

• Häufig Versuch einer iterativ-inkrementellen Erstellung des kanonisches Modells

• Häufig Verwendung von Elementen des kanonischen Modells innerhalb der Anwendungsentwicklung

119


Probleme mit Services einer Micro-SOA (1)

• Applikationsinterne Performanzanforderungen werden nicht erreicht. Durch Mangel an Konzepten für– Lokale Kommunikation– Synchrone Aufrufe– Große Datenmengen– Verarbeitung von Strömen– Nutzung von gemeinsamen Datenkontexten

• Die Vorteile einer Macro-SOA Infrastruktur können nur unzureichend genutzt werden– Lastverteilung– Skalierung– Ausfallsicherheit

120

61


Probleme mit Services einer Micro-SOA (2)

• Interne Services unterliegen äußeren Restriktionen

• Interne Services müssen Mechanismen für Abwärtskompatibilität und Deprecation anbieten

• Service-Konsumenten nutzen Implementierungsdetails

• Hohe Aufwände bei Änderung der Service-Implementierung

• Notwendigkeit der Transformation zwischen XML-Dokumenten der privaten und öffentlichen Serviceschicht

• Steigende Aufwände durch Verwaltung der Abhängigkeiten von Services

121


Probleme mit Shared Services einer Micro-SOA

• Erhöhte Wartungsaufwände durch getrenntes Deployment

• Paralleler Betrieb von verschiedenen Versionen

• Paralleler Betrieb von verschiedenen Services

• Zielkonflikte bei der Entwicklung zwischen Wiederverwendung und Redundanzfreiheit

122

62


Probleme mit (Sparten-)ESB einer Micro-SOA

• Zusätzliche Aufwände für Lizenzen, Betrieb und Know How

• ESB-Föderationsprojekte

• ESB-Integrationsprojekte

• Performance

• Wartung– Konfiguration– Deployment– Monitoring

• Hohe QM-Aufwände (Testbarkeit)

123


Probleme mit Compound-Services einer Micro-SOA

• Performance-Probleme– Lokale Performance-Optimierungen in unteren Schichten sind nicht

mehr möglich– Hohe Transformationsaufwände von und in XML

• Hohe Implementierungsaufwände– Notwendigkeit der Übersetzung zwischen verschiedenen Paradigmen

(Strukturiert, Relational, OO)– Bei komplexer algebraischen Problemen– Fehlerbehandlung– Transaktionshandling

• Höhere Implementierungsaufwände bei Benutzung der Dienste bedingt durch Asynchronität

124

63


„Green Field Probleme“ einer Micro-SOA

• Geringere Entwicklungsgeschwindigkeit als bei bisheriger Anwendungsentwicklung

• Hohe Aufwände für Change Requests während der Implementierung

• Sinkende Akzeptanz der Stakeholder während Implementierung und Betrieb– Widerspruch zwischen Werbeversprechen und „Realität“ tritt sehr

deutlich zu Tage

125


Probleme der UI in einer Micro-SOA

• Maskenflüsse im Prozess

• Mensch-Maschine-Interaktion wird im Geschäftsprozess modelliert

• Hohe Änderungshäufigkeit

• Aufwendige Wartung

• Mangelhafte Usability ist dem Fachanwendern kaum noch vermittelbar– „Anwendung stört den Arbeitsablauf“

126

64


Mehr von OIO zum Thema...

• Schulung: SOA – Service orientierte Architekturen– http://www.oio.de/seminar/entscheider/soa-schulung.htm

• Artikel: Modellgetriebene Software-Entwicklung mit BPMN und SOA– http://www.oio.de/m/konf/doag2010/SOA-BPM-Modellgetriebene-

Software-Entwicklung.pdf

• Beratung zu SOA & WebServices– http://www.oio.de/beratung-consulting/software-integration/soa-web-

services/

127



[email protected]

??

? ?

????

Fragen ?

65



[email protected]

Vielen Dank für ihre Aufmerksamkeit !

Micro-SOA vs Macro-SOA - OIO€¦ · 1 Orientation in Objects GmbH Weinheimer Str. 68 68309...

Documents

Transcript of Micro-SOA vs Macro-SOA - OIO€¦ · 1 Orientation in Objects GmbH Weinheimer Str. 68 68309...