Hogyan építsünk szolgáltatásorientált architektúrát (SOA))

Hogyan építsünk szolgáltatásorientált architektúrát (SOA))

ebben a cikkben összpontosítunk a téma a szolgáltatás-orientált architektúra (SOA). Kezdjük egy mély merülés 1) SOA: a leírás, majd megy, hogy megvitassák 2) épület egy szolgáltatás-orientált architektúra.

szolgáltatásorientált architektúra: a leírás

mi a SOA?

a SOA vagy a szolgáltatásorientált architektúra olyan módszer, amelyen keresztül a különböző típusú szolgáltatások egymástól függetlenül kölcsönhatásba léphetnek. A szolgáltatás a funkcionalitás önálló része, és számos szolgáltatás kombinálható egy szoftveralkalmazás széles körű használatának és funkcionalitásának biztosítására. Amit a SOA csinál, az az, hogy egyszerűbbé teszi a hálózathoz csatlakoztatott PC-k szoftveralkatrészeinek interakcióját és együttműködését. A SOA tervezési mintája olyan, hogy a benne lévő alkalmazások komponensei szolgáltatásokat nyújthatnak más ilyen komponenseknek, többnyire hálózaton keresztül. Minden egyes számítógépes rendszer tetszőleges számú szolgáltatást futtathat, amelyek mindegyike arra épül, hogy emberi segítség nélkül információt cseréljen a hálózat bármely más szolgáltatásával.

az üzleti terminológiában a SOA olyan üzleti összehangolt informatikai szolgáltatások összessége, amelyek együttesen foglalkoznak az üzleti vállalat céljaival és folyamataival. A SOA szerkezeti kialakítása biztosítja, hogy igazodjon az üzleti követelményekhez, valamint a technológiai megoldáshoz.

a SOA főbb elemei

itt vannak a SOA fő elemei:

• SOA illesztőprogramok – a SOA illesztőprogramok vagy a vállalati üzleti vezetők olyan dolgokat tartalmaznak, mint a verseny, a stratégia, a szabályozási erők és a piaci erők. Mindezek együttesen alakítják az üzleti architektúrát és formálják az üzleti szintű teljesítménymenedzsmentet
• SOA-engedélyezők – az öt fő SOA-engedélyező a vállalati üzleti modell, az üzleti teljesítmény optimalizálása, a Portfólió racionalizálása, a vállalati szemantika meghatározása és a fő teljesítménymutatók. Az üzleti modell megléte fontos a szolgáltatások megfelelő összehangolásához az üzleti célokkal. A szemantikai információs modell megadja az adott vállalkozás általános és általános üzleti adatait. A fő teljesítménymutatók vagy KPI-k lehetővé teszik a SOA hatásának értékelését és megkönnyítik az üzleti folyamatok mérését. Másrészt a Portfólió racionalizálása lehetővé teszi az alkalmazások, az adatok és az infrastruktúra konszolidálását és egyszerűsítését.
• SOA implementáció – ami a megvalósítást illeti, az Üzleti szolgáltatások és folyamatok a fő szempontok. Az üzleti folyamatok többnyire az üzleti célokhoz és a műveletek célkitűzéseihez kapcsolódnak, másrészt az üzleti szolgáltatásoknak jól össze kell hangolódniuk, és kritikus fontosságúak a SOA rugalmas és sikeres megvalósításához. A SOA megvalósításával kapcsolatos egyéb szempontok közé tartoznak a vállalati tartalomtárak, a szemantikus üzenetküldés és az integrációs szolgáltatások. Az információ a vállalat adatforrásait képviseli, és ezeket az adatokat olyan dokumentumok formájában továbbítják, amelyek egyfajta szemantikai üzeneteket biztosítanak a szolgáltatások és a folyamatok között.
• SOA támogatás – a meglévő alkalmazások és rendszerek összes funkciója és eleme elérhető és használható a szolgáltatások számára néhány integrációs szolgáltatás támogatásával, amelyek új szolgáltatási interfészeken keresztül leveszik a meglévő funkciók fedelét.

a SOA fő elvei

az alábbiakban felsoroljuk a SOA fő elveit:

