Die Service Component Architecture - eine Einführung

Die der Komposition dienende Service Component Architecture (SCA) stellt eine der Zukunftstechnologien im Softwareentwicklungsumfeld dar. In der folgenden Einführung wird dieses hersteller-, technologie- und sprachneutrale Modell zur Erstellung von SOA basierten Softwaresystemen vorgestellt.

Ausgangssituation

Durch natürlich und/oder Zukauf gewachsene Unternehmen sind viele IT-Systeme, wohl meistens als sehr Komplex zu beschreiben. Viele dieser Systeme zeichnen sich zudem durch eine starre und zerbrechliche Architektur aus, welche man nicht erweitern will bzw. kann.

Wo möchten wir hin?

Um eine Erhöhung der Kundenbindung und Verbesserung der Kommunikation zwischen den Geschäftspartnern zu ermöglichen, müssen die Schnittstellen von und zu den technischen Systemen wohldefiniert sein und der Semantik der eigenen Geschäftsregeln entsprechen.

Diese technischen Systeme, als Ausprägungen für mehrwertgenerierte Services kommunizieren in Service-orientierten Architekturen über standardisierte Protokolle. Meist werden diese mittels SOAP basierten Web Services umgesetzt, bzw. nach außen verfügbar gemacht.

Das Ziel aller Tätigkeiten sollte eine Flexibilisierung der Wiederverwendung und die einfache Rekombination von Services sein.

Die SCA-Kernkonzepte

Zur Erreichung dieses Zieles kämpfen drei Technologien Java Business Integration (aka JSR 208 oder JBI) vom Java Community Process, das Windows Communication Foundation (WCF) von Microsoft und die mittlerweile bei Oasis[1] verwaltete Service Component Architectur (SCA). Im Folgenden wird die SCA, welche ein hersteller-, technologie und sprachneutrales Modell zur Erstellung von Softwaresystemen ermöglichen möchte, vorgestellt.

Abbildung: SCA Kernkonzepte

Component

Abbildung: Component

Die Component dient der Konfiguration einer Implementierung innerhalb eines Composites, hierbei ist das setzen von Properties möglich. Innerhalb einer Component ist es möglich, des SCA Laufzeitumgebung mitzuteilen, welche Services zur Verfügung und konsumiert werden.

  <component name="Component1">
    <implementation.java class="com.planetsoa.CalculatorImpl" />
    <property name="system">metric</property>
    <service name="CalcService">
      <interface.java interface="com.planetsoa.Calculator" />
    </service>
  </component>
				

Wie man dem Listing entnehmen kann, wurde in der Component1 ein Calculator-Dienst definiert. Hierzu wurde eine Instanz der Klasse com.planetsoa.CalculatorImpl, welche wohl einen Rechner darstellt, erzeugt. Diese Instanz wird mit denen im Interface com.planetsoa.Calculator spezifizierten Methoden, als Service innerhalb eines Composites zur Verfügung gestellt.

Service/Reference

Abbildung: Service und Reference

Mit dem Service Element ist es möglich zu definieren, welche Dienste eine Component oder ein Composite ihrer Umwelt zur Verfügung stellt. Diese Services können dann in der gleichen, in einer entfernten oder gar in einer nicht SCA-basierten Domain verwendet werden.
Abhängigkeiten zu einem externen Service, welcher wieder in der gleichen, in einer entfernten oder gar in keiner Domain zur Verfügung gestellt wurde, kann mit einem Reference Element angegeben werden.
Beide, Service und Reference Element, können mittels Interface und Binding weiter spezifiziert werden.

  <component name="Component1">
    <implementation.java class="com.planetsoa.CalculatorImpl" />
    <service name="CalcService">
      <interface.java interface="com.planetsoa.Calculator" />
    </service>
    ...
    <reference name="paymentService" target="PaymentComponent" />
    <reference name="myRMIService">
      <tuscany:binding.rmi host="localhost" port="8099" serviceName="CalculatorRMIService" />
    </reference>
    <reference name="monitorService">
      <binding.ws uri="http://www.planetsoa.com/serviceM" />
    </reference> 
    ...
  </component>
  <component name="PaymentComponent">
    ...
  </component>
				

