co je to SOA? 7 kroků SOA

tento blog popisuje kroky SOA, které musí organizace podniknout, než bude skutečně úspěšná při realizaci výhod nákladů a agility, které nabízí Architektura orientovaná na podnikové služby. Popisuje, co SOA znamená, a různé fáze přijetí SOA tím, že popisuje technologie, procesy, a osvědčené postupy, které jsou k dispozici, aby společnostem pomohly uspět v jejich iniciativách architektury orientovaných na služby.

co je SOA?

Service-oriented architecture (SOA) je typ architektury používané v návrhu softwaru, který podporuje orientaci na služby, přičemž služby jsou poskytovány jiným komponentům prostřednictvím komunikačního protokolu přes síť.

co znamená SOA?

definice SOA, jak je uvedeno na Wikipedii:

Service-oriented architecture (SOA) je styl softwarového designu, kde jsou služby poskytovány ostatním komponentám aplikačními komponentami prostřednictvím komunikačního protokolu přes síť. Základní principy architektury orientované na služby jsou nezávislé na dodavatelích, produktech a technologiích. Služba je diskrétní jednotka funkcí, ke které lze přistupovat vzdáleně a jednat a aktualizovat nezávisle, například načítání výpisu z kreditní karty online.

služba má čtyři vlastnosti podle jedné z mnoha definic SOA:

1. logicky představuje podnikatelskou činnost se stanoveným výsledkem.
2. je samostatný.
3. je to černá skříňka pro své spotřebitele.
4. může se skládat z jiných podkladových služeb.

různé služby mohou být použity ve spojení k zajištění funkčnosti velké softwarové aplikace, princip SOA sdílí s modulárním programováním. Architektura orientovaná na služby integruje distribuované, Samostatně udržované a nasazené softwarové komponenty. Je to umožněno technologiemi a standardy, které usnadňují komunikaci a spolupráci komponent v síti, zejména v síti IP.

to poskytuje stručnou odpověď na to, co znamená SOA, ale nepopisuje důvody, proč by organizace chtěla přejít k architektuře orientované na služby, nebo výhody SOA.

také z Wikipedie o tom, co SOA znamená:

někteří podnikoví architekti věří, že SOA může pomoci podnikům reagovat rychleji a nákladově efektivněji na měnící se tržní podmínky.Tento styl architektury podporuje opětovné použití na úrovni makro (služby) spíše než na úrovni mikro (tříd). Může také zjednodušit propojení s existujícími it (staršími) aktivy a jejich využití.

v některých ohledech lze SOA považovat spíše za architektonický vývoj než za revoluci. Zachycuje mnoho osvědčených postupů předchozích softwarových architektur. Například v komunikačních systémech došlo k malému vývoji řešení, která používají skutečně statické vazby pro komunikaci s jinými zařízeními v síti. Přijetím přístupu SOA, takové systémy se mohou postavit tak, aby zdůraznily význam dobře definovaných, vysoce funkční rozhraní.

vrtání do těchto konceptů vidíme, že existuje soubor základních schopností, které jsou potřebné k dosažení potenciálních výhod SOA. Wikipedia pojednává o řadě těchto hlavních principů, mezi které patří:

• opětovné použití – schopnost zapouzdřit a vystavit hrubozrnné obchodní funkce jako služby
• Loose-coupling – zajištění toho, aby spotřebitelé služeb byli dostatečně abstrahováni od fyzické implementace služby
• identifikace a kategorizace (objevitelnost) – ujistěte se, že potenciální spotřebitelé mohou najít služby, které potřebují

bez ohledu na to, jakou definici SOA používáte, tyto základní principy vedou k přirozenému pořadí činností, které musí organizace dokončit, aby postupně realizovala výhody orientované na služby architektura.

podívejte se, proč je Akana silným umělcem ve Forrester Wave™: API Management Solutions, zpráva Q3 2020.

stáhnout zprávu

jaké jsou sedm kroků SOA?

existuje sedm kroků SOA:

1. vytvořit / vystavit služby
2. registrovat služby
3. zabezpečené služby
4. spravovat (monitorovat) služby
5. zprostředkovat a virtualizovat služby
6. řídit SOA
7. integrace SOA s ESB

