SOA:
Licht in den Begriffdschungel
Donnerstag, 24. Mai, 9.15 bis 10.45
Dr. Dieter Wenger, Wenger Competence Consulting, [email protected], Tel. 079 237 1001
Ziele des Seminars

Welches sind die Erwartungen des Geschäftes an die IT?

Wieweit können diese Erwartungen mittels SOA erfüllt werden?

Wie sieht die moderne Software-Architektur aus?

Wie sieht deren Nutzung aus?
Das Seminar ist ausgerichtet auf:

IT-Management, IT-Projektleiter, Consultants, Business Engineers,
Integratoren, Organisatoren, ...
Achtung !

Dies ist kein technisches SOA Seminar.
2
Agenda

SOA & Moderne Software Architektur (35 Minuten)


Case Study: Health (20 Minuten)



Swisscom Information Services (SCIS) AG
e-Serve AG
Case Study: Banking (20 Minuten)


Wenger Competence Consulting
Steria Schweiz AG
Diskussion (15 Minuten)
3
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
4
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
5
Erwartungen des Geschäfts
Ziele des Geschäftes:

Differenzierung durch:


Steigerung der Geschäftsprozess-Werte (Business Value)
Senkung der Geschäftsprozess-Kosten
Erwartungen an die Software-Lösungen:

Hohe Geschäftsprozess-Unterstützung



Hohe Flexibilität






Hohe administrative Flexibilität
Schnelle Umsetzung von neuen geschäftlichen Anforderungen
Strategische Optionen
Hohe Stabilität
Tiefe Kosten


Automatisierung, Benutzerunterstützung (Autonomisierung)
Business Compliance / Business Orientierung
Geringe Betriebs- und Prozessoptimierungs-Kosten
Kontrolle durch Business / Transparenz für Business
Hohe Performanz
6
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
7
SOA: Prinzip Redundanzfreiheit
Ein Geschäftsprozess ist ein Service !
VerkaufsProzess
SupportProzess
Outsourcing

Teile von Prozessen, die in verschiedenen
Prozessen gleich sind, werden in einen
neuen Prozess ausgelagert.


VerkaufsProzess
SupportProzess
KundenManagement
Prozess
Auslagerung von Services.
Es entsteht eine ServiceAuslagerungstruktur
Beispiel:

Der Service ‚Kunde aufnehmen/mutieren‘ ist
in 2 verschiedenen Prozessen gleich.
Vorteile:

Reuse

Eliminierung Prozess-Redundanz
(Ressourcen)

Eliminierung Daten-Redundanz
... Service ‚Kunde aufnehmen/mutieren‘
8
SOA: Prinzip Standardisierung

Individualisierung versus Standardisierung
Standard-Service

Merkmal


Vorteile




Hoher Reuse (hoher Nutzungs-Entwicklungs Faktor)
Hohe, anhaltende Qualität
Best-of-Breed
Tiefe Kosten
Nachteile

Keine Individualität
Lösung:

Optimale Aufteilung in Standard- und Individual-Services.
9
SOA: Individualität versus Standardisierung
1.
Unterteilung der Services in TeilServices (Teil-Teil Services, ...):
1.
2.
2.
3.
Bis ein Teil-Service 100%
Standard oder 100% individuell.
Bis zu atomaren Services.
Auslagerung der Standard TeilServices (Teil-Teil Services, ...)
Identifikation von gleichen TeilServices
Nutzen:

Voraussetzung für Release-Management
10
SOA: Aufbau der Service-Orientierten Architektur
Individuell
Reuse
nein
ja
Standard
---
Auslagerung
Auslagerung
Auslagerung
Aufbau der Service-Architektur

Mittels Auslagerung

Identifikation von gleichen Services
Ziel:

Mächtige (viel Business Value) sich nicht überschneidende
Services.
11
SOA & Workflow
Service-Auslagerungstruktur

Durch die Auslagerung entsteht ein
Workflow.

Orchestration von Services
VerkaufsProzess
Service-Hierarchie

Ein Service wird unterteilt in TeilServices und ausgelagerten
Services, die zusammen einen
Workflow bilden.
SupportProzess
KundenManagement
Prozess
12
Zusammenfassung

Die Services sind die Bausteine der Verarbeitung.

Sie liefern den Business Value.

