Di 7.3. MDSD und SOA und BPM - wie passt das zusammen? Peter Friese Thomas Stahl

Transkript

1 Di 7.3 January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich MDSD und SOA und BPM - wie passt das zusammen? Peter Friese Thomas Stahl

2 Peter Friese Tom Stahl Erläuterung der Kernkonzepte BPM und SOA - Herausforderungen MDSD und SOA / BPM heutige Ansätze MDSD und SOA / BPM ungelöste Probleme MDSD und SOA / BPM Lösungsansätze Fazit

3 target software architecture several Development Process multistep singlestep precise / formal Domain M2M transform Model M2T automated no roundtrip knowledge Template engine Metamodel proteced regions Metametamodel Domain Specific Language graphical textual 3 Metamodell <<instanceof>> Modell MDSD Generator generierte Artefakte manuell entwickelte Artefakte (optional) Zielplattform 4

4 Generator Framework Generative Architektur Domänenspezifische Anwendung Validator validiert instanceof Modell DSL M2M Engine M2T Engine führt aus führt aus M2M Transformations M2T Transformations generierte Artefakte manuell entwickelte Artefakte (optional) stützt sich auf stützt sich auf Workflow Engine Plattform Generator Framework Generative Architektur Domänenspezifische Anwendung validiert Constraints Finance Metamodel instanceof Vermögensmanagement Modell grafische DSL führt aus führt aus M2M Transformations M2T Transformations generierte Artefakte manuell entwickelte Artefakte stützt sich auf stützt sich auf Finance-Plattform

5 Modell = vereinfachte, formale (!) Abbildung der Realität Metamodell Beschreibt, wie ein Modell aufgebaut ist (sorgt somit für Formalität) Definiert die abstrakte Syntax der Modellierungssprache (konkrete Syntax kann z.b. grafisch oder textuell sein) Metamodelle werden auch durch Metamodelle beschrieben => Metametamodell Wohlbekanntes Beispiel: UML (Unified Modeling Language) Metametamode l M3 MOF E-MOF Metamodel M2 UML YourOwnMeta model Model M1 Model Model Instance M0 Instance Instance Conceptual UML EMF / Ecore 7 Architekturstil (Enterprise-Level) als führendes Paradigma lose gekoppelte Nutzung der über (entfernte) Aufrufe Kapselung durch implementierungsunabhängige Schnittstellen Servicevertrag spezifiziert funktionale und nicht-funktionale Merkmale (Metadaten) der Schnittstelle Fein-granulare können zu grobranularen orchestriert werden Management-Paradigma (Governance) realisieren Geschäftsfunktionen => Orientierung an Geschäftsprozessen / Unternehmensstrategie, Flexibilisierung von Geschäftsprozessen Re-Use Management, Service-Mining (Top-Down und Bottom-Up)

6 Management-Paradigma (Governance) Mittel zur Optimierung von Geschäftsprozessen (Define -> Create -> Execute -> Monitor -> Optimize) Betriebswirtschaftliche Transparenz: BAM (Business Activity Monitoring) Architekturstil (Enterprise-Level) Prozesse als führendes Paradigma Definition von Kontrollfluß (Aktivitäten / Transitionen) und Informationsfluß (Objekte, Produzent / Konsument) Aktivitäten benutzen oder sind im Sinne von SOA Verhältnis BPM und SOA These: BPM ist Bestandteil von SOA, auch Prozesse können wieder sein -> SOA führt Antithese: BPM benötigt SOA -> BPM führt Synthese: BPM ist das Endbenutzer-sichtbare Frontend von SOA und Interaktivität These: besitzen keine Oberfläche Antithese: Auch UseCases (von Anwendungen) sind (Business-) Synthese: Oberflächen selbst können sein (Mash-Up) und mit nicht-interaktiven orchestriert werden

7 Erläuterung der Kernkonzepte BPM und SOA - Herausforderungen MDSD und SOA/BPM heutige Ansätze MDSD und SOA/BPM ungelöste Probleme MDSD und SOA/BPM Lösungsansätze Fazit Geschäftsprozess modellierung Struktur / Statik <<compose>>? Workflow (ausführbar) Facharchitektur / Domänenmodell <<realize>> <<realize>> fachlich technisch Abstraktionsniveau Verhalten /Dynamik <<compose>> Technische Architektur /

