Service Component Architecture

Die Service Component Architecture (SCA) ist eine Sammlung an Spezifikationen, welche ein Modell einer Serviceorientierten Architektur (SOA) beschreiben. SCA basiert auf offenen Standards wie Web Services. Dem SOA-Gedanken folgend sind SCA-Komponenten unabhängig von einer konkreten Technologie.

Beteilige dich an der Diskussion!

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+) Begründung: Artikel ist wertend und erklärt das Lemma nicht. --Temporäres Interesse 13:43, 14. Sep. 2009 (CEST)

Partner

Die folgenden Firmen arbeiten als Partner zusammen an der Erstellung der Spezifikationen der Service Component Architecture: BEA Systems, Cape Clear, IBM, SpringSource, IONA Technologies, Oracle Corporation, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, SAP AG, Software AG, Sun Microsystems, Sybase, TIBCO, Xcalia und Zend Technologies.

Definition

Die veröffentlichte Spezifikation scheint vage in vielfacher Hinsicht. Aber sie entwickelt sich rasch und es bilden sich neue Spezifikationen heraus. Die Spezifikationen legen für nach SCA entworfene Anwendungen folgende Eigenschaften fest:

• Entkopplung der Service-Implementierung und -Bereitstellung von den spezifischen Möglichkeiten der Infrastruktur.
• Sollte mit verschiedenen Programmiersprachen und -standards zusammenarbeiten, unter anderem mit C++, Java, COBOL und PHP, sowie mit XML, BPEL und XSLT.
• Muss verschiedene Meldungskonstrukte unterstützen, insbesondere einfache Aufrufe ohne Antwort, asynchrone Kommunikation, eine Konversation über mehrere Nachrichten hinweg und Notifications.
• Infrastrukturmöglichkeiten wie Sicherheit, Transaktionen und verlässliches Melden sollten über Metadaten auf die Kodierung einwirken.
• Daten sollten als Service Data Objects repräsentiert werden.
• Nach SCA-Prinzipien entworfene Komponenten sollten einfach wiederverwendbar sein.
• Lokale Serviceaufrufe sollten stärker gekoppelt sein. Damit wird der Overhead für das Erzeugen und Parsen von Meldungen reduziert, der allein für den Transport über Netzwerke gedacht ist.

Weitere Analyse

Gartner Group hat 2005 eine Kurzmeldung veröffentlicht, die zu dem Schluss kommt, dass die in SCA enthaltene Technologie Service Data Objects (SDO) aufgrund ihrer Reife rascheren Zuspruch erfahren wird.

Vorteile:

• ausgelegt für alle existierenden Java-Plattformen und C++-Technologien (Jedoch hat das SCA-C++-Komponentenmodell schwere Mängel)
• weniger technologieabhängig – benötigt z. B. weder Java noch XML
• verwendet SDO, den einzigen Industriestandard für Datenzugriffe in SOA

Nachteile:

• Fehlende Unterstützung durch Microsoft reduziert die Relevanz von SCA für eine große Zahl potentieller Anwender.
• Die Spezifikation adressiert nicht die Performanz von SOA-Anwendungen, was ein Störfaktor für die Anwendung bleibt.

Es wird behauptet, dass SCA durch einen Ansatz namens Aktivierung („Activation“) interoperabel sei. Diese Methode stelle, verglichen mit den älteren Methoden „mediation“ (z. B. JBI) oder „Invocation“ (JCA), ein Höchstmaß an Komponentenautonomie sicher.

SCA Artefakte

Das SCA Assembly Model besteht aus einer Serie von Artefakten. Diese werden durch Elemente in XML-Dateien definiert. Eine SCA-Anwendung kann zur Laufzeit andere nicht standardisierte Repräsentationen von Artefakten haben, die durch diese XML-Dateien repräsentiert werden. Zusätzlich kann sie die dynamische Konfiguration von Systemen erlauben. Allerdings legen die XML-Dateien die portable Repräsentation der SCA-Artefakte fest.