Es gibt Individual- und Standard-Services.

Die Services haben diverse Granularitäten:

Ebene Prozess

Ebene Task

Ebene Teil-Task (Teil-Teil-Task, ...)

Ebene atomare Services

Die Services bilden eine Service-Auslagerungstruktur.

Die Services bilden einen Workflow (Orchestration, Choreography).

Die Services bilden unter sich eine Service-Hierarchie.

Aufgrund der Individuell-Standard Optimierung
SOA ist ein Prinzip zur Strukturierung der Services
Die Kriterien sind Redundanzfreiheit und Wiederverwendbarkeit
13
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
14
SOA & BPM
Business
Corporate
Process Model
(CPM)

Integration
SOA und BPM sind untrennbar


Prototyping

IT (Code)
Library of atomic
generic Services
Modeling
Task Model
(TM)
Logic
Process Model
(PM)
SOA ist eigentlich nur ein Strukturierungsprinzip von BPM
Der wesentliche Teil der Services ist rein modell-basiert !
Nur die atomaren Services sind code-basiert !

Wie viele Arten von atomaren, generischen Services werden benötigt ?
15
SOA & BPM
Business
Process Model
(PM)
Logic
...
Corporate
Process Model
(CPM)
Die Anzahl der atomaren, generischen Services ist klein


Ca. 100 allgemeine, je nach Branche weitere
Code-Reduktion:


Integration

Prototyping
Library of atomic
generic Services
IT
(Code)
Task Model
(TM)
Modeling
...
Gegenüber konventioneller Software ergibt sich eine Reduktion um Zehnerpotenzen !
SOA bedeutet ‚Modell-basierte Software‘ !
16
SOA & BPM : BPEL
Beispiel

BPEL (links)




Business Process Execution Language (BPEL) für Orchestration von Services
XML-based language (description) für SOA
Einige ? betreffend BPEL (see John Evdemon)
Prozessdarstellung (rechts)
Traveler
Process
Travel Service
Agent
Process
Airline Service
By John Evdemon, Architect Microsoft
Co-Chair, Oasis WS-BPEL Technical Committee
Airline
Process
17
SOA & BPM: Case-Orientierung
Memory
Data
Layer
Case
Process/Task
Layer
Task Case
Input
variables
Output
variables
Outcomes
Entry
Service
Data
Base

Services liefern einen Business Value.




Auch Work Item genannt
Durch Klassenmodell beschrieben (BOM)
Der Case ist memory-resident


Der Business Value besteht aus Daten (Informationen)
Daten bilden den Case (Prozess-Case, Task-Case, ...)


Persistant
DB
Layer
Performance
Die Services kommunizieren untereinander über den Case.
Rules basieren auf dem Case (data-driven).
18
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
19
Model-Based (Model-Driven) Architecture



Auch ‚Model-Driven Architecture‘ (MDA) genannt.
Die gesamte geschäftliche Logik liegt im Modell.
Die Plattform umfasst Engines und atomare,
generische Services, die die geschäftliche Logik
ausführbar machen.
Business Prozess
1 Prozessunterstützende Software



Kunde,
Angestellter,
Manager
Business
Engineer
Administrator
BPM-basierte Software getrieben
durch das Modell
Plus eLearning, Knowledge
Management, Controling, Reporting
2 Administrative Software


BPM-basierte Software getrieben
durch das Modell; verändert teilweise
das Modell
3 BPM Software (BE Umgebung)


1
2
3

Software
Engineer
Integriertes Geschäfts-Modell
Process-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
4

BPM-basierte Software für das
‚Business Process Management‘
Methodische Kompetenz zur ProzessOptimierung
Inkl. Project Management: Planing &
Controling des Projektes
4 Model-Based Programming


MDSD ... Model-Driven Software
Development
20
Model-Based (Model-Driven) Architecture


Das Modell muss fähig sein, den gesamten ‚Business Logic Content‘ zu
umfassen.
Die diversen Arten von ‚Business Logic Content‘ müssen unterstützt werden:







Workflow Logic incl. Event-Logic
Rule Logic (BRM)
Business Object Logic (BOM)
Business Content Logic
User-Interface Logic
Functional Logic
Concept Logic – Ontology
Komplettes Modell – Wieso?

Nur ein komplettes Modell ist direkt ausführbar.