• szolgáltatási architektúra – az egyes szolgáltatások fizikai elrendezése vagy kialakítása, amelyek meghaladják a Szolgáltatás által használt összes erőforrást.
• Service composition architecture – a szolgáltatás-orientált tervezési módszerekkel kifejlesztett összes szolgáltatás kompozíciócentrikus, és ez a fő jellemzőjük. Ez az architektúra tehát a különféle szolgáltatások egyedi architektúráinak összetétele.
• Service inventory architecture – ez az architektúra a service inventory blueprint-ből származik, ahol a service inventory olyan szolgáltatásokból áll, amelyek automatizálják a vállalkozások eljárásait.
• szolgáltatás-orientált vállalati architektúra – ez a típus összetételből, szolgáltatásból és készletarchitektúrából áll.

a SOA koncepció fejlődése

• monolitikus tervezés – ez a kialakítás viszonylag strukturálatlan eljárási kódoláshoz kapcsolódott
• objektum – és szerkezetorientált tervezés-Ez a tervezés magában foglalja a funkcionalitáson alapuló programegységeket.
• kliens-szerver tervezés (kétszintű tervezés)-ez az elosztott tervezés fogalma, amely a funkciók két szintre történő összekapcsolásához kapcsolódik.
• elosztott objektumtervezés (multitier design) – ez a kialakítás magában foglalja az objektum interakciókat heterogén környezetben és az elosztott objektumtervezést.
• Component object model architecture – ez egy olyan kialakítás, amelyben az elemek logikai alapú részekké aggregálódnak, erősen típusokkal, valamint jól definiált interfésszel.
• szolgáltatásorientált architektúra – ez egy olyan kialakítás, amely magában foglalja a durva szemcsés szolgáltatások és a szabványos interfészek közötti interakciókat és kommunikációt a rugalmas interoperáció érdekében.

SOA és JAVA

sok fejlesztő úgy gondolja, hogy a SOA, valamint a webszolgáltatások szinonimái egymásnak, de ez nem igaz. Azt is elhihetik, hogy egyszerűen nem lehet SOA-t építeni webszolgáltatások használata nélkül, de a valóságban a SOA tervezési elv, de a webszolgáltatások egyfajta megvalósítási technológia. Ez azt jelenti, hogy a SOA valójában egy bizonyos fajta megvalósítási technológia használata nélkül is felépíthető. De a Java egy másik fajta hagyományos technológia, amely felhasználható szolgáltatásorientált architektúra fejlesztésére vagy építésére.

a SOA fő célja a modulok közötti laza csatolás kifejlesztése, és olyan alkalmazás építhető, ahol a modulok nem kapcsolódnak túl szorosan egymáshoz. Ez a fajta szerkezet JAVA segítségével építhető vagy alakítható ki.

melyek a SOA jellemzői?

• laza kapcsolat – a SOA szolgáltatásai lazán kapcsolódnak egymáshoz, hogy egyetlen kapcsolatot alkossanak. Ez előfeltételezi az egyes szolgálatok közötti kölcsönös függőség csöppségét. A fő ötlet az, hogy csökkentse a kölcsönös függőséget arra a szintre, ahol a kompatibilitás továbbra is fennmarad.
• a szabványosított szolgáltatási felület – a SOA egyik alapvető követelménye az interfészek szabványosításának szükségessége, valamint a részletek. A részleteknek tartalmazniuk kell, hogy mely adatokra van szükség, hogyan lehet egy szolgáltatást használni, és hogyan kell alkalmazni a szabályokat.
• újrafelhasználhatóság – a SOA-ban a szolgáltatások újrafelhasználhatósága a folyamatláncon keresztül más felek által is lehetséges, más típusú célokra is.
• szolgáltatás Megtalálhatósága – egy másik jellemző, hogy a szolgáltatást könnyen meg kell találni annak használatához. Minden fogyasztó számára elérhetővé válnak a szolgáltatási adattárak, és ezek az adattárak a szolgáltatás interfészéből és végrehajtási módjából állnak.
• szolgáltatási autonómia – minden szolgáltatásnak képesnek kell lennie arra, hogy önállóan működjön és működjön. Ez a kifejezés azokra a szolgáltatásokra utal, amelyek önellátóak, és képesek önállóan kezelni az erőforrásokat, a logikát és a környezetet.
• szolgáltatásszervezési kapacitás – ez egy olyan folyamat, amelyben egy egyedi szolgáltatást más ilyen szolgáltatásokkal kombinálnak, hogy nagyobb üzleti folyamatokat vagy egységeket eredményezzenek. Ez a SOA további jellemzője vagy követelménye.
• szolgáltatások Hontalansága – a szolgáltatások teljesítése azon a koncepción alapul, hogy egy meghatározott szolgáltatást nyújtanak. Ez figyelembe veszi az adatok megőrzését, de csak akkor, ha a követelményt kifejezetten meghatározzák vagy kérik.

