SOA:
Licht in den BegriffdschungelDonnerstag, 24. Mai, 9.15 bis 10.45
Dr. Dieter Wenger, Wenger Competence Consulting, [email protected], Tel. 079 237 1001
2
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.
3
Agenda
SOA & Moderne Software Architektur (35 Minuten) Wenger Competence Consulting
Case Study: Health (20 Minuten) Swisscom Information Services (SCIS) AG e-Serve AG
Case Study: Banking (20 Minuten) Steria Schweiz AG
Diskussion (15 Minuten)
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
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
6
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
Automatisierung, Benutzerunterstützung (Autonomisierung) Business Compliance / Business Orientierung
Hohe Flexibilität Hohe administrative Flexibilität Schnelle Umsetzung von neuen geschäftlichen Anforderungen Strategische Optionen
Hohe Stabilität Tiefe Kosten
Geringe Betriebs- und Prozessoptimierungs-Kosten Kontrolle durch Business / Transparenz für Business Hohe Performanz
7
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
8
SOA: Prinzip Redundanzfreiheit
Ein Geschäftsprozess ist ein Service !
Outsourcing Teile von Prozessen, die in verschiedenen
Prozessen gleich sind, werden in einen neuen Prozess ausgelagert.
Auslagerung von Services. Es entsteht eine Service-
Auslagerungstruktur
Beispiel: Der Service ‚Kunde aufnehmen/mutieren‘ ist
in 2 verschiedenen Prozessen gleich.
Vorteile: Reuse Eliminierung Prozess-Redundanz
(Ressourcen) Eliminierung Daten-Redundanz
Verkaufs-Prozess
Support-Prozess
Verkaufs-Prozess
Support-Prozess
Kunden-Management
Prozess ... Service ‚Kunde aufnehmen/mutieren‘
9
SOA: Prinzip Standardisierung
Individualisierung versus Standardisierung
Standard-Service Merkmal
Hoher Reuse (hoher Nutzungs-Entwicklungs Faktor) Vorteile
Hohe, anhaltende Qualität Best-of-Breed Tiefe Kosten
Nachteile Keine Individualität
Lösung: Optimale Aufteilung in Standard- und Individual-Services.
10
SOA: Individualität versus Standardisierung
1. Unterteilung der Services in Teil-Services (Teil-Teil Services, ...):
1. Bis ein Teil-Service 100% Standard oder 100% individuell.
2. Bis zu atomaren Services.
2. Auslagerung der Standard Teil-Services (Teil-Teil Services, ...)
3. Identifikation von gleichen Teil-Services
Nutzen:
Voraussetzung für Release-Management
11
SOA: Aufbau der Service-Orientierten Architektur
Individuell Standard
Reuse nein --- Auslagerung
ja Auslagerung Auslagerung
Aufbau der Service-Architektur
Mittels Auslagerung Identifikation von gleichen Services
Ziel:
Mächtige (viel Business Value) sich nicht überschneidende Services.
12
SOA & Workflow
Service-Auslagerungstruktur Durch die Auslagerung entsteht ein
Workflow. Orchestration von Services
Service-Hierarchie Ein Service wird unterteilt in Teil-
Services und ausgelagerten Services, die zusammen einen Workflow bilden.
Verkaufs-Prozess
Support-Prozess
Kunden-Management
Prozess
13
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
14
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
15
SOA & BPM
IT (C
od
e)
Library of atomic generic Services
CorporateProcess Model
(CPM)
Process Model(PM)
Task Model(TM)
Inte
gra
tion
Prototyping
Business Logic M
odeling
SOA und BPM sind untrennbar 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 ?
16
SOA & BPM
IT
(Code)
CorporateProcess Model
(CPM)
Process Model(PM)
Task Model(TM)
Integra-tion
Prototyping
Business Logic M
odeling
...
...
Library of atomic generic Services
Die Anzahl der atomaren, generischen Services ist klein Ca. 100 allgemeine, je nach Branche weitere
Code-Reduktion: Gegenüber konventioneller Software ergibt sich eine Reduktion um Zehnerpotenzen !
SOA bedeutet ‚Modell-basierte Software‘ !
17
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)
TravelerProcess
Travel Service
AirlineProcess
AgentProcess
Airline Service
By John Evdemon, Architect MicrosoftCo-Chair, Oasis WS-BPEL Technical Committee
18
SOA & BPM: Case-Orientierung
Services liefern einen Business Value. Der Business Value besteht aus Daten (Informationen)
Daten bilden den Case (Prozess-Case, Task-Case, ...) Auch Work Item genannt Durch Klassenmodell beschrieben (BOM)
Der Case ist memory-resident Performance
Die Services kommunizieren untereinander über den Case. Rules basieren auf dem Case (data-driven).
DataBase
Process/TaskLayer
MemoryDataLayer
PersistantDB
Layer
Case
Entry
Service
Inputvariables
Outcomes
Outputvariables
Task Case
19
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
20
Model-Based (Model-Driven) Architecture
Business Prozess
Prozessunterstützende Software BPM-basierte Software getrieben
durch das Modell Plus eLearning, Knowledge
Management, Controling, Reporting
Administrative Software BPM-basierte Software getrieben
durch das Modell; verändert teilweise das Modell
BPM Software (BE Umgebung) BPM-basierte Software für das
‚Business Process Management‘ Methodische Kompetenz zur Prozess-
Optimierung Inkl. Project Management: Planing &
Controling des Projektes
Model-Based Programming MDSD ... Model-Driven Software
Development
Integriertes Geschäfts-ModellProcess-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
Kunde,Angestellter,
ManagerAdministrator
BusinessEngineer
SoftwareEngineer
1 2 3
4
1
2
3
4
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.
21
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 !
22
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
23
Enterprise Content
Der Enterprise Content umfasst: Die gesamte Logik, wie Prozesse manuell und automatisch (elektronisch)
durchgeführt werden. Workflow Logik Regel Logik (BRM) User-Interface Logik (WEB2.0) Funktionale Logik
Die Daten, die für die Bearbeitung benötigt werden und die bearbeitet werden.
Datenlogik (BOM) Die unstrukturierten Daten einer Unternehmung.
(Document) Content Logik Ontologie (Begriffliche Logik)
Also: Business Logik Daten Dokumente
24
ECM: Corporate Knowledge - Enterprise Content
Corporate Knowledge = Enterprise Content
Corporate Knowledge hat 2 Rollen: ‚Controling & driving‘ des Business Processing
CK = Business Logic: Business Logic Content (Competence) des BPM Modelles Beispiel: Die Business Prozess Logik, um Rechnungen zu prüfen.
‚Being processed‘ durch das Business Processing 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.
Corporate
Knowledge
(CK)
(EC ... Enterprise Content)
Business Processing
CK as Competence
CK as Information
Dynamic Business Logic (Competence)
OperationalAgility
25
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
26
Moderne Software-Architektur
Kombination der Prinzipien: Service-Based Model-Driven Prozess-Oriented
Case-Orientiert / Data-Driven
Kombination der Schlagworte: SOA BPM MDA ECM BRM
ITEngineering
Dritt-Systeme
BPM2 Plattform
Integriertes Business Model:Process-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional ModelSoftwareEngineering
Software Services
Bibliothek von Aktivitäts-Typen
BusinessEngineering
Geschäft Administration
27
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
28
Vorteile
Erwartungen Geschäft Service-Based Model-Driven Process-Oriented
Hohe Geschäftsprozess-Unterstützung
Optimale Individualisierung
Umfassende und grosse Menge an Geschäftslogik (Geschäfts-Kompetenz)
Process-Compliance
Hohe FlexibilitätModularisierungOptimaler Reuse
Hoher modell-basierter Anteil
Process-Compliance
Hohe StabilitätReleasefähigkeitStandard-Services
Hoch reusable Code (atomare Services)
Tiefe Kosten Optimale Standardisierung
Effizienz in der Prozess-Optimierung
Process-Compliance
Business TransparenzPrototypingModel2Execution
Process-Compliance
Hohe PerformanzAtomare ServicesSOA/BPM Plattform
Horizontale IntegrationDaten memory-resident
Weitere Vorteile: Outsourcing-Option Migrations-Option aus Legacy
29
SOA / BPM als ‚Disruptive Technology‘
Alternative zu konventionell erstellten IT-Lösungen Gibt es heute noch Gründe für die Erstellung von konventionellen
Lösungen? Ersatz von konventionell erstellten IT-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.
BasisSystem x
Basis SystemLayer
BasisSystem y
ProcessLayer
30
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
31
Traditionelle Lösungen versus SOA Lösungen
IT verlangt einheitliche kompakte Plattform
Business verlangt prozess-orientierte, entkoppelt Struktur
BPM: beides Solutions entkoppelt Plattform kompakt
DB DB DB DB
BPM Platform IT
BusinessProcessModel
BusinessProcessModel
BusinessProcessModel
BusinessProcessModel
DBDB
SolutionCode
ITDB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
SolutionCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
SolutionCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
SolutionCode
IT-Platform
Insellösungen (stove pipes, silos)
32
Traditionelle Lösungen versus SOA Lösungen
Vertikale Systeme
werden ersetzt durch
Business ProcessModelle
+SOA / BPM Platform
DB DB DB DB
BPM Platform IT
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
DB
IT
ApplicationCode
BusinessProcessModel
BusinessProcessModel
BusinessProcessModel
BusinessProcessModel
Range of Industries
Insellösungen (stove pipes, silos)
33
Migration
Mit SOA (BPM) kann eine risikolose Migration durchgeführt werden. Schrittweise
Kosteneffizient
ProcessLayer
BusinessServiceLayer
DataLayer
UserInterface
Layer
MainModuleLayer
BusinessFunction
Layer
DataLayer
Silo (Stove Pipe) Application Architecture SOA-Based (BPM-Based) Application Architecture
ServiceModuleLayer
Pragmatic, stepwise, riskless & economic way for migration !
No extraordinary investments, minimal risk !
Immediate Benefit for Business !
34
Migration: Ausgangssituation
UserInterface
Layer
MainModuleLayer
BusinessFunction
Layer
DataLayer
ServiceModuleLayer
35
Migration: Erste migrierte Business Prozesse
ProcessLayer
BusinessServiceLayer
DataLayer
UserInterface
Layer
MainModuleLayer
BusinessFunction
Layer
DataLayer
ServiceModuleLayer
36
Migration: Weitere migrierte Business Prozesse
UserInterface
Layer
MainModuleLayer
BusinessFunction
Layer
DataLayer
ServiceModuleLayer
ProcessLayer
BusinessServiceLayer
DataLayer
37
Migration: Elimination der ersten Silo Anwendungen
UserInterface
Layer
MainModuleLayer
BusinessFunction
Layer
DataLayer
ServiceModuleLayer
ProcessLayer
BusinessServiceLayer
DataLayer
38
Migration: Die perfekte SOA/BPM Welt
ProcessLayer
BusinessServiceLayer
DataLayer
39
Migration: Die perfekte SOA/BPM Welt
ProcessLayer
BusinessServiceLayer
DataLayer
40
Szenarium: Outsourcing
Anforderungen Business Prozess Engineering Plattform Ausgerichtet auf den Business Engineer (nicht Software Engineer) Optimale Unterstützung des Prozess Management Zyklus
Requirement Management, Modellierung, Prototyping
Integriertes Geschäfts-ModellProcess-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
Kunde,Angestellter,
ManagerAdministrator
BusinessEngineer
SoftwareEngineer
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
41
Szenarium: Inhouse IT
Anforderungen Unternehmen Inhouse Business Engineering für
Business Prozess Optimierung Die geschäftliche Kompetenz muss
im Hause bleiben ! Innerhalb Informatik
Ausrichtung der Informatik auf neue Software Architektur
Enge Zusammenarbeit von Business und Software Engineering
Anforderungen Lösungen: Migration der bestehenden
Lösungen
Integriertes Geschäfts-ModellProcess-, Data-, Rule-, Concept-, Content-,
Interface-, Event- und Functional Model
Kunde,Angestellter,
ManagerAdministrator
BusinessEngineer
SoftwareEngineer
Anforderungen Business Prozess Engineering Plattform Optimale Unterstützung des Prozess Management Zyklus
Requirement Management, Modellierung, Prototyping Offene Plattform
IT muss die Plattform transparent haben (Sourcecode) Plattform für Software- und Business-Engineering
Migration zur modernen Software-Architektur
42
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
43
Arten von Plattformen
Art der Plattform:
Einsatz:Process-Modeling
EAIWorkflow Mgt
(BPM1.0)BPM2.0
Macro-Workflow +++ +++ +++ +++
Micro-Workflow -++ --- --- +++
Modell-Basiert: Vollständigkeit der modellierbaren Logik
--+ --+ --+ +++
Plattform-Funktionalität: Learning, Document Mgt, Project Mgt, Knowlegde Mgt, Performance Mgt
--- --- +++ +++
ECM --- --- -++ +++
SOA --+ +++ -++ +++
Model2Execution: Prozess Mgt Zyklus
--+ --+ --+ +++
Ziel / Aufgabe: ModellierungSystem-
Integration
System-Integration, Workflow
Neues Software
Paradigma
44
Positionierung im Markt
Plattform Ansatz Beurteilung
Typ BeispieleProcess
ModelingSOA MDA Bemerkung
Applicat.-
Integrat.
Voll-ständig. Modell
Code Replace-ment
Eignung Business Analyst
Bermerkung
Business Modeling
WebSpere BPMS (IBM), Oracle, Visio (MS), SAP, ...
(+)++ --- ---
Kombination von Modeling Tool und Development Plattform notwendig; Integration mittels BPEL
--- --+ --- +++
Gap zwischen Design und Implementation. Komplexere Prozesslösungen nur konventionell möglich.
Workflow(BPM 1.0)
Metastorm (e-Works), filenet, ultimus, ...
-++ -++ --+
Fokus auf der Koordination von bestehenden Anwendungen; kommen aus dem WFM und Document Management
-++ --+ --+ -++
Ist eine Erweiterung von konventionellen Lösungen. Komplexere Prozesslösungen nur konventionell möglich
EAI
Seebeyond, axway, biztalk, e2e, ...
--+ +++ --+
Fokus auf der Integration von bestehenden Anwendungen
+++ --+ --+ ---Komplexere Prozesslösungen nur konventionell möglich
BPM 2.0
Intalio, Pega-system, Savvion, abaXX, e-Serve BPM2
(+)++ +++ (+)++
Umfassende Erfüllung der Kriterien von BPM wie Koordination, ‚Executable Model‘ und ‚Code Replacement‘.
(+)++ (+)++ (+)++ (+)++
Kompletter Paradigma-Wechsel (disruptive technology). Komplexeste Prozesse können hoch automatisiert und autonomisiert werden bei wesentlich tieferen Kosten.Neu: Spezielle Plattform für Business Analyst
45
BPMS: BPMS 2006 Report
Bruce Silver Associates, The 2006 BPMS Report
46
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
47
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)
48
SOA-Roadmap
Implementierung einer modernen Software-Architektur Erstellung einer Roadmap
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) Aufstellen eines Business Engineering Team
Profil Projektleiter, die Geschäft kennen Aufbau Business Engineering Kompetenz
Evaluation 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.
Anhang:
50
Diskussion
Welche Rolle spielt UML 2.0? Abhängigkeit von einer Plattform?
51
Model & Types of Application
Type of Solution
Logic UI Workflow DB ProcessingDocument Processing
Work-GroupCase
ManagementTransaction Processing
Knowledge Processing
UserInterface
+++++ +++++ ++++ +++++ +++++ +++++
Makro-Workflow
+++++ +++++ ++++ +++++ +++++ +++
Micro-Workflow
+++++ +++++ +++
BusinessRules
+++ +++ +++ +++++ +++++ +++++
BusinessObjects
+ +++++ +++++ +++
BusinessContent
+ +++++ +++++ ++++ +++++
Data Base+++ +++++ +++ +++ +++++ +++++ +++
Functional++ ++ ++ ++ +++ +++ +++
Ontology+++++ ++++ +++++
52
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.
53
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
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