Service Component Architecture

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 3. Dezember 2008 um 20:59 Uhr durch Flash1984 (Diskussion | Beiträge) (grossteils selbst nach edit immer noch unverstaendlich - offensichtlich zu woertlich uebersetzt...). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen
Eine gesichtete Version dieser Seite, die am 3. Dezember 2008 freigegeben wurde, basiert auf dieser Version.

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 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 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 Diensten anderer Komponenten des selben 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 es könnte 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.[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=53725680“