mi a SOA? 7 SOA Steps

ez a blog leírja azokat a SOA lépéseket, amelyeket egy szervezetnek meg kell tennie ahhoz, hogy valóban sikeres legyen a vállalati szolgáltatásorientált architektúra által kínált költség-és agilitási előnyök megvalósításában. Megvitatja, hogy mit jelent a SOA és a SOA elfogadásának különböző szakaszai, leírva a rendelkezésre álló technológiákat, folyamatokat és legjobb gyakorlatokat, amelyek segítenek a vállalatoknak a szolgáltatásorientált architektúra kezdeményezéseikben.

mi az a SOA?

a szolgáltatásorientált architektúra (SOA) egy olyan típusú architektúra, amelyet a szoftvertervezésben használnak, amely támogatja a szolgáltatásorientációt, amelynek során a szolgáltatásokat más komponenseknek a kommunikációs protokoll hálózaton keresztül.

mit jelent a SOA?

a SOA meghatározása a Wikipedia szerint:

a szolgáltatás-orientált architektúra (SOA) egy olyan szoftvertervezési stílus, ahol a szolgáltatásokat a többi komponensnek alkalmazáskomponensek nyújtják, hálózaton keresztüli kommunikációs protokollon keresztül. A szolgáltatásorientált architektúra alapelvei függetlenek a gyártóktól, termékektől és technológiáktól. A szolgáltatás a funkcionalitás diszkrét egysége, amely távolról is elérhető, függetlenül működik és frissíthető, például a hitelkártya-kimutatás online lekérése.

egy szolgáltatásnak négy tulajdonsága van a SOA számos meghatározásának egyike szerint:

1. logikusan egy meghatározott kimenetelű üzleti tevékenységet képvisel.
2. önálló.
3. ez egy fekete doboz a fogyasztók számára.
4. állhat más mögöttes szolgáltatásokból.

különböző szolgáltatásokat lehet használni együtt, hogy a funkcionalitás egy nagy szoftver alkalmazás, elv SOA részvények moduláris programozás. A szolgáltatásorientált architektúra integrálja az elosztott, külön karbantartott és telepített szoftverkomponenseket. Ezt olyan technológiák és szabványok teszik lehetővé, amelyek megkönnyítik az összetevők kommunikációját és együttműködését a hálózaton, különösen az IP-hálózaton keresztül.

ez tömör választ ad arra, hogy mit jelent a SOA, de nem írja le azokat az okokat, amelyek miatt egy szervezet a szolgáltatásorientált architektúra felé szeretne elmozdulni, vagy a SOA előnyeit.

A Wikipédiából is, hogy mit jelent a SOA:

egyes vállalati építészek úgy vélik, hogy a SOA segíthet a vállalkozásoknak gyorsabban és költséghatékonyabban reagálni a változó piaci feltételekre.Ez az építészeti stílus elősegíti az újrafelhasználást makró (szolgáltatás) szinten, nem pedig mikro (osztályok) szinten. Egyszerűsítheti a meglévő IT (örökölt) eszközök összekapcsolását és használatát is.

bizonyos szempontból a SOA inkább építészeti evolúciónak, mint forradalomnak tekinthető. A korábbi szoftverarchitektúrák számos bevált gyakorlatát rögzíti. A kommunikációs rendszerekben például kevés olyan megoldást fejlesztettek ki, amelyek valóban statikus kötéseket használnak a hálózat más berendezéseivel való beszélgetéshez. A SOA-megközelítés elfogadásával az ilyen rendszerek képesek arra, hogy hangsúlyozzák a jól definiált, nagyon interoperábilis interfészek fontosságát.

ezeket a fogalmakat fúrva láthatjuk, hogy van egy sor alapvető képesség, amelyek szükségesek a SOA potenciális előnyeinek eléréséhez. A Wikipedia számos ilyen irányadó alapelvet tárgyal, amelyek között vannak:

• újrafelhasználás – a durva szemcsés üzleti funkciók szolgáltatásként történő beágyazásának és feltárásának képessége
• Laza kapcsolás-annak biztosítása, hogy a szolgáltatás fogyasztói kellően elvonatkoztassanak a szolgáltatás fizikai megvalósításától
• azonosítás és kategorizálás (felfedezhetőség) – annak biztosítása, hogy a potenciális fogyasztók megtalálják a szükséges szolgáltatásokat