a SOA előnyei és előnyei

• jobb befektetési megtérülés – a SOA egyik legnagyobb előnye, hogy kiváló befektetési megtérülést kínál. Mivel a folyamat robusztus rétegek létrehozását foglalja magában, ezek a szolgáltatási rétegek mindegyike jobb megtérülést kínál a szoftver létrehozásához.
• Kódmobilitás – ez a SOA egy másik fontos előnye, és azért lehetséges, mert a szolgáltatásorientált architektúrában van egy helyátláthatóság. A legtöbb ügyfelet nem érdekli, hogy hol találhatók a szolgáltatások, mert van egy dinamikus kötés, valamint a szolgáltatások keresése. Ez azt jelenti, hogy a SOA-t használó vállalkozások áthelyezhetik a szolgáltatásokat különböző gépekre, vagy áthelyezhetik külső szolgáltatókhoz.
• az újrafelhasználhatóság – a SOA másik előnye, hogy a különböző kódok és szolgáltatások újra és újra használhatók. A futásidejű szolgáltatás újrafelhasználásának kényelme olyan egyszerű, mint egy szolgáltatás megtalálása a könyvtárban és kötése. A fejlesztőknek nem kell aggódniuk a platformok és egyéb inkompatibilitások miatt.
• támogatás különböző ügyféltípusokhoz – bármely vállalat több ügyféltípust és több ügyfelet használhat egy szolgáltatás eléréséhez a SOA-ban. Ez azért van, mert egy ilyen struktúrában vagy koncepcióban a rétegeket szolgáltatásokra osztották, és az ügyfélrétegek és a különböző ügyféltípusok egyszerűbbek.
• magasabb szintű elérhetőség – több szervernek több olyan szolgáltatása van, amely ezeket használja, mivel a SOA támogatja a hely átláthatóságát. Ez azt jelenti, hogy az általános rendelkezésre állás nagyon magas. Például, ha egy gép vagy egy hálózat egy része leáll, vagy valamilyen problémája van, a kéréseket átirányíthatják más szolgáltatásokra anélkül, hogy az ügyfél tudná vagy zavarná.
• kevesebb hiba – ez a SOA egyik fő előnye. A hibák valószínűsége sokkal alacsonyabb, és az Általános tesztelés sokkal jobb a szolgáltatások közzétett interfészeinek köszönhetően, amelyek könnyen tesztelhetők. A több tesztelés nagyobb pontosságot és kevesebb hibát eredményez.

SOA kihívások