Das Basis-Artefakt ist das Kompositum. Dies ist zugleich die Auslieferungs-Einheit innerhalb SCA und enthält Services, auf die von außen zugegriffen werden kann. Ein Kompositum enthält ein oder mehrere Komponenten, die die vom Modul bereitgestellten Geschäftsfunktionen enthalten. Komponenten stellen ihre Funktionen als Services bereit. Diese können entweder von anderen Komponenten desselben Moduls verwendet werden oder sie sind über Entry Points (Einstiegspunkte) auch außerhalb des Moduls verfügbar. Komponenten können von Services anderer Komponenten abhängen – diese Abhängigkeiten werden Referenzen genannt. Referenzen können entweder mit Diensten anderer Komponenten desselben Moduls verknüpft werden oder mit Dienste außerhalb des Moduls insbesondere der anderer Module. Referenzen auf Dienste außerhalb des Moduls werden im Modul als externe Services definiert. Auch enthalten im Modul sind Beziehungen zwischen Referenzen und Diensten. Diese werden durch Wires (Drähte) repräsentiert.

Eine Komponente besteht aus einer konfigurierten Implementierung, wobei die Implementierung das Stück Programmcode ist, welches die sogenannte business logic implementiert. Die Komponente konfiguriert die Implementierung besitzt sogenannte Properties (Eigenschaften), die für jede konkrete Implementierung festgehalten werden. Die Komponente kann die Konfiguration der Implementierung außerdem ändern, indem sie das Wiring der von der Implementierung deklarierten Referenzen auf konkrete Dienste festlegt.

Komposita werden innerhalb eines SCA-Systems ausgeliefert. Ein SCA-System repräsentiert eine Menge von Diensten, die wiederum einen Bereich von Geschäftsfunktionalität bereitstellen, der von einer einzelnen konkreten Geschäftseinheit kontrolliert wird. Beispiel Buchhaltung: Das SCA-System könnte alle finanzbezogenen Funktionen abdecken. Zusätzlich könnte es eine Reihe von Modulen enthalten, die mit jeweils abgegrenzten Teilbereichen der Buchhaltung umgehen: Eines für Kunden-Konten, ein anderes für Rechnungen. Bei der Erstellung und Konfiguration eines SCA-Systems helfen Subsysteme. Subsysteme werden verwendet, um miteinander in Beziehung stehende Komposita zu gruppieren. Subsysteme enthalten Modul-Komponenten, dies sind konfigurierte Instanzen von Modulen. Subsysteme haben, wie Module, Entry Points und External Services, die die externen Dienste und Referenzen abbilden. Subsysteme können ferner Wires enthalten, die die Modulkomponenten verbinden, Entry Points und External Services.

Implementierungen

• Rogue Wave HydraSCA
• Covansys
• Apache Tuscany
• Paremus Infiniflow
• Newton
• SCA and SDO for PHP
• PocoCapsule
• Trentino
• TIBCO ActiveMatrix Service Grid

Literatur

• Wolfgang Beinhauer, Michael Herr, Achim Schmidt: SOA für Agile Unternehmen, Symposion Publishing 2008, ISBN 978-3-939707-14-1 (www.symposion.de/it-management)

Weblinks

• Open Service Oriented Architecture collaboration, die offizielle Homepage für Informationen rund um die SCA Spezifikationen
• IBM developerworks introductory article on SCA
• Die Service Component Architecture – eine Einführung
• aktuelle Spezifikationen
• Apache Open Source project implementation of the SCA specification
• PocoCapsule open source SCA implementation (für C++)
• SCA Announcements at OASIS web site
• Service Data Objects initial work by BEA and IBM (PDF-Datei)
• Comparing WCF and SCA
• Summary of SCA
• BPEL in SCA assembly
• Die Gretchenfrage: WCF, SCA oder JBI? (PDF-Datei; 364 kB)
• Eclipse STP SCA Tools
• Trentino C++ SCA Runtime