Eine Normalform für Services Serviceorientierte Architektur konkret

Transkript

1 Eine Normalform für Services Serviceorientierte Architektur konkret Prof. Dr. Bernhard Humm, Oliver Juwig Software Engineering 2006 Leipzig, 30. März 2006

2 Serviceorientierte Architektur (SOA) erfolgreich gestalten: mit konkreten Regeln SOA verspricht Flexibilisierung von Geschäftsprozessen bei Reduktion von IT-Kosten Gute fachliche Architektur der ITAnwendungslandschaft entscheidend Defizit in SOA-Literatur: konkrete Regeln Quasar Enterprise: Regeln zum Design von Komponenten und Services Beispiel: Normalform für Services sd&m AG, , Seite 2

3 Agenda Agenda Serviceorientierte Architektur Definition von Grundbegriffen Normalform für Services Architekturempfehlung und Fazit sd&m AG, , Seite 3

4 Serviceorientierte Architektur Komponenten, Services und Servicekategorien: Anwendungslandschaften nach SOA-Prinzipien gestalten Interaktions- Komponenten Ideale AL Prozess- Komponenten Funktions- und Bestands- Komponenten Reale AL Reale Komponenten und Produkte SAP R/3 Siebel individuelle Altsysteme neue Service- Komponenten sd&m AG, , Seite 4

5 Serviceorientierte Architektur Regeln für das Design von Services in einer SOA Kategorie Art Regeln Interaktion Prozess Funktion, Bestand elementar normal kontextfrei zusammengesetzt orchestrierbar kategorienrein, service-orientiert, technikneutral grobgranular, idempotent sd&m AG, , Seite 5

6 Agenda Agenda Serviceorientierte Architektur Definition von Grundbegriffen Normalform für Services Architekturempfehlung und Fazit sd&m AG, , Seite 6

7 Definition von Grundbegriffen Komponenten und Services Komponententyp (kurz: Komponente) C: definiert durch die Menge der Services {Service 1,, Service n } (Aufrufschnittstelle) Service: fasst eine Menge von Operationen {o 1, o n } zusammen Signatur einer Operation o: Eingabeparameter und ihre Typen, optional Typ eines Rückgabewerts o 1 : void legepartneran (Number id, String name) Service 1 : PartnerPflege C: PartnerVerwaltung sd&m AG, , Seite 7

8 Definition von Grundbegriffen Komponenten-Instanzen und Zustände Eine Komponente C kann beliebig viele Komponenten- Instanzen c haben Zu jedem Zeitpunkt t hat c einen definierten Zustand s t Zustand s t: Menge von Aussagen {i 1, i 2, }, die zum Zeitpunkt t für c gültig sind s t = {i 1, i 2, } i 1 = Partner #4711 i 2 = Partner #4711 hat Name Müller i 3 = Partner #4712 c: PartnerVerwaltung sd&m AG, , Seite 8

9 Definition von Grundbegriffen Abfragen und Kommandos Abfrage q (lesende Operation): ändert den Zustand einer Komponenten-Instanz c nie (s t+1 = s t ) Kommando cmd (schreibende Operation): führt die Komponenteninstanz c vom Zustand s t in den neuen Zustand s t+1 über Zustandsänderung s = s t+1 \ s t Kommando: legepartneran (4711, Müller ) c: PartnerVerwaltung Abfrage: Service 1 : PartnerPflege findepartner(4711) sd&m AG, , Seite 9

10 Agenda Agenda Serviceorientierte Architektur Definition von Grundbegriffen Normalform für Services Architekturempfehlung und Fazit sd&m AG, , Seite 10

11 Normalform für Services Vollständige Abfragen- und Kommandomengen Vollständige Abfragemenge Q = {q 1, q n }: zu jedem Zeitpunkt t kann der gesamte Zustand einer Komponenteninstanz c erfragt werden Vollständige Kommandomenge CMD = {cmd 1,, cmd n }: alle erlaubten Zustände s S aller Komponenteninstanzen c können stets erreicht werden Abfrage: findepartner(4711) c: PartnerVerwaltung i 1 = Partner #4711 i 2 = Partner #4711 hat Name Müller i 3 = Partner #4712 Service 1 : PartnerPflege sd&m AG, , Seite 11

12 Normalform für Services Orthogonale Abfrage- und Kommandomengen Abfragemenge Q = {q 1, q n } orthogonal: Abfragen liefern jeweils unterschiedliche Aussagen Die Kommandomenge CMD = {cmd 1,, cmd n } orthogonal: Kommandos bewirken jeweils unterschiedliche Zustandsübergänge Orthogonalität Redundanzfreiheit cmd 1 : legepartneran(4711, Müller ) cmd 2 : aenderepartner(4711, Müller ) s = {i 1, i 2 } i 1 = Partner #4711 i 2 = Partner #4711 hat Name Müller i 2 i 1 s: cmd 1 s: cmd 2 cmd 1,cmd 2 nicht orthogonal sd&m AG, , Seite 12

13 Normalform für Services Normalform für Services Normalform (kurz: Operationen sind normal): Teilmenge der Abfragen Q und Teilmenge der Kommandos CMD sind vollständig und orthogonal Theoreme: Minimal: Nimmt man von normalen Mengen eine Operation weg, ist sie nicht mehr vollständig Ableitungsfrei: Normale Operationen sind niemals voneinander abgeleitet Service PartnerPflege { // Kommandos void legepartneran(number id) void aenderepartner(number id, String name) // Abfragen Partner findepartner(number id) } Operation in in Normalform sd&m AG, , Seite 13

14 Agenda Agenda Serviceorientierte Architektur Definition von Grundbegriffen Normalform für Services Architekturempfehlung und und Fazit Fazit sd&m AG, , Seite 14

15 Architekturempfehlung und Fazit Architekturempfehlung und Fazit Trenne klar Abfragen von Kommandos Identifiziere elementare Services in Normalform Zusammengesetzte Service dürfen redundant sein (Benutzerfreundlichkeit, bessere Performance etc.) Keine 100% Konformität in der Praxis: adäquate Lösungen finden Konkrete Regeln sind wichtig für die Projektpraxis Kategorie Art Regeln Interaktion Prozess Funktion, Bestand zusammengesetzt orchestrierbar kategorienrein, service-orientiert, technikneutral grobgranular, idempotent elementar normal kontextfrei Dies ist erst der Anfang! sd&m AG, , Seite 15