Konzeption und Implementierung von SOA Composed Services in der Praxis Markus Trenkle, Lyubomir Yordanov InterFace AG, Yordanov Consulting Nürnberg Schlüsselworte Systemarchitektur, Composed Services, SOA, BPEL, JDeveloper Einleitung SOA-Architekturen mit einem Enterprise Service Bus als zentrale Integrations- und Kommunikationskomponente sind für komplexe und heterogene IT-Landschaften besonders gut geeignet. Architekturen, die nach diesem Paradigma aufgebaut sind, basieren - wie der Name schon sagt - auf Services. Damit diese Services die für die Geschäftsprozesse notwendige Funktionalität erbringen können, werden sie in Hierarchiestufen aufgebaut, die immer genauer die Fachlichkeit abbilden. Insbesondere sind Services höherer Hierarchiestufen oft nur Kompositionen von Services untergeordneter Schichten. Das sind die sogenannten Composed Services. Es gibt unterschiedliche Techniken um Composed Services zu implementieren. In diesem Vortrag und der anschließenden Demonstration werden die Vorteile der Verwendung der Oracle SOA Suite und die Nutzung der SCA Spezifikation anhand eines praxisnahen Beispiels vorgestellt. Beweggründe / Ausgangslage Die am meisten verwendete Technologie in aktuellen SOA-Architekturen ist die Webservice Technologie. SOA bedarf allerdings eine Einführung und Einhaltung unternehmensweiter Standards, damit sie auch erfolgreich angewendet werden kann. Durch die besonderen Anforderungen an Design, Aufbau und Nutzung werden Webservices in der SOA Welt zu SOA Services. Diese besonderen Anforderungen sind sowohl technischer als auch fachlicher Natur. Jeder SOA Service muss z.b. fachlich motiviert sein und sich in einem für die Automatisierung der Geschäftsprozesse geeignet geschnittenen SOA Service Portfolio wiederfinden. Technisch gesehen werden beispielsweise Vorgaben für das Design der WSDLs und XSDs definiert, Namenskonventionen für Operationen und Datentypen eingeführt, besondere Versionierungsprinzipien eingehalten. Aus Sicht der Systemarchitektur sind SOA Services in definierten Infrastrukturlandschaften deployed, die nicht-funktionale Anforderungen wie Security, Hochverfügbarkeit, Lastverteilung usw. unterstützen. Wir unterscheiden generell zwei Arten von SOA Services: Elementare Services: bieten Funktionalität direkt an Composed Services: kombinieren andere SOA Services Die Geschäftslogik elementarer SOA Services erfüllt sehr heterogene Anforderungen. Auch wenn ihre Schnittstellen unternehmensweiten Standards unterliegen, spiegelt sich diese Anforderungen in der Nutzung unterschiedlicher Technologien und Programmiermodelle (Java,.Net, SAP, C++,...). Bei Composed Services dagegen ist die Funktionalität immer die Gleiche: Services werden anhand interner Logik aufgerufen, Datenmodelle werden transformiert, es wird ein Ergebnis zurückgegeben. Damit sind sie ideale Kandidaten für eine Standardisierung der Implementierung.
Ein Programmiermodell, das sich für SOA und Composed Services als besonders geeignet erwiesen hat, ist die Service Component Architecture (SCA). Auf diesem Modell basiert auch die Entwicklung von Composed Services mit der Oracle SOA Suite. Es handelt sich um einen sprach- und technologieneutraler Satz von Spezifikationen. SCA erlaubt eine vereinfachte Komposition von Services, indem es viele der Infrastrukturelemente abstrahiert, die für den Aufruf der benötigten Services notwendig sind. SCA definiert, wie die Komponenten zu erstellen, zu kombinieren und als neuer Service zusammenzufassen sind. SCA lässt sich mit bestehenden Konzepten sehr gut integrieren und ist der Standard für zukünftige SOA Anwendungen. Abbildung 1: Elemente der SCA Kernkomponente von SCA ist das Composite. Es besitzt eine Schnittstelle (das Service Element im Bild) und kann über References andere Services aufrufen. Sowohl für den Service als auch für die References können unterschiedliche Bindings verwendet werden WebService, JMS, usw. Die Geschäftslogik innerhalb des Composites wird von den Components ausgeführt. Das können Transformationskomponenten sein (Mediator), Business rules für Entscheidungen, BPEL Prozesse für die Steuerung des Ablaufs usw. Die Konfiguration dieser Komponenten und vom Composite selbst wird über Properties vorgenommen, die auf Composite-Ebene verfügbar sind. Das ist für Staging besonders wichtig, da Änderungen dieser Properties von betrieblichen Teams durchgeführt werden sollen z.b. URLs von Adressen benötigter WebServices usw. Die SCA Composed Services werden mit dem JDeveloper entwickelt. Die Komponenten eines Composites sind XML Dateien mit Instruktionen zu den Services Engines der SOA Suite (Mediator, Business Rules, BPEL, ). Da es sich um eine deklarative und konfigurative Art der Entwicklung handelt, werden Herausforderungen wie z.b. Parallelisierung, Optimierung der Marshalling- bzw. Unmarshalling Aktivitäten, Anwenden von Policies in PEPs (Policy Enforcement Points) usw. von der Infrastruktur übernommen und zur Laufzeit optimal ausgeführt. Das Composite ist eine gekapselte Einheit, die in die Laufzeitumgebung deployed werden kann. Über die unternehmensweite Nutzung der SOA Suite für SCA und Composed Services steht eine definierte Plattform für Deployment und Betrieb zur Verfügung.
Abbildung 2: SOA Suite als Plattform für den Betrieb von Composites Live-Demo In unserer Beratungsarbeit begegnen uns immer wieder Vorbehalte gegen den Einsatz der SOA Suite und der visuellen Programmierung in BPEL. Mit Vorführungen wie dieser versuchen wir, das Interesse zu wecken und die Vorteile herauszustellen. Dazu implementieren wir live einen einfachen Anwendungsfall. Abbildung 3: Anwendungsfall Ein PersonService verwaltet Vor- und Nachnamen sowie eine ID. Getrennt davon sind Adressen in einem eigenen AdressService gespeichert. Ein Servicenutzer möchte die Personendaten mit Adressen auslesen. Statt eines Aufrufs der beiden Services durch den Nutzer soll ein Composed Service die Anreicherung übernehmen. Vorbereitet haben wir die Entwicklungs- und Laufzeitumgebung. Sie besteht aus folgenden Komponenten: Oracle 11g Datenbank in einer virtuellen Maschine Oracle WebLogic Application Server in einer zweiten virtuellen Maschine. Neben der SOA Suite 11.1.1.7 sind darauf die beiden Person- und AdressService deployed
Entwicklungsumgebung (JDeveloper 11.1.1.7) auf dem Hostsystem Testanwendung SoapUI Schnittstellendefinition (wsdl) für den Composed Service, verfügbar im MDS Damit entsteht in ca. 20-30 Minuten ein System, das die beschriebenen Anforderungen umsetzt. Diese Lösung erhebt den Anspruch, produktionsreif zu sein. Lösungsarchitektur In der SOA Suite werden funktionale Bausteine innerhalb eines SCA erstellt. Diese Deploy-Einheit definiert die Schnittstellen nach Außen und den Informationsfluss zwischen den Bausteinen. Abbildung 4: Implementierung des Anwendungsfalls: SCA Ein BPEL-Prozess implementiert die Funktionalität jeweils einer Servicemethode. Der Mediator übernimmt die Verteilung der Anfragen auf die passende Implementierung. In unserem Anwendungsfall wäre dieser Schritt nicht nötig, da der Composed Service nur eine Methode anbietet, aber die Lösung sollte erweiterbar sein. Die Implementierungs selbst erfolgt in BPEL, sowohl im grafischen Editor als auch im xml-code. Ein typisches Codemuster ist die Abfolge Assign/Transformation: Zuweisen von Parametern an input-variablen Invoke: Aufruf eines Service Assign/Transformation: Verarbeiten und Transformieren von output-variablen
Abbildung 5: Implementierung des Anwendungsfalls: BPEL
Zusammenfassung Die Nutzung der Oracle SOA Suite erlaubt es, auf eine einfache Art und Weise und schnell performante, produktionsreife Composed Services zu entwickeln. Des Weiteren bringt diese Standardisierung auch Vorteile aus Projektmanagement-Sicht: Kostenreduktion durch Verwendung vordefinierter Konzepte für Entwicklung, Deployment und Betrieb Stabile Rahmenbedingungen für Governance Betrachtung des kompletten Lifecycles (Wartung und Pflege) Umgang mit strukturellen Gegebenheiten wie Personalaustausch Nutzung definierter Infrastruktur mit Support Kontaktadressen Dr. Markus Trenkle InterFace AG Südwestpark 37-41 90449 Nürnberg Telefon: +49 151 52726526 E-Mail markus.trenkle@interface-ag.de Lyubomir Yordanov Yordanov Consulting Bergstr. 11 D-90403 Nürnberg Telefon: +49 179 5472474 E-Mail lyubomir@yordanov.eu