Architektura komponentów usługi

Service Component Architecture ( SCA ) to technologia oprogramowania zaprojektowana w celu zapewnienia modelu dla aplikacji zgodnych z zasadami architektury zorientowanej na usługi . Technologia stworzona przez głównych dostawców oprogramowania, w tym IBM , Oracle Corporation i TIBCO Software , obejmuje szeroki zakres technologii i jako taka jest określona w niezależnych specyfikacjach w celu zachowania neutralności języka programowania i środowiska aplikacji. Często korzysta z korporacyjnej magistrali usług (ESB).

Historia

Pierwotnymi partnerami ogłoszonymi 30 listopada 2005 r. byli: BEA Systems , IBM , IONA Technologies , Oracle Corporation , SAP AG , Sybase , Xcalia i Zend Technologies . Dodatkowi członkowie ogłoszeni 26 lipca 2006 r. to Cape Clear , Interface21 , Primeton Technologies, Progress Software , Red Hat , Rogue Wave Software , Software AG , Sun Microsystems i Oprogramowanie TIBCO . Siemens AG dołączył do współpracy firm pracujących nad technologią 18 września 2006 roku.

Oprócz partnerów, społeczność SCA miała kilku formalnych zwolenników.

Definicja

21 marca 2007 roku OSOA Collaboration opublikowało pierwszą wersję specyfikacji. Specyfikacje mówiły, że aplikacja zaprojektowana z SCA powinna mieć:

  • Oddzielenie logiki biznesowej aplikacji od szczegółów wywoływanych przez nią wywołań usług
  • Usługi docelowe w wielu językach, w tym C++ , Java , COBOL i PHP , a także XML , BPEL i XSLT
  • Możliwość pracy z różnymi konstrukcjami komunikacyjnymi, w tym jednokierunkowymi, asynchronicznymi, zwrotnymi połączeniami i powiadomieniami
  • Możliwość „powiązania” ze starszymi komponentami lub usługami, do których normalnie uzyskuje się dostęp za pomocą technologii takich jak Web Services , EJB , JMS , JCA , RMI , RPC , CORBA i inne
  • Możliwość zadeklarowania (poza logiką biznesową) wymagań dotyczących jakości usług , takich jak bezpieczeństwo, transakcje i wykorzystanie niezawodnego przesyłania komunikatów
  • Dane mogą być reprezentowane w obiektach danych usług

W związku z tym promowano SCA, aby oferować elastyczność dla aplikacji złożonych , elastycznie wprowadzając komponenty wielokrotnego użytku w stylu programowania SOA.

Firma marketingowa Gartner Group opublikowała w grudniu 2005 r. krótki opis promujący SCA i zawartą w nim technologię Service Data Objects (SDO).

Zalety:

Niedogodności:

  • Specyfikacja nie odnosi się do wydajności aplikacji SOA, co nadal jest przeciwnikiem adopcji.
  • Skoncentrowanie się na przenośności (zamiast interoperacyjności), co czyni go podatnym na powtarzanie błędów CORBA .

Mówiono, że SCA zapewnia interoperacyjność poprzez podejście zwane „Aktywacją”. Jest to metoda zapewniająca najwyższy stopień autonomii komponentów w porównaniu ze starszą metodą „mediacji” (np. JBI ) czy „Inwokacji” stosowaną w JCA , jak wyjaśnił architekt z SAP.

Artefakty

Model zespołu SCA składa się z serii artefaktów, które są zdefiniowane przez elementy zawarte w plikach XML. Środowisko wykonawcze SCA może mieć inne niestandardowe reprezentacje artefaktów reprezentowanych przez te pliki XML i może umożliwiać dynamiczną modyfikację konfiguracji systemów. Jednak pliki XML definiują przenośną reprezentację artefaktów SCA.

Podstawowym artefaktem jest Composite , który jest jednostką wdrożenia dla SCA i zawiera usługi , do których można uzyskać zdalny dostęp. Złożony zawiera co najmniej jeden komponent , który zawiera funkcję biznesową zapewnianą przez moduł. Komponenty oferują swoją funkcję jako usługi, z których mogą korzystać inne komponenty w ramach tego samego modułu lub które mogą być udostępniane do użytku poza modułem za pośrednictwem Punktów Wejścia . Komponenty mogą również zależeć od usług świadczonych przez inne komponenty — te zależności nazywane są referencjami . Referencje mogą być połączone z usługami dostarczanymi przez inne komponenty w tym samym module lub referencje mogą być połączone z usługami dostarczanymi poza modułem, które mogą być dostarczane przez inne moduły. Odniesienia do usług świadczonych poza modułem, w tym usług świadczonych przez inne moduły, definiowane są przez Usługi Zewnętrzne w module. Moduł zawiera również powiązania między referencjami i usługami, reprezentowane przez przewody .

Komponent składa się ze skonfigurowanej implementacji , gdzie implementacją jest fragment kodu programu realizujący funkcje biznesowe. Komponent konfiguruje implementację z określonymi wartościami dla ustawialnych właściwości zadeklarowanych przez implementację. Komponent może również skonfigurować implementację z okablowaniem referencji zadeklarowanych przez implementację do określonych usług docelowych.

Kompozyty są wdrażane w ramach systemu SCA . System SCA reprezentuje zestaw usług zapewniających obszar funkcjonalności biznesowej kontrolowany przez pojedynczą organizację. Na przykład w dziale księgowości w przedsiębiorstwie system SCA może obejmować wszystkie funkcje związane z finansami i może zawierać szereg modułów zajmujących się określonymi obszarami księgowości, z których jeden dotyczy rachunków klientów, a drugi dotyczy zobowiązań. Aby pomóc w budowaniu i konfigurowaniu systemu SCA, Composites mogą być używane jako implementacje komponentów, w taki sam sposób jak klasy Java lub BPEL procesy. Innymi słowy, SCA pozwala na hierarchię kompozytów, która jest dowolnie głęboka – taki zagnieżdżony model nazywany jest rekurencyjnym.

Wychwytywanie i wyrażanie wymagań niefunkcjonalnych, takich jak bezpieczeństwo, jest ważnym aspektem definicji usługi i wpływa na SCA przez cały cykl życia komponentów i kompozycji. SCA zapewnia ramy polityki wspierające specyfikację ograniczeń, możliwości i oczekiwań dotyczących jakości usług (QoS), od projektu komponentów po konkretne wdrożenie.

Przejście do organu normalizacyjnego

Po kilku latach inkubacji w ramach nieformalnej współpracy branżowej, na rynku pojawiają się wczesne (V1.0) implementacje specyfikacji. Partnerzy współpracujący wskazali, że formalna normalizacja branżowa byłaby odpowiednim kolejnym krokiem i ogłosili swoje zamiary w marcu 2007 r. Wybraną Organizacją ds. Rozwoju Standardów jest organizacja OASIS oraz nowa OASIS Open CSA Powołano Sekcję Członkowską. Statuty sześciu nowych Komitetów Technicznych (TC) zostały przesłane do OASIS, aw ramach organizacji OASIS wystosowano zaproszenie do uczestnictwa dla członków Komitetów Technicznych. Komitety Techniczne planowały rozpocząć pracę we wrześniu 2007 r. Uczestnictwo w tych OASIS SCA TC pozostaje otwarte dla wszystkich firm, grup non-profit, rządów, instytucji akademickich i osób prywatnych. Archiwa prac będą dostępne zarówno dla członków, jak i osób niebędących członkami, a OASIS zaoferuje mechanizm publicznego komentowania.

Zobacz też

Dalsza lektura

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Service_Component_Architecture&oldid=1105680945 ”