kroky SOA 2 až 6 popisují problémy mezi podniky, které by měly být řešeny centralizovanou platformou infrastruktury SOA. Kroky 1 a 7 řeší specifické potřeby a jsou často dodávány jako součást stávajícího zásobníku podnikových aplikací. Po těchto krocích povede organizaci správnou cestou k realizaci výhod SOA. Pokračujte ve čtení a jděte hlouběji do každého kroku SOA.

vytvořit / vystavit služby

první krok v pohybu organizace směrem k SOA je zřejmý. Bez služeb nemůže existovat žádná aplikace SOA, takže prvním krokem musí být vystavení nebo vytvoření služeb, které mohou být snadno spotřebovány aplikacemi povolenými webovými službami.

existuje řada zajímavých rozhodnutí, kterým společnosti čelí při zahájení tohoto procesu, v neposlední řadě je rozhodnutí, zda obnovit stávající aplikace pomocí paradigmatu orientovaného na služby, nebo vystavit existující aplikační logiku jako soubor služeb. Toto samozřejmě není binární rozhodnutí a většina organizací bude stavět nové služby od nuly, často pomocí J2EE a/nebo. NET, a také vystaví služby ze stávajících sálových počítačů a dalších obchodních aplikací.

existuje celá řada různých řešení pro společnosti, které chtějí vystavit stávající aplikace jako služby, včetně SOLA společnosti Akana, která je na trhu, která umožňuje aplikacím sálových počítačů CICS vystavovat a konzumovat spolehlivé, bezpečné a vysoce výkonné služby.

každá společnost s významnou (více než 1000 MIPS podle společnosti Gartner) investicí do sálových počítačů by měla zkoumat způsoby, jak lépe využít výhod této platformy, a měla by využívat webové služby pro snadnou integraci svých aplikací sálových počítačů s moderními systémy. Akana SOLA je výrobně ověřená u zákazníků, jako je Merrill Lynch, kde zpracovává více než 2 miliony transakcí denně z více než 600 webových služeb. SOLA je jediný produkt, který nabízí programátorům sálových počítačů snadno použitelné webové rozhraní pro vystavení a konzumaci služeb z aplikací CICS. Obsahuje vestavěnou podporu pro pokročilé funkce webových služeb, jako je WS-Security, XML-Encryption a XML-Signature.

většina společností tradiční podnikové integrace aplikací (EAI) také dodává verze svých adaptérů, které vystavují webové služby spíše než jejich tradiční proprietární protokoly. Ve skutečnosti se mnoho z těchto platforem EAI znovu objevuje jako produkty sběrnice podnikových služeb. ESB řeší několik různých problémů, jedním z nich je funkce typu komoditních datových služeb používaná k odhalení rozhraní webových služeb od tradičních adaptérů.

co je webová služba?

Z Wikipedie:

ve vztahu k webovým službám W3C definuje W3C webovou službu jako: „webová služba je softwarový systém určený k podpoře interoperabilní interakce stroj-stroj v síti . Má rozhraní popsané ve strojově zpracovatelném formátu (konkrétně WSDL). Jiné systémy interagují s webovou službou způsobem předepsaným jejím popisem pomocí SOAP zpráv, obvykle přenášených pomocí HTTP se SERIALIZACÍ XML ve spojení s jinými standardy souvisejícími s webem.“

tato definice je zajímavá z technického hlediska, ale ve skutečnosti se nedostane k jádru hodnoty, kterou lze odvodit z SOA a webových služeb. Základním aspektem webových služeb je, že by měly vystavovat obchodní logiku prostřednictvím rozhraní založeného na standardech. Jedním z důležitých aspektů odhalení nebo vytvoření služby je její granularita. Existuje mnoho různých myšlenkových směrů o tom, co představuje službu (Viz výše), ale většina podnikových architektů by souhlasila s tím, že aby byla užitečná v SOA, musí být služba dostatečně hrubě Zrnitá, aby byla užitečná pro více různých aplikací.