• tesztelési hely hiánya – a SOA egyik legnagyobb kihívása a tesztelési hely hiánya. Egy tipikus architektúrában nincsenek jól kialakított vagy kifinomult eszközök vagy módszerek egy fej nélküli szolgáltatás, például üzenet vagy adatbázis-szolgáltatás tesztelésére. A SOA fő célja, hogy agilitást kínáljon a vállalatok és a vállalkozások számára. De a horizontális bizalom hiánya miatt be kell fektetni egy tesztelési keretbe, amely megkönnyítené a kihívást.
• szolgáltatások metaadatainak kezelése – ez a SOA gyakori és nagyon nyilvánvaló kihívása. A szolgáltatások metaadatainak kezelése nemcsak nehéz, hanem gyakran nagyon bonyolult is. A szolgáltatás alapú építészeti tér magában foglalja a szolgáltatásokat, amelyek üzenetváltással lépnek kapcsolatba egymással. Ilyen esetben egyetlen szolgáltatás néha több millió üzenetet generálhat. Ezeknek a szolgáltatásoknak a kezelése nagyon nehéz lehet, különösen akkor, ha a szolgáltatásokat különböző vállalatok és szervezeti egységek nyújtják egy vállalaton belül. Ez sok bizalmi kérdést vet fel.
• a biztonság megfelelő szintjének biztosítása – a SOA másik kihívása a megfelelő szintű biztonság biztosítása. Az alkalmazás által felügyelt biztonság nem a megfelelő módszer vagy modell a szolgáltatások biztosításához, mert az alkalmazásokba tervezett biztonsági modellek nem elegendőek, ha az alkalmazás megmutatja magát másoknak.
• interoperabilitás – ez a SOA implementációk döntő szempontjává válik. Gyakran, a szolgáltatások kölcsönös függőségének csökkentése vagy csökkentése érdekében, a köztük lévő kompatibilitás csökkenhet, de a függőséget olyan szintre kell csökkenteni, hogy a kompatibilitás továbbra is fenntartható legyen.
• szállítói hype – jelentős szállítói hype van a SOA-val kapcsolatban, és ez bizonyos szintű indokolatlan elvárásokat hoz létre. Bár a SOA-nak számos előnye van, számos hátránya is lehet. Például a SOA nem garantálja az informatikai költségek csökkentését, sőt a rendszerek agilitásának javítását sem ígéri. Így jobb lenne, ha egyértelmű különbség lenne a hype és a valóság között.

szolgáltatásorientált architektúra építése

SOA keretrendszer

ahhoz, hogy megértsük, hogyan épül fel a SOA, először meg kell értenünk, mi a keretrendszere.

a SOA-t 5 különböző vízszintes rétegnek tekintik, amelyek:

1. fogyasztói interfész réteg-ezek azok az alkalmazások, amelyek hozzáférnek a szolgáltatási vagy alkalmazás interfészekhez.
2. üzleti folyamatréteg-ez egy olyan réteg, amely az alkalmazások tekintetében üzleti felhasználási eseteket reprezentáló szolgáltatás.
3. Szolgáltatások – sok szolgáltatást egyesítenek egy egész vállalkozás létrehozásához.
4. szolgáltatási összetevők – ezek azok az összetevők vagy alkatrészek, amelyeket szolgáltatások, például technológiai interfészek és műszaki könyvtárak stb.
5. operációs rendszerek – ez az a réteg, amely MŰSZAKI mintákat, adatmodelleket, adattárakat stb.

a következők a SOA keretrendszer függőleges rétegei, amelyeket a vízszintesekre alkalmaznak és támogatnak:

1. integrációs réteg-ez a réteg protokoll-támogatásból vagy platformintegrációból, adatintegrációból, alkalmazás-és szolgáltatásintegrációból stb.áll.
2. szolgáltatás minősége – a szolgáltatás minőségét alkotó tényezők közé tartozik a rendelkezésre állás, a biztonság, a teljesítmény és mások.
3. információs – ez a réteg elsősorban üzleti információkkal szolgál.
4. irányítás – ezt a réteget vagy informatikai stratégiai réteget vízszintes rétegek szabályozzák, hogy szükség szerint elérjék a képességet, valamint a működési modellt.

SOA implementációs keretrendszer (SOAIF)

a SOA implementációhoz futásidejű infrastrukturális szoftverekre és eszközökre van szükség. Ezt együttesen szolgáltatásorientált architektúra megvalósítási keretrendszernek vagy SOAIF-nak nevezhetjük. Ez a koncepció egy olyan átfogó keretrendszerre törekszik, amely mindenféle technológiát kínál, amelyre egy vállalkozásnak szüksége lehet nemcsak a SOA felépítéséhez, hanem futtatásához is. A SOAIF magában foglalja mind a futásidejű, mind a tervezési idejű képességeket. Ez magában foglalja azokat a szoftverfunkciókat is, amelyekre a vállalatnak szüksége lehet egy SOA futtatásához, valamint annak felépítéséhez, beleértve a szolgáltatás-orientáltakat is:

• modellezés
• integráció
• eszközök
• menedzsment
• biztonság
• folyamatok

a SOA megközelítései

három fő típus vagy módszer vagy megközelítés létezik, amelyek kialakultak a klubinformációk, az eltérő és az üzleti rendszerek tekintetében. Mivel a különböző szolgáltatók és vállalkozások versenyeznek az ügyfelek és a fogyasztók számára nyújtott megoldások felé, ezek a megközelítések segítenek megfelelni a durva szemcsés, lazán clubbed és aszinkron szolgáltatások követelményeinek.

1. Az Enterprise Service Bus

az első megközelítés, amely segít az optimális SOA felépítésében és megvalósításában, az enterprise service bus vagy ESB. Ez a megközelítés segít összehangolni és rendezni a különböző elemeket, amelyek elosztott szolgáltatások formájában vannak a hálózaton. Ez a megközelítés a rendszereket diszkrét és elosztott szolgáltatásoknak tekinti, amelyek aszinkron üzenetorientált infrastruktúrán keresztül kapcsolódnak egymáshoz. Ez a fajta üzenetorientált infrastruktúra lehetővé teszi a független szolgáltatások vagy modulok közötti lazán összekapcsolt kapcsolatokat.

2. Business Process Management

sok vállalat már évek óta megpróbálta megoldani az üzleti folyamatok problémáit az üzleti folyamatok menedzsment megközelítésének megvalósításával. Ez a megközelítés az informatikai eszközöket és rendszereket olyan tevékenységeknek vagy feladatoknak tekinti, amelyek jól szinkronizált és jól összehangolt üzleti folyamatokban vesznek részt. A BPM eszközöket elsősorban az eljárások modellezésekor és tervezésekor használják, nem pedig olyan folyamatok építésére, amelyek elérhetik az integrációs célokat. Ez a BPM fő kihívása. By BPM megoldások önmagukban elég ahhoz, hogy megfeleljen SOA követelményeknek, mert nem áll a futásidejű környezet, amely szükséges lazán kapcsolt modulok.

3. Szolgáltatásorientált integráció

a SOA megfelelő megvalósításának harmadik és utolsó megközelítése a szolgáltatásorientált integrációs megközelítés. Ez a megközelítés az építészeti irányadó szabályokat vagy elveket használja olyan környezet vagy ökoszisztéma felépítéséhez, amelyet a vállalkozások dinamikusan kombinálhatnak, és olyan kiváló szintű folyamatokat hozhatnak létre, amelyek megfelelnek az állandóan változó és változó követelményeknek. Ez a megközelítés túlmutat a szorosan összekapcsolt és törékeny modulokon azáltal, hogy különbséget tesz a fogyasztó és a szolgáltatás gyártója között. Így a laza összekapcsolás szempontját írja elő, amely a SOA megfelelő végrehajtásához szükséges az üzleti követelmények teljesítéséhez. Még ez a megközelítés önmagában nem elegendő a szolgáltatások közötti hosszú távú interakciók garantálásához.

a SOA építésének legjobb gyakorlatai

a SOA építése során a legjobb és legelőnyösebb gyakorlatokat kell követni. Ezek a gyakorlatok a következők:

1. végrehajtási technológiák sokkal felvillanyozott, és meg kell emlékezni, hogy nem ugrik rájuk, mert a népszerűsége. Alaposan meg kell vizsgálni, hogy a webszolgáltatások jobban megfelelnek-e igényeiknek és igényeiknek. Fontos megjegyezni, hogy a szolgáltatás-orientált alkalmazások építése olyan technológiák felhasználásával, mint az RMI, inkább alkalmas lehet egy vállalkozás esetére, mint a webszolgáltatásokra.
2. emlékeznünk kell arra, hogy ne hozzunk létre vagy építsünk nagyon szorosan összekapcsolt vagy összekapcsolt modulokat, mivel ez törékeny felépítéshez vagy infrastruktúrához vezet.
3. fontos az interoperabilitás fenntartása, ehhez pedig a WS-I legjobb gyakorlatait kell követni.
4. ha nem lát értelmet a webszolgáltatások használatában, akkor sok más alternatív lehetőség is választható.