Ist Modell nicht komplett, dann können nur gewisse Typen von Anwendungen
erstellt werden.

Der Business Engineer muss an allen Modellen gleichzeitig arbeiten können !
21
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
22
Enterprise Content
Der Enterprise Content umfasst:

Die gesamte Logik, wie Prozesse manuell und automatisch (elektronisch)
durchgeführt werden.





Die Daten, die für die Bearbeitung benötigt werden und die bearbeitet
werden.


Workflow Logik
Regel Logik (BRM)
User-Interface Logik (WEB2.0)
Funktionale Logik
Datenlogik (BOM)
Die unstrukturierten Daten einer Unternehmung.


(Document) Content Logik
Ontologie (Begriffliche Logik)
Also:

Business Logik

Daten

Dokumente
23
ECM: Corporate Knowledge - Enterprise Content
Corporate
CK as Competence
Knowledge
Business
Processing
(CK)
(EC ... Enterprise Content)
CK as Information
Dynamic
Business Logic
(Competence)
Operational
Agility
Corporate Knowledge = Enterprise Content
Corporate Knowledge hat 2 Rollen:

‚Controling & driving‘ des Business Processing



‚Being processed‘ durch das Business Processing



CK = Business Logic: Business Logic Content (Competence) des BPM Modelles
Beispiel: Die Business Prozess Logik, um Rechnungen zu prüfen.
CK als Information
Beispiel: Rechnungen, die geprüft werden
Corporate Knowledge in beiden Rollen

Z.B. Business Rules, die gepflegt werden und die die Verarbeitung steuern.
24
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
25
Moderne Software-Architektur
Geschäft
Business
Engineering
Administration
Kombination der Prinzipien:

Service-Based

Model-Driven

Prozess-Oriented

Software
Engineering
Integriertes Business Model:
Process-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
BPM2 Plattform
Bibliothek von Aktivitäts-Typen
IT
Engineering
Software Services
Case-Orientiert / Data-Driven
Kombination der Schlagworte:

SOA

BPM

MDA

ECM

BRM
DrittSysteme
26
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
27
Vorteile
Erwartungen Geschäft
Service-Based
Model-Driven
Process-Oriented
Hohe GeschäftsprozessUnterstützung
Optimale
Individualisierung
Umfassende und grosse
Menge an Geschäftslogik
(Geschäfts-Kompetenz)
Process-Compliance
Hohe Flexibilität
Modularisierung
Optimaler Reuse
Hoher modell-basierter
Anteil
Process-Compliance
Hohe Stabilität
Releasefähigkeit
Standard-Services
Hoch reusable Code
(atomare Services)
Tiefe Kosten
Optimale
Standardisierung
Effizienz in der ProzessOptimierung
Process-Compliance
Business Transparenz
Prototyping
Model2Execution
Process-Compliance
Hohe Performanz
Atomare Services
SOA/BPM Plattform
Horizontale Integration
Daten memory-resident
Weitere Vorteile:

Outsourcing-Option

Migrations-Option aus Legacy
28
SOA / BPM als ‚Disruptive Technology‘

Alternative zu konventionell erstellten IT-Lösungen


Ersatz von konventionell erstellten IT-Lösungen





Gibt es heute noch Gründe für die Erstellung von konventionellen
Lösungen?
‚Cobol‘-Lösung nicht durch ‚Java‘-Lösung ersetzen!
Weil: Die Probleme bleiben die gleichen oder werden noch grösser, weil
die Anforderungen wachsen.
Erweiterung von konventionell erstellten IT-Lösungen.
Migration von konventionell erstellten IT-Lösungen.
Merge von konventionellen IT-Lösungen


Aufgrund von Firmenzusammenschlüssen und Neustrukturierungen.
Es wird eine Prozess-Schicht über die redundanten Systeme gelegt.
Process
Layer
Basis
System x
Basis
System y
Basis System
Layer
29
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
30
Traditionelle Lösungen versus SOA Lösungen
Insellösungen (stove pipes, silos)
Application
Application
Application
Code
Code
Code
Application
Application
Application
Code
Code
Code
Application
Solution
Application
Solution
Application
Solution
Code
Code
Code
IT
IT
IT
Solution
Code
IT
IT
IT
IT
IT
IT
DB
DB
DB
DB
DB
DB
DB
DB
DB
IT-Platform
IT
DB

