Serviceorientierte ­Entwicklung

Serviceorientierte ­Entwicklung Bei der Entwicklung serviceorientierter Anwendungen sollten sich die IT-Spezialisten auf geeignete Methoden und Werkzeuge stützen und Bausteine nach einem einheitlichen Konzept entwerfen.

Serviceorientierte Systeme kann man in drei Klassen einteilen. Bei der ersten Klasse steht der Geschäftsprozess als Sequenz von Aktivitäten im Vordergrund. Die zweite Gruppe behandelt die Informationsintegration, und bei der dritten steht die Anwendungssicht im Vordergrund. Eine Service-Oriented Business Application (SOBA) ist dabei weit mehr als eine Sammlung von Web Services, die über Punkt-zu-Punkt-Verbindungen kommunizieren. Eine SOBA ist vielmehr eine Komposition lose gekoppelter Services, die einen geschäftlichen Zweck erfüllen und eine SOA-Infrastruktur nutzen, um effizient entwickelt und in flexibler Weise neuen Geschäftsanforderungen angepasst werden zu können. Eine SOBA ist in erster Linie kein System verteilter Unternehmensanwendungen oder Dienste, sondern eine Anwendung, die im Normalfall auf nur einem Application Server läuft. Eine SOBA kann zum Beispiel eine ERP-Anwendung sein, die aus vielen lose gekoppelten Services zusammengesetzt ist. In diese Richtung entwickeln derzeit große Applikationsanbieter wie Oracle und SAP ihre Produkte weiter. Damit stellen SOBAs auch lose gekoppelte Enterprise Services dar, deren Ablauf von einer Service Orchestration Engine (SOE) koordiniert wird und die mit Hilfe eines Enterprise Service Bus (ESB) indirekt miteinander kommunizieren. Von dem Erfolg und der Notwendigkeit von SOBAs ist auch Charles Abrams, Analyst bei dem Marktforschungs- und Beratungshaus Gartner überzeugt: »Wir erwarten, dass im Jahr 2007 viele Software-Hersteller Anwendungen als Services in vertikalen Märkten und über horizontale Funktionen liefern werden. Bis zum Jahr 2008 werden Anwendungen voraussichtlich in mehr als 70 Prozent der Unternehmen serviceorientiert realisiert.«

Architektur
Eine Architektur für SOBAs beruht auf Modulen, die lose gekoppelt werden. Sie bilden eine Einheit, die aus verschiedenen Komponenten zusammengesetzt ist. Service-Module kommunizieren nur indirekt mit Hilfe eines Information Integrator (II) und werden mittels einer Service Orchestration Engine (SOE) oder einer Rule Engine (RE) orchestriert. Dabei sind II, SOE und RE Bestandteile eines Infrastruktur-Frameworks für SOBAs, das auf einem Application Server läuft. Der II entspricht dem ESB in einem verteilten SOA-System. Ein Service-Modul ist aus Service-Komponenten zusammengesetzt, die als Basis-Bausteine implementiert sind. Die Abbildung auf Seite 34 zeigt eine SOBA-Architektur mit den Infrastrukturkomponenten II, SOE und RE.

Entwicklungsmethodik
Eine SOA sieht den Einsatz unabhängiger Services vor. Sie bietet allerdings kein Vorgehen, um entsprechende Anwendungen zu entwickeln. Zu einer Entwicklungsmethodik für SOBAs gehören definierte Werkzeuge und eine rollenbasierte Zuordnung der Aufgaben. Nur so lassen sich Service-Module als Bausteine einer SOBA entwerfen und implementieren. Der SOBA-Entwicklungsablauf betrifft Fachbereich und IT und deren Zusammenwirken. Eine flexible und effiziente Entwicklung von SOBAs setzt ein modellgetriebenes Entwerfen über den gesamten Lebenszyklus voraus, wie im dritten Teil dieser Serie dargelegt. Große Teile des Anwendungscodes können dann konfiguriert statt programmiert werden – inklusive Deployment und Change Management. Die Bausteine einer SOBA spielen für eine SOA eine entscheidende Rolle. Bei der Entwicklung einer serviceorientierten Anwendung sollte nach einer Service Component Architecture (SCA) vorgegangen werden. Dabei werden die benötigten Dienste gemäß einer Anleitung informationstechnisch entworfen und dann implementiert. Darauf aufbauend werden diese Bausteine gekoppelt. Für die SCA ist es dabei wichtig, eine große Bandbreite an Technologien zur Umsetzung zu unterstützen. So können Unternehmen, die verschiedene Entwicklungsumgebungen und Programmiersprachen einsetzen, diese weiterverwenden und trotzdem SCA-konform arbeiten. Eine SCA spezifiziert also ein Modell, mit dessen Hilfe man Anwendungen entwickeln kann, die auf der Idee der SOA beruhen.