to jsou samozřejmě gely s jedním ze základních principů služeb v SOA – aby mohla být služba znovu použita; musí být obecně užitečná a použitelná. Příkladem obecně užitečné služby může být služba „getCustomerInfo“, která vrátí podrobnosti o zákazníkovi z identifikátoru zákazníka. Jemnější služba, která nemusí být obecně užitečná, může být něco specifického pro konkrétní aplikaci, například „setApplicationState“.

je důležité zvážit granularitu služeb jak při budování nových služeb, tak při vystavení stávající obchodní logiky jako služby. Například by bylo snadné provést transakci CICS a vystavit více různých služeb pro nastavení a získání různých parametrů, zatímco realita je taková, že hrubší Zrnitá služba, která vystavuje celou transakci jako jednu službu, může být mnohem obecněji užitečná, a proto cenné.

související čtení: zjistěte, jak Sola Mainframe API společnosti Akana poskytuje zákazníkům rychlý a snadný proces vystavování aplikací sálových počítačů jako bezpečných webových služeb a umožňuje aplikacím sálových počítačů konzumovat webové služby.

Zaregistrujte se

Ok, takže máte ve svém podniku k dispozici jednu nebo více služeb. Co teď?

aby mohla být služba použita, natož znovu použita, musí aplikační architekti a vývojáři, kteří by mohli těžit z této služby, vědět, že existuje. Zde přichází registr. Na své nejjednodušší úrovni, registr není nic jiného než index knihovny, který pomáhá potenciálním uživatelům služeb najít služby, o které by se mohli zajímat. Registr by měl nabízet rozhraní pro vyhledávání i procházení a měl by být organizován logicky, aby usnadnil rychlé a přesné zjišťování služeb.

v dnešním SOA je uznávaným standardem pro základní služby registru UDDI (Universal Discover, Description, and Integration). SPECIFIKACE UDDI poskytuje datový model a sadu rozhraní (Všechny samotné webové služby) pro publikování a objevování služeb, jakož i další sadu rozhraní pro správu samotného serveru registru.

mnoho dodavatelů registru posunulo původní koncept registru o něco dále a používají technologie registru jako základ pro úplnější úložiště. Dodavatelé registru také přidávají do svých publikačních nástrojů filtry založené na zásadách a nabízejí „řešení správy designu a času“.

Akana považuje registr za základní stavební kámen SOA. Všechny naše produkty využívají UDDI jako jediné centrální úložiště pro autoritativní informace o službách v SOA. Produkty mohou pracovat s jakýmkoli registrem kompatibilním s UDDI a Akana obsahuje svůj vlastní server registru UDDIv3 s produktem Service Manager pro společnosti, které ještě nemají registr. V tomto ohledu registr plní roli SOA, kterou LDAP plní pro řešení správy identit a přístupu.

produkty společnosti Akana se zaměřují na správu run-time a využívají registr jako centrální místo k nalezení zásad run-time pro implementaci a prosazování. Samozřejmě, že vestavěný registr je plně funkční UDDIv3 server, a tak také dělá ideální design-time služby úložiště.

Beyond registry je celý koncept služeb zásad a metadat, které poskytují komplexní úložiště pro všechny artefakty doby návrhu a běhu pro služby v SOA. Tento koncept je podrobněji popsán v akanově whitepaper referenčním modelu infrastruktury SOA.

Secure

svět SOA a webových služeb není všechno víno a růže. Za předpokladu, že jste nyní dokončili kroky jeden a krok, udělejte krok zpět a zvažte, co jste udělali. Za předpokladu, že se chystáte na maximální obchodní hodnotu, je pravděpodobné, že jste vzali kritické aplikace, rozdělili je na hrubé zrnité části funkčnosti, vystavili tuto funkci jako služby a poté tyto služby zveřejnili do univerzálně přístupného registru.

to vše se může zdát jako dobrá věc a ve většině případů je to skvělá věc, ale možná jste neúmyslně vytvořili nějaké zející bezpečnostní díry ve vaší organizaci a odhalili citlivé informace nebo transakce s vysokou hodnotou každému, kdo má základní dovednosti webových služeb. Zajištění bezpečnosti služeb znamená vytvoření vrstvy pro vymáhání zabezpečení u poskytovatelů služeb a vrstvy pro implementaci zabezpečení u spotřebitelů služeb.

