Servisně orientovaná architektura (SOA) se objevila na počátku tohoto století jako vývoj distribuovaného výpočtu. Před SOA, služby byly chápány jako konečný výsledek procesu vývoje aplikace. V SOA se samotná aplikace skládá ze služeb. Služby lze dodávat jednotlivě nebo kombinovat jako komponenty ve větší složené službě.
Služby interagují po drátě pomocí protokolu, jako je REST nebo SOAP (Simple Object Access Protocol). Služby jsou volně vázané, což znamená, že servisní rozhraní je nezávislé na základní implementaci. Vývojáři nebo systémoví integrátoři mohou do aplikace sestavit jednu nebo více služeb, aniž by nutně věděli, jak je každá služba implementována.
Tento článek je přehledem Java SOA a klíčových charakteristik architektury orientované na služby implementované pomocí webových služeb založených na SOAP. Také stručně porovnám SOA a mikroslužby a proberu rozdíl mezi RESTful a SOAP webovými službami v Javě.
SOA a webové služby
SOA a webové služby jsou často sjednoceny, ale nejsou to samé. SOA je architektura, která umožňuje vývojářům kombinovat více aplikačních služeb do větší, složené služby. SOA lze implementovat pomocí webových služeb založených na SOAP nebo REST API, nebo někdy kombinací obou. Je důležité si uvědomit, že v SOA, a servis je jakýkoli vzdáleně dostupný zdroj, který může reagovat na požadavky. A webová služba je implementován pomocí specifických protokolů.
Proč architektura orientovaná na služby?
SOA řeší tři běžné podnikové výzvy:
- Rychle reagujte na obchodní změny.
- Využijte stávající investice do infrastruktury.
- Podporujte nové kanály interakce se zákazníky, partnery a dodavateli.
Podniková infrastruktura je heterogenní napříč operačními systémy, aplikacemi, systémovým softwarem a aplikační infrastrukturou. Ve výsledku se mnoho podnikových systémů skládá ze složitých a nekonzistentních aplikací poskytujících řadu vzájemně závislých služeb. Existující aplikace, na nichž běží aktuální obchodní procesy, jsou zásadní, takže je třeba začít od nuly nebo je upravovat. Podniky však musí být schopny upravovat a rozšiřovat technickou infrastrukturu tak, aby splňovaly obchodní požadavky.
SOA a mikroslužby
Microservices je architektonický styl vyvinutý z SOA. Obě jsou distribuované architektury a obě nabízejí oddělené paradigma. Zatímco architecure zaměřený na služby je těžší na infrastruktuře, mikroslužby nabízejí flexibilnější a lehčí styl vývoje. Pro oba existují klady a zápory a oba jsou široce používány. Obecně lze říci, že SOA je častěji implementována nebo udržována zavedenými podniky, které mají zdroje na podporu větší formality. Mikroslužby se často obracejí na nové nebo rostoucí organizace, které vyžadují agilitu.
Ve srovnání s monolitickou architekturou umožňuje volně propojená povaha SOA relativně bezproblémové připojení nových služeb nebo upgrade stávajících služeb pro nové obchodní požadavky. Poskytuje také možnost zpřístupnit služby napříč různými kanály a vystavit starší aplikace jako služby, čímž zajistí investice do infrastruktury.
Protože jsou volně spojené, lze SOA komponenty měnit s minimálním dopadem na ostatní komponenty. Komponenty lze také přidat do architektury standardizovaným způsobem a lze je škálovat tak, aby řešily zatížení.
Jako příklad zvažte, jak může podnik použít sadu existujících aplikací k vytvoření nové, složené aplikace dodavatelského řetězce. Zatímco existující aplikace jsou heterogenní a distribuované napříč různými systémy, jejich funkčnost je vystavena a je k nim přistupováno pomocí standardních rozhraní.
Matthew Tyson Klíčové vlastnosti SOA
SOA může být stejně jednoduché jako jedna komponenta spotřebovávající služby poskytované jinou komponentou nebo tak sofistikované jako řada komponent interagujících prostřednictvím sběrnice podnikových služeb, jako je ESB společnosti MuleSoft. Bez ohledu na rozsah je klíčem k úspěšné implementaci SOA použití co nejmenší složitosti k dosažení vašich cílů. Vaše první a poslední otázka by vždy měla být: Vyhovuje tento design našim obchodním požadavkům?
Bez ohledu na rozsah nebo složitost je vzor architektury orientované na služby víceméně stejný:
- Poskytovatelé služeb zveřejňují koncové body a popisují dostupné akce v každém koncovém bodě.
- Spotřebitelé služeb vydávají žádosti a využívají odpovědi.
- Poskytovatelé služeb generují zprávy pro zpracování požadavků.
Implementace architektury orientované na služby
Chcete-li implementovat SOA, začnete se základní architekturou služeb, pak poskytněte infrastrukturu, což znamená protokoly a další nástroje, které umožňují komunikaci a interoperabilitu. Obrázek 2 ukazuje schéma typické architektury služby.
Matthew Tyson V tomto diagramu tři spotřebitelé vyvolávají služby zasíláním zpráv na sběrnici podnikových služeb, které transformují a směrují zprávy na příslušnou implementaci služby. A motor obchodních pravidel zahrnuje obchodní pravidla ve službě nebo napříč službami. A vrstva správy služeb spravuje činnosti jako audit, fakturace a protokolování.
Komponenty v této architektuře jsou volně spojené, takže je lze vypnout nebo aktualizovat s relativně minimálním dopadem na aplikaci jako celek. To dává podnikům flexibilitu podle potřeby přidávat nebo aktualizovat obchodní procesy. Změny jednotlivých služeb by z větší části neměly výrazně ovlivnit ostatní služby.
SOAP vs RESTful webové služby
Je možné přijmout styl SOA a implementovat jej pomocí REST, například pomocí rozhraní JAX-RS API nebo Spring Boot Actuator, ale tato diskuse je mimo rozsah tohoto článku. Viz "SOAP vs REST vs JSON" pro užitečné srovnání webových služeb SOAP vs RESTful. Existuje také určité překrývání mezi webovými službami RESTful a lehčím stylem spojeným s mikroslužbami.
Webové služby založené na protokolu SOAP
Webové služby implementované pomocí protokolu SOAP jsou stále přísnější než implementace webových služeb nebo mikroslužeb RESTful, ale mnohem flexibilnější než počátky SOA. Zde se podíváme na protokoly vysoké úrovně požadované pro webové služby založené na protokolu SOAP.
SOAP, WSDL a XSD
SOAP, WSDL a XSD jsou základní infrastrukturou implementace webové služby založené na protokolu SOAP. WSDL se používá k popisu služby a SOAP je transportní vrstva pro odesílání zpráv mezi spotřebiteli služeb a poskytovateli. Služby komunikují se zprávami formálně definovanými pomocí schématu XML (XSD). WSDL si můžete představit jako rozhraní služby (volně analogické s rozhraním Java). Implementace se provádí ve třídách Java a komunikace v síti probíhá prostřednictvím protokolu SOAP. Z funkčního hlediska by zákazník vyhledal službu, získal WSDL pro tuto službu a poté službu vyvolal pomocí SOAP.
Zabezpečení webových služeb
Specifikace WS-I Basic Profile 2.0 řeší zabezpečení zpráv. Tato specifikace se zaměřuje na výměnu pověření, integritu zpráv a důvěrnost zpráv.
Objevování webových služeb
Jakmile se stal základním kamenem objevování webových služeb, UDDI (univerzální popis, definice a integrace) se vytratilo do historie. Dnes je běžné vystavit webovou službu založenou na protokolu SOAP způsobem, jaký byste udělali jakékoli jiné službě, prostřednictvím adresy URL koncového bodu. Jako příklad můžete použít rozhraní koncového bodu služby JAX-WS a jeho @Webová služba a @WebMethod anotace.
Vytváření a zavádění webových služeb
Vývojáři prostředí Java mají několik možností pro budování a nasazování webových služeb založených na protokolu SOAP, včetně Apache Axis2 a Spring-WS; standardem Java je však JAX-WS, rozhraní Java API pro webové služby XML. Základní myšlenkou JAX-WS je vytvoření tříd Java a jejich anotace k vytvoření požadovaných artefaktů. Pod kapotou používá JAX-WS několik balíčků Java, včetně JAXB, knihovny pro obecné účely pro vázání tříd Java na XML.
JAX-WS skrývá základní složitost a protokoly od vývojáře, čímž zefektivňuje proces definování a nasazení SOAP služeb založených na Javě. Moderní prostředí Java IDE, jako je Eclipse, zahrnují plnou podporu pro vývoj webových služeb JAX-WS. Specifikace JAX-WS byla také vybrána pro pokračující vývoj v Jakartě EE.
Závěr
Architektura orientovaná na služby implementovaná s webovými službami založenými na SOAP vyžaduje přísnější a formálnější definice služeb než webové služby RESTful nebo mikroslužby. Některé větší organizace však nadále upřednostňují formálnější styl vynucený SOAP. Mnoho rozsáhlých starších systémů je také postaveno na protokolu SOAP a některé B2B a interní systémy si pro své formálně definované smlouvy API vybírají webové služby založené na protokolu SOAP. Ať už vyvíjíte nebo udržujete rozsáhlý podnikový systém, porozumění vzoru SOA a schopnost vyhodnotit vaše možnosti implementace vám dobře poslouží ve vaší programátorské kariéře.
Tento příběh: „Co je architektura orientovaná na služby?“ byl původně publikován společností JavaWorld.
