Servisně orientovaná architektura (SOA) se na počátku tohoto století objevila jako vývoj distribuovaného výpočetního systému. Před SOA byly služby chápány jako konečný výsledek procesu vývoje aplikace. V SOA se samotná aplikace skládá ze služeb. Služby mohou být dodávány jednotlivě nebo kombinovány jako komponenty ve větší složené službě.
Služby interagují po síti pomocí protokolu, jako je REST nebo SOAP (Simple Object Access Protocol). Služby jsou volně spojené, 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 obsahuje přehled Java SOA a klíčové charakteristiky architektura 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ě.
Proč je služba orientovaná na architekturu?
SOA řeší tři běžné podnikové výzvy :
- Rychlá reakce na obchodní změny.
- Využití stávajících investic do infrastruktury.
- Podpora nových kanálů 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 řada vzájemně závislých služeb. Stávající aplikace provozující současné obchodní procesy jsou zásadní, takže zahájení od nuly nebo jejich úprava je choulostivou záležitostí. Podniky však musí být schopny upravit a rozšířit technickou infrastrukturu tak, aby splňovaly obchodní požadavky.
Jak ve srovnání s monolitickým archi Díky volné povaze architektury SOA je relativně snadné zapojit nové služby nebo upgradovat stávající služby podle nových obchodních požadavků. Poskytuje také možnost zpřístupnit služby napříč různými kanály a vystavit starší aplikace jako služby, a tím chránit investice do infrastruktury.
Protože jsou volně propojeny, komponenty SOA lze 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é, kompozitní aplikace dodavatelského řetězce. I když jsou stávající aplikace heterogenní a distribuované napříč různými systémy, jejich funkčnost je přístupná a přístupná pomocí standardních rozhraní.
Obrázek 1. Aplikace dodavatelského řetězce v architektuře orientované na služby
Klíčové vlastnosti architektury SOA
SOA může být stejně jednoduché jako jedna součást 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 k dosažení vašich cílů použít co nejméně složitosti. Vaše první a poslední otázka by vždy měla znít: Splňuje tento design naše obchodní požadavky?
Bez ohledu na rozsah nebo složitost je vzor architektury orientované na služby je 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 spotřebovávají odpovědi.
- Poskytovatelé služeb generují zprávy pro zpracování požadavků.
Implementace služby- orientovaná architektura
Chcete-li implementovat architekturu SOA, začněte se základní architekturou služeb, poté poskytněte infrastrukturu, což znamená protokoly a další nástroje, které umožňují komunikaci a interoperabilitu. Obrázek 2 ukazuje diagram typické architektury služby.
Obrázek 2. Ukázková architektura služby
V tomto diagramu tři spotřebitelé vyvolávají služby zasíláním zpráv na podnikovou sběrnici služeb, která transformuje a směruje zprávy na příslušnou implementaci služby . Modul obchodních pravidel zahrnuje obchodní pravidla ve službě nebo napříč službami. Vrstva správy služeb spravuje činnosti, jako je auditování, 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.
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ž v počátcích SOA. Zde se jen 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 SOAP. K popisu služby se používá WSDL a SOAP je transportní vrstva pro odesílání zpráv mezi spotřebiteli a poskytovateli služeb. Služby komunikují se zprávami formálně definovanými pomocí schématu XML (XSD). Můžete myslet na WSDL 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. Spotřebitel by funkčně hledal službu, získal by WSDL pro tuto službu a potom by službu vyvolal pomocí SOAP.
Zabezpečení webové služby
WS -I Specifikace základního profilu 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.
Zjišťování webových služeb
Jakmile je základním kamenem zjišťování webových služeb, UDDI (univerzální popis, definice a integrace) vybledlo. 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 @WebService a @WebMethod anotace.
Vytváření a nasazování webových služeb
Vývojáři prostředí Java mají několik možností pro vytváření a nasazování na základě protokolu SOAP. webové služby, 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 vytváření tříd Java a jejich anotace k vytvář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 skryje podkladovou složitost a protokoly od vývojáře, čímž zefektivní 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 WS byla také vybrána pro pokračující vývoj v Jakartě EE.
Závěr
Architektura zaměřená na služby implementovaná pomocí webových služeb založených na protokolu SOAP vyžaduje přísnější a formální definice služeb než RESTful webové služby 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 možnosti jeho implementace vám dobře poslouží ve vaší programátorské kariéře.