dobrým způsobem, jak porozumět bezpečnostním rizikům s webovými službami, je vzpomenout si na tradiční aplikace sálových počítačů se zelenou obrazovkou. Jediným zabezpečením vyžadovaným těmito aplikacemi bylo zabezpečení přihlášení, pokud jste měli přístup k aplikaci, byli jste v. Tyto aplikace obsahovaly stejné základní prvky jako moderní aplikace (rozhraní, obchodní logika, datové služby), ale pouze rozhraní bylo přístupné mimo aplikaci. Ve světě webových služeb je pravděpodobné, že některé základní datové služby budou vystaveny jako služby, některé obchodní logiky by určitě měly být vystaveny a aplikace nebyla napsána s ohledem na žádný z těchto přístupových bodů. To znamená, že je důležité zabezpečit služby, které vystavujete jednotlivě, nemůžete se spolehnout na vnitřní části aplikace, abyste zajistili její vlastní bezpečnost.

co to znamená zabezpečit webovou službu? Stejných 5 zásad zabezpečení, které platí pro jiné aplikace, platí i pro webové služby:

• ověření-ujistěte se, že znáte totožnost žadatele o službu (a také se ujistěte, že žadatel zná totožnost služby, kterou kontaktuje). Existuje několik různých standardů webových služeb pro ověřování požadavků, od jednoduchých přístupů, jako je základní autentizace http, až po složitější mechanismy, jako je podpis SAML nebo x.509. Dobrý nástroj pro zabezpečení webových služeb by měl podporovat všechny tyto různé možnosti.
• autorizace-ujistěte se, že žadatel má oprávnění k přístupu ke službě nebo operaci, kterou požaduje. Autorizace je složitá záležitost a existuje řada různých produktů pro rozhodování o zásadách. Většina velkých podniků bude mít stávající řešení pro autorizaci (CA SiteMinder, IBM TAM atd.), a dobré řešení zabezpečení webových služeb by mělo být schopno se s nimi integrovat a poskytovat své vlastní autorizační schopnosti.
• Ochrana osobních údajů-zajistěte, aby zprávy o žádosti a odpovědi nemohly číst neoprávněné strany 3rd. To je místo, kde standardy, jako je šifrování XML, přicházejí do své vlastní, ale aby bylo možné úspěšně používat šifrování XML, musí řešení zabezpečení webových služeb poskytovat efektivní možnosti správy a distribuce klíčů a certifikátů a v ideálním případě některé nástroje na straně klienta, které pomáhají vývojářům spotřebitelů.
• neodmítnutí-ujistěte se, že žadatel nemůže odepřít odeslání žádosti a ujistěte se, že služba nemůže odepřít odeslání své odpovědi. Jedná se o roli podpisu XML, se stejnou správou a distribucí klíčů jako pro soukromí.
• audit-zajistěte, aby systém mohl podle potřeby udržovat přesný a včasný záznam požadavků a odpovědí.

jedna zajímavá otázka a bod debaty, který vyvstává kolem zabezpečení webových služeb, je místo, kde by se toto zabezpečení mělo použít. Někteří prodejci budou tvrdit, že zabezpečení by mělo být Ústřední funkcí vynucenou prostřednictvím clusteru centrálně rozmístěných proxy serverů, zatímco jiní budou tvrdit, že by to měla být výhradně doména poskytovatele služeb nebo kontejneru. Realita je samozřejmě někde mezi těmito dvěma pozicemi. Proxy (nebo cluster proxy) jistě hraje důležitou roli při poskytování služeb ověřování a detekce hrozeb na okraji sítě, aby byla chráněna před vnějšími hrozbami. Stejně důležitou roli hraje také bezpečnost poskytovatele nebo kontejneru, aby byla zajištěna bezpečnost služby na poslední míli.

