A szolgáltatás-orientált architektúra (SOA) a század elején jelent meg az elosztott számítástechnika evolúciójaként. A SOA előtt a szolgáltatásokat az alkalmazásfejlesztési folyamat végeredményeként értették. A SOA-ban maga az alkalmazás szolgáltatásokból áll. A szolgáltatások külön-külön is szállíthatók, vagy egy nagyobb, összetett szolgáltatás összetevőjeként kombinálhatók.
A szolgáltatások a vezetéken keresztül kölcsönhatásba lépnek egy olyan protokoll segítségével, mint a REST vagy a SOAP (egyszerű objektum-hozzáférési protokoll). A szolgáltatások lazán vannak összekapcsolva, vagyis a szolgáltatási felület független az alapul szolgáló megvalósítástól. A fejlesztők vagy a rendszerintegrátorok egy vagy több szolgáltatást összeállíthatnak egy alkalmazásba anélkül, hogy szükségszerűen tudnák az egyes szolgáltatások megvalósítását.
Ez a cikk a Java SOA áttekintését és a SOAP-alapú webszolgáltatások segítségével megvalósított szolgáltatás-orientált architektúra. Röviden összehasonlítom a SOA-t és a mikroszolgáltatásokat, és megvitatom a különbséget a RESTful és a SOAP-alapú webszolgáltatások között a Java-ban.
Miért szolgáltatóorientált architektúra?
A SOA három gyakori vállalati kihívással foglalkozik :
- Gyorsan reagálhat az üzleti változásokra.
- Használja ki a meglévő infrastrukturális beruházásokat.
- Támogassa az ügyfelekkel, partnerekkel és beszállítókkal folytatott együttműködés új csatornáit.
A vállalati infrastruktúra heterogén az operációs rendszerek, alkalmazások, rendszerszoftverek és alkalmazásinfrastruktúrák között. Ennek eredményeként számos vállalati rendszer összetett és következetlen alkalmazásokból áll, amelyek egy egymástól függő szolgáltatások köre. A jelenlegi üzleti folyamatokat futtató meglévő alkalmazások kritikus fontosságúak, ezért a nulláról való kiindulás vagy azok módosítása kényes javaslat. De a vállalkozásoknak képesnek kell lenniük a műszaki infrastruktúra módosítására és bővítésére, hogy megfeleljenek az üzleti igényeknek.
Mint monolit archihoz képest A SOA lazán összekapcsolt jellege viszonylag zökkenőmentessé teszi az új szolgáltatások csatlakoztatását vagy a meglévő szolgáltatások frissítését az új üzleti követelményeknek megfelelően. Lehetőséget nyújt arra is, hogy a szolgáltatásokat különböző csatornákon keresztül fogyaszthatóvá tegye, és a régi alkalmazásokat szolgáltatásként tárja fel, ezáltal megóvva az infrastrukturális beruházásokat.
Mivel lazán vannak összekapcsolva, a SOA összetevői minimális hatással megváltoztathatók más alkatrészekre. . Komponensek szabványosított módon hozzáadhatók az architektúrához, és méretezhetők a terhelés kezelésére.
Példaként vegye fontolóra, hogyan használhatja egy vállalkozás a meglévő alkalmazások készletét egy új, összetett ellátási lánc alkalmazás. Míg a meglévő alkalmazások heterogének és el vannak osztva különböző rendszereken, funkcionalitásuk ki van téve és szabványos interfészek használatával érhető el.
1. ábra: Ellátási lánc alkalmazás szolgáltatás-orientált architektúrában
A SOA főbb jellemzői
A SOA lehet olyan egyszerű, mint egy komponens, amely egy másik komponens által nyújtott szolgáltatásokat fogyaszt, vagy olyan kifinomult, mint egy vállalati szolgáltatási buszon, például a MuleSoft ESB-jén keresztül kölcsönhatásba lépő komponensek sora. Bármilyen léptékű is, a SOA sikeres megvalósításának kulcsa hogy a lehető legkevesebb komplexitást használja céljainak elérése érdekében. Az első és az utolsó kérdés mindig az legyen: Megfelel-e ez a kialakítás üzleti követelményeinknek?
Mérettől vagy összetettségtől függetlenül a szolgáltatás-orientált architektúra mintája nagyjából megegyezik:
- A szolgáltatók kiteszik a végpontokat és leírják a az egyes végpontokon elérhető műveletek.
- A szolgáltatás fogyasztói kéréseket adnak ki és válaszokat fogyasztanak.
- A szolgáltatók üzeneteket generálnak a kérések kezelésére.
Szolgáltatás megvalósítása- orientált architektúra
A SOA megvalósításához az alapszolgáltatási architektúrával kell kezdeni, majd biztosítani kell az infrastruktúrát, azaz protokollokat és egyéb eszközöket, amelyek lehetővé teszik a kommunikációt és az interoperabilitást. A 2. ábra egy tipikus szolgáltatási architektúra diagramját mutatja.
2. ábra: Szolgáltatási architektúra minta
Ebben a diagramban három fogyasztó hívja meg a szolgáltatásokat üzenetek küldésével egy vállalati szolgáltatási buszra, amely átalakítja és átirányítja az üzeneteket egy megfelelő szolgáltatásmegvalósításhoz . Az üzleti szabályok motorja az üzleti szabályokat beépíti egy szolgáltatásba vagy a szolgáltatások egészébe. A szolgáltatáskezelési réteg kezeli az olyan tevékenységeket, mint az auditálás, a számlázás és a naplózás.
Az architektúra összetevői lazán vannak összekapcsolva, így kikapcsolhatók vagy frissíthetők, viszonylag minimális hatással az alkalmazás egészére. Ez rugalmasságot biztosít a vállalat számára az üzleti folyamatok szükség szerinti hozzáadásához vagy frissítéséhez. Az egyes szolgáltatások változásainak többnyire nem szabad nagyban befolyásolniuk a többi szolgáltatást.
SOAP-alapú webszolgáltatások
A SOAP használatával megvalósított webszolgáltatások még mindig merevebbek, mint a RESTful webszolgáltatások vagy a mikroszolgáltatások megvalósítása, de sokkal rugalmasabbak, mint a SOA korai szakaszai. Itt csak megnézzük a SOAP-alapú webszolgáltatásokhoz szükséges magas szintű protokollokat.
SOAP, WSDL és XSD
A SOAP, WSDL és XSD az alapvető infrastruktúra SOAP alapú webszolgáltatás megvalósítás. A szolgáltatás leírására WSDL-t használunk, a SOAP pedig a szolgáltatási fogyasztók és a szolgáltatók közötti üzenetek küldésének szállítási rétege. A szolgáltatások az XML séma (XSD) segítségével formálisan meghatározott üzenetekkel kommunikálnak. Gondolhat a WSDL-re mint a szolgáltatás interfésze (lazán analóg a Java interfésszel). A megvalósítás Java osztályokban történik, és a hálózaton keresztüli kommunikáció SOAP-on keresztül történik. Funkcionálisan a fogyasztó keres egy szolgáltatást, megkapja a szolgáltatáshoz szükséges WSDL-t, majd a SOAP használatával hívja meg a szolgáltatást.
Webszolgáltatás biztonsága
A WS -A Basic Profile 2.0 specifikáció az üzenetek biztonságával foglalkozik. Ez a specifikáció a hitelesítő adatok cseréjére, az üzenet integritására és az üzenet titkosságára összpontosít.
Webszolgáltatás felfedezése
Miután a webszolgáltatás felfedezésének sarokköve, az UDDI (Universal Description, Definition and Integration) elhalványult. a történelembe. Ma gyakran előfordul, hogy egy SOAP alapú webszolgáltatást úgy mutatnak be, mint bármely más szolgáltatást, egy végpont URL-en keresztül. Például használhatja a JAX-WS szolgáltatás végpont interfészét és annak @WebService és @WebMethod kommentárok.
Webszolgáltatások készítése és telepítése
A Java fejlesztőknek számos lehetőségük van a SOAP-alapú kiépítésre és telepítésre. webszolgáltatások, beleértve az Apache Axis2-t és a Spring-WS-t; a Java szabvány azonban a JAX-WS, az XML Web Services Java API-ja. A JAX-WS alapgondolata Java osztályok létrehozása és jegyzetekkel ellátása a szükséges melléktermékek létrehozásához. A burkolat alatt a JAX-WS több Java csomagot használ, köztük a JAXB-t, egy általános könyvtárat a Java osztályok XML-hez való kötésére.
A JAX-WS elrejti a mögöttes bonyolultságot és protokollokat a fejlesztő elől, így egyszerűsítve a folyamatot A modern Java IDE-k, mint például az Eclipse, teljes körű támogatást nyújtanak a JAX-WS webszolgáltatások fejlesztéséhez. A WS specifikációt a Jakarta EE folyamatos fejlesztésére is kiválasztották.
Következtetés
A SOAP-alapú webszolgáltatásokkal megvalósított szolgáltatás-orientált architektúra merevebb és formális szolgáltatásdefiníciók, mint a RESTful webszolgáltatások vagy mikroszolgáltatások. Néhány nagyobb szervezet azonban továbbra is a SOAP által érvényesített formálisabb stílust részesíti előnyben. Számos nagyszabású régi rendszer is SOAP-ra épül, és egyes B2B és belső rendszerek formálisan definiált API-szerződéseikhez SOAP-alapú webszolgáltatásokat választanak. Akár nagyszabású vállalati rendszert fejleszt, akár fenntart, az SOA-minta megértése és annak megvalósításának lehetőségeinek értékelése jól fog szolgálni a programozási karrierje során.