nem számít, melyik SOA – meghatározást használja, ezek az alapvető jogok a az igazgatók a tevékenységek természetes rendjéhez vezetnek, amelyet a szervezetnek teljesítenie kell, hogy fokozatosan megvalósítsa a szolgáltatásorientált előnyöket építészet.

nézze meg, hogy az Akana miért erős előadó a Forrester Wave xhamsterben: API Management Solutions, Q3 2020 jelentés.

Jelentés letöltése

mi a hét SOA lépés?

hét SOA lépés van:

1. szolgáltatások létrehozása/leleplezése
2. szolgáltatások regisztrálása
3. biztonságos szolgáltatások
4. szolgáltatások kezelése (monitorozása)
5. szolgáltatások közvetítése és virtualizálása
6. szabályozza a SOA-t
7. SOA integráció ESB-vel

a SOA 2-6.lépései leírják a vállalatok közötti aggályokat, amelyeket egy központosított SOA infrastrukturális platformon kell kezelni. Az 1.és 7. lépés speciális igényeket elégít ki, és gyakran egy meglévő vállalati alkalmazáscsomag részeként történik. Ezeket a lépéseket követve a szervezet a helyes úton halad a SOA előnyeinek megvalósítása felé. Olvassa tovább, hogy mélyebben belemerüljön az egyes SOA lépésekbe.

szolgáltatások létrehozása/feltárása

a szervezet SOA felé történő elmozdulásának első lépése nyilvánvaló. Szolgáltatások nélkül nem létezhet SOA alkalmazás, ezért az első lépés olyan szolgáltatások feltárása vagy létrehozása, amelyeket a webszolgáltatások által engedélyezett alkalmazások könnyen felhasználhatnak.

számos érdekes döntés van a vállalatok előtt, amikor megkezdik ezt a folyamatot, nem utolsósorban az a döntés, hogy a meglévő alkalmazásokat szolgáltatásorientált paradigma segítségével újjáépítik-e, vagy a meglévő alkalmazáslogikát szolgáltatáskészletként tárják fel. Ez természetesen nem bináris döntés, és a legtöbb szervezet új szolgáltatásokat épít a semmiből, gyakran J2EE és/vagy.net használatával, és a meglévő mainframe és más üzleti alkalmazások szolgáltatásait is feltárja.

számos különböző megoldás létezik azon vállalatok számára, amelyek a meglévő alkalmazásokat szolgáltatásként kívánják feltárni, beleértve az Akana piacvezető SOLA-ját, amely lehetővé teszi a mainframe CICS alkalmazások számára, hogy megbízható, biztonságos, nagy teljesítményű szolgáltatásokat nyújtsanak és használjanak.

minden olyan vállalatnak, amelynek jelentős (a Gartner szerint több mint 1000 MIPS) befektetése van a mainframe-be, meg kell vizsgálnia a platform előnyeinek jobb kihasználásának módjait, és webszolgáltatásokat kell használnia a mainframe alkalmazások modern rendszerekkel való egyszerű integrálásához. Az Akana sola gyártása olyan ügyfeleknél bizonyított, mint a Merrill Lynch, ahol naponta több mint 2 millió tranzakciót dolgoz fel több mint 600 webszolgáltatásból. A SOLA az egyetlen olyan termék, amely a mainframe programozók számára könnyen használható, webalapú felületet kínál a CICS alkalmazások szolgáltatásainak feltárására és fogyasztására. Ez magában foglalja a beépített támogatás a fejlett webszolgáltatások képességek, mint a WS-Security, XML-titkosítás, és az XML-aláírás.

a hagyományos vállalati alkalmazásintegrációs (EAI) vállalatok többsége olyan adaptereket is szállít, amelyek a hagyományos szabadalmaztatott protokollok helyett a webszolgáltatásokat tárják fel. Valójában sok ilyen EAI platformok újra feltörekvő vállalati szolgáltatás busz termékek. Az ESB több különböző kérdéssel foglalkozik, amelyek közül az egyik a commodity data services típusú funkcionalitás, amelyet a webszolgáltatások interfészeinek a hagyományos adapterek általi feltárására használnak.

mi az a webszolgáltatás?

A Wikipédiából:

a W3C webszolgáltatásokkal kapcsolatban a W3C a következőképpen definiálta a webszolgáltatást: “a webszolgáltatás olyan szoftverrendszer, amelyet arra terveztek, hogy támogassa az interoperábilis gépek közötti interakciót egy hálózaton keresztül. Van egy interfésze, amelyet géppel feldolgozható formátumban (konkrétan WSDL) írnak le. Más rendszerek a SOAP-üzenetek leírásában előírt módon lépnek kapcsolatba a webszolgáltatással, általában HTTP-vel, XML-sorosítással, más webhez kapcsolódó szabványokkal együtt.”

ez a meghatározás technikai szempontból érdekes, de nem igazán jut el a SOA-ból és a webes szolgáltatásokból levezethető érték középpontjába. A webszolgáltatások alapvető szempontja, hogy az üzleti logikát szabványalapú felületen keresztül kell feltárniuk. A szolgáltatás feltárásának vagy létrehozásának egyik fontos szempontja a részletesség. Számos különböző gondolkodási iskola létezik arról, hogy mi minősül szolgáltatásnak (lásd fent), de a legtöbb vállalati építész egyetért abban, hogy ahhoz, hogy hasznos legyen egy SOA-ban, a szolgáltatásnak kellően durva szemcsésnek kell lennie ahhoz, hogy több különböző alkalmazás számára hasznos legyen.

ez természetesen a SOA szolgáltatásainak egyik alapvető tételével gélek – ahhoz, hogy egy szolgáltatás újra felhasználható legyen; általában hasznosnak és használhatónak kell lennie. Egy általánosan hasznos szolgáltatásra példa lehet egy” getCustomerInfo ” szolgáltatás, amely egy ügyfélazonosítóból ad vissza adatokat az ügyfélről. Egy finomszemcsés szolgáltatás, amely általában nem hasznos, lehet valami specifikus egy adott alkalmazáshoz, például a “setApplicationState”.

fontos figyelembe venni a szolgáltatások részletességét mind az új szolgáltatások építésekor, mind a meglévő üzleti logika szolgáltatásként való feltárásakor. Például nem lenne könnyű, hogy egy CICS tranzakció, és ki több különböző szolgáltatásokat beállítani, és kap a különböző paramétereket, míg a valóság az, hogy egy durvább szemcsés szolgáltatás, amely kiteszi az egész tranzakció, mint egy szolgáltatás lehet sokkal általánosabban hasznos, és ezért értékes.

Related Reading: Ismerje meg, hogy az Akana Sola Mainframe API hogyan nyújt gyors és egyszerű folyamatot az ügyfelek számára a mainframe alkalmazások biztonságos webszolgáltatásként való megjelenítéséhez, és lehetővé teszi a mainframe alkalmazások számára a webes szolgáltatások használatát.

regisztráció

Ok, tehát egy vagy több szolgáltatás áll rendelkezésre a vállalkozásában. És most?

ahhoz, hogy egy szolgáltatás használható legyen, nem is beszélve az újrafelhasználásról, az alkalmazásépítőknek és a fejlesztőknek tudniuk kell, hogy a szolgáltatás létezik. Itt jön be egy nyilvántartás. A legegyszerűbb szinten a nyilvántartás nem más, mint egy könyvtári index, amely segít a szolgáltatások potenciális felhasználóinak megtalálni azokat a szolgáltatásokat, amelyek érdekelhetik őket. A nyilvántartásnak mind Keresési, mind böngészési felületet kell kínálnia, és logikusan kell megszerveznie a szolgáltatások gyors és pontos megtalálását.

a mai SOA-ban az alapvető rendszerleíró adatbázis-szolgáltatások elfogadott szabványa az UDDI (Universal Discover, Description and Integration). Az UDDI specifikáció adatmodellt és interfészkészletet (az összes webszolgáltatást) biztosít a szolgáltatások közzétételéhez és felfedezéséhez, valamint további interfészkészletet magának a beállításjegyzék-kiszolgálónak a kezeléséhez.

sok registry gyártók vették az eredeti koncepció a registry egy kicsit tovább, és használja registry technológiák, mint az alap egy teljesebb adattár. A rendszerleíró adatbázis-gyártók “házirend-alapú szűrőket is hozzáadnak közzétételi eszközeikhez, és “tervezési idő irányítási megoldásokat”kínálnak.