8 Struktur / Statik Facharchitektur Geschäftssysteme Fachkomponenten Geschäfts- Geschäftsobjekte/Entitäten Technisches-Design Service-Definitionen Deployment-Descriptoren Entitäten/Persistenz/Transaktionen Übergang Methodisch, echter Informationsgewinn => nicht vollständig automatisierbar <<realize>> WF formal GPM Facharchitektur Fachlich / nicht formal Abstraktionsniveau Verhalten /Dynamik Verhalten /Dynamik Struktur / Statik GPM <<realize>> Abstraktionsniveau Facharchitektur WF Workflow automatisiert Geschäftsprozesse ganz oder teilweise (Unterschiedliche Automationsstufen) Übergang: Methodisch, echter Informationsgewinn (kein einfacher Filter) => nicht vollständig automatisierbar Quelle:

9 Abstraktionsniveau Verhalten /Dynamik GPM WF <<realize>> <<compose>> <<compose>> Struktur / Statik Technische bilden Baukasten für Workflow- Definitionen (-> SOA) Analog sollten Geschäfts- als Baukasten für Geschäftsprozesse dienen Facharchitektur <<realize>> Anforderungen aus dem Baukasten-Paradigma und den methodischen Übergängen: Recherchierbarkeit Versionierbarkeit Traceability Kompatibilität und Integrität an den Partitionsgrenzen Erläuterung der Kernkonzepte BPM und SOA - Herausforderungen MDSD und SOA/BPM heutige Ansätze MDSD und SOA/BPM ungelöste Probleme MDSD und SOA/BPM Lösungsansätze Fazit

10 MDSD eignet sich zur Beschreibung und Entwicklung SOA-basierter Systeme Abstraktionsniveau Verhalten /Dynamik GPM WF Struktur / Statik Facharchitektur Beschreibung durch Modelle: Service-Signaturen und Typsystem Gültige Interaktionen zwischen QoS-Verträge Komponenten (Provider / Consumer) Generierung aus Modellen: Registry und Repository Einträge Watchdog-Code für QoS Deployment-Code für unterschiedliche Plattformen Mappings auf Kommunikations- Infrastrukturen (Web, JMS, Tibco ) Prozessmodelle sind MDSD-Modelle Abstraktionsniveau Verhalten /Dynamik GPM WF Struktur / Statik Facharchitektur BPM-Tool zur Prozessmodellierung benutzen Konsistente Betankung der BPM- Runtime. Beispiel 1: BPMN-> M2MT->BPEL->BPEL-Engine Beispiel 2: KPI-Def als Konfigurationsmodell -> Model-Weaving mit Prozessmodell -> BAM-Engine

11 MDSD löst nicht die methodischen Übergänge, kann diese aber stützen Verhalten /Dynamik Struktur / Statik Typisches Missverständnis Die von der OMG spezifizierte M2M Transformation von BPMN nach BPEL GPM Facharchitektur ist genau der Übergang zwischen den Partitionen GPM und Workflow Auflösung WF Syntax-Transformation ( grafisch nach textuell ) BPMN kann tendenziell in beiden Partitionen verwendet werden Abstraktionsniveau/Informationsgehalt ist unterschiedlich (vgl. Analyse <-> Design) Ggf. WF-Initialgenerierung aus den zu automatisierenden Anteilen eines GP- Modells Abstraktionsniveau Erläuterung der Kernkonzepte BPM und SOA - Herausforderungen MDSD und SOA/BPM heutige Ansätze MDSD und SOA/BPM ungelöste Probleme MDSD und SOA/BPM Lösungsansätze Fazit

