SCA
A Service Component Architecture (SCA) viszonylag új , Szolgáltatás Orientál Architektúrára (SOA) épülő fejlesztési modell, amely néhány nagyobb szoftvergyártó - mint például a BEA Systems, IBM, ORACLE, SAP Archiválva 2011. április 19-i dátummal a Wayback Machine-ben, stb. - kezdeményezésére jött létre. Az első publikált verzió (0.9) 2005 novemberében jelent meg. 2007 márciusában publikálták az 1.0 verziót, a modell fejlesztésének menedzselését napjainkban az OASIS végzi. Az SCA maga olyan specifikációk gyűjteményének tekinthető, amely skálázható alkalmazások készítéséhez nyújt hatékony fejlesztési modellt.
SCA alapok
[szerkesztés]Egy modern alkalmazás szoftverkomponensek olyan halmazának tekinthető, amelyek egymással együttműködni képesek. Ezen szoftverkomponensek készülhetnek ugyanazon technológia alapján, de egymástól eltérő technológia szerint is. A komponensek futhatnak egy adott számítógépen egy adott operációs rendszer alatt, vagy akár több különböző számítógépen, különböző operációs rendszerek processzeiként. (Elosztott alkalmazások). Az SCA specifikáció tartalmazza, miként készíthetünk komponenseket, illetőleg miként szervezhetjük össze azokat komplett alkalmazásokba. Az SCA alkalmazások készülhetnek Java, vagy tetszőleges más programnyelven, épülhetnek egymástól eltérő keretrendszerekre, mint például a Spring, vagy a Java EE.
Komponensek és kompozíciók
[szerkesztés]A komponensek
[szerkesztés]Minden SCA alkalmazás egy vagy több komponensből áll, amelyek lehetnek egy processzből álló alkalmazások, de akár osztott rendszerként különböző gépeken, különböző operációs rendszer alatt futó processzekből állók is. Az egyes komponensek készülhetnek ugyanazon technológia alapján, de akár eltérő technológiára is épülhetnek. Maga a komponens egy megfelelően konfigurált megjelenési formája egy adott implementációnak. Az implementáció az a kód, amely az adott komponens funkcióját megvalósítja. Ezt a kódot különböző nyelveken (pl. Java, C++, BPEL) is írhatják. A komponens az SCA modell legkisebb egysége.
Szolgáltatások, referenciák és tulajdonságok
[szerkesztés]Az egyes komponensek egymással interakcióra képes elemi egységek. Egy adott komponens szolgáltatásokat nyújthat más komponensek, illetőleg SCA – n kívüli szoftverek részére, valamint szolgáltatásokat igényelhet más komponensektől, vagy SCA – n kívüli szoftverektől. Az SCA terminológiában szolgáltatásnak (service) egy adott komponens által nyújtott szolgáltatásokat nevezzük. A szolgáltatásokat a komponens implementálhatja saját maga, de igénybe veheti e célból más komponensek szolgáltatásait is. Ez utóbbit az un. referenciákon keresztül valósítja meg. A referencia olyan kapcsolódási pont, amelyen keresztül egy SCA komponens más komponens szolgáltatására hivatkozhat. A komponensek harmadik eleme, amelyen keresztül a külvilággal kapcsolatot tarthatnak a tulajdonságok (propertyk). A tulajdonságok a konfigurációs állományból (SCDL) kapnak értéket, szerepük az adott komponens működésének finomhangolása az adott környezet által meghatározott értékek alapján.
Kompozíciók
[szerkesztés]Az egyes komponenseket, mint atomi egységeket nagyobb struktúrába szervezve kapjuk a kompozíciókat. A kompozíció olyan logikai struktúra, amely SCA komponensekből áll. A kompozíción belül lévő komponensek száma nincs explicit módon meghatározva, s ugyancsak nem tartalmaz a specifikáció követelményeket az egyes komponensek fizikai elhelyezkedésére vonatkozólag sem . Az egyes kompozíciók kapcsolatban állhatnak más kompozíciókkal, vagy SCA modellen kívül eső elemekkel, például adatbázis-kezelő rendszerekkel is.
A komponensek és kompozíciók konfigurálása
[szerkesztés]Az SCA kompozíciókat, a bennük található komponenseket, a kapcsolatokat és az azt leíró policyt XML alapú konfigurációs állományokban írják le. Ezen állományok leíró nyelve a Service Component Definition Language (SCDL).
Egy példa a kompozíciók leírására:
<composite name =”myComposite” autowire=”true” ...><br />
<component name=”Acomp” >
<implementation.java class=”services.myClass”/>
<property name=”p1”>
P1
</property>
</component>
<component name=”Bcomp” >
<implementation.bpel processes=”myProcess”/>
<property name=”p2”>
P2
</property>
</component>
<component name=”Ccomp” >
<implementation.java class=”services.myClass2”/>
<property name=”p3”>
P3
</property>
</component>
<service name="AS" promote="Acomp/AS"
<binding.ws uri=”http://www.example.com/exampleservices/serviceA/>
</service>
<reference name=”R1” promote=”Bcomp/R1”/>
<reference name=”R2” promote=”Ccomp/R2”/>
</composite>
Az SCDL konfigurációs állomány sémájának felépítéséről az alábbi linken tájékozódhatunk: https://web.archive.org/web/20110904211635/http://simsapi.org/api/scdl
Domain
[szerkesztés]Ha egy elosztott alkalmazást vizsgálunk előfordulhat, hogy maga az alkalmazás különböző gépeken, különböző operációs rendszereken, eltérő technológiával létrehozott komponensekből, illetőleg kompozíciókból tevődik össze. Az SCA modell engedi, hogy alkalmazásunk ilyen heterogén módon legyen megvalósítva, mindeközben nem specifikálja, hogy az egyes komponensek között milyen módon valósuljon meg az interakció. A domain olyan SCA futási környezetben definiált logikai egység, amely egy szállítótól származó, azonos, vagy egymással kompatibilis technológiára épülő komponensekből, illetőleg kompozíciókból áll. A domain határai nem korlátozódnak egyetlen számítógépre. Az alkalmazás komponensei továbbra is futhatnak különböző gépek eltérő operációs rendszerein, azonban a komponenseknek minden esetben azonos vagy egymással kompatibilis technológiára kell épülniük, s azokat egy szállítói csoport tartja karban. A domain határain belül lévő komponensek, illetőleg kompozíciók képesek kapcsolatot létesíteni a domain határain kívül eső elemekkel is, akár SCA technológiára épülnek azok, akár nem. A domain határain belül lévő elemek interakcióira általában a közösen menedzselt keretrendszer implicit módon határozza meg a kommunikációs metódust, de a domain határain túllépő kommunikációra ilyen automatizmus nem biztosított. Ez esetben az interakciót megvalósító protokollt explicit módon specifikálni kell. Az SCA nem követeli meg kizárólagosan egyetlen protokoll használatát, bár a gyakorlatban legtöbbször valamelyik webszolgáltatás használatos.
Kötések
[szerkesztés]A komponensek szolgáltatásaik és referenciáik segítségével kommunikálnak más szoftverekkel. Az SCA modell ezen kommunikációs mechanizmusra nem ír elő kötelező megoldásokat, így azokat az alkalmazás fejlesztése során specifikálni kell. Ezen feladat megvalósítását kötésnek (binding) nevezzük. A kötések meghatározzák a kommunikáció mikéntjét az SCA komponensek között, illetőleg más szoftverelemekkel is. Egy domainen belül, mivel azonos technológiára épülő komponensek kommunikációjáról van szó, amelyet ugyanazon szállítók tartanak karban, a kötéseket nem kell explicit módon megadni, azokat a keretrendszer automatikusan meghatározza. Az alkalmazott implicit kötésre nincs általános szabály, így szállítóként, illetőleg domainenként eltérő lehet. Szerencsére ezzel az alkalmazásfejlesztőnek nem kell foglalkoznia.
Explicit módon meg kell adni a kötéseket abban az esetben, ha két domain között, vagy a domain és SCA modellen kívül eső szoftverek között kell interakciót megvalósítani. Ez esetben mind a szolgáltatások, mind a referenciák részére specifikálni kell, mely kommunikációs protokollt használják. A specifikációt az SCDL állomány tartalmazza, például:
<service name=”AS” promote=”Acomp/AS”<br />
<binding.ws uri=”http://www.example.com/exampleservices/serviceA/>
</service>
A lehetséges kommunikációs módszerek a teljesség igénye nélkül a következők lehetnek: a HTTP protokoll feletti SOAP (Simple Object Access Protocol) például Webszolgáltatás kötést használ, az üzenetvezérelt protokollok a JMS (Java Message Service) kötéseket. Az EJB (Enterprise JavaBean) kötések megengedik a session babok részére az IIOP (Internet Inter -ORB) protokoll használatát. Mindezek mellett minden SCA futási környezet biztosít SCA kötéseket, amely szállítófüggő, többnyire valamilyen bináris formátumú kommunikációt jelent.
Huzalok és promóciók
[szerkesztés]Huzaloknak (wire) nevezzük egy kompozíción belüli komponensek referenciái és szolgáltatásai között lévő kapcsolatot. Az ábránkon ilyen huzalra példa az RA - BS, illetőleg az RB – CS kapcsolat. Mivel a kompozíciók egy domainen belül helyezkednek el, így a huzalokon megvalósuló kommunikációs forma meghatározását a futási környezet implicit biztosítja, amely futási környezetenként eltérő lehet. Mivel a huzalokat a keretrendszer implicit módon hozza létre, nem szükséges azokat a konfigurációs állományban leírni.
Nemcsak a komponensek, hanem a kompozíciók is nyújthatnak szolgáltatásokat, illetőleg lehetnek referenciái más szolgáltatások irányába. Ahhoz, hogy a kompozíciók ezt megtehessék egy vagy több belső komponense szolgáltatását, illetőleg referenciáit elérhetővé kell tenni a külvilág számára. Ez a promóció (promotion – előléptetés, reklámozás). A promóciókat az SCDL állományban írjuk le, például:
<reference name=”R1” promote=”Bcomp/R1”/><br />
Az ábrán ilyen promóció az AS, ami egy szolgáltatás az Acomp komponenstől, illetőleg az R1 és R2 , amelyek referenciák Bcomp és Ccomp komponensektől.
Az a mód, ahogy az egyes komponensek definiálják szolgáltatásaikat és referenciáikat nagymértékben függ attól a nyelvtől, illetőleg technológiától amelynek alapján készültek. A J2EE technológiával készült komponensek például annotációkat használnak, más technológiára épülők API hívásokat. Az SCA a komponenst felhasználó elől elfedi a technológia részleteit, számára a komponensek, illetőleg a kompozíciók mint szolgáltatások jelennek meg.
Policy
[szerkesztés]Az elosztott alkalmazások egyes részei között létrejövő kommunikáció igen komplex módon is megvalósulhat. Annak érdekében, hogy a kommunikációs mechanizmust az alkalmazás fejlesztője átláthatóbban menedzselhesse, policyket használhatunk. A policy-k segítségével a fejlesztő specifikálhatja a kommunikációban részt vevő komponensek szándékát, célját. A policy – k létrehozására az SCA definiál egy policy keretrendszert. A keretrendszer alapvetően két széles kategóriát foglal magába:
- Az interakció policy a komponensek egymás közötti interakciójára vonatkozik. Például leírhatja, hogy az adott kommunikáció során biztonságos adatátvitelre van szükség. Ekkor például titkosított csatornát használhatunk.
- Az implementációs policy módosíthatja, hogy az egyes komponensek az adott környezetben miként működjenek. Például egy adott komponens egy adott tranzakción belül futhat csak.
Egy adott domainen belül nincs meghatározva, hogy miként kell leírni az egyes policy - ket, így az szállítóként eltérhet, azonban különböző domainek között szállító független policy - t kell használni. Például a web szolgáltatásokra WS-Policy.
SCA implementációk
[szerkesztés]Maga az SCA modell semmit nem mond arról a technológiáról, amelyet egy SCA környezet implementációja során használhatunk, így számos egymástól eltérő megoldás is lehetséges. Nyílt forráskódú megoldások, például a Tuscany és a Fabric3 Archiválva 2020. augusztus 13-i dátummal a Wayback Machine-ben, de számos gyártó létrehozott saját változatot.
További információk
[szerkesztés]- Service Component Architecture Home
- Service-oriented architecture
- OASIS_%28organization%29
- introducing_sca
- sca
- sca-java
- org Archiválva 2020. augusztus 13-i dátummal a Wayback Machine-ben