Akana a nyilvántartást a SOA alapvető építőelemének tekinti. Minden termékünk kihasználja az UDDI-t, mint egyetlen központi áruházat, amely hiteles információkat nyújt a SOA szolgáltatásairól. A termékek bármilyen UDDI-kompatibilis rendszerleíró adatbázissal működhetnek, az Akana pedig saját UDDIv3 rendszerleíró szervert tartalmaz a Service Manager termékkel olyan vállalatok számára, amelyek még nem rendelkeznek nyilvántartással. Ebben a tekintetben a registry tölti be a SOA szerepét, amelyet az LDAP töltött be az Identity and Access Management solutions számára.

az Akana termékei a futásidejű kormányzásra összpontosítanak, és a rendszerleíró adatbázist központi helyként használják a futásidejű Irányelvek megvalósításához és érvényesítéséhez. Természetesen a beágyazott rendszerleíró adatbázis teljesen működőképes UDDIv3 szerver, így ideális tervezési idejű szolgáltatási adattárat is létrehoz.

a Beyond registry a házirend-és metaadat-szolgáltatások teljes koncepciója, amelyek átfogó tárolókat biztosítanak a SOA szolgáltatásainak összes tervezési és futási idejű melléktermékéhez. Ezt a koncepciót részletesebben tárgyalja az Akana a SOA Infrastructure Reference Model című fehér könyve.

biztonságos

a SOA és a webszolgáltatások világa nem minden bor és rózsa. Feltételezve, hogy befejezte az első lépést és a lépést, tegyen egy lépést hátra, és fontolja meg, mit tett. Feltételezve, hogy megy a maximális üzleti érték, akkor valószínű, hogy volna kritikus alkalmazások, bontani őket durva szemcsés darab funkcionalitás, kitéve ezt a funkciót, mint a szolgáltatások, majd közzétette ezeket a szolgáltatásokat egy általánosan hozzáférhető registry.

ez mind jó dolognak tűnhet, és a legtöbb esetben nagyszerű dolog, de lehet, hogy véletlenül létrehozott néhány tátongó biztonsági rést a szervezetében, és érzékeny információkat vagy nagy értékű tranzakciókat tárt fel bárki számára, aki kezdeti webszolgáltatási ismeretekkel rendelkezik. A szolgáltatások biztonságának biztosítása azt jelenti, hogy a szolgáltatóknál biztonsági végrehajtási réteget, a szolgáltatás fogyasztóinál pedig biztonsági végrehajtási réteget építenek ki.

a webszolgáltatások biztonsági kockázatainak megértésének jó módja a hagyományos zöld képernyős mainframe alkalmazásokra való visszagondolás. Az alkalmazások által megkövetelt egyetlen biztonság a bejelentkezési biztonság volt, ha hozzáférhet az alkalmazáshoz, benne voltál. Ezek az alkalmazások ugyanazokat az alapdarabokat tartalmazták, mint egy modern alkalmazás (interfész, üzleti logika, adatszolgáltatások), de csak az interfész volt elérhető az alkalmazáson kívül. A webszolgáltatások világában valószínű, hogy az alapvető adatszolgáltatások egy része szolgáltatásként lesz kitéve, az üzleti logika egy részét mindenképpen ki kell fedni, és az alkalmazást nem ezen hozzáférési pontok egyikének szem előtt tartásával írták. Ez azt jelenti, hogy kritikus fontosságú az Ön által közzétett szolgáltatások külön-külön történő biztosítása, nem támaszkodhat az alkalmazás belső részeire a saját biztonságának biztosítása érdekében.

tehát mit jelent egy webszolgáltatás biztonsága? Ugyanaz az 5 biztonsági elv, amely más alkalmazásokra vonatkozik, a Webszolgáltatásokra is vonatkozik:

• hitelesítés-győződjön meg arról, hogy ismeri a szolgáltatást igénylő személyazonosságát (valamint arról is, hogy a kérelmező ismeri annak a szolgáltatásnak a személyazonosságát, amelyhez kapcsolatba lép). Számos különböző webszolgáltatási szabvány létezik a kérések hitelesítésére, kezdve az egyszerű megközelítésektől, például a http alaphitelesítéstől az összetettebb mechanizmusokig, mint például a SAML vagy az X. 509 aláírás. Egy jó webszolgáltatási biztonsági eszköznek támogatnia kell ezeket a különféle lehetőségeket.
• Engedélyezés – ellenőrizze, hogy a kérelmező jogosult-e hozzáférni a kért Szolgáltatáshoz vagy művelethez. Az engedélyezés összetett kérdés, és számos különféle szakpolitikai döntési termék áll rendelkezésre. A legtöbb nagyvállalat rendelkezik meglévő engedélyezési megoldással (CA SiteMinder, IBM TAM stb.), és egy jó webszolgáltatási biztonsági megoldásnak képesnek kell lennie arra, hogy integrálja ezeket, valamint saját engedélyezési képességeket biztosítson.
• Adatvédelem – győződjön meg arról, hogy a kérés és a válaszüzenetek nem olvashatók illetéktelen 3.felek által. Itt jönnek létre az XML-titkosításhoz hasonló szabványok, de az XML-titkosítás sikeres használatához a webszolgáltatások biztonsági megoldásának hatékony kulcs-és tanúsítványkezelési és terjesztési képességeket kell biztosítania, és ideális esetben néhány ügyféloldali eszközt a fogyasztói Fejlesztők támogatására.
• visszautasítás megtagadása-győződjön meg arról, hogy a kérelmező nem tagadhatja meg a kérés elküldését, és hogy a szolgáltatás nem tagadhatja meg a válasz elküldését. Ez az XML-aláírás szerepe, ugyanazzal a kulcskezeléssel és terjesztéssel, mint az adatvédelem.
• auditálás – győződjön meg arról, hogy a rendszer szükség szerint pontos és időszerű nyilvántartást vezet a kérésekről és a válaszokról.

a webszolgáltatások biztonsága körül felmerülő egyik érdekes kérdés és vitapont az, hogy hol kell alkalmazni ezt a biztonságot. Egyes gyártók azzal érvelnek, hogy a biztonságnak központi funkciónak kell lennie, amelyet központilag telepített proxyk klaszterén keresztül érvényesítenek, míg mások azzal érvelnek, hogy kizárólag a Szolgáltató vagy a tároló domainjének kell lennie. A valóság természetesen valahol e két álláspont között van. Minden bizonnyal fontos szerepe van a proxynak (vagy proxy klaszternek) abban, hogy hitelesítési és fenyegetésészlelési szolgáltatásokat nyújtson a hálózat szélén a külső fenyegetések elleni védelem érdekében. Ugyanilyen fontos szerepet játszik a Szolgáltató vagy a konténer alapú biztonság is, hogy biztosítsa a szolgáltatás biztonságát az utolsó mérföldig.

sok vállalat hajlamos figyelmen kívül hagyni azt a kutatást, amely azt mutatja, hogy a biztonsági fenyegetések többsége a vállalaton belüli, nem pedig külső, ezért a biztonságot egy tűzfal típusú megoldásra ruházza át. Az Akana nagy teljesítményű proxyt kínál, amely központosított vagy hálózati élbiztonsági funkciókat hajt végre, valamint a konténerügynökök széles skáláját kínálja a telepített szolgáltatások utolsó mérföldes biztonságának biztosítása érdekében.

a webszolgáltatások biztosítása szükséges:

• teljesen működőképes konténerügynökök telepítése az utolsó mérföld biztonságának biztosítása és a kriptográfiai műveletek terhelésének elosztása érdekében
• nagy teljesítményű hálózati közvetítők telepítése az útválasztáshoz és a hálózati élbiztonság érvényesítéséhez
• átfogó kulcs-és tanúsítványkezelés és-terjesztés biztosítása annak biztosítása érdekében, hogy a Szolgáltató és a fogyasztói fejlesztők sikeresen végrehajthassák a szükséges biztonsági házirendeket
• fogyasztói fejlesztői eszközkészletek biztosítása a fogyasztói fejlesztők számára a vállalati biztonság felfedezésének és megvalósításának bonyolultságából Irányelvek

kapcsolódó olvasmány: Tudjon meg többet az API biztonsági bevált gyakorlatairól.

kezelése

három lépés a SOA 7 lépéses megközelítésében, és elkezdünk némi előrelépést elérni a vállalati SOA valós értékének elérése felé. Van néhány szolgáltatásunk, ezeket a rendszerleíró adatbázisban közzétesszük, és a potenciális felhasználók felfedezhetik, és gondoskodtunk arról, hogy biztonságosak legyenek. Mi másra lenne még szükségünk?

