Service-orientierte Architekturen sind seit einigen Jahren ein wichtiges Architektur-Paradigma für Geschäftsanwendungen. Darunter versteht man Architekturstile, die verschiedene Prinzipien erfüllen wie Aggregation von Funktionen zu Services, plattformunabhängige Darstellung dieser Services (beispielsweise durch Webservice-Schnittstellen mit SOAP/WSDL), lose Kopplung der Systeme/Services (wie durch nachrichtenorientierte Middleware) oder Finden und Koppeln der Services zur Laufzeit (Find-Bind-Invoke-Paradigma).
Wenigstens zwei Aspekte sind jedoch in vielen SOA-Frameworks bisher zu kurz gekommen:
Die SCA-Spezifikation dient im Wesentlichen dazu, Service-Kompositionen zu beschreiben. Dabei wird eine Komponente durch mehrere Aspekte beschrieben:
- Service-Schnittstelle(n)
- Eigenschaften (Properties)
- Referenzen
- Implementierung der Services
Beginnen wir beim letzten Punkt: SCA ist ein explizit Plattform-unabhängiger Standard, die Implementierungen können also im Prinzip auf einer beliebigen Plattform erfolgen (z.B. Java, BPEL, C++ oder Cobol). Hier erkennt man, dass BPEL als eine Art der Service-Komposition verwendet werden kann. Andere sind aber gleichberechtigt möglich: In der Service Composition wird dann angegeben, wie der Service konkret implementiert ist. Weiter wird beschrieben, welche Eigenschaften mit welchen Werten belegt werden sollen (z.B. zur Konfigurationszeit). Zuletzt wird definiert, von welchen weiteren Services diese Komponente abhängig ist, womit die Komposition «eingeleitet» wird. Die Definition wird jeweils in Form einer SCDL-Konfigurationsdatei im XML-Format hinterlegt (siehe Kasten).
Auf der Abbildung «Struktur einer SCA-Komposition» sieht man, wie eine solche Komposition in der Praxis aussehen könnte. Der Anstoss eines Service-Aufrufes könnte von einer Interaktion eines Benutzers mit einer Benutzerschnittstelle wie einem Web-Interface erfolgen. Um diesen «Auftrag» abzuarbeiten, sind in diesem Beispiel mehrere Services erforderlich, die in verschiedenen Sprachen implementiert und auf drei verschiedene Domänen verteilt sind. Diese Domänen können unterschiedliche Server sein, auch unterschiedliche SCA-Runtimes (beispielsweise von verschiedenen Anbietern).
Innerhalb einer Domäne werden in der SCDL-Datei die Komponenten und deren Abhängigkeiten definiert. Service-Schnittstellen können von anderen SCA-Komponenten oder von externen Services verwendet werden. In diesem Beispiel verwendet eine Komponente auch einen Data Access Service, der Daten persistiert – mehr dazu später.
Man erkennt in der Abbildung auch, dass Komponenten sehr unterschiedlich realisiert sein können. Eine Komponente wird beispielsweise durch einen BPEL-Prozess realisiert. Dies funktioniert darum gut, weil sich BPEL-Prinzipien wie Partner Links leicht auf SCA-Services/Referenzen abbilden lassen. Andere Komponenten werden in Java, C++ oder anderen Sprachen implementiert.
Ein Composite ist also ein logisches Konstrukt, und von aussen ist nicht ersichtlich, ob diese Service-Komposition in einer virtuellen Maschine oder auf mehreren Servern verteilt läuft. Aus Sicht des (Java-)Programmierers verhält sich SCA sehr «entwicklerfreundlich». Es sind relativ wenige Konfigurationen in XML abzulegen. Die Hinterlegung der meisten Informationen, die für die Definition der Kompositionen sowie für die Publikation einer Komponente über ein bestimmtes Binding (z.B. Webservice, SOAP over JMS) erforderlich sind, erfolgt über Annotationen im Java-Code. Die Bindings abstrahieren von der konkreten Kommunikationstechnologie. Für den Entwickler macht es also keinen grossen Unterschied, ob die konkrete Kommunikation eben über JMS, SCA oder Web Services erfolgt. Für den Entwickler der Beispiel-Benutzerschnittstelle ist ein einziger Serviceaufruf erforderlich, der dann tatsächlich eine Serie von komplex verdrahteten Services verwendet.
Die SCA-Spezifikationen sind relativ umfangreich und bestehen aus einer Reihe von Detailspezifikationen wie SCA Assembly Model, SCA Java Common Annotations oder SCA Spring Component Implementation. Daneben gibt es auch Spezifikationen, die Transaktionen und Policies definieren.
Beispiel einer SCDL-Konfigurationsdatei
In Service-orientierten Architekturen müssen häufig verschiedene Komponenten mit unterschiedlichen Datentypen über Plattformgrenzen hinweg zusammenarbeiten. Die SDO-Spezifikation unterstützt in dieser Hinsicht die SCA-Spezifikation, muss aber nicht unbedingt mit SCA gemeinsam verwendet werden und könnte prinzipiell auch in anderen Geschäftsanwendungen ohne SCA angewendet werden.
SDO erlaubt die Definition beziehungsweise die Beschreibung von Daten unabhängig von einer bestimmten Plattform wie Java oder C++. Damit soll es möglich sein, ein einzelnes Datenmodell für das ganze Unternehmen (oder Teile davon) zu definieren und dieses dann auf verschiedenen Plattformen zu verwenden (mit spezifischen APIs für die jeweilige Plattform). Kernkonzepte von SDO sind:
SCA und SDO werden von einer Reihe von kommerziellen Middleware-Produkten unterstützt. Apache Tuscany ist eine der wenigen zur Zeit verfügbaren Open-Source-Implementierungen von SCA/SDO. Im Bereich SCA und SDO wird Java, C++ und PHP unterstützt, Transaktionen und Policies noch nicht. Zur Persistierung von SDOs wird ein Data Access Service (DAS) für Relationale Datenbanken angeboten (Java und C++).
SCA und SDO sind sehr interessante Ansätze, um im SOA-Umfeld Anwendungen zu entwickeln. Die Standards sind noch relativ neu, werden aber von vielen Grossen der Branche getragen und unterstützt sowie in den eigenen Produkten implementiert. Es gibt die erste Open-Source-Implementierung mit Tuscany und weitere dürften folgen.
Es verhält sich zurzeit wie mit allen sehr neuen Technologien: Es scheint noch niemand so ganz genau zu wissen, was konkret die Anwendungsfälle für SCA/SDO sein werden beziehungsweise wie man es korrekt auch in Bezug zu anderen Technologien einsetzt. In Blogs und auf Konferenzen streitet man sich unter anderem darüber, ob es sich um ein SOA-Programmiermodell handelt oder nicht, ob es eine Konkurrenz zu JBI ist und um viele andere Details.
Die Abgrenzung zu anderen Technologien wie z.B. zu JBI (Java Business Integration, siehe Artikel in InfoWeek 2007/20) ist noch nicht ganz klar. Beide zielen in einen ähnlichen Bereich. SCA versucht die Anwendungsentwickler anzusprechen, während es bei JBI um Integrationsaspekte geht. (JBI ist ausserdem ein «reiner» Java Standard, während SCA plattformunabhängig ist). Tatsächlich liessen sich SCA Runtimes in JBI integrieren oder als JBI-Komponenten deployen.
Leider wird dies meines Wissens nach zurzeit nicht gemacht (jedenfalls nicht von Tuscany oder Servicemix). Damit könnte JBI die Basis-Komponentendefinition sein, die ESB-Komponenten beschreibt, und SCA die Komposition beschreibt.
Ähnlich verhält es sich mit SDO. SDO ist O/R-Mapping- und XML-Mapping-Ansätzen durchaus vergleichbar, hat aber verschiedene Vorteile im Bereich verteilter Komponenten. Auch hier würde man sich eine breitere Unterstützung von anderen Frameworks wünschen, z.B. SDO-Komponenten über JMS in ActiveMQ oder Mapping von relationalen Datenbanken auf SDO (z.B. in Frameworks wie Ibatis).
Zusammengefasst kann man sagen, dass die Technologie ziemlich neu ist, ebenso wie Apache Tuscany. Die Ansätze sind sehr spannend und durchaus vielversprechend. Entwickler und Architekten von Geschäftsanwendungen kann man empfehlen, sich in diese Konzepte einzulesen. Ob man zum jetzigen Zeitpunkt allerdings schon systemkritische Anwendungen damit entwickeln möchte, bleibt der eigenen Einschätzung überlassen.
SDOs als Datenmodell
Alexander Schatten (alexander@schatten.info) ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.
