„Service Component Architecture“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen
[gesichtete Version][gesichtete Version]
Inhalt gelöscht Inhalt hinzugefügt
K Implementierungen: Englischen Text rausgenommen, detto Weblinks
InternetArchiveBot hat 3 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert. #IABot (v2.0beta14)
(13 dazwischenliegende Versionen von 12 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{QS-Informatik| Artikel ist wertend und erklärt das Lemma nicht. --[[Benutzer:Temporäres Interesse|Temporäres Interesse]] 13:43, 14. Sep. 2009 (CEST)|Knacknüsse=Ja}}
{{QS-Informatik| Artikel ist wertend und erklärt das Lemma nicht. --[[Benutzer:Temporäres Interesse|Temporäres Interesse]] 13:43, 14. Sep. 2009 (CEST)|Knacknüsse=Ja}}
Die '''Service Component Architecture (SCA)''' ist eine Sammlung an Spezifikationen, welche ein Modell einer [[Serviceorientierte Architektur|Serviceorientierten Architektur]] (SOA) beschreiben. SCA basiert auf offenen Standards wie [[Web Services]].<ref>[http://www.osoa.org/display/Main/Service+Component+Architecture+Home Service Component Architecture Home] - SCA auf www.osoa.org</ref> Dem SOA-Gedanken folgend sind SCA-Komponenten unabhängig von einer konkreten Technologie.
Die '''Service Component Architecture''' ('''SCA''') ist eine Sammlung an Spezifikationen, welche ein Modell einer [[Serviceorientierte Architektur|Serviceorientierten Architektur]] (SOA) beschreiben. SCA basiert auf offenen Standards wie [[Web Services]].<ref>{{Webarchiv|url=http://www.osoa.org/display/Main/Service+Component+Architecture+Home |wayback=20110411193109 |text=Service Component Architecture Home |archiv-bot=2019-05-13 15:56:19 InternetArchiveBot }} – SCA auf www.osoa.org</ref> Dem SOA-Gedanken folgend sind SCA-Komponenten unabhängig von einer konkreten Technologie.


== Partner ==
== Partner ==
Die folgenden Firmen arbeiten als Partner zusammen an der Erstellung der Spezifikationen der Service Component Architecture:
Die folgenden Firmen arbeiten als Partner zusammen an der Erstellung der Spezifikationen der Service Component Architecture:
[[BEA Systems]], [[Cape Clear (software company)|Cape Clear]], [[IBM]], [[SpringSource]], [[IONA (Unternehmen)|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]].<ref>[http://www.osoa.org/display/Main/Service+Component+Architecture+Partners Sercice Component Architecture Partners]</ref>
[[BEA Systems]], [[Cape Clear (software company)|Cape Clear]], [[IBM]], [[SpringSource]], [[IONA (Unternehmen)|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]].<ref>[http://www.osoa.org/display/Main/Service+Component+Architecture+Partners Service Component Architecture Partners]</ref>


== Definition ==
== Definition ==
Die veröffentlichte Spezifikation <ref>http://www-128.ibm.com/developerworks/library/specification/ws-sca/</ref> scheint vage in vielfacher Hinsicht. Aber sie entwickelt sich rasch und es bilden sich neue Spezifikationen heraus <ref>http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications</ref>. Die Spezifikationen legen für nach SCA entworfene Anwendungen folgende Eigenschaften fest:
Die veröffentlichte Spezifikation<ref>http://www-128.ibm.com/developerworks/library/specification/ws-sca/</ref> scheint vage in vielfacher Hinsicht. Aber sie entwickelt sich rasch und es bilden sich neue Spezifikationen heraus<ref>{{Webarchiv|url=http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications |wayback=20071012184346 |text=Archivierte Kopie |archiv-bot=2019-05-13 15:56:19 InternetArchiveBot }}</ref>. 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.
* 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 (Programmiersprache)|Java]], [[COBOL]] und [[PHP]], sowie mit [[Extensible Markup Language|XML]], [[BPEL]] und [[XSLT]].
* Sollte mit verschiedenen Programmiersprachen und -standards zusammenarbeiten, unter anderem mit [[C++]], [[Java (Programmiersprache)|Java]], [[COBOL]] und [[PHP]], sowie mit [[Extensible Markup Language|XML]], [[BPEL]] und [[XSLT]].
Zeile 17: Zeile 17:


== Weitere Analyse ==
== 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. <ref>http://www.gartner.com/resources/136600/136687/new_soa_specification_will_f_136687.pdf</ref>
[[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.<ref>http://www.gartner.com/resources/136600/136687/new_soa_specification_will_f_136687.pdf</ref>


Vorteile:
Vorteile:
* ausgelegt für alle existierenden [[Java-Plattform]]en und C++-Technologien (Jedoch hat das SCA-C++-Komponentenmodell schwere Mängel<ref>[http://web.archive.org/web/20080224210629/http://ke-jin.blogspot.com/2007/11/service-component-architecture-sca.html !] via [[Internet Archive]]</ref>)
* ausgelegt für alle existierenden [[Java-Plattform]]en und C++-Technologien (Jedoch hat das SCA-C++-Komponentenmodell schwere Mängel)<ref>{{Webarchiv | url=http://ke-jin.blogspot.com/2007/11/service-component-architecture-sca.html | wayback=20080224210629 | text=SCA considered harmful}}</ref>
* weniger technologieabhängig – benötigt z. B. weder [[Java (Programmiersprache)|Java]] noch [[Extensible Markup Language|XML]]
* weniger technologieabhängig – benötigt z.&nbsp;B. weder [[Java (Programmiersprache)|Java]] noch [[Extensible Markup Language|XML]]
* verwendet SDO, den einzigen Industriestandard für Datenzugriffe in SOA
* verwendet SDO, den einzigen Industriestandard für Datenzugriffe in SOA


Zeile 28: Zeile 28:
* Die Spezifikation adressiert nicht die Performanz von SOA-Anwendungen, was ein Störfaktor für die Anwendung bleibt.
* 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" ([[J2EE Connector Architecture|JCA]]), ein Höchstmaß an Komponentenautonomie sicher. <ref>https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2824].</ref>
Es wird behauptet, dass SCA durch einen Ansatz namens Aktivierung („Activation“) interoperabel sei. Diese Methode stelle, verglichen mit den älteren Methoden „mediation“ (z.&nbsp;B. JBI) oder „Invocation“ ([[J2EE Connector Architecture|JCA]]), ein Höchstmaß an Komponentenautonomie sicher.<ref>{{Webarchiv|url=https://www.sdn.sap.com/irj/sdn/weblogs?blog=%2Fpub%2Fwlg%2F2824 |archive-is=20121217172144 |text=Archivierte Kopie |archiv-bot=2019-05-13 15:56:19 InternetArchiveBot }}</ref>


== SCA Artefakte ==
== SCA Artefakte ==
<!-- Image with unknown copyright status removed: [[Bild:SCA-composite.jpg‎|350px|right]] -->
<!-- Image with unknown copyright status removed: [[Datei:SCA-composite.jpg|350px]] -->

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 ''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 [[Webservice|''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.
Das Basis-Artefakt ist das ''Kompositum''. Dies ist zugleich die Auslieferungs-Einheit innerhalb SCA und enthält [[Webservice|''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.
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.<ref>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.
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.<ref>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.</ref>
</ref>


== Implementierungen ==
== Implementierungen ==
Zeile 52: Zeile 49:
* PocoCapsule
* PocoCapsule
* Trentino
* 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 ==
== Weblinks ==
* [http://www.osoa.org/display/Main/Home Open Service Oriented Architecture collaboration], die offizielle Homepage für Informationen rund um die SCA Spezifikationen
* [http://www.osoa.org/display/Main/Home Open Service Oriented Architecture collaboration], die offizielle Homepage für Informationen rund um die SCA Spezifikationen
* [http://www-128.ibm.com/developerworks/library/specification/ws-sca/ IBM developerworks introductory article on SCA]
* [http://www-128.ibm.com/developerworks/library/specification/ws-sca/ IBM developerworks introductory article on SCA]
* [http://www.planet-soa.com/sca/index.html Die Service Component Architecture - eine Einführung]
* [http://www.planet-soa.com/sca/index.html Die Service Component Architecture eine Einführung]
* [http://www.osoa.org/display/Main/Service%2BComponent%2BArchitecture%2BSpecifications aktuelle Spezifikationen]
* [http://www.osoa.org/display/Main/Service%2BComponent%2BArchitecture%2BSpecifications aktuelle Spezifikationen]
* [http://incubator.apache.org/tuscany/ Apache Open Source project implementation of the SCA specification]
* [http://incubator.apache.org/tuscany/ Apache Open Source project implementation of the SCA specification]
Zeile 65: Zeile 66:
* [http://xml.coverpages.org/ni2005-12-07-a.html#summarySCA Summary of SCA]
* [http://xml.coverpages.org/ni2005-12-07-a.html#summarySCA Summary of SCA]
* [http://khanderaotech.blogspot.com/2007/02/bpel-in-sca-assembly-model.html BPEL in SCA assembly]
* [http://khanderaotech.blogspot.com/2007/02/bpel-in-sca-assembly-model.html BPEL in SCA assembly]
* [http://www.exxeta.com/images/stories/JavaSpektrum.pdf Die Gretchenfage: WCF, SCA oder JBI?] (PDF-Datei; 364 kB)
* [http://www.exxeta.com/images/stories/JavaSpektrum.pdf Die Gretchenfage: WCF, SCA oder JBI?] (PDF-Datei; 364&nbsp;kB)
* [http://www.eclipse.org/stp/sca/index.php Eclipse STP SCA Tools]
* [http://www.eclipse.org/stp/sca/index.php Eclipse STP SCA Tools]
* [http://trentino.sourceforge.net/ Trentino C++ SCA Runtime]

== 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)


== Einzelnachweise ==
== Einzelnachweise ==
Zeile 77: Zeile 76:
[[Kategorie:IT-Architektur]]
[[Kategorie:IT-Architektur]]
[[Kategorie:Webservice]]
[[Kategorie:Webservice]]

[[en:Service Component Architecture]]
[[es:Service Component Architecture]]
[[fr:Service Component Architecture]]
[[ja:Service Component Architecture]]
[[pl:Service Component Architecture]]
[[zh:服务组件架构]]

Version vom 13. Mai 2019, 17:56 Uhr

QS-Informatik
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)

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.[1] Dem SOA-Gedanken folgend sind SCA-Komponenten unabhängig von einer konkreten Technologie.

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

Definition

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

Vorteile:

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

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

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)

Einzelnachweise

  1. Service Component Architecture Home (Memento des Originals vom 11. April 2011 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.osoa.org – SCA auf www.osoa.org
  2. Service Component Architecture Partners
  3. http://www-128.ibm.com/developerworks/library/specification/ws-sca/
  4. Archivierte Kopie (Memento des Originals vom 12. Oktober 2007 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.osoa.org
  5. http://www.gartner.com/resources/136600/136687/new_soa_specification_will_f_136687.pdf
  6. SCA considered harmful (Memento vom 24. Februar 2008 im Internet Archive)
  7. Archivierte Kopie (Memento des Originals vom 17. Dezember 2012 im Webarchiv archive.today)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.sdn.sap.com
  8. 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.