a kérdés megválaszolásához először meg kell vizsgálnunk egy lehetséges katasztrófahelyzetet. Mi történik, ha a szolgáltatásaim a saját sikereik áldozataivá válnak? Azaz. a szolgáltatás annyira népszerűvé vált, hogy több (tíz, száz vagy ezer) különböző alkalmazás fogyasztja, és a terhelés alatt elkezd csat. Hirtelen több tíz, száz vagy ezer alkalmazásunk van, amelyek nem működnek vagy rosszul teljesítenek, és nem tudjuk, miért vagy hogyan állítsuk meg.

figyelemmel kell kísérnünk szolgáltatásainkat, hogy tudjuk, hogy a normál működési paraméterek között teljesítenek-e, és hogy a kapacitástervezési modellek végrehajtásával felismerjük a lehetséges problémákat, mielőtt azok felmerülnének.

az általunk telepített felügyeleti megoldásnak képesnek kell lennie a szolgáltatások alapvető elérhetőségének, teljesítményének (válaszidő), átviteli sebességének megfigyelésére, sőt a tartalom és a felhasználó alapú monitorozásra is. Képesnek kell lennie arra, hogy figyelemmel kísérje és figyelmeztesse a konkrét SLA-küszöbértékeket, és képesnek kell lennie arra, hogy különböző SLA-kat alkalmazzon ugyanazon szolgáltatás vagy művelet különböző felhasználóira.

sok gyártó ezt a termékkategóriát Webszolgáltatáskezelési megoldásként határozza meg, bár sok elemző egyetért abban, hogy a menedzsment sokkal szélesebb, mint egy egyszerű felügyeleti megoldás, és a következő lépésben leírt funkciók nagy részét tartalmaznia kell.

ideális esetben természetesen nem kellene külön biztonsági és felügyeleti megoldásokat telepítenünk, mert minden alkalommal, amikor az üzeneteket közvetítőn vagy közvetítőn keresztül lehallgatjuk, újabb teljesítmény-szűk keresztmetszetet okozunk. Ez az oka annak, hogy az Akana Service Manager és a Network Director egy átfogó SOA biztonsági, felügyeleti és felügyeleti platformot biztosít egyetlen, nagy teljesítményű, könnyen telepíthető megoldásban.

egyes webszolgáltatáskezelő (monitoring) szolgáltatók üzleti Tevékenységfigyelő (Bam) platformként pozícionálják megoldásaikat, bár a BAM egy komplex megoldás, amely számos back – és front-office rendszerrel és adatbázissal való integrációt igényel. A webes szolgáltatások tartalmi interakcióinak figyelése nem tekinthető a vállalati BAM-megoldás alternatívájának.

Kapcsolódó Olvasmányok: Tudjon meg többet az Akana End-to-End API menedzsment megoldásáról.

5. Mediate and Virtualize

ezen a ponton úgy tűnik, hogy a SOA készen áll a főműsoridőre. És így is van, legalábbis egy ideig…

a következő kihívások akkor jelentkeznek, amikor a SOA érlelődik. Be kell vezetnie a szolgáltatások új verzióit, vagy növelnie kell a szolgáltatás kapacitását annak több példányának futtatásával, alkalmazásokat kell biztosítania a szolgáltatások meghatározott példányainak használatához, és olyan szolgáltatásokat kell kínálnia, amelyek a különböző interfésztípusok szélesebb körét tárják fel.

itt jön be a szolgáltatás virtualizációja. A virtualizáció összetettnek tűnik, de a valóság meglehetősen egyszerű. A virtuális szolgáltatás egy teljesen új szolgáltatás, amelyet saját WSDL határoz meg, saját hálózati címmel és szállítási paraméterekkel. Nem valósít meg semmilyen üzleti logikát; egyszerűen proxyként működik egy vagy több fizikai szolgáltatáshoz, útválasztáshoz, terheléselosztáshoz, átalakításhoz és közvetítéshez a különböző kérésüzenet-típusok és szabványok között.

bár a felszínen egyszerű, a virtualizáció fogalma rendkívül erős. Lehetővé teszi a szolgáltatás fogyasztóinak teljes elvonását a fizikai szolgáltatás közvetlen ismereteitől. Például egy virtuális szolgáltatáson keresztül egy. NET kliens, amely egy megbízható üzenetküldő protokoll Microsoft megvalósítását használja a SOAP segítségével http-n keresztül, egy egyszerű, régi XML szolgáltatást fogyaszthat, amelyet az IBM WebSphere MQ sorozaton keresztül tárnak fel egy mainframe alkalmazásból. A. net kliens azt hinné, hogy egy http szolgáltatással folytatott kommunikáció támogatta a megbízható üzenetküldési protokollt, míg a mainframe alkalmazás azt hitte, hogy egy másik natív MQ sorozatú alkalmazás lekérdezi.

