Architektura komponent služby - Service Component Architecture - Wikipedia

Architektura komponent služby (SCA) je softwarová technologie navržená k poskytování modelu pro následující aplikace architektura orientovaná na služby zásady.[1] Technologie vytvořená významnými prodejci softwaru, včetně IBM, Oracle Corporation a Software TIBCO, zahrnuje širokou škálu technologií a jako takový je specifikován v nezávislých specifikacích pro zachování neutrality programovacího jazyka a aplikačního prostředí.[1] Mnohokrát používá podnikový servisní autobus (ESB).

Dějiny

Původní partneři oznámení 30. listopadu 2005 byli: Systémy BEA, IBM, IONA Technologies, Oracle Corporation, SAP AG, Sybase, Xcalia a Zend Technologies.[2]26. července 2006 byli oznámeni další členové Cape Clear, Rozhraní21, Primeton Technologies, Software Progress, červená čepice, Rogue Wave Software, Software AG, Sun Microsystems a Software TIBCO.[3]Siemens AG se ke spolupráci společností pracujících na této technologii připojil 18. září 2006.

Kromě partnerů měla komunita SCA několik formálních příznivců.[4]

Definice

21. března 2007 vydala OSOA Collaboration první verzi specifikace.[5] Specifikace uváděly, že aplikace navržená pomocí SCA by měla mít:

  • Oddělení aplikační obchodní logiky od podrobností jejích vyvolaných servisních volání
  • Cílové služby v mnoha jazycích včetně C ++, Jáva, COBOL, a PHP stejně jako XML, BPEL, a XSLT
  • Schopnost pracovat s různými komunikačními konstrukcemi, včetně jednosměrných, asynchronních, zpětného volání a oznámení
  • Schopnost „vázat“ se na starší komponenty nebo služby, k nimž normálně přistupují technologie jako např Webové služby, EJB, JMS, JCA, RMI, RPC, CORBA a další
  • Schopnost deklarovat (mimo obchodní logiku) kvalita služeb požadavky, jako je bezpečnost, transakce a používání spolehlivých zpráv
  • Data mohou být zastoupena v Servisní datové objekty

Společnost SCA byla proto povýšena, aby nabídla flexibilitu pro kompozitní aplikace, flexibilně začleňující opakovaně použitelné komponenty do programovacího stylu SOA.

Marketingová firma Gartner Group zveřejnil krátký briefing, který propagoval SCA a jeho zahrnutou technologii Servisní datové objekty (SDO) v prosinci 2005.[2]

Výhody:

Nevýhody:

  • Specifikace neřeší výkon aplikací SOA, což je i nadále odrazujícím prvkem přijetí.
  • Zaměření na přenositelnost (místo interoperability),[6] takže je zranitelný vůči opakování CORBA chyby.[7]

Společnost SCA prý poskytovala interoperabilitu prostřednictvím přístupu zvaného „Aktivace“. Jedná se o metodu, která poskytuje nejvyšší stupeň autonomie komponent ve srovnání se starší „mediaci“ (např. JBI ) nebo metoda „Vyvolání“ použitá v JCA, jak vysvětlil architekt ve společnosti SAP.[8]

Artefakty

The Model sestavy SCA se skládá z řady artefaktů, které jsou definovány prvky obsaženými v souborech XML. Modul runtime SCA může obsahovat další nestandardní reprezentace artefaktů představovaných těmito soubory XML a může umožňovat dynamickou úpravu konfigurace systémů. Soubory XML však definují přenosnou reprezentaci artefaktů SCA.

Základní artefakt je kompozitní, což je jednotka nasazení pro SCA a která platí služby ke kterému lze přistupovat vzdáleně. Kompozit obsahuje jeden nebo více komponenty,[9] které obsahují obchodní funkci poskytovanou modulem. Komponenty nabízejí svou funkci jako služby, které mohou být použity jinými komponentami ve stejném modulu nebo které mohou být zpřístupněny pro použití mimo modul prostřednictvím Vstupní body. Komponenty mohou také záviset na službách poskytovaných jinými komponentami - tyto závislosti se nazývají Reference. Odkazy mohou být spojeny se službami poskytovanými jinými komponentami ve stejném modulu, nebo odkazy mohou být propojeny se službami poskytovanými mimo modul, které mohou být poskytovány jinými moduly. Odkazy na služby poskytované mimo modul, včetně služeb poskytovaných jinými moduly, jsou definovány externími službami v modulu. V modulu jsou také obsaženy vazby mezi referencemi a službami, které zastupuje dráty.

