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. 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: 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.
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. 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, és nem az alkalmazások technológiai célú szétbontásán.
A szolgáltatásorientált architektúra célja
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. Szempontok A lazán kapcsolódó egységeket, amelyek különböző funkciókat valósítanak meg, szolgáltatásoknak nevezzük. Ezek egy hálózatba vannak kapcsolva, és egy protokoll által meghatározott módon kommunikálnak.
A minta manifesztuma 2009 októberében jelent meg. Ez hat szempontot jelölt meg, amiket a minta alkalmazásához figyelembe kell venni: 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ásokThomas Erl (June 2005). About the Principles. Serviceorientation.org é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ő.
Elvek 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:Yvonne Balzer Improve your SOA project plans, IBM, July 16, 2004Principles by Thomas Erl of SOA Systems Inc. eight specific service-orientation principles 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.2004 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 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. 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, 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.K. Julisch et al., Compliance by Design – Bridging the Chasm between Auditors and IT Architects . Computers & Security, Elsevier. Volume 30, Issue 6-7, Sep.-Oct. 2011.
A legfontosabb szabványok bélyegkép|200px|jobbra|A legfontosabb szabványok és kapcsolódásuk
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é. 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 A szolgáltatás beazonosítása
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
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 Vállalati szolgáltatás sín (ESB)
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
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.