a virtuális szolgáltatások széles körű funkcionalitást kínálnak:

• az XML-transzformációs technológiák lehetővé teszik a fogyasztók számára, hogy továbbra is használják a szolgáltatás régi verzióját, amely már nem létezik, a kérés-és válaszüzenetek átalakításával a régi és az új verzió között.
• különböző szolgáltatások közül választhatnak ki konkrét műveleteket, és egyetlen funkcionális WSDL-be egyesíthetik őket egy adott fogyasztóalkalmazás-osztály számára.
• különböző politikai követelményeket tudnak biztosítani a különböző felhasználói osztályok számára (pl. belső felhasználók egy házirendkészlettel, valamint a szolgáltatás egy másik megvalósításával, amely más házirendkészletet kényszerít ki a külső fogyasztók számára).
• szállítási áthidalást tudnak biztosítani a szolgáltatások és a fogyasztók számára inkompatibilis átviteleken (pl. http és JMS). * Közvetíthetnek a különböző szabványok végrehajtása vagy akár a szabványok változatai között.
• közvetíthetnek a különböző üzenetküldési stílusok között – RSS, SOAP, REST, POX (egyszerű régi XML).
• hatékony tartalom – vagy kontextusalapú útválasztást biztosítanak a fejlett terheléselosztás és a magas rendelkezésre állási képességek biztosítása érdekében.

a virtuális szolgáltatások lényege, hogy minden útválasztáshoz vagy más fejlett webszolgáltatáshoz szükségesek, és gyorsan minden vállalati SOA nélkülözhetetlen részévé válnak.

Govern

az 5-ből 7 lépés befejeződött, az enterprise SOA nagyjából készen áll. Most már biztonságos, felügyelt szolgáltatásokkal rendelkezik, amelyek széles közönség számára elérhetők megbízható, terheléskiegyensúlyozott módon, és könnyen felfedezhetők.

a következő lépés az, hogy az első 5 lépésben nyújtott összes képességet összekapcsoljuk egy irányítási kerettel. A kormányzás túlhasznált és sokszor visszaélt munka, ezért nézzük meg röviden a kormányzás meghatározását.

a kormányzás kifejezés azokra a folyamatokra és rendszerekre vonatkozik, amelyek által egy szervezet vagy társadalom működik. Gyakran létrejön egy kormány, amely kezeli ezeket a folyamatokat és rendszereket.

ebből a meghatározásból az a lényeg, hogy a kormányzás folyamatokról és rendszerekről szól. A SOA kormányzás esetében olyan szervezeti folyamatokról beszélünk, mint egy architektúra-felülvizsgálati testület, és olyan rendszerekről, mint a nyilvántartás, a biztonság és a menedzsment technológiák, amelyeket ebben a blogban tárgyalunk.

a SOA irányítása gyakran két különálló részre oszlik, a tervezés-idő irányításra és a futás-idő irányításra. A tervezés idején a szervezetek ellenőrizni akarják (szabályozzák) a közzétehető szolgáltatások típusait, ki teheti közzé őket, milyen típusú sémákat és üzeneteket fogadhatnak el ezek a szolgáltatások, valamint számos más szabályt a Szolgáltatásokkal kapcsolatban. Futás közben a szervezeteknek biztosítaniuk kell szolgáltatásaik biztonságát, megbízhatóságát és teljesítményét, és biztosítaniuk kell, hogy a szolgáltatások megfeleljenek a meghatározott vállalati irányelveknek. A tervezési idő irányítása érdekes, és segít biztosítani a szervezett, jól megtervezett SOA – t, de jelentéktelenné válik, összehasonlítva a SOA futás közbeni aktív ellenőrzésével.