Im obigen Listing wurden drei unterschiedliche Reference-Arten konfiguriert. Die erste mit dem Namen paymentService verweist auf einen in der gleichen Laufzeitumgebung zur Verfügung gestellten Service. Die Reference mit dem Namen myRMIService verweist wohl, entsprechend dem Binding (tuscany:binding.rmi), auf einen Service, welcher in einer entfernten Laufzeitumgebung zur Verfügung gestellt wurde. Der mittels Web Service (binding.ws) angebundene monitorService wird sich wohl außerhalb der Tuscany[2] Domain befinden und könnte in einer nicht Java basierten Umgebung ablaufen.

Componsite

Abbildung: Composite

Der Composite dient der Zusammenstellung und Konfiguration von Service-Komponenten, die zusammen deployed wurden. In diesem Zusammenhang ist es die Aufgabe einer SCA-Laufzeitumgebung den Composite entsprechend der Konfiguration zur Verfügung zu stellen.

Ein Composite kann möglicherweise als Implementierung für andere Composites in einem höheren Layer dienen und besteht aus:

• Veröffentlichen Services
• Service Implementierungen in Form von Components
• Benötigte Services als References
• Properties

  <?xml version="1.0" encoding="UTF-8"?>
  <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
         targetNamespace="http://planetsoa.com/soaBank"
         name="soaBank" >
    <service name="Bankkonto" promote="BankkontoComponent">
      <interface.java interface="com.planetsoa.bank.Bankkonto"/>
      <binding.ws port="http://planetsoa.com/Bankkonto#
              wsdl.endpoint(Bankkonto/BankkontoSOAP)"/>
    </service>
    <component name="BankkontoComponent">
      <implementation.java class="com.planetsoa.bank.BankkontoImpl"/>
    </component>
  </composite> 
				

Das Listing zeigt eine typische Composite-Definition. Hierbei wurde ein Composite mit dem Namen soaBank erzeugt. Dieser Composite promotet ein Bankkonto Service, dessen nach außen gegebenen Dienste wurden mittels Java-Interface spezifiziert. Dieses Interface wird von der Implementierung BankkontoImpl in Form einer Component implementiert. Wie dem Listing ferner noch entnommen werden kann, wird der SCA-Laufzeitumgebung mittels binding.ws mitgeteilt, das dieser Composite als Web Service zur Verfügung stehen soll.

Wire und Binding

Ein wie oben beschriebener Composite kann mittels sogenannter Wire mit anderen Composites verbunden werden. Hierbei sind diese Wires aber rein virtueller Natur und dienen der Service-Reference Kommunikation.
Die erfolgreiche Kommunikation kann natürlich nur geschehen, wenn Service Geber und Service Nehmer über die gleiche Schnittstelle (Java Interface oder WSDL 1.1 portType) verfügen. Mittels Binding (WSDL, JMS, EJB oder Bean) kann ein Service Geber angeben, welche Zugriffsmechanismen er zur Verfügung stellt.

Domains

Eine Grundannahme der Ersteller der SCA-Spezifikationsfamilie war, dass SCA-Laufzeitumgebungen von unterschiedlichen Herstellern entwickelt und angeboten werden. Viele Unternehmen werden sich aber für ein Produkt eines Herstellers entscheiden und dieses in unterschiedlichen Abteilungen einsetzen. In diesem Zusammenhang kann meist davon ausgegangen werden, dass diese Laufzeitumgebungen meist von der IT-Abteilung gewartet werden. Aus diesem Grunde ist es möglich, kompatible Laufzeitumgebungen in einer Domain zu verbinden.

Durch diesen Verbund von baugleichen Laufzeitumgebungen ist es möglich, dass diese Laufzeitumgebungen mit optimierten (zum Teil binären) Übertragungsprotokollen operieren können. Zwischen zwei Domains ist es hingegen notwendig, dass diese mittels Web Services (Web Service Binding) oder andern interoperablen Protokollen kommunizieren.

Zusammenfassung

Durch den Fokus auf die Komposition von Services ohne darüber Prozesse abbilden zu wollen kann SCA für diesen Zweck als gelungen angesehen werden. Bedingt durch ihre Jugendhaftigkeit wird wohl erst Ende 2008 die Ersten nicht Early Adopter mit den ersten SCA-Projekten starten.

Quellen

[1] http://oasis-opencsa.org/sca

[2] http://incubator.apache.org/tuscany/

David Chappell: Introducing SCA Juli 2007
(http://www.davidchappell.com/articles/Introducing_SCA.pdf)

ws-universe.com
(http://www.ws-universe.com)

Open SOA Collaboration
(http://www.osoa.org)

Nicole Wengatz: SCA, OSGi und Spring, Java Spektrum 4/2007