Business
Process
Model
Business
Process
Model
Business
Process
Model
BPM Platform
DB
DB
DB
Business
Process
Model
IT
DB

IT verlangt einheitliche
kompakte Plattform
Business verlangt
prozess-orientierte,
entkoppelt Struktur
BPM: beides

Solutions entkoppelt

Plattform kompakt
31
Traditionelle Lösungen versus SOA Lösungen
Insellösungen (stove pipes, silos)
Application
Application
Application
Application
Code
Code
Code
Code
Application
Application
Application
Application
Code
Code
Code
Code
Application
Application
Application
Application
Code
Code
Code
Code
IT
IT
IT
IT
IT
IT
IT
IT
IT
IT
IT
IT
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
DB
Vertikale Systeme
werden ersetzt durch
Range of Industries
Business
Process
Model
Business
Process
Model
Business
Process
Model
BPM Platform
DB
DB
DB
Business
Process
Model
IT
DB
Business Process
Modelle
+
SOA / BPM Platform
32
Migration
Silo (Stove Pipe) Application Architecture
User
Interface
Layer
SOA-Based (BPM-Based) Application Architecture
Process
Layer
Main
Module
Layer
Business
Service
Function
Module
Layer
Business
Service
Layer
Data
Layer
Data
Layer
Pragmatic, stepwise, riskless & economic way for migration !
Immediate Benefit for Business !
No extraordinary investments, minimal risk !

Mit SOA (BPM) kann eine risikolose Migration durchgeführt werden.

Schrittweise

Kosteneffizient
33
Migration: Ausgangssituation
User
Interface
Layer
Main
Module
Layer
Business
Service
Function
Module
Layer
Data
Layer
34
Migration: Erste migrierte Business Prozesse
Process
Layer
User
Interface
Layer
Main
Module
Layer
Business
Service
Layer
Business
Service
Function
Module
Layer
Data
Layer
Data
Layer
35
Migration: Weitere migrierte Business Prozesse
Process
Layer
User
Interface
Layer
Main
Module
Layer
Business
Service
Layer
Business
Service
Function
Module
Layer
Data
Layer
Data
Layer
36
Migration: Elimination der ersten Silo Anwendungen
Process
Layer
User
Interface
Layer
Main
Module
Layer
Business
Service
Layer
Business
Service
Function
Module
Layer
Data
Layer
Data
Layer
37
Migration: Die perfekte SOA/BPM Welt
Process
Layer
Business
Service
Layer
Data
Layer
38
Migration: Die perfekte SOA/BPM Welt
Process
Layer
Business
Service
Layer
Data
Layer
39
Szenarium: Outsourcing
Anforderungen Unternehmen

Inhouse Business Engineering
für Business Prozess
Optimierung

Die geschäftliche Kompetenz
muss im Hause bleiben !
Anforderungen Lösungen:

Hohe administrative Flexibilität
Kunde,
Angestellter,
Manager
Administrator
Business
Engineer
Software
Engineer
Integriertes Geschäfts-Modell
Process-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
Anforderungen Business Prozess Engineering Plattform

Ausgerichtet auf den Business Engineer (nicht Software Engineer)

Optimale Unterstützung des Prozess Management Zyklus

Requirement Management, Modellierung, Prototyping
40
Szenarium: Inhouse IT
Anforderungen Unternehmen

Inhouse Business Engineering für
Business Prozess Optimierung




Kunde,
Angestellter,
Manager
Administrator
Business
Engineer
Die geschäftliche Kompetenz muss
im Hause bleiben !
Innerhalb Informatik
Ausrichtung der Informatik auf
neue Software Architektur
Enge Zusammenarbeit von
Business und Software
Engineering
Software
Engineer
Anforderungen Lösungen:

Migration der bestehenden
Lösungen
Integriertes Geschäfts-Modell
Process-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
Anforderungen Business Prozess Engineering Plattform

Optimale Unterstützung des Prozess Management Zyklus


Offene Plattform


Requirement Management, Modellierung, Prototyping
IT muss die Plattform transparent haben (Sourcecode)
Plattform für Software- und Business-Engineering