mnoho společností má tendenci přehlížet výzkum, který ukazuje, že většina bezpečnostních hrozeb je interní pro podnik, nikoli externí, a proto deleguje zabezpečení na řešení typu brány firewall. Akana nabízí vysoce výkonný proxy, který provádí centralizované nebo síťové bezpečnostní funkce edge, a širokou škálu agentů v kontejnerech, aby byla zajištěna bezpečnost nasazených služeb na poslední míli.

zabezpečení webových služeb vyžaduje:

• nasadit plně funkční agenty v kontejnerech, aby zajistili bezpečnost poslední míle a distribuovali zátěž kryptografických operací
• nasadit vysoce výkonné síťové zprostředkovatele pro směrování a vynucování zabezpečení hran sítě
• poskytovat komplexní správu a distribuci klíčů a certifikátů, aby bylo zajištěno, že poskytovatel služeb a spotřebitelští vývojáři mohou úspěšně implementovat požadované bezpečnostní zásady
• poskytovat sady nástrojů pro vývojáře spotřebitelů abstraktním vývojářům spotřebitelů ze složitosti objevování a implementace podnikové bezpečnosti zásady

související čtení: Zjistěte více o osvědčených postupech zabezpečení API.

Spravujte

tři kroky do přístupu 7 kroků k SOA a začínáme dělat určitý pokrok směrem k dosažení skutečné hodnoty z enterprise SOA. Máme některé služby, jsou publikovány v registru a mohou být objeveny potenciálními uživateli a zajistili jsme, že jsou bezpečné. Co jiného bychom mohli potřebovat?

abychom odpověděli na tuto otázku, měli bychom se nejprve podívat na možný scénář katastrofy. Co se stane, když se mé služby stanou oběťmi vlastního úspěchu? Tedy. služba se stala tak populární, že existuje několik (desítky, stovky nebo tisíce) různých aplikací, které ji spotřebovávají, a začne se pod zátěží připoutat. Najednou máme desítky, stovky nebo tisíce aplikací, které selhávají nebo fungují špatně a nevíme proč, nebo jak to zastavit.

musíme sledovat naše služby, abychom věděli, zda fungují v normálních provozních parametrech, a abychom viděli potenciální problémy dříve, než k nim dojde implementací modelů plánování kapacit.

monitorovací řešení, které nasazujeme, by mělo být schopno sledovat služby pro základní dostupnost, výkon( Doba odezvy), propustnost a dokonce rozšířit na monitorování obsahu a uživatelů. Měl by být schopen sledovat a upozorňovat na konkrétní prahové hodnoty SLA a měl by být schopen aplikovat různé SLA na různé uživatele stejné služby nebo operace.

mnoho dodavatelů definuje tuto kategorii produktu jako řešení pro správu webových služeb, ačkoli mnoho analytiků souhlasí s tím, že správa je mnohem širší než jednoduché monitorovací řešení a měla by zahrnovat většinu funkcí popsaných v dalším kroku.

v ideálním případě bychom samozřejmě neměli zavádět samostatná řešení pro zabezpečení a monitorování, protože pokaždé, když zachytíme zprávy prostřednictvím agenta nebo zprostředkovatele, přidáme další překážku výkonu. To je důvod, proč Správce služeb Akana kombinuje s ředitelem sítě a poskytuje komplexní platformu pro zabezpečení, monitorování a správu SOA v jediném, vysoce výkonném a snadno implementovatelném řešení.

někteří dodavatelé správy webových služeb (monitorování) umisťují svá řešení jako platformy pro monitorování obchodních aktivit (Bam), ačkoli BAM je komplexní řešení vyžadující integraci s mnoha systémy a databázemi back – a front-office. Monitorování interakcí webových služeb s obsahem by nemělo být považováno za alternativu k podnikovému řešení BAM.

Související Čtení: Zjistěte více o řešení správy API společnosti Akana End-to-End.

5. Zprostředkovat a virtualizovat

v tomto okamžiku se zdá, že naše SOA je připravena na primetime. A tak to alespoň na chvíli je…

