Zum Inhalt springen

Service Component Architecture

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 17. November 2008 um 11:24 Uhr durch 145.253.187.66 (Diskussion) (→SCA Artefakte). Sie kann sich erheblich von der aktuellen Version unterscheiden.

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:

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 mit verschiedenen Meldungs-Konstrukten zusammenarbeiten, insbesondere Einweg, Asynchron, Frage-Antwort und Benachrichtigung.
  • Infrastruktur-Mö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 interoperabel ist durch einen Ansatz namens Aktivierung ("Activation"). Diese Methode stelle ein Höchstmaß an Komponentenautonomie sicher, verglichen mit den älteren Methoden "mediation" (z. B. JBI) oder "Invocation", verwendet in der JCA, wie erläutert von einem Architekten bei SAP [1].

SCA Artefakte

Das SCA Assembly Model besteht aus einer Serie von Artefakten. Diese werden definiert durch Elemente in XML-Dateien. Eine SCA-Anwendung kann zur Laufzeit andere, nicht standardisierte Repräsentationen von Artefakten haben, die durch diese XML-Dateien repräsentiert werden. Und sie kann 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 des selben 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 Services anderer Komponenten desselben Moduls verknüpft werden, oder mit Services außerhalb des Moduls, insbesondere Services anderer Module. Referenzen auf Services außerhalb des Moduls, auch Services anderer Module, werden im Modul als externe Services definiert. Auch enthalten im Modul sind Beziehungen zwischen Referenzen und Services. Diese werden representiert durch Wires (Drähte).

Eine Komponente besteht aus einer konfigurierten Implementation, wobei die Implementation das Stück Programmcode ist, welches die Geschäftsfunktionen implementiert. Die Komponente konfiguriert die Implementation über spezifische Werte für durch die Implementation deklarierte, änderbare Properties (Eigenschaften). Die Komponente kann die Implementation außerdem konfigurieren, indem sie die Verdrahtung (wiring) der von der Implementation deklarierten Referenzen mit spezifischen Ziel-Services vornimmt.

Komposita werden ausgeliefert innerhalb eines SCA-Systems. Ein SCA-System repräsentiert eine Menge von Services, die wiederum einen Bereich von Geschäftsfunktionalität bereitstellt, der von einer einzelnen Organisation kontrolliert wird. Beispiel Buchhaltung: Das SCA-System könnte alle finanzbezogenen Funktionen abdecken. Und es könnte eine Reihe von Modulen enthalten, die mit jeweils abgegrenzten Bereichen 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 komposites zu gruppieren. Subsysteme enthalten Modul-Komponenten, das sind konfigurierte Exemplare von Modulen. Subsysteme haben, wie Module, Entry Points und External Services, die die externen Services und Referenzen abbilden, die außerhalb des Systems existieren. Subsysteme können ferner Wires enthalten, die die Modulkomponenten verbinden, Entry Points und External Services.[6]

Implementationen

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. ↑ 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.
  7. ↑ http://www.covansys.com/what/SCAFrameworkforSOA.htm


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)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Service_Component_Architecture&oldid=53087249“