Migration zur modernen Software-Architektur
41
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
42
Arten von Plattformen
Art der Plattform:
ProcessModeling
EAI
Workflow Mgt
(BPM1.0)
BPM2.0
Macro-Workflow
+++
+++
+++
+++
Micro-Workflow
-++
---
---
+++
--+
--+
--+
+++
Learning, Document Mgt,
Project Mgt, Knowlegde
Mgt, Performance Mgt
---
---
+++
+++
ECM
---
---
-++
+++
SOA
--+
+++
-++
+++
--+
--+
--+
+++
Modellierung
SystemIntegration
SystemIntegration,
Workflow
Neues
Software
Paradigma
Einsatz:
Modell-Basiert:
Vollständigkeit der
modellierbaren Logik
PlattformFunktionalität:
Model2Execution:
Prozess Mgt Zyklus
Ziel / Aufgabe:
43
Positionierung im Markt
Plattform
Typ
Beispiele
Business
Modeling
WebSpere
BPMS (IBM),
Oracle, Visio
(MS), SAP, ...
Metastorm (eWorkflow Works),
(BPM 1.0) filenet,
ultimus, ...
EAI
BPM 2.0
Seebeyond,
axway,
biztalk, e2e,
...
Intalio, Pegasystem,
Savvion,
abaXX, eServe BPM2
Ansatz
Process
Modeling
(+)++
-++
--+
(+)++
SOA
---
-++
+++
+++
Beurteilung
Applicat.
VollCode
Eignung
ständig. Replace Business
Integrat. Modell
-ment
Analyst
MDA
Bemerkung
---
Kombination von
Modeling Tool und
Development Plattform
notwendig; Integration
mittels BPEL
--+
Fokus auf der
Koordination von
bestehenden
Anwendungen;
kommen aus dem WFM
und Document
Management
-++
--+
--+
Fokus auf der
Integration von
bestehenden
Anwendungen
+++
--+
Umfassende Erfüllung
der Kriterien von BPM
(+)++ wie Koordination,
‚Executable Model‘ und
‚Code Replacement‘.
---
(+)++
--+
(+)++
Bermerkung
+++
Gap zwischen Design und
Implementation.
Komplexere
Prozesslösungen nur
konventionell möglich.
--+
-++
Ist eine Erweiterung von
konventionellen Lösungen.
Komplexere
Prozesslösungen nur
konventionell möglich
--+
---
---
(+)++
(+)++
Komplexere
Prozesslösungen nur
konventionell möglich
Kompletter ParadigmaWechsel (disruptive
technology). Komplexeste
Prozesse können hoch
automatisiert und
autonomisiert werden bei
wesentlich tieferen Kosten.
Neu: Spezielle Plattform für
Business Analyst
44
BPMS: BPMS 2006 Report
Bruce Silver Associates, The 2006 BPMS Report
45
Inhalt

Erwartungen des Geschäftes

SOA: Prinzip

SOA & Business Process Management (BPM)

SOA & Model-Based Architecture (MDA)

SOA & Enterprise Content Management (ECM)

SOA: Moderne Software Architektur

Merkmale

Vorteile

Nutzung

Plattformen

Die Roadmap
46
Summary

SOA ist keine technologische Herausforderung

SOA ist eine Business Engineering Herausforderung

SOA bedeutet auch BPM, MDA, ECM, BRM



Deren Kombination bildet die neue Software-Architektur

Paradigma-Wechsel, Disruptive Technology
Investieren Sie ins Business Engineering

Gefordert im individuellen Teil

Kaufen des Standard Teil
Beziehen Sie die Plattform-Technologie

Wenn Sie eine Inhouse IT haben

Die Plattform-Technologie muss offen sein (Source-Code)
47
SOA-Roadmap
Implementierung einer modernen Software-Architektur

Erstellung einer Roadmap




Aufstellen eines Business Engineering Team



Profil Projektleiter, die Geschäft kennen
Aufbau Business Engineering Kompetenz
Evaluation



Wie sieht die Software-Architektur heute aus?
Welche Geschäftsprozesse sind Kernprozesse (individuell)?
Wer: Kleines Team von massgebenden Personen inkl. externer Beratung
(der Aufwand ist gering; Tage)
Business Engineering Plattform (SOA, BPM)
Outsourcing Partner
Durchführen der Migration

