Szolgáltatásorientált architektúra
A szolgáltatásorientált architektúra (angolul Service-Oriented Architecture, röviden SOA) egy programozási módszer, aminek lényege, hogy az egyes szolgáltatások egy hálózatban helyezkednek el, és egy protokoll által meghatározott módon kommunikálnak. Alapvető elvei függetlenek gyártóktól, termékektől, terjesztőktől és technológiáktól.[1] A szolgáltatások különálló egységek, amik távolról is elérhetők, egymástól függetlenül elérhetők, használhatók, frissíthetők, újra kombinálhatók a folyamatok folytonos változásának, megújulásának megfelelően.
Egy szolgáltatásnak a következőket kell teljesítenie:[2]
- Logikailag reprezentál egy üzleti aktivitást előre meghatározott kimenettel.
- Önálló, független egység (self-contained).
- Feketedoboz a kliensei számára.
- Tartalmazhat több részszolgáltatást.[3]
Az 1970-es években a modularitásra megadott definíció szerint különböző szolgáltatások használhatók együtt, hogy egy nagy alkalmazás funkcionalitását nyújtsák.[4] Azonban a szolgáltatásorientált architektúra célja nem az egyes alkalmazások tagolása, és az így létrejövő, részfunkcionalitásokat nyújtó modulok közötti kapcsolat biztosítása, hanem ellenkezőleg: minden szempontból önálló, saját funkcionalitással bíró, és eleve együttműködésre tervezett szolgáltatások összekapcsolásán keresztül megvalósítani az üzleti folyamatokat. A SOA a vállalat üzleti folyamataira jellemző – valós üzleti tevékenységeket tükröző – szolgáltatások tervezésén alapul,[2] és nem az alkalmazások technológiai célú szétbontásán.
A szolgáltatásorientált architektúra célja
[szerkesztés]A szolgáltatásorientált architektúra a lazán kapcsolódó, és együttműködő szoftver szolgáltatások segítségével támogatja az üzleti és más folyamatokat. Rendelkezik megfelelő mechanizmussal különböző működési modellek meghatározására, felépítésére. Biztosítja, hogy egy-egy szolgáltatás pontosan megfeleljen a működési modell által meghatározott céloknak.
A szolgáltatások protokollokkal kapcsolódnak, amelyek metaadatokkal leírják az adatok tárolásának, küldésének, konvertálásának módját. A metaadatok leírják az egyes szolgáltatások célját, működését és minőségi jellemzőit is. Az architektúra célja, hogy a felhasználók hosszabb kódszakaszokat kombinálhassanak, amelyekből ad hoc módon létrehozhatják alkalmazásaikat. Egy szolgáltatás egyszerű interfészt reprezentál, ami feketedobozként absztrahálja az alatta levő bonyolultságot. A felhasználók a belső reprezentáció ismerete nélkül vehetik igénybe ezeket a szolgáltatásokat.[5]
Szempontok
[szerkesztés]A lazán kapcsolódó egységeket, amelyek különböző funkciókat valósítanak meg, szolgáltatásoknak nevezzük.[6] Ezek egy hálózatba vannak kapcsolva, és egy protokoll által meghatározott módon kommunikálnak.[7]
A minta manifesztuma 2009 októberében jelent meg. Ez hat szempontot jelölt meg, amiket a minta alkalmazásához figyelembe kell venni:[8]
- Az üzleti érték fontosabb, mint a technikai stratégia.
- A stratégiai célok fontosabbak, mint a projekt-specifikus előnyök.
- A belső együttműködés fontosabb, mint a konfigurációs integráció.
- A megosztott szolgáltatások fontosabbak, mint a specifikus célú megvalósítások.
- A rugalmasság fontosabb, mint az optimalizáció.
- Az evolúciós finomítás fontosabb, mint az első változat tökéletessége.
A szolgáltatásorientált architektúra az elosztott számítások[6][9] és a moduláris számításoktól a modern mashup, Saas, és felhőprogramozás közötti kontinuum részének tekinthető.[10]
Elvek
[szerkesztés]Nincsenek általános szabványok az architektúra pontos összeállítására, habár egyes vállalatok közzétették saját elveiket. Ezek közül több tartalmazza a következőket:[12][13][14][15]
- Szabványos formátumú szerződések:
- A szolgáltatások kommunikációjukban szabványt követnek, amit egy vagy több dokumentum le is ír.
- Szolgáltatásreferenciák autonómiája:
- A szolgáltatások közötti kapcsolat olyan laza, hogy csak azt tudják egymásról, hogy léteznek.
- Szolgáltatások helytől független láthatósága:
- A szolgáltatások fizikai helyüktől függetlenül elérhetik egymást.
- Szolgáltatások tartóssága:
- A szolgáltatásokat tartósra kell tervezni. Ha egy szolgáltatás hívható ma, akkor holnap is hívható kell, hogy legyen. Az újabb szolgáltatásoknak kerülniük kell, hogy újabb követelményeket támasszanak a kliensekkel szemben.
- Szolgáltatások absztrakciója:
- A szolgáltatások feketedobozként működnek, belső logikájuk rejtve van a kliensek előtt.
- Szolgáltatások autonómiája
- A szolgáltatások függetlenek egymástól, és kontrollálja annak működését, tervezési időtől futás ideig.
- Szolgáltatások állapotmentessége:
- A szolgáltatások nem tárolhatnak a kliens számára fontos adatokat. A szolgáltatás vagy visszaad egy értéket, vagy hibaüzenetet dob vissza.
- Szolgáltatások szemcsézettsége:
- A szolgáltatások hatóköre és mérete legyen megfelelő. A szolgáltatás által nyújtott funkcionalitásnak relevánsnak kell lennie a kliens számára.
- Szolgáltatások normalizációja:
- A szolgáltatásoknak minimalizálniuk kell a redundanciát. Van, amikor egy bizonyos mértékű redundancia elkerülhetetlen optimalizáció, aggregáció és hozzáférés miatt.[16]
- Szolgáltatások komponálhatósága:
- A szolgáltatásoknak komponálhatónak kell lenniük egymással.
- Szolgáltatások megtalálhatósága
- A szolgáltatásokat kommunikatív metaadatokkal kell ellátni, hogy hatékonyan meg lehessen őket találni, és tudni, hogy mire valók.
- Szolgáltatások újrahasználhatósága
- Az alkalmazáslogikát szolgáltatásokra kell szétosztani, hogy ezzel támogassák a kód újrafelhasználását.
- Szolgáltatások beburkolása
- Sok szolgáltatást újra lehet használni, akár szolgáltatásorientált architektúrában beburkolással.
Minták
[szerkesztés]A részrendszerek a következő csoportokba oszthatók:
- Szolgáltató
- Létrehozza a webszolgáltatást, és információt közvetít a névszolgáltatónak. Azt is leírja, hogy milyen szolgáltatást nyújt, mi a fontosabb: a könnyű elérhetőség vagy a biztonság, mennyiért lehet igénybe venni, és további információkat is adhat, amik bekerülnek a névszolgáltatóhoz.[17]
- Névszolgáltató
- Egy névszolgáltató feladata az, hogy információt nyújtson az elérhető szolgáltatásokról. Megvalósítójuk döntésétől függően lehetnek nyilvánosak vagy privátok, ez utóbbiakat nem mindenki veheti igénybe. Az UDDI egy korai kísérlet volt a webszolgáltatások felderítésére.
- Szolgáltatásigénylő
- Az általa igényelt szolgáltatás elérhetőségét névszolgáltatónál keresi, majd a kellő információk birtokában hozzákapcsolódik a szolgáltatóhoz, és meghívja szolgáltatásait. Egy résztvevő lehet egyszer szolgáltató, másszor szolgáltatásigénylő. A szolgáltatók is névszolgáltatónál keresik a számukra fontos adatokat.
A szolgáltatások kapcsolatát a szabványosított szolgáltatásszerződés szabályozza,[18] aminek van üzleti része, funkcionális része és technikai része.
A szolgáltatáskompozíciós mintáknak két széles, magas szintű architekturális stílusa van: a koreográfia és a hangszerelés. Az alacsony szintű vállalati integrációs minták nem kapcsolódnak egyikhez sem, de még mindig fontosak, és a keretrendszerekben választhatók is.[19][20][21]
A legfontosabb szabványok
[szerkesztés]
A SOA-t egy szabványos felszínen, a webszolgáltatás platformon valósítják meg. Ezt a Web szolgáltatás szabványt egyformán támogatja a .NET és a Java. A SOA által használt szolgáltatásorientált környezet legfontosabb szabványai a következők:
- SOAP, egy XML (WSDL) alapú kiterjesztett üzenet formátum (boríték).
- WSDL, webszolgáltatás leíró nyelv, (Web Services Description Language)
- UDDI, általános kereső és integrációs leírásokat tároló eszköz (Universal Description Discovery and Integration).
- Üzenetküldés, mint ActiveMQ, JMS, RabbitMQ.
- RESTful HTTP, a REST saját megkötés alapú architekturális stílusával
- OPC-UA
- WCF a Microsofttól
- Apache Thrift
- SORCER
A SOAP a W3C 1.2 ajánlása óta vált népszerűvé, amit 2003-ban tettek közzé.[22] Ezekre a szabványokra hivatkoznak úgy is, mint webszolgáltatás specifikációk. Ezek teszik lehetővé a szélesebb körű együttműködést, és védelmet a szolgáltatótól való függéstől. Használhatók más szolgáltatás alapú technológiák, mint Jini, CORBA vagy REST.
Magas szintű programnyelvek, mint a BPEL és a WS-CDL és WS-Coordination specifikációk kiterjesztik a szolgáltatás fogalmát azzal, hogy meghatároznak egy módszert, amivel definiálható és támogatható finomszemcsézett szolgáltatások hangszerelése durvaszemcsézett üzleti szolgáltatásokká, amik beágyazhatók munkafolyamatokba és üzleti folyamatokba, amiket összetett szolgáltatások vagy portálok valósítanak meg.
A Service-oriented modeling framework (SOMF) modellezőnyelvet és munkakörnyezetet nyújt, amivel különböző komponensek írhatók le, hogy hozzájáruljanak a szolgáltatásorientált architektúra eredményes modelljéhez.
Szolgáltatástervezés
[szerkesztés]A szolgáltatás beazonosítása
[szerkesztés]A létező alkalmazási környezetekben használt alkalmazások funkciói nagyon gyakran felhasználhatók mint szolgáltatások. Ez a hozzáállás esetenként egyáltalán nem igényel programozást, más esetben a program nem túl jelentős módosításával megvalósítható. Ez természetesen jelentős költség- és nem mellékesen időmegtakarítással jár.
Azonban a fejlesztők általában nem vagy alig rendelkeznek ismeretekkel a meglévő alkalmazásokról ezért egy SOA projektben rendkívül fontos, hogy a fejlesztők és az „üzleti” elvárásokat megfogalmazó szponzorok a fejlesztések tervezési fázisába bevonják a meglévő alkalmazások üzemeltetőit és kulcsfelhasználóit is a munkába.
A legtöbb intézmény informatikai rendszere, létrejöttének megfelelően, több különálló sziget rendszerből áll. Ezek a rendszerek egységes rendszerbe történő integrálását biztosíthatja egy SOA projekt. Az informatikai piac minden jelentős szállítója biztosít olyan SOA megoldásokat, amelyek szolgáltatás brókerek, tárolt eljárások segítségével, lehetővé teszik meglévő alkalmazásoknak szolgáltatásként történő felhasználását
Szolgáltatás létrehozása
[szerkesztés]A szolgáltatás-specifikációk elkészítése az adott funkciók megvalósításához szükséges WSDL dokumentumok elkészítését jelenti. Ehhez először megfelelő modellező eszközt kell kiválasztani a szállítók által kínált eszközök közül. Majd, amennyiben szükséges, meg kell keresni a megfelelő eszközt a meglévő alkalmazások szolgáltatásorientált felhasználására. Amennyiben elkerülhetetlen új szolgáltatások alkalmazása, akkor a meglévő informatikai környezetbe legkönnyebben beilleszthető fejlesztő eszközt kell kiválasztani.
Minden jelentős szoftverszállító HP, IBM, Microsoft, Oracle, de kisebb csak erre a területre specializálódott cégek egyaránt biztosítanak eszközöket úgy a meglévő üzleti alkalmazások (Legacy systems) szolgáltatásorientált architektúrában történő felhasználására, mint azoknak szolgáltatássá alakítására. (HP SOA Gateway; IBM Rational Developer & IBM WebSphere; Microsoft Net Framework; Oracle SOA Suite components stb.)
Szolgáltatások összekapcsolhatósága
[szerkesztés]A vállalati szolgáltatás sín a SOA elvei szerint kialakított szolgáltatás kérők és szolgáltatás szolgáltatók közötti összekapcsolhatóságot biztosító infrastruktúra.
Harmadik fél szolgáltatásainak felhasználása
[szerkesztés]A szolgáltatásorientált architektúra nagyon fontos eleme, hogy lehetőséget biztosít mások (harmadik fél) által kidolgozott szolgáltatások felhasználására. Ez természetesen megköveteli megfelelő biztonsági eszközök alkalmazását. Ezeknek a biztonsági követelményeknek való megfelelést különböző gyártók által kialakított SOA szabványnak megfelelő eszközök biztosítják. Ezt a SOA Integration Appliance segítségével valósítják meg a szolgáltatásorientált architektúrákban.
A szolgáltatásorientált architektúrák számára a SOA szabványok létrehozásában részt vevő szervezetek kidolgoztak egy SOA biztonsági referencia modellt.
Megőrzéstervezés (Preservation Planning vagy SOA Governance)
[szerkesztés]A szolgáltatásorientált architektúra legfontosabb eleme a használt szolgáltatások rendszerezése, azok folyamatos minőségbiztosítása és az elérhetőségük biztosítása.
A szolgáltatásorientált architektúra különösen nagy figyelmet fordít a SOA rendszerek életciklusának kezelésére. Ezt külön tanulmányok taglalják, és a szolgáltatások nyilvántartását biztosító regiszterek és katalógusok kezelésére a legtöbb szoftvergyártó speciális eszközöket biztosít.
Megvalósítási megközelítések
[szerkesztés]Szolgáltatásorientált architektúra megvalósítható webszolgáltatásokkal.[23] Ez megtehető funkcionális építőegységekkel, amelyek platformtól és programozási nyelvtől függetlenül elérhetők internetes protokollokkal. Ezek a szolgáltatások reprezentálhatnak új alkalmazásokat vagy adaptálhatnak létező rendszereket úgy, hogy elérhetők legyenek hálózaton.[24]
A megvalósítók rendszerint webszolgáltatások szabványaira támaszkodnak. A legfontosabb szabványokkal külön szakasz foglalkozik. Egy megvalósítás több protokollt is használhat, és még fájlkezelő rendszer mechanizmust is igénybe vehet a kommunikációhoz. A szolgáltatások függetlenségének kulcsa a szabvány használata és az interfész közzététele. Ennek ismeretében a szolgáltatásoknak nem kell ismerniük egymás belső szerkezetét. Mivel a formális definíció független nyelvtől és platformtól, azért például egy kliens igénybe vehet .NET keretrendszerű C# szolgáltatást és egy Java EE-t használó Java szolgáltatást. Mendzselt környezet adaptálhat COBOL rendszert, és szolgáltatásként reprezentálhat..[25]
Egy SOA keretrendszerben a szolgáltatásorientált modellezés azonosítja a különféle módsuzereket, amelyekkel megfogalmazható, elemezhető, tervezhető és felépíthető a szolgáltatásorientált rendszer. A modell lehetővé teszi a projekt megtervezését, mérföldkövek azonosítását.
Szervezeti előnyök
[szerkesztés]Egyes architektek hiszik, hogy a minta segít a vállalatoknak, üzleti köröknek gyorsabban reagálni a piaci változásokra.[26] Ez az architektúra magasabb szinten támogatja az újrafelhasználást, mint az osztályok. Egyszerűsíti a kapcsolatfelvételt a már létező rendszerekkel, és azok felhasználását.
Az architektúra alkalmazásával a szervezet egészlegesen közelítheti meg a probléma megoldását. A fejlesztők nem egy általuk összeválogatott eszközkészletet használnak, hanem egy szabványhoz igazodnak. A vállalatnak is lehet saját szolgáltatásorientált architektúrája üzleti irányú infrastruktúrához. Az architektúrát úgy is bemutathatják, mint úthálózatot, ami kényelmet nyújt a sofőröknek. Ha mindenkinek lenne kocsija, de nem lennének utak, akkor sokkal nehezebb lenne eljutni bárhová.[27]
A minta több tekintetben architekturális forradalomnak, mint forradalomnak tekinthető. Magában foglalja korábbi architektúrák előnyeit. Például kommunikációs rendszerekben valóban statikus kötéseket használó megoldásokat használtak. Szolgáltatásorientált architektúrával ezek a rendszerek meghatározhatják magukat, ha elfogadják, hogy fontosak a jóldefiniált, együttműködésre képes interfészek. A minta további előfutárai a komponens alapú rendszerek és az objektumorientált rendszerek távoli objektumai, például a CORBA rendszerében.
Egy szolgáltatás a funkcionalitás egy önálló egységét valósítja meg, ami csak formálisan definiált interfész útján érhető el. A szolgáltatások a nanovállalatok egy fajtájának tekinthetők, amik könnyen gyárthatók és javíthatók. A szolgáltatások lehetnek megakorporációk is, amiket több szolgáltatás összehangolt munkája épít fel. Az architektúra részletes leírásaiban szerepel is egy szervezet API-jának definíciója.
A szolgáltatások különálló objektumként való kezelésének előnyei:
- Az elkülönítés azt sugallja, hogy a szolgáltatások egymástól függetlenül, gyorsan fejleszthetők, szemben azzal, hogy közösen használnának nagyobb kódrészeket. Ezzel a szolgáltatásokat is jobban meg lehet érteni, alkalomadtán az üzleti interfészeket is egyszerűsíteni. Ez támogatja az agilis fejlesztést, és segíti az innovációt, gyorsítja a fejlesztést.[28]
- Ezen a módon elkülönülnek a szolgáltatások és az azokat felhasználó rendszerek. Ez javítja a tervezést, hiszen a szolgáltatásoknak nem kell tudniuk arról, hogy ki veszi őket igénybe.
- A rendszer dokumentációja és tesztelése is egyszerűbbé válik, amiket egy nagyobb projekt részeként nehezebb lenne megvalósítani. Ez fontos a későbbi újrafelhasználáshoz.
Az architektúra közvetve segíti a tesztelést is, mivel az elemek külön-külön tesztelhetők, nem látnak bele egymás megvalósításába. A szolgáltatások önállóak, állapotmentesek, interfészük teljesen dokumentált. Megfelelően definiált tesztadatok birtokában megépíthető a megfelelő csonk, ami a tesztre reagál. A szolgáltatáshoz eltárolják a regressziós tesztek, szkriptek, adatok és válaszok teljes sorát. A szolgáltatás tesztelhető feketedobozként felhasználva a meglevő csonkokat, az általa hívott szolgáltatásoknak megfelelően. Tesztkörnyezetek építhetők, ahol a primitív és a teszt hatókörén kívüli szolgáltatások csonkok, a többi teljes szolgáltatások teszt telepítése. Mivel minden interfész dokumentációjához csatolva vannak a regressziós tesztek dokumentációi, könnyű azonosítani a problémákat a teszt szolgáltatásokban. A teszt célja csak annyi, hogy igazolja, hogy a szolgáltatás a dokumentációnak megfelelően működik, megtalálja a hiányosságokat a dokumentációban, és a környezetből hiányzó teszteseteket. Egyedül az idempotens szolgáltatások adatainak ellenőrzése okozhat további bonyodalmakat.
A példák hasznosak ahhoz, hogy olyan szinten támogassák a dokumentációt, amilyen szinten az hasznos. Erre példa néhány Java Community Process API. Ezek nagyon részletesek, emiatt mindenki csak azt olvassa el belőlük, ami neki kell. A JSR-89-ben az ossjsa.pdf egy ilyen fájlra nyújt példát.[29]
Kritika
[szerkesztés]A szolgáltatásorientált architektúrát felhasználták webszolgáltatásokhoz;[30] azonban ez csak egy lehetőség az architektúra megvalósítására. A távoli natív vagy bináris procedúra (RPC) hiányában az alkalmazások lassabbak lehetnek, több erőforrást igényelhetnek, ami növeli a költségeket. A legtöbb megvalósítás kompromisszumként elfogadja, ám ezen segíthetnek különféle technológiák, mint Java Business Integration (JBI), Windows Communication Foundation (WCF) és data distribution service (DDS)), amik nem függnek távoli eljáráshívástól vagy XML feldolgozástól. Ugyanakkor nyílt forrású XML technikák, mint VTD-XML és XML-kompatibilis bináris formátumok a nem funkcionális tulajdonságok szignifikáns javítását igénylik. Ezek a tulajdonságok azzal is javíthatók, ha a megvalósítás XML-ről áttér JSON-re.[31][32][33]
Állapotot tároló szolgáltatások esetén a szolgáltatásnak és a kliensnek ugyanazt a kliens-specifikus környezet kell használnia. Ezt vagy ennek referenciáját tartalmaznia kell a szolgáltatás és a kliens üzeneteinek. Ennek az a hátránya, hogy korlátozza a skálázhatóságot, ha a szolgáltatónak minden kliensre emlékeznie kell. Erősíti a szolgáltatás és a kliens kapcsolatát, és nehezebbé teszi a szolgáltatások cseréjét.[34] Néhány kritikus úgy véli, hogy a szolgáltatásokat még mindig túlzottan korlátozzák az általuk nyújtott alkalmazások.[35]
Kihívást jelent a metaadatok kezelése. Az architektúrán alapuló rendszerek sok szolgáltatást tartalmaznak, amelyek egymással kommunikálnak ahhoz, hogy feladatokat végezzenek el. Emiatt az üzenetek száma is nagy. Továbbá az egyes szolgáltatások nem biztos, hogy bízhatnak egymásban, mert egymással versengő cégekhez tartozhatnak. Ezt az architektúra irányításának kell kezelnie.[36]
További nagyobb probléma az egységes tesztkörnyezet hiánya. Hiányoznak azok az eszközök, amelyek támogatnák az igényelt feature-okat a tesztelés során. A bonyolultság fő okai:[37]
- A megoldás heterogenitása és bonyolultsága.
- Az autonóm szolgáltatások miatt sok kombinációt kell tesztelni.
- Különböző, sőt egymással versengő terjesztők termékeinek használata.
- A platform és a teljes rendszer folyamatosan változik, mivel újabb és újabb szolgáltatásokat vezetnek be.[38]
Kiterjesztések és változatok
[szerkesztés]Web 2.0
[szerkesztés]Tim O'Reilly megalkotta a Web 2.0 kifejezést a web alapú szolgáltatások egy gyorsan növekvő csoportjára.[39] A Web 2.0 és a szolgáltatásorientált architektúra között hasonlóságok fedezhetők fel.
A szolgáltatásorientált architektúra mögötti elgondolás szerint az alkalmazáslogika egységesen definiált interfészekkel ellátott szolgáltatásokba foglalandó, ezeket pedig elérhetővé kell tenni felfedező mechanizmusok számára. A bonyolultság elrejtése és az újrafelhasználás, illetve a lazán kapcsolódó szolgáltatások arra ösztönözték a kutatókat, hogy elgondolkodjanak a két szervező erő hasonlóságáról. Egyes szerint a kettőnek különböző elemei vannak, míg mások szerint a Web 2.0 a szolgáltatásorientált architektúra globális megvalósítása.[40]
A Web 2.0 és a szolgáltatásorientált architektúra eltérő felhasználói igényekre adnak választ, emiatt különböznek a tervek és a technológiák. Azonban 2008-ra használati esetekkel kimutatták a két elv és technológiájuk kombinációjának lehetőségeit.[40]
Mikroszolgáltatások
[szerkesztés]A mikroszolgáltatások a szolgáltatásorientált architektúra modern értelmezése konkurrens környezetben.[41] A szolgáltatások folyamatok, amelyek hálózaton keresztül kommunikálnak, hogy elérjék céljukat. A kommunikációt technológiafüggetlen protokollok alapján végzik,[42] így az egymást használó szolgáltatások készülhetnek különböző nyelvek és keretrendszerek felhasználásával. Ez a megvalósítási modell a DevOps 2014-es bevezetését követően vált népszerűvé. Ez a modell kifejezetten előtérbe tolja a folyamatos fejlesztést és más agilis technikákat.[43]
A mikroszolgáltatásokra nincs egységesen elfogadott definíció. Az irodalomban a következő elvek és jellemzők szerepelnek:
- finomszemcsézett interfészek (függetlenül telepíthetők)
- üzletvezérelt fejlesztés (például tartományvezérelt tervezés)
- IDEAL köd alkalmazási architektúrák
- többnyelvű programozás és perzisztencia
- könnyűsúlyú konténer deployolás
- decentralizált folyamatos kézbesítés
- DevOps holisztikus szolgáltatásfigyeléssel
Jegyzetek
[szerkesztés]- ↑ Chapter 1: Service Oriented Architecture (SOA). msdn.microsoft.com . [2017. július 7-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. november 13.)
- ↑ a b Archivált másolat. [2017. november 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. november 13.)
- ↑ What Is SOA?. www.opengroup.org . [2016. augusztus 19-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. november 13.)
- ↑ Velte, Anthony T.. Cloud Computing: A Practical Approach. McGraw Hill (2010). ISBN 978-0-07-162694-1
- ↑ Migrating to a service-oriented architecture, Part 1, 2008. december 9. [2008. december 9-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. szeptember 21.)
- ↑ a b Michael Bell. Introduction to Service-Oriented Modeling, Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons, 3. o. (2008). ISBN 978-0-470-14111-3
- ↑ Michael Bell. SOA Modeling Patterns for Service-Oriented Discovery and Analysis. Wiley & Sons, 390. o. (2010). ISBN 978-0-470-48197-4
- ↑ SOA Manifesto. www.soa-manifesto.org . [2017. július 25-i dátummal az eredetiből archiválva]. (Hozzáférés: 2016. szeptember 21.)
- ↑ Thomas Erl (June 2005). About the Principles. Serviceorientation.org
- ↑ Application Platform Strategies Blog: SOA is Dead; Long Live Services. Apsblog.burtongroup.com, 2009. január 5. [2009. január 15-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. augusztus 13.)
- ↑ Enterprise SOA. Prentice Hall, 2005
- ↑ Yvonne Balzer Improve your SOA project plans, IBM, July 16, 2004
- ↑ Microsoft Windows Communication Foundation team: Principles of Service Oriented Design. msdn.microsoft.com, 2012. [2016. augusztus 8-i dátummal az eredetiből archiválva]. (Hozzáférés: 2012. szeptember 3.)
- ↑ Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles
- ↑ M. Hadi Valipour. A brief survey of software architecture concepts and service oriented architecture, 2009 2nd IEEE International Conference on Computer Science and Information Technology, 34–38. o.. DOI: 10.1109/ICCSIT.2009.5235004 (2009). ISBN 978-1-4244-4519-6
- ↑ Tony Shan. Building a service-oriented e Banking platform, IEEE International Conference on Services Computing, 2004. (SCC 2004). Proceedings. 2004, 237–244. o.. DOI: 10.1109/SCC.2004.1358011 (2004). ISBN 0-7695-2225-42004
- ↑ Exploring Cloud Service Brokering from an Interface Perspective. IEEE
- ↑ A Survey on Service Contract. IEEE
- ↑ (2016) „A Decade of Enterprise Integration Patterns”. IEEE Software 33 (1), 13–19. o. DOI:10.1109/MS.2016.11.
- ↑ Rotem-Gal-Oz, Arnon. SOA Patterns. Manning Publications (2012). ISBN 978-1933988269
- ↑ K. Julisch et al., Compliance by Design – Bridging the Chasm between Auditors and IT Architects Archiválva 2017. szeptember 21-i dátummal a Wayback Machine-ben. Computers & Security, Elsevier. Volume 30, Issue 6-7, Sep.-Oct. 2011.
- ↑ SOAP Version 1.2 の公開について (W3C 勧告) (japán nyelven). W3.org. (Hozzáférés: 2012. augusztus 13.)
- ↑ Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-Oriented Architecture in Production in the Finance Industry, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
- ↑ www.ibm.com. (Hozzáférés: 2016. szeptember 10.)
- ↑ Okishima, Haruhiru: . "Case Study of System Architecture that use COBOL assets", 2006
- ↑ Christopher Koch A New Blueprint For The Enterprise Archiválva 2009. január 16-i dátummal a Wayback Machine-ben, CIO Magazine, March 1, 2005
- ↑ Elizabeth Millard (January 2005). "Building a Better Process". Computer User. Page 20.
- ↑ Brayan Zimmerli (November 11, 2009) Business Benefits of SOA Archiválva 2010. november 5-i dátummal a Wayback Machine-ben, University of Applied Science of Northwestern Switzerland, School of Business
- ↑ JSR-000089 OSS Service Activation API Specification 1.0 Final Release. sun.com
- ↑ Joe McKendrick: Bray: SOA too complex; 'just vendor BS'. ZDNet
- ↑ Jimmy Zhang (February 20, 2008) "Index XML Documents with VTD-XML" Archiválva 2008. július 4-i dátummal a Wayback Machine-ben. XML Journal.
- ↑ Jimmy Zhang (August 5, 2008) "i-Technology Viewpoint: The Performance Woe of Binary XML" Archiválva 2020. január 9-i dátummal a Wayback Machine-ben. Microservices Journal.
- ↑ Jimmy Zhang (January 9, 2008) "Manipulate XML Content the Ximple Way" Archiválva 2017. július 30-i dátummal a Wayback Machine-ben. devx.com.
- ↑ The Reason SOA Isn’t Delivering Sustainable Software. jpmorgenthal.com, 2009. június 19. [2014. március 28-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. június 27.)
- ↑ SOA services still too constrained by applications they represent. zdnet.com, 2009. június 27. (Hozzáférés: 2009. június 27.)
- ↑ Governance Layer. www.opengroup.org . [2016. június 4-i dátummal az eredetiből archiválva]. (Hozzáférés: 2017. december 8.)
- ↑ How to Efficiently Test Service Oriented Architecture | WSO2 Inc. wso2.com . (Hozzáférés: 2016. szeptember 22.)
- ↑ http://drops.dagstuhl.de/opus/volltexte/2009/2046/pdf/09021_abstracts_collection.2046.pdf
- ↑ What Is Web 2.0. Tim O'Reilly, 2005. szeptember 30. (Hozzáférés: 2008. június 10.)
- ↑ a b (2007) „Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services”, Kiadó: IT Professional 9 (2007), Nr. 3, pp. 36–41, IEEE Computer Society. [2013. december 3-i dátummal az eredetiből archiválva]. (Hozzáférés: 2008. február 23.)
- ↑ Microservices: yesterday, today, and tomorrow. (Hozzáférés: 2016. július 6.)
- ↑ James Lewis and Martin Fowler: Microservices
- ↑ Balalaie, A. (2016. május 1.). „Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture”. IEEE Software 33 (3), 42–52. o. DOI:10.1109/MS.2016.64. ISSN 0740-7459.
További információk
[szerkesztés][1] SOA gyorstalpaló
[2][halott link] Szolgáltatásorientált technológiák és ezek hatása a jövő üzleti alkalmazásaira
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Service-oriented architecture című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