další sada výzev nastává, když vaše SOA zraje. Musíte zavést nové verze služeb nebo zvýšit kapacitu služby spuštěním více instancí, musíte poskytovat aplikace pro použití konkrétních instancí služeb a musíte nabízet služby, které vystavují širší škálu různých typů rozhraní.

zde přichází virtualizace služeb. Virtualizace se zdá složitá, ale realita je poměrně jednoduchá. Virtuální služba je zcela nová služba, definovaná vlastním WSDL, s vlastní síťovou adresou a transportními parametry. Neimplementuje žádnou obchodní logiku; jednoduše funguje jako proxy k jedné nebo více fyzickým službám, směrování, vyvažování zátěže, transformaci a zprostředkování mezi různými typy a standardy zpráv požadavků.

i když je koncept virtualizace na povrchu jednoduchý, je extrémně silný. Poskytuje možnost plně abstraktní služby spotřebitelům z jakékoli přímé znalosti fyzické služby. Například prostřednictvím virtuální služby by klient. NET, který používá implementaci spolehlivého protokolu pro zasílání zpráv společností Microsoft s protokolem SOAP přes http, mohl spotřebovat obyčejnou starou službu XML vystavenou prostřednictvím řady IBM WebSphere MQ z aplikace sálových počítačů. Klient. net by věřil, že to byla komunikace se službou http, která podporovala jeho spolehlivý protokol zasílání zpráv, zatímco aplikace sálového počítače by věřila, že je dotazována jinou nativní aplikací řady MQ.

virtuální služby nabízejí širokou škálu funkcí:

• mohou používat technologie transformace XML, které spotřebitelům umožňují pokračovat v používání staré verze služby, která již neexistuje transformací zpráv požadavků a odpovědí mezi starou verzí a novou verzí, která byla nasazena.
• mohou vybrat konkrétní operace z více různých služeb a kombinovat je do jednoho funkčního WSDL pro konkrétní třídu náročné aplikace.
• mohou poskytovat různé požadavky na zásady pro různé třídy uživatelů (tj. interní uživatelé s jednou sadou zásad a další implementací služby, která vynucuje jinou sadu zásad pro externí spotřebitele).
• mohou poskytovat přepravní přemostění pro služby a spotřebitele na nekompatibilních přepravách (např. http a JMS). * Mohou zprostředkovat mezi různými implementacemi standardů nebo dokonce verzemi standardů.
• mohou zprostředkovat mezi různými styly zpráv-RSS, SOAP, REST, POX (prostý starý XML).
• mohou poskytovat výkonné směrování založené na obsahu nebo kontextu, aby poskytovaly pokročilé funkce vyrovnávání zatížení a vysokou dostupnost.

Sečteno a podtrženo s virtuálními službami je, že jsou vyžadovány pro jakékoli směrování nebo jiné pokročilé webové služby a rychle se stanou nezbytnou součástí každého podnikového SOA.

vládnout

s 5 ze 7 kroků dokončených, podnik SOA je do značné míry připraven jít. Nyní máte zabezpečené, spravované služby, které jsou k dispozici širokému publiku spolehlivým, vyváženým způsobem a jsou snadno zjistitelné.

dalším krokem je spojit všechny schopnosti dodané během prvních 5 kroků s rámcem správy. Správa věcí veřejných je nadužívaná a hodně zneužívaná práce, pojďme se tedy krátce podívat na definici správy věcí veřejných. Opět z Wikipedie:

pojem správa se zabývá procesy a systémy, kterými organizace nebo společnost působí. Často je zřízena vláda, která tyto procesy a systémy spravuje.

klíčovým bodem, který je třeba vzít z této definice, je, že správa věcí veřejných je o procesech a systémech. V případě správy SOA, diskutujeme o organizačních procesech, jako je rada pro kontrolu architektury, a systémy jako registr, zabezpečení, a technologie správy diskutované v tomto blogu.