12 Integration/Konsistenz zwischen allen vier Partitionen derzeit nicht zufriedenstellend gelöst (Insellösungen) Methodischer Übergang zwischen Fachlichkeit und Technik ist nicht werkzeuggestützt Schlecht koppelbare Metamodelle der Partitionen Partitionsübergreifende Recherchierbarkeit Partitionsübergreifende Versionierbarkeit Partitionsübergreifende Traceability GPM-Repository Traceability Integrität Traceability Integrität Facharchitektur-Repository Leitfrage: Was zeichnet die Insel- Repositories aus? Feste fachliche Strukturen (z.b. kann das SOA-Repository i.w. nur verwalten), aber Traceability Integrität Workflow-Repository SOA-Repository Traceability Integrität gleiche bzw.ähnliche Features Unterschiedliche Handhabung Nicht synchron

13 Erläuterung der Kernkonzepte BPM und SOA - Herausforderungen MDSD und SOA/BPM heutige Ansätze MDSD und SOA/BPM ungelöste Probleme MDSD und SOA/BPM Lösungsansätze Fazit Traceability (lokal) GPM-Repository Traceability (lokal) Facharchitektur-Repository Batch-Synchronisierung/ Import + Bisherige Tools können unverändert genutzt werden - Es kann nur Information importiert werden, die vom jeweiligen Repository verstanden wird - Datenaktualität und damit konsistenz nicht gegeben - Transferinfrastruktur muss geschaffen / gewartet werden Traceability (lokal) Workflow-Repository Traceability (lokal) SOA-Repository Verbindung über Namenskonvention + Traceability über Reporting in Grenzen möglich - Weiche Informationen: Konsistenz durch Disziplin Externe Informationen / Bridges + Nicht-invasive Toolunterstützung für Traceability und Recherchierbarkeit in Grenzen möglich - Sehr aufwändig - Tragfähigkeit unklar Essenzielle Repository-Features sind zwar lokal aber nicht (ohne Weiteres) übergreifend konsistent verfügbar Die klassischen Integrationsansätze lösen die Probleme nicht

14 Strukturen sind prinzipiell frei definierbar / konfigurierbar -> flexible Metamodelle Vordefinierte Kern-Strukturen zum Aufsetzen von Business-Logik -> fixe Core-Metamodelle Strukturen sind in einer Sprache formuliert -> einheitliches Meta-Metamodell Repository Features stehen homogen und partitionsübergreifend zur Verfügung Repository Features redundanzfrei implementiert -> keine Synchronisations-Mechanismen erforderlich Traceability Integrität GPM-Metamodelle Ereignisorientierte MM EPK Ablauforientierte MM BPMN UML - Activity Workflow-Metamodelle WfmC BPMN UML-Activity BPEL Facharchitektur-Metamodelle und -Core-Modelle VAA (Versicherungen) AUTOSAR (Automotive) SOA-Metamodelle WebService MM Service/Komponenten-MM CORBA EDOC-ECA/CCA SCA

15 ProcessDefinition * <<realize>> Activity Geschäftsservice 1 <<automate>> realize ProcessDefinition * Activity * <<call>> ServiceInterface Recherchierbarkeit, Traceability, Versioning Definierbarkeit / Validierbarkeit von Konsistenzbedingungen zwischen den Partitionen Baukastenprinzip wird möglich Verbesserung des Entwicklungsprozesses Unterschiedliche Ein-/Ausgabekanäle möglich durch Entkopplung von abstrakter Syntax (MM) und konkreter Syntax (DSL/Frontend/Editor) Die methodischen Übergänge zwischen den Quadranten sind auch mit diesem Ansatz in aller Regel nicht vollständig automatisierbar (Informationsgewinn)

16 Erläuterung der Kernkonzepte BPM und SOA - Herausforderungen MDSD und SOA/BPM heutige Ansätze MDSD und SOA/BPM ungelöste Probleme MDSD und SOA/BPM Lösungsansätze Fazit MDSD-Ansätze sind im SOA/BPM-Umfeld bereits heute nutzbar bzw. etabliert. Die Vision eines partitionsübergreifenden, integrierten Model-Repositories eröffnet neue Möglichkeiten für ein ganzheitliches Engineering und Management.

17 Danke für Ihre Aufmerksamkeit! Fragen? Thomas Stahl Peter Friese