Service component architecture

Service Component Architecture (SCA) ist eine relativ neue, aber wichtige Initiative, beworben von führenden Anbietern der Java-EE-Technologie. Ihre Befürworter behaupten, sie sei auf natürliche Weise geeignet für die Fertigung von Anwendungen, die den Prinzipien einer Serviceorientierten Architektur (SOA) folgen. Dem SOA-Gedanken folgend sind SCA-Komponenten unabhängig von einer konkreten Technologie.

Unterstützer

Sponsoren sind unter anderem:

• die ursprünglichen Mitglieder: BEA Systems, IBM, IONA Technologies, Oracle Corporation, SAP AG, Sybase, Xcalia und Zend Technologies
• die weiteren Mitglieder, bekanntgegeben am 26. Juli 2006: Cape Clear, Interface21, Primeton Technologies, Progress Software, Red Hat, Rogue Wave Software, Software AG, Sun Microsystems und TIBCO Software.^[1]

Definition

Die veröffentlichte Spezifikation ^[2] scheint vage in vielfacher Hinsicht. Aber sie entwickelt sich rasch und es bilden sich neue Spezifikationen heraus ^[3]. 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 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. ^[4]

Vorteile:

• ausgelegt für alle existierenden Java-Plattformen und C++-Technologien (Jedoch hat das SCA-C++-Komponentenmodell schwere Mängel^[5])
• 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. ^[6]

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.^[7]

Implementationen

• Rogue Wave HydraSCA
• Covansys' Service Component Architecture (SCA) Framework for SOA^[8]
• Apache Tuscany
• Paremus Infiniflow: Distributed, dynamic, lightweight SCA & OSGi runtime platform
• Newton Open source distributed SCA & OSGi
• SCA and SDO for PHP
• PocoCapsule WebServices und SCA for C++

Fußnoten

1. ↑ Technologiehersteller erweitern die Zusammenarbeit mit SOA-Technologien http://www.hoise.com/primeur/06/articles/monthly/AE-PR-08-06-92.html
2. ↑ http://www-128.ibm.com/developerworks/library/specification/ws-sca/
3. ↑ http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
4. ↑ http://www.gartner.com/resources/136600/136687/new_soa_specification_will_f_136687.pdf
5. ↑ http://ke-jin.blogspot.com/2007/11/service-component-architecture-sca.html
6. ↑ https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824].
7. ↑ BEA, IBM, IONA, Oracle, SAP, Siebel, Sybase (zusammen, die “Autoren”) stimmen überein, eine royalty-free Lizenz anzubieten, unter vernünftigen, diskriminierungsfreien Bedingungen für Patente, die sie für notwendig halten, um die Service Component Architecture Specification zu implementieren.
8. ↑ http://www.covansys.com/what/SCAFrameworkforSOA.htm

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
• Comparing WCF and SCA
• Summary of SCA
• BPEL in SCA assembly
• Die Gretchenfage: WCF, SCA oder JBI?
• Eclipse STP SCA Tools

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)