az Akana Service Manager az iparág vezető futásidejű irányítási platformja, amely átfogó megoldást kínál a biztonság, a felügyelet, a menedzsment, a közvetítés és a nyilvántartás számára. A futásidejű irányítás lényegében egységes keretet biztosít az e dokumentumban leírt SOA-ra vonatkozó különböző lépések alkalmazásának ellenőrzésére és nyomon követésére. Egyetlen átfogó megoldást kínál, amely felügyeletet biztosít a szolgáltatási nyilvántartás, a biztonság, a menedzsment és a közvetítés területén. A jó futásidejű irányítási megoldás a workbench egyik formájaként fog megnyilvánulni, amely eszközöket biztosít a SOA összes aktív résztvevője számára.

• Szolgáltatásfejlesztő: eszközök a metaadatok közzétételéhez, kategorizálásához, meghatározásához, “ügynök” letöltéséhez, virtualizáláshoz, verzióhoz, házirend kiválasztásához, láthatóság/hozzáférési jogok kiválasztásához, részvétel a kapacitástervezésben és a hozzáférés munkafolyamatában
• szolgáltatás fogyasztó: eszközök a szolgáltatás felfedezésének, kiválasztásának és a munkafolyamat elérésének megkönnyítéséhez
• műveleti személyzet: eszközök a szolgáltatás teljesítményének figyelemmel kísérésére, problémák elhárítása, függőségek figyelése, verziószolgáltatások, virtualizáció, proxykezelés
• biztonsági személyzet: eszközök a házirend-kezeléshez, a házirend-jelentéskészítéshez, a megfelelőség ellenőrzéséhez, a biztonsági auditáláshoz
• vállalati építész: Eszközök alkalmazásfigyeléshez, kapcsolatkezeléshez, tervezési házirend érvényesítéséhez és meghatározásához, szolgáltatásverzió-kezeléshez, szolgáltatás-proxy-hozzárendeléshez, szolgáltatás virtualizációhoz
• vállalati informatikai menedzsment: újrafelhasználási metrika menedzsment, szolgáltatás-újrafelhasználási mutatók, SOA statisztikák

SOA integráció az ESB-vel

Visszatekintve a SOA felé vezető utolsó 6 lépés eredményeire, azon tűnődünk, vajon mi lehet még. Mára már van egy sor szolgáltatást, amelyek közzé a registry, biztonságos, felügyelt, megbízható és lazán kapcsolt, minden csomagolva egy szilárd tervezési és futásidejű irányítási megoldás.

egyes vállalkozások számára az utolsó lépés egy vagy több Enterprise Services Bus (ESB) implementáció telepítése a szolgáltatások magasabb szintű összetett vagy hangszerelt szolgáltatásokba történő integrálására. Ezeket az esb-ket gyakran egy szélesebb alkalmazáscsomag részeként szállítják, mint például az Oracle eBusiness applications vagy az SAP. Egyes speciális ESB-k összetett összetett szolgáltatások létrehozására használhatók, és kiterjednek az üzleti folyamatok kezelésére (BPM).

kapcsolódó olvasmány:Tudjon meg többet az Akana integrációs megoldásairól.

az Enterprise Service Bus (ESB) egyre népszerűbb fogalom. Az eredetileg mind az üzenetorientált köztes szoftver, mind az EAI (enterprise application integration) megoldások fejlődéseként fogant ESB nagyon különböző dolgokat jelent a különböző szervezetek számára. Ahogy az elemzők, a gyártók és az ügyfelek elfogadják az ESB ötletét, úgy tűnik, hogy az ESB 3 funkcionális koncepciót foglal magában; az EAI eszközből vett adapterek a régi alkalmazásokkal való kapcsolat biztosításához, az üzenetorientált köztes szoftver platformból származó üzenetküldő szolgáltatások a megbízható kézbesítés biztosítása érdekében, valamint a folyamatszervezés az agilis alkalmazások létrehozásához.

az elemzők konszenzusa az, hogy a legtöbb szervezet több ESB platformot fog kapni több gyártótól, szolgáltatásokat nyújtva a saját kontextusában. Ebben a környezetben rendkívül fontos, hogy az ESBs központi SOA-infrastruktúrát használjon annak érdekében, hogy biztosítsa a biztonsági és üzenetküldési irányelveknek való következetes megfelelést az általuk kínált és fogyasztott szolgáltatások tekintetében.

az Akana Service Manager és Network Director termékei együttesen teljes körű megoldást nyújtanak a vállalat több ESB-példányának irányítására és közvetítésére.

most, hogy többet tudsz arról, hogy mit jelent a SOA és a legfontosabb SOA lépések, nézd meg az Akana-t akcióban!

Vizsgálat Megkezdése