Governance pro SOA je často rozdělena do dvou samostatných částí, design – time governance a run-time governance. V době návrhu chtějí organizace kontrolovat (řídit) typy služeb, které lze publikovat, kdo je může publikovat, jaké typy schémat a zpráv mohou tyto služby přijímat, a řadu dalších pravidel o službách. V době běhu musí organizace zajistit bezpečnost, spolehlivost a výkon svých služeb a musí zajistit, aby služby byly v souladu s definovanými podnikovými zásadami. Design-time governance je zajímavá a pomáhá zajistit organizovanou, dobře navrženou SOA, ale ve srovnání s aktivní kontrolou SOA za běhu bledne do bezvýznamnosti.

Akana Service Manager je přední průmyslová platforma run-time governance, která nabízí komplexní řešení pro bezpečnost, monitorování, správu, zprostředkování a registr. Run-time governance v podstatě poskytuje jediný rámec pro kontrolu a monitorování uplatňování různých kroků na SOA popsaných v tomto dokumentu. Poskytuje jediné zastřešující řešení poskytující dohled nad registrem služeb, bezpečnost, řízení, a zprostředkování. Dobré řešení správy za běhu se projeví jako forma pracovního stolu poskytujícího nástroje pro všechny aktivní účastníky SOA.

• Vývojář Služeb: nástroje pro publikování, kategorizaci, definování metadat, stahování „agent“, virtualizaci, verzi, výběr zásad, výběr viditelnosti/přístupových práv, účast na plánování kapacit a přístupu k workflow
• Service Consumer: nástroje pro usnadnění vyhledávání služeb, výběru a přístupu k workflow
• Operations Staff: nástroje pro sledování výkonu služeb, řešení problémů, sledování závislostí, služby verzí, virtualizace, správa proxy
• Security Staff: nástroje pro správu zásad, hlášení zásad, kontrolu dodržování předpisů, bezpečnostní audit
• Enterprise Architect: Nástroje pro monitorování aplikací, správu vztahů, validaci a definici zásad návrhu, správu verzí služeb, přiřazení služby proxy, virtualizaci služeb
• Enterprise IT Management: Reuse metric management, metriky opětovného použití služby, statistiky SOA

integrace SOA s ESB

při pohledu zpět na výsledky Posledních 6 kroků směrem k SOA nás zajímá, co jiného může být. Nyní máme sadu služeb, které jsou publikovány v registru, bezpečné, spravované, spolehlivé a volně spojené, vše zabalené v solidním řešení pro správu designu a běhu.

posledním krokem pro některé podniky je nasazení jedné nebo více implementací Enterprise Services Bus (ESB) pro integraci služeb do kompozitních nebo organizovaných služeb vyšší úrovně. Tyto ESB budou často dodávány jako součást širší sady aplikací, jako jsou aplikace Oracle eBusiness nebo SAP. Některé specializované ESB mohou být použity k vytvoření komplexních kompozitních služeb a rozšíří se do oblasti řízení podnikových procesů (BPM).

související čtení: Zjistěte více o integračních řešeních Akana.

Enterprise Service Bus (ESB) je stále populárnější koncept. ESB, původně koncipovaná jako vývoj řešení middleware zaměřených na zprávy a EAI (enterprise application integration), znamená pro různé organizace velmi odlišné věci. Jak se analytici, prodejci a zákazníci vyrovnávají s myšlenkou ESB, zdá se, že ESB zapouzdřuje 3 funkční koncepty; adaptéry převzaté z nástroje EAI k zajištění konektivity se staršími aplikacemi, služby zasílání zpráv převzaté z platformy middleware zaměřené na zprávy k zajištění spolehlivého doručení a orchestrace procesů k vytváření agilních aplikací.

shoda mezi analytiky je, že většina organizací skončí s více platformami ESB od více dodavatelů a poskytuje služby ve svém vlastním kontextu. V tomto prostředí je důležité, aby ESB používaly centrální infrastrukturu SOA k zajištění důsledného dodržování zásad zabezpečení a zasílání zpráv pro služby, které vystavují a konzumují.

produkty Akana Service Manager a Network Director se kombinují a poskytují kompletní řešení pro správu a zprostředkování mezi více instancemi ESB v podniku.

Nyní, když víte více o tom, co znamená SOA a klíčové kroky SOA, podívejte se na Akana v akci!

Zahájit Zkušební Verzi