Business-Modellierung
Anfangsvoraussetzung bei der SOBA-Entwicklung ist der fachliche Entwurf von Domänen samt deren Vokabularen. Business-Domänen sind Gebiete geschäftlicher Funktionen etwa für Vertrieb, Marketing oder Personalverwaltung. Domänen sind durch Vokabulare gekennzeichnet, die Objekte (Nomina) und Funktionen (Verben) umfassen. So wird zum Beispiel eine Marketing-Domäne Objekte wie Budget und Zielgruppe enthalten. Diese Begriffe – definiert auf fachlicher Ebene – bestimmen die interne Nomenklatur. Mit einem Domain Editor können Domänen und Subdomänen mit ihren Vokabularen definiert werden. Die Business Services werden mit einem Business Service Designer auf abstrakter fachlicher Ebene definiert. Die Schnittstellen (Schemas) eines Service-Moduls werden durch Geschäftsobjekte, die mit einem Business Object Designer erstellt werden, definiert und entsprechen den kanonischen Dokumentenschemas, die auf fachlicher Ebene zwischen den Business-Services ausgetauscht werden. Der Ablauf der Service-Module wird durch Geschäftsregeln mit einem entsprechenden Editor definiert und mit einem Orchestration Designer spezifiziert. Zusam­men­gesetzte Services müssen vor der Implementierung mit einem Service-Simulator getestet werden können. Sodann wird das Innere eines Service-Moduls definiert. Ein Service-Modul enthält Service-Komponenten, Einstiegspunkte, externe Dienste und Verbindungen. Komponenten enthalten die Logik der Module. Einstiegspunkte stellen den Dienst nach außen zur Verfügung. Externe Dienste beschreiben die Abhängigkeit des Moduls von Services, die von außerhalb des Moduls genutzt werden. Die Verbindungen werden dazu genutzt, Dienste zu den Komponenten und von ihnen weg zu beschreiben. Der Entwurf legt mit einem Service Module Designer fest, aus welchen Komponenten das Modul besteht und wie sie miteinander verknüpft sind, das heißt, Services von anderen Komponenten anfordern. Notwendige Daten-Adapter-Komponenten stehen dem Designer zur Verfügung, um mit einem Mapping Tool die Datentransformation zwischen den Komponenten zu definieren.

Implementierung
Komponenten können auf verschiedene Weise als Web Services in unterschiedlichen Programmiersprachen (vor allem Java, C#, C++), unterstützt durch die Entwicklungsplattformen Visual Studio in der Microsoft-Welt oder meist Eclipse andernfalls, implementiert werden. Oft benötigte Komponentenarten lassen sich in Service-Modulen als bereits implementierte Bausteine wiederverwenden. Eine Regelkomponente, verdrahtet mit einer vorgefertigten Selector-Komponente, erlaubt es zum Beispiel, einen Service von einer Komponente abhängig von der berechneten Business Policy zu selektieren. Ebenso kann eine Komponente Benutzereingaben erfordern oder als automatisch ablaufender Prozess (etwa durch BPEL oder mit Hilfe von Zustandsautomaten dargestellt) implementiert sein und in Service-Modulen wiederverwendet werden.

Konfiguration
Eine große Erleichterung für die Entwicklung und Wartung von SOBAs ist es, dass Infrastrukturdefinitionen wie Transaktionen, Reliable Messaging und Sicherheitsmerkmale nicht innerhalb von Komponenten oder Modulen programmiert, sondern an den Verbindungen zwischen diesen Bausteinen konfiguriert werden können. Ein Deployment Tool muss abschließend dafür sorgen, dass das im Repository abgelegte Modell in entsprechende Konfigurationsdateien übersetzt wird.

Dr. Peter Eichhorst ist Chef des IT-Dienstleisters Socon in Dresden und San Diego.