Business Engineering getrieben; nicht IT-getrieben
Das Vorgehen bleibt prinzipiell das gleiche, ob grosse oder kleinere
Organisation.
48
Anhang:
Diskussion


Welche Rolle spielt UML 2.0?
Abhängigkeit von einer Plattform?
50
Model & Types of Application
Type of Solution
UI Workflow
DB Processing
Document
Processing
Work-Group
Case
Management
User
Interface
+++++
+++++
++++
+++++
+++++
MakroWorkflow
+++++
+++++
++++
+++++
+++++
+++
+++++
+++++
+++
+++++
+++++
+++++
+++++
+++++
+++
Logic
MicroWorkflow
Business
Rules
+++
Business
Objects
+
Business
Content
+
Data Base
Functional
Ontology
+++
+++
+++++
+++++
++++
Transaction
Processing
Knowledge
Processing
+++++
+++++
+++
+++++
+++
+++
+++++
+++++
+++
++
++
++
++
+++
+++
+++
+++++
++++
+++++
51
Choreography versus Orchestration




Choreography is concerned with interaction and conversation of Web
Services, wherein languages, communication technologies, formal models
along with techniques for operations like service compatibility determination
or validity checking of conversation protocols is of interest. Orchestration
is concerned with arrangement of several services to a more complex
functionalities, wherein mainly service composition are of interest.
Choreography and Orchestration with Web Services are considered as the
enabling technologies of Web Service based process management.
Bei der Orchestrierung, gibt es jemanden - den Dirigenten - der den
Orchestermitgliedern sagt, was sie zu tun haben und sicherstellt, dass der
Takt eingehalten wird. Bei der Choreographie folgen die Tänzer einem
definierten Plan - aber jeder unabhängig voneinander.
Die Definition ist gleichzeitig eine gute Gedächtnisstütze, da die Analogie
perfekt zu den Begriffen passt. Eine weitere Definition von Paul Downey
vergleicht Orchestration mit einer zentral gesteuerten Ampel, bzw.
Choreography mit einem Kreisverkehr, wo jeder Teilnehmer Regeln folgt,
denen zuvor zugestimmt wurde.
Der Unterschied zwischen den beiden Begriffen ist, und da sind sich die
meisten Kommentatoren einig, jedoch eher akademischer Natur. Der Nutzen
der Unterscheidung in der Praxis ist eher gering.
52
WEB-Services: Registry / Repository (UDDI.org)
Wikipedia:

UDDI (Universal Description, Discovery and Integration) ist ein Begriff
aus der Computertechnik und bezeichnet einen Verzeichnisdienst, der die
zentrale Rolle in einem Umfeld von dynamischen Web Services spielen soll.

Der Verzeichnisdienst besitzt eine SOAP-Schnittstelle. Er enthält
Unternehmen, ihre Daten und ihre Services. Dabei kann man in UDDI
zwischen drei Arten der Informationen unterscheiden: Den "White Pages",
einer Art Telefonbuch, den "Yellow Pages", also die elektronische
Entsprechung der gelben Seiten, und den "Green Pages". Die genaue
Aufteilung mit samt der Daten, die den einzelnen Teilen entspringen werden,
sind in folgender Liste ausgeführt:

White Pages
Namensregister, sortiert nach Namen
Auflistung der Anbieter mit allen Detailangaben
Kontaktinformationen (Telefon, Telefax,...)

Yellow Pages
Branchenverzeichnis
Spezifische Suche gemäß verschiedener Taxonomien (Ort, Dienstart,...)
Verweist auf White Pages
Klassifiziert die Services anhand internationaler Standards wie UNSPSC

Green Pages
Informationen über das Geschäftsmodell des Unternehmens
Technische Details zu den angebotenen Web Services
Auskunft über Geschäftsprozesse
53
Case Study: Swisscom IT Services AG
Health Prozesse anhand Leistungs-Management
Hans-Jürgen Gerdum, Swisscom IT Services AG,
[email protected]
www.swisscom.com
Roland Bendelac, e-Serve AG,
[email protected]
www.e-serve.ch
Case Study: Steria Schweiz AG
Beispiel Bank-Prozess
Thomas Rathmann, Steria Schweiz AG,
[email protected]
www.steria.ch

SOA & BPM - e-Serve Net AG, Münchenstein