Komponenta se skládá z nakonfigurovaného implementace, kde implementace je část programového kódu implementující obchodní funkce. Komponenta konfiguruje implementaci se specifickými hodnotami pro nastavitelnost vlastnosti deklarováno implementací. Komponenta může také konfigurovat implementaci zapojením odkazů deklarovaných implementací na konkrétní cílové služby.

Kompozity jsou rozmístěny v rámci Systém SCA. Systém SCA představuje sadu služeb poskytujících oblast obchodních funkcí, která je řízena jedinou organizací. Například pro účetní oddělení v podniku může systém SCA pokrýt všechny finanční funkce a může obsahovat řadu modulů zabývajících se specifickými oblastmi účetnictví, jeden pro zákaznické účty a druhý pro účty splatné. Abychom pomohli sestavit a nakonfigurovat systém SCA, lze kompozity použít jako implementace komponent, stejně jako třídy Java nebo BPEL procesy. Jinými slovy, SCA umožňuje hierarchii kompozitů, která je libovolně hluboká - takový vnořený model se nazývá rekurzivní.

Zachycení a vyjádření nefunkčních požadavků, jako je bezpečnost, je důležitým aspektem definice služby a ovlivňuje SCA po celou dobu životního cyklu komponent a složení. SCA poskytuje Rámec politiky podporovat specifikaci omezení, schopností a očekávání kvality služeb (QoS), od návrhu komponent až po konkrétní nasazení.

Přechod na normalizační orgán

Po několika letech inkubace v rámci neformální spolupráce v oboru přicházejí na trh brzy (V1.0) implementace specifikace. Partneři pro spolupráci uvedli, že formální odvětvová standardizace bude vhodným dalším krokem, a oznámili své záměry v březnu 2007. Vybranou organizací pro rozvoj norem je Organizace OASIS a nový OÁZA Otevřete CSA Členská sekce byla založena.[10] Na OASIS byly předloženy charty šesti nových technických výborů (TC)[11] a v rámci organizace OASIS byla vydána výzva k účasti pro členy technické komise. Technické výbory plánovaly zahájit svou práci v září 2007. Účast na těchto TC OASIS SCA zůstává otevřená všem společnostem, neziskovým skupinám, vládám, akademickým institucím a jednotlivcům. Archivy práce budou přístupné jak členům, tak nečlenům a OASIS nabídne mechanismus pro veřejné připomínky.[12]

Viz také

Reference

  1. ^ A b Edwards, Mike. „Architektura komponent služby“. OÁZA. Citováno 7. dubna 2011.
  2. ^ A b Daniel Sholler, David Mitchell Smith (5. prosince 2005). „Nová specifikace SOA naplní mezeru mezi uživateli Java“ (PDF). Gartner Group. Citováno 29. dubna 2017.CS1 maint: používá parametr autoři (odkaz)
  3. ^ Prodejci technologií srinivas rozšiřují spolupráci na technologiích SOA http://www.hoise.com/primeur/06/articles/monthly/AE-PR-08-06-92.html Archivováno 12.07.2011 na Wayback Machine
  4. ^ Podporovatelé technologie OSOA http://www.osoa.org/display/Main/Current+OSOA+Supporters+Community
  5. ^ „Specifikace architektury komponent služby“. Otevřete webovou stránku SOA Collaboration. Archivovány od originál 12. října 2007. Citováno 29. dubna 2017.
  6. ^ [1] Archivováno 2008-07-05 na Wayback Machine SCA a SDO, příští Corba?
  7. ^ „Archivovaná kopie“. Archivovány od originál dne 02.12.2008. Citováno 2011-04-08.CS1 maint: archivovaná kopie jako titul (odkaz) Vzestup a pád CORBY
  8. ^ "community.user: Porovnání SCA, Java EE a JBI | SCN". Sdn.sap.com. 12. 12. 2005. Archivovány od originál dne 2012-12-17. Citováno 2013-06-16.
  9. ^ Bell, Michael (2008). „Konceptualizace zaměřená na služby“. Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. str. 3. ISBN  978-0-470-14111-3.
  10. ^ „OASIS Otevřená členská sekce CSA pro SCA“.
  11. ^ „Šest technických výborů navržených pro členskou sekci OASIS Open CSA“.
  12. ^ „Formulář šesti výborů OASIS pro standardizaci architektury komponent služeb (SCA) pro SOA“.

Další čtení

  • Porozumění SCA od odborníků Jim Marino a Michael Rowley [2]
  • SOA pro Business Developer: Concepts, BPEL a SCA—ISBN  978-158347-065-7
  • Apache Toskánsko v akci, ISBN  978-1-933988-89-4
  • Open Source SOA, ISBN  1-933988-54-1

externí odkazy