Architektúra orientovaná na služby. Technologická architektúra, štandardy a vzory

Prečo teda bola SOA vynájdená? Počet a zložitosť informačných systémov používaných spoločnosťami rastie, zvyšujú sa aj obchodné požiadavky na ne a modernizácia CIS je čoraz náročnejšia a nákladnejšia. Vzniká rozpor: časté zmeny v obchodné procesy vyžadované od IT špecialistov maximálna rýchlosť ich zavedenie, avšak z hľadiska ekonomickej efektívnosti je potrebné minimalizovať náklady na vlastníctvo CIS. K bolesti hlavy pridávajú úlohy integrácia procesov medzi viacerými spoločnosťami.

Teda pre n procesne orientované riadenie vyžaduje nástroj, s ktorým môžete nielen efektívne riadiť procesy ale aj s minimálne náklady a v čo najskôr zabezpečiť prispôsobivosť CIS zmenám v procesoch. Jednorazové riešenia a „záplaty“ totiž vedú k „spevneniu“ IT riešenia – a následne obchodné procesy spoločnosti, čo negatívne ovplyvňuje celkovú výkonnosť podniku. A v prípade vážneho procesné zmeny musíte zničiť vytvorený „IT monolit“ a buď sa presťahovať do „štandardného bytu“ ERP riešenia, alebo si postaviť nový domov pomocou niekoľkých aplikácií svojpomocne.

Vo väčšine prípadov tieto problémy vznikajú v dôsledku chýbajúcich architektonických štandardov v oblasti IT. Navyše na ich prekonanie sú potrebné nielen normy, ale aj súbor komponentov („stavebných blokov“), ktoré spĺňajú normy. Rovnako nevyhnutné je prostredie vykonávania obchodných procesov(„malta“), pomocou ktorej sú tehly držané pohromade. Úlohy zvyšovania flexibility CIS, znižovania nákladov na vývoj aplikácií, zvyšovania rýchlosti reakcie na meniace sa obchodné požiadavky, ako aj zabezpečovania potrebnej úrovne integrácie medzi informačnými systémami má riešiť tzv. SOA - Service Oriented Architecture.

Podniková architektúra

Často sa požiadavky na podnikový informačný systém menia ešte pred jeho nasadením. Ako zabezpečiť požadovanú flexibilitu? Jeden z možných prístupov (kľúč pre SOA) spočíva vo využívaní štandardných IT služieb.

S týmto prístupom na základe procesné modely špičková úroveň vytvára všeobecnú predstavu IT architektúra podniku, čo v prvom rade znamená určenie hlavných typov IP, ktoré sa budú používať. Ďalej popis procesov, na nižších úrovniach podrobností vám umožní identifikovať hlavné modely alebo skupiny služieb, ktoré bude potrebné podporovať obchodné procesy. Popis procesov na úrovni pracoviska určí požadovanú funkcionalitu pre služby (tzv. „mapovanie“) medzi funkciami obchodné procesy a IT systémových služieb a pri absencii potrebnej služby je potrebné formulovať požiadavky na jej rozvoj a vytvárať ju.

Tento prístup sa používa v mnohých procesne orientované projekty o automatizácii, kde na funkciu obchodný proces Konkrétna transakcia ERP systému je prepojená s úrovňou pracoviska, ale v budúcnosti bude táto transakcia manuálne nakonfigurovaná pre úlohy konkrétneho používateľa. SOA môže uľahčiť automatizáciu pomocou knižnice štandardných služieb spojených s popis procesov prostredníctvom jedného štandardu. V ideálnom prípade to minimalizuje potrebu manuálneho nastavovania. Využitie SOA však vyžaduje, aby podnikové IT služby mali špecialistov, ktorí sa dobre orientujú nielen v informačných technológiách, ale aj v obchodné procesy.

Jedným zo základných princípov zdokonaľovania činností je opätovné použitie už získaných výsledkov vrátane programového kódu. Kedysi sa široko využívalo opätovné použitie raz vyvinutých funkcií a postupov (štruktúrované programovanie). Následne sa objavil koncept objektovo orientovaného programovania, ktorý vyriešil problém zjednodušenia programového kódu a jeho opätovné použitie. Teraz je čas prejsť na novú programovaciu paradigmu spojenú nie s objektmi, ale s obchodné procesy a ich súčasť – obchodné funkcie.
Teraz pod vlajkou SOA zásady sa skutočne presadzujú procesne orientovaný prístup k budovaniu IT riešení. Vývojár IT riešení formalizuje obchodný proces a pripája k nej štandardné služby z knižnice, po ktorých je výsledné riešenie odovzdané na realizáciu. Tento prístup vám umožňuje minimalizovať vývoj kódu. V prípade potreby urobte procesné zmeny stačí zmeniť jeho logiku bez vplyvu na funkčnosť služieb, čo výrazne urýchli implementáciu zmien. Je oveľa jednoduchšie zmeniť jednu službu a zároveň kontrolovať vplyv tejto zmeny na funkcie ostatných procesy ako vykonávať rôzne zmeny v každej aplikácii s podobnou funkcionalitou.
Okrem toho použitie systematického prístupu, ktorý vyžaduje SOA núti vás zastaviť sa a premýšľať o tom, ako to urobiť teraz, aby sa neskôr výsledné riešenie dalo použiť v iných obchodné procesy.

Základné princípy SOA

Mnohí sa identifikujú SOA s webovými službami alebo workflow systémami, ale nie je to tak. SOA- nie súbor technológií, ale predovšetkým procesne orientovaná architektúra JE. SOA je možné definovať nasledujúcim spôsobom: Toto je aplikačná architektúra postavená na vrchole formalizované obchodné procesy, ktorého funkcie sú prezentované ako opakovane použiteľné služby s prehľadne popísanými rozhraniami.

V koncepcii SOA Sú dve strany: obchodné procesy a technické možnosti – IT služby. Pojem „služba“ sa interpretuje rôznymi spôsobmi – ako určitá funkcia, softvérový komponent alebo typizovaný proces. Každá organizácia môže mať svoju vlastnú úroveň služieb. Okrem toho, záujmy obchodu nie sú v žiadnom prípade totožné so záujmami IT služieb: podnik spravidla chce, aby sa zohľadnili želania každého kľúčového užívateľa, teda mnohých rôznych služieb.

Ale aby sa minimalizovali náklady na správu služieb, IT oddelenie potrebuje typizácia procesu a funkcie vykonávané pomocou IT, to znamená, že je v jej záujme mať minimálny počet agregovaných služieb. Výsledkom je, že medzi rôznorodými požiadavkami kľúčových podnikových používateľov a štandardnými riešeniami v procesné oblasti a IT služieb, treba nájsť „zlatú strednú cestu“. metodika SOA Práve to poskytuje príležitosť na štandardizáciu v oblasti, kde to veľmi chýba.

Jedna z hlavných požiadaviek vznikajúcich pri používaní SOA, - potreba vytvorenia knižnice štandardných služieb. V skutočnosti pri budovaní informačného systému založeného na princípoch SOA okrem toho opísaný proces musíte mať zoznam služieb s Detailný popis vstupy a výstupy. Potom sa v štádiu vývoja určitá služba z knižnice napojí na určitú funkciu a ak absentuje, určia sa požiadavky na jej rozvoj. Tu môžeme nakresliť analógiu s objektovými knižnicami používanými v programovaní, iba v prípade úrovne abstrakcie SOA vyššie.

Služba je v skutočnosti výsledkom vykonania časti proces(z IT alebo obchodnej domény), teda v rámci návrhu aplikačnej architektúry založenej na SOA je potrebné určiť úroveň typizovanej služby. Služba najvyššej úrovne je chápaná ako IT služba dodávaná podniku (napríklad podnikový informačný systém, ktorý automatizuje proces predaja), kým služba nižšej úrovne je automatizovaná operácia, v rámci ktorej dochádza k určitému výsledku (napríklad získanie zákaznícke údaje zo systému CRM).

Najefektívnejšie je implementovať písanie na vyšších úrovniach služby, ale čím vyššia je úroveň písania, tým viac zmien bude potrebné vykonať v službe a tým ťažšie bude udržať ju v jej „elementárnej“ forme. Na jednej strane by veľkosť služby nemala obmedzovať zmena procesu, na druhej strane musí byť taká, aby sa dala na úrovni voľne ovládať premenlivé obchodné procesy.

Preto je vhodné začať od najzákladnejšej úrovne - zvýraznenie služieb vytvorených na úrovni funkcií obchodné procesy, pričom princíp ich prideľovania bude vykonávať jeden účinkujúci. V budúcnosti sa môžete pokúsiť prejsť na vyššiu úroveň písania a písania častí spolu so službami obchodné procesy.

Výhody a výzvy prístupu SOA

Kým sa objavia plnohodnotné IT systémy kompatibilné so SOA, potrvá minimálne tri roky. Základné princípy SOA však môžete začať používať už teraz – rozhodujte o obchodných procesoch a vytvárajte množstvo služieb. Hlavná výhoda SOA pochádza z opätovného použitia služieb. Aj keď automatizácia jedného procesu vyžaduje viac času a peňazí, minimalizáciu nákladov možno dosiahnuť počas dlhšieho obdobia, keď sa už vyvinuté služby opätovne použijú pri automatizácii nasledujúcich procesov.

SOA navyše zjednodušuje integráciu nových aplikácií do CIS. Koniec koncov, vzhľad slova „integrácia“ v zadávacích podmienok na implementáciu CIS zvyšuje rozpočet projektu najmenej dvakrát. V rámci SOA by sa nové softvérové ​​produkty mali ľahko integrovať do existujúceho CIS prostredníctvom mechanizmu služieb. Preto riešením integračných problémov prostredníctvom štandardizácie a automatizácie podnikových procesov SOA zníži náklady na integráciu.

Pri všetkých výhodách SOA však zostáva jedna zložitá otázka – prenos dát medzi službami a oddelenie funkčnosti služieb od používaných dát. Mnohé služby nebudú mať spoločné klasifikátory, čo bude komplikovať výmenu dát medzi nimi. Stále nie je jasné, čo s týmto problémom robiť. Ak je však spoločnosť v organizačnom chaose, tak SOA nepomôže. Kým sa rozhrania obchodných procesov a informačných systémov používaných na ich podporu nedostanú do určitých spoločných súradníc, technologická integrácia je vo všeobecnosti nemožná, bez ohľadu na spôsob organizácie IT. Ale ak sa popíšu procesy a vzťah k nim už používaných informačných systémov, tak sa obnoví poriadok, čo je samo o sebe užitočné pre zvýšenie efektivity IT a prípravu na nasadenie SOA.

Na zjednotenie popisov procesov sa čoraz viac používa Business Process Executive Languages ​​​​(BPEL) - jazyk vykonávania obchodných procesov a jeho miesto v SOA je veľmi dôležité, pretože takýto popis je nevyhnutnou podmienkou implementovať SOA. Zároveň by mal byť zrozumiteľný pre majiteľov podnikových procesov aj informačných systémov. V tomto prípade použitie zápisu eEPC (event chain of business process control) pre obchodnú úroveň s následnou transformáciou výsledných modelov do BPEL nám umožňuje minimalizovať náklady na formalizáciu procesov a ich automatizáciu. Na základe jazyka BPEL automatizačný systém zavolá požadované opísané služby, aby im poskytol informácie potrebné na vykonanie.

Obchodní analytici formalizujúci procesy musia byť schopní sprostredkovať svoj popis Informačné systémy na ďalšie vykonanie. Navyše kvalita tohto rozhrania by mala eliminovať potrebu manuálnych úprav. Výrobcovia informačných systémov musia navyše zmeniť svoju architektúru a vytvárať knižnice služieb s podrobným popisom vstupov, výstupov a volacích rozhraní. A ak je prvá úloha vyriešená prenosom popisu procesu vo formáte BPEL, potom úloha „rezania“ veľkých informačných systémov triedy ERP vo forme služieb stále vyžaduje riešenie.

Pri budovaní IT architektúry založenej na SOA problém nespočíva len v typovaní služieb, ale aj v zmene prístupov k riadeniu organizácie z funkčne orientovaného na procesne orientovaný. A to nie je otázka techniky, ale úrovne riadenia vo firme. V Rusku to nie je vždy vysoké. Písanie obchodných procesov nemusí byť nevyhnutne podporované samotným podnikom, takže sa mení firemná kultúra a vzájomné porozumenie medzi podnikmi a IT je nevyhnutnou podmienkou efektívnej implementácie SOA. Pred prechodom na SOA je potrebné pozdvihnúť vyspelosť procesov aspoň na tretiu alebo štvrtú úroveň, čo pre mnohých Ruské spoločnosti predstavuje nebeské výšky.

Ďalšou výzvou na ceste k SOA je počet typizovaných služieb. Berúc do úvahy zvláštnosti obchodných procesov veľké spoločnosti, potom počet služieb môže presiahnuť tisíc, čo si vyžaduje prístupy a nástroje na ich riadenie a sily prísne požiadavky k ich vývoju a dokumentácii. Okrem toho hlavnou požiadavkou pri navrhovaní je, že čím menšie, tým lepšie. Zároveň však musíte pochopiť, že hlavnou úlohou SOA je typovať služby pri zachovaní špecifík podnikania.

Ďalším nevyriešeným problémom je integrita informácií používaných rôznymi službami. Ak dôjde k prerušeniu implementácie procesu v systéme, budete musieť analyzovať nielen jeden protokol, manuálne vykonávať zmeny, ale celý súbor protokolových súborov jednotlivých služieb (ktorých vytvorenie je ešte potrebné zabezpečiť). To znamená, že automatizačný systém bude potrebovať funkčnosť na obnovenie neúspešných inštancií procesov bez zastavenia jeho produktívnej prevádzky.

Zatiaľ neboli vytvorené plnohodnotné IT nástroje, ktoré sa môžu stať základom pre implementáciu SOA. To zostáva jednou z hlavných prekážok jej šírenia. Existujúce aplikácie nie sú schopné plne podporovať SOA. Problémy so spoľahlivosťou a informačná bezpečnosť výsledná „kompozitná“ aplikácia môže tiež ukončiť SOA. Teraz je totiž potrebné sledovať činnosť viacerých informačných systémov a ak bude SOA implementovaná, budete musieť monitorovať množstvo rôznych služieb, ktoré sa navzájom ovplyvňujú, a to ako prostredníctvom úrovne automatizácie obchodných procesov, tak aj priamo. Na prechod od štandardného ERP systému k prístupu orientovanému na služby bude potrebné prepracovať väčšinu systémov na trhu. softvérové ​​produkty a vyvinúť obrovské množstvo riešení, čo je nepravdepodobné v priebehu budúceho roka alebo dvoch.

Záver

Nástup SOA opäť nastolil otázku efektívnosti využívania IT a vnesenia poriadku do IT systémov. V blízkej budúcnosti bude SOA zohrávať úlohu katalyzátora práce na inventarizácii podnikovej IT architektúry a popise obchodných procesov. No akonáhle bude IT trh schopný poskytnúť sadu plnohodnotných nástrojov, ktoré umožnia aplikovať princípy SOA v praxi, mnohé spoločnosti začnú pracovať na budovaní IT riešení založených na tomto koncepte. Tí, ktorí majú na začiatku procesne orientovanú obchodnú organizáciu, budú v popredí – napríklad spoločnosti v telekomunikačnom a finančnom sektore. Gartner predpovedá, že do roku 2008 bude viac ako 60 % podnikov používať SOA ako základný princíp svojej podnikovej IT architektúry.

Prvé kroky k SOA

Začnite v malom – identifikujte jeden z malých starších systémov a pokúste sa ho rozdeliť na sadu služieb, pričom pracujte na štandardoch popisu služieb a metódach správy knižníc. Potom pomocou tohto systému prepracujte niekoľko procesov.

• Urobte si inventúru svojej IT architektúry popísaním procesov a architektonických prvkov.
• Urobte procesy primárne: vytvorte kompetenciu podnikových procesov v rámci IT oddelenia, aby ste mohli navrhovať systémy založené na SOA.
• Nepoužívajte metodiky a štandardy bez toho, aby ste brali do úvahy svoje vlastné špecifiká: väčšina metód vyžaduje zohľadnenie špecifickej situácie, takže budú musieť byť upravené tak, aby vyhovovali charakteristikám vašej organizácie.
• Pokúste sa vytvoriť a udržiavať proces dokumentovania všetkého vývoja.
• Určiť základné štandardy v oblasti dizajnu CIS a upevniť ich.

Veľmi často je vývoj jedného alebo druhého prístupu sprevádzaný vznikom nesprávnych alebo chybných interpretácií. SOA nie je žiadnou novinkou: IT oddelenia už mnoho rokov úspešne budujú a nasadzujú aplikácie, ktoré podporujú architektúru orientovanú na služby – dávno pred príchodom XML a webových služieb.

SOA je len iný štýl budovania moderných firemných systémov. Je orientovaný na služby, vyznačuje sa distribuovanou architektúrou a voľne prepojenými rozhraniami. Služba v tomto prípade nie je ničím iným ako jednotkou práce vykonanej poskytovateľom služby s cieľom poskytnúť spotrebiteľovi služby požadovaný výsledok. Je to služba a nie objekt ako v OOP, ktorý je opakovane použiteľný a zároveň nezávisí od technológií, jazykových prostredí a iných zdrojov. Softvéroví agenti preberajú integračnú úlohu medzi poskytovateľom služieb a spotrebiteľom. Množstvo architektonických prvkov SOA umožňuje znížiť mieru prepojenia medzi rôznymi systémovými prvkami. Na interakciu komponentov sa používa relatívne malá množina jednoduchých rozhraní, ktoré majú len najvšeobecnejšiu sémantiku a sú dostupné všetkým poskytovateľom a spotrebiteľom. Prostredníctvom týchto rozhraní sa prenášajú správy obmedzené na určitú slovnú zásobu. A keďže je uvedená iba všeobecná štruktúra podnikového systému a slovná zásoba, všetka sémantika a obchodná logika špecifická pre aplikáciu sú popísané priamo v týchto správach.

Samotné webové služby neimplikujú žiadne architektonické riešenie, pričom práve architektúra určuje štýl procesov interakcie. SOA nepredpisuje rigidnú vertikálnu metodológiu pre návrh, implementáciu alebo správu IT infraštruktúry. Namiesto toho je SOA obmedzená iba na súbor princípov, ktoré charakterizujú každý z týchto procesov; preto sa niekedy nazýva nie architektúra, ale architektonický štýl.

Všimnime si niektoré z týchto zásad.

Distribuovaný dizajn. Rozhodnutia o vnútorných vlastnostiach informačných systémov robia rôzne skupiny ľudí, ktorí majú svoje organizačné, politické a ekonomické motívy.

Pretrvávanie zmien. Jednotlivé úseky architektúry môžu kedykoľvek prejsť zmenami.

Dôsledné zlepšovanie. Lokálne zlepšovanie komponentov architektúry by malo viesť k zlepšeniu celej architektúry ako celku - k zvýšeniu celkovej užitočnosti komponentov rovnakej úrovne ako je ten, ktorý sa mení, ako aj komponentov nižších a vyšších úrovní.

Rekurzívnosť. Podobné riešenia sa vyskytujú na rôznych úrovniach architektúry.

Nech sa to môže zdať akokoľvek nečakané, uvedené princípy sformuloval americký architekt Christopher Alexander vo vzťahu k architektúre modernej metropoly. V roku 1987 s kolegami publikoval prácu s názvom Nová teória urbanistického dizajnu, v ktorej načrtol ich názory na možnosť decentralizovaného rozvoja miest. Alexander vo svojej práci ukázal, ako sa dá realizovať mestský rozvoj s prihliadnutím na výraznú demografickú heterogenitu obyvateľov. Podobne SOA na základe prispôsobenia týchto princípov umožňuje spájať informačné systémy patriace rôznym autonómnym organizáciám a ich relatívne autonómne štrukturálne členenia do spoločného interagujúceho organizmu.

Všeobecná schéma.

Vo svojej najvšeobecnejšej forme SOA zahŕňa troch hlavných účastníkov: poskytovateľa služieb, spotrebiteľa služieb a register služieb (pozri obrázok 2). Interakcia účastníkov vyzerá celkom jednoducho: poskytovateľ služby zaregistruje svoje služby v registri a spotrebiteľ kontaktuje register so žiadosťou). Absencia niektorého z týchto prvkov je neprijateľná a pridávanie ďalších komponentov je v praxi nielen možné, ale aj nevyhnutné. Tieto prvky môžu zahŕňať všetky druhy midlvéru, ktorý riadi poradie a kontext interakcie, monitoruje a riadi služby, ako aj riadi metadáta a iné podporné procesy.

Ryža. 2.

Ak chcete službu používať, musíte dodržiavať konvenciu rozhrania pre prístup k službe - rozhranie musí byť nezávislé na platforme. SOA implementuje škálovateľnosť služieb – možnosť pridávať služby, ako aj ich modernizáciu. Poskytovateľ služby a jeho spotrebiteľ sa ocitnú bez spojenia – komunikujú pomocou správ. Keďže rozhranie musí byť nezávislé od platformy, technológia použitá na definovanie správ musí byť tiež nezávislá od platformy. Vo všeobecnosti sú teda správy dokumenty XML, ktoré zodpovedajú schéme XML.

SOA model nezávisí od technológií použitých na implementáciu SOA a jeho hlavnou metodologicky významnou súčasťou je register služieb. V asynchrónnom komunikačnom protokole medzi poskytovateľom a spotrebiteľom služby uvedenom v diagrame vykonáva funkcie sprostredkovateľa. Poskytovateľ umiestňuje informácie o svojich službách do registra, čo spotrebiteľovi umožňuje kedykoľvek nájsť službu, ktorú potrebuje. Na prvý pohľad to nevyzerá ako nič zvláštne, no za týmto komunikačným procesom sa skrýva hlavná kvalita SOA – loose coupling. Vďaka tejto vlastnosti získavajú služby mobilitu, možnosť presúvať sa z jedného servera na druhý bez toho, aby vyžadovali schválenie a koordináciu so všetkými spotrebiteľmi. Prirodzene, spotrebitelia služieb v niektorých prípadoch nie sú schopní a nemali by brať do úvahy pravidelné prerozdeľovanie zdrojov, ktoré zabezpečujú fungovanie služieb.

Neskorá väzba tiež umožňuje, aby sa konečné zostavenie odkazov odložilo skôr do doby spustenia ako do doby vývoja programu, čo je typické pre tradičné monolitické systémy. Parametre komunikácie (ako je adresa, protokol a komunikačný kanál) môžete zmeniť aj za behu. To dáva niekoľko rozmerov flexibility samotnému prepojeniu medzi poskytovateľom a odberateľom služby – volaným a volajúcim objektom, resp. Najmä poskytovateľ a spotrebiteľ môžu byť vykonávaní na ľubovoľne fyzicky vzdialených infraštruktúrach. Každý systém môže mať svoje vlastné parametre životný cyklus a akékoľvek ich zmeny, ktoré neovplyvnia rozhranie služby, nevyžadujú zastavenie žiadnej z nich.

V SOA sú služby vnímané ako autonómne entity, ktoré nie sú centrálne riadené. To umožňuje, aby sa informačné systémy interagujúce prostredníctvom služieb rozvíjali v súlade s potrebami podnikania, o ktorých spotrebitelia služieb spravidla nielen nevedia, ale ani o ne nemajú záujem. To by však nebolo možné, ak by rozhranie služby nebolo pevne stanovené vzájomnou dohodou medzi poskytovateľom a spotrebiteľom služby. Jedným z charakteristických znakov SOA je prítomnosť zmlúv, ktoré popisujú rozhrania služieb. Takáto zmluva je dokument, ktorý špecifikuje očakávania služby vo vzťahu k jej spotrebiteľom a naopak. Zmluvy o webových službách sú opísané v dokumente WSDL, ktorý v zápise XML definuje, ako by mali spotrebitelia pristupovať k službe. Používanie XML v tejto fáze má zásadný význam, pretože umožňuje poskytovateľovi aj spotrebiteľovi služby byť nezávislí od konkrétnej platformy.

Podobné zmluvy existovali pred príchodom webových služieb. Napríklad v architektúre CORBA sa na popis rozhrania objektov použil IDL, ktorý je v mnohých významných parametroch horší ako WSDL. Hlavným z nich je nedostatočná podpora pre XML a XML Schema, ktoré sa stali najbežnejšími značkovacími jazykmi pre správy prenášané cez sieť a pre reprezentáciu dátových modelov. Technické zmluvy formulované poskytovateľom služieb musia byť dostupné potenciálnym zákazníkom na interpretáciu, analýzu a implementáciu integrácie. Na tento účel sa používa špeciálny register, ktorý katalogizuje dostupné služby.

Na používané softvérové ​​architektúry má v poslednom období výrazný vplyv potreba integrácie a interakcie aplikácií v rámci veľkého množstva podnikových informačných systémov alebo viacerých podnikov spojených do celého partnerského reťazca. Podrobná úvaha o týchto aspektoch presahuje rámec tohto kurzu, považovali sme však za vhodné poskytnúť stručné informácie o nových prístupoch k návrhu architektúry informačných systémov, keďže majú priamy vplyv na princípy formovania podnikovej architektúry ako celý.

Hovoríme v prvom rade o servisnom modeli interakcie medzi aplikáciami spoločný systém v rámci tzv. servisne orientovanej architektúry (Service-oriented architecture SOA) a o implementácii „modelom riadenej architektúry“ (model-driven architecture MDA).

• explicitné oddelenie obchodnej logiky aplikačného systému od logiky prezentácie informácií;
• implementácia obchodnej logiky aplikačného systému vo forme množstva programových modulov (služieb), ktoré sú prístupné zvonku (používateľom a iným modulom), najčastejšie v režime „žiadosť-odpoveď“, prostredníctvom jasne definovaných formálnych prístupové rozhrania;
• v tomto prípade „spotrebiteľ služby“, ktorým môže byť aplikačný systém alebo iná služba, má možnosť volať službu cez rozhrania s použitím vhodných komunikačných mechanizmov.

Samotný koncept SOA nie je niečo zásadne nové, keďže podobné schopnosti boli implementované už skôr, napríklad pomocou technológií zasielania správ. Zásadným faktorom je, že moderné prístupy k implementácii SOA pokrývajú nielen technologickú úroveň výmeny dát, ale aj úroveň obchodných operácií. Jedným z dôležitých výsledkov bol najmä vývoj špecializovaného jazyka BPEL (Business Process Executable Language for Web Services) na popis aspektov interakcie rôznych služieb z pohľadu implementácie obchodných pravidiel. Všeobecne povedané, prijatie SOA ako cieľovej architektúry bude znamenať zodpovedajúci prístup k vývoju aplikácií (SODA - service-oriented development architecture).

Na úlohy e-business zodpovedajúca funkcionalita SOA je implementovaná na úrovni webových služieb (služieb). Webové služby sú chápané ako softvérové ​​systémy, ktoré používajú XML ako dátový formát, štandardy Web Services Description Language (WSDL) na popis ich rozhraní, Simple Object Access Protocol (SOAP) na popis formátu prijímaných a odosielaných správ a Univerzálny popis, Discovery and Integration (UDDI) na vytváranie adresárov dostupných služieb. A hoci princípy servisne orientovanej architektúry pre tvorbu informačných systémov neznamenajú nutne využitie technológií webových služieb, prepojenie týchto dvoch smerov vo vývoji informačných technológií je pomerne úzke. Webové služby sú zároveň technologickými špecifikáciami, pričom architektúra orientovaná na služby(SOA) je princíp návrhu architektúry softvérových systémov.

Berúc do úvahy existujúce trendy uvedené vyššie pri prechode na podnikanie v „reálnom čase“ a vytváraní takzvaných systémov „rozšíreného podniku“, ktoré spájajú samotný podnik, jeho dodávateľov, partnerov a zákazníkov v jednotný systém, je zrejmé, že technológie webových služieb nájdu svoje uplatnenie na všetkých úrovniach podnikových informačných systémov. Predpokladá sa, že v budúcnosti sa takmer všetka interakcia aplikácií, či už v rámci toho istého informačného systému, ako aj medzi systémami jednotlivých účastníkov obchodného procesu, bude uskutočňovať pomocou takéhoto mechanizmu, takže otázky koordinovaného fungovania týchto služieb stať sa dosť kritickým. Na opísanie takejto práce boli navrhnuté aj špeciálne pojmy - „choreografia“ a „orchestrácia“ (samozrejme analogicky s riadením orchestra rôznych nástrojov alebo súboru rôznych interpretov). Navyše, ak choreografia definuje interakciu rôznych účastníkov využívajúcich služby, potom orchestrácia popisuje interakciu služieb v rámci jedného obchodného procesu, najmä pomocou jazyka ako BPEL.

Navyše je vhodné integrovať aj staršie aplikácie využívajúce túto technológiu, keď určitá, najdôležitejšia časť existujúcej funkcionality je akoby „zapuzdrená“ a prezentovaná so štandardizovaným rozhraním. Ak má podnik existujúcu infraštruktúru webových služieb, možno očakávať výrazné zníženie času a nákladov na integráciu.

Vplyv prístupov orientovaných na služby na zmeny v architektúre možno teda charakterizovať ako vyvážený prechod od centralizovanej infraštruktúry informačných technológií a samostatnej funkcionality. aplikačných systémov smerom k architektúre, ktorá umožňuje rýchla tvorba nové systémy z množiny dostupných služieb, t.j. flexibilnejší, dynamickejší a spolupracujúci.

20 odpovedí

Malý teaser:

SOA je štýl archivácie aplikácií takým spôsobom, že pozostávajú z diskrétnych softvérových agentov, ktorí majú jednoduché, dobre definované rozhrania a sú organizovaní prostredníctvom voľnej komunikácie, aby vykonávali požadovanú funkciu.

V SOA existujú 2 roly – poskytovateľ služieb a spotrebiteľ služby. Softvérový agent môže hrať obe úlohy. SOA nie je úplne nový koncept – tento článok sa však zameriava na SOA implementovanú pomocou webových služieb.

SOA je nová ikona pre niektoré veľmi staré nápady:

Rozdeľte svoj kód na opakovane použiteľné moduly.

Zahrňte do modulu akékoľvek rozhodnutie o dizajne, ktoré sa môže zmeniť.

Navrhnite svoje moduly tak, aby sa dali kombinovať rôzne cesty(niekedy nazývané „rodina“ alebo „produktový rad“).

To všetko sú princípy dizajnu softvér pre základ, z ktorých mnohé ako prvý sformuloval David Parnas.

Čo je nové v SOA

Urobíte to online.

Moduly komunikujú posielaním správ medzi sebou cez sieť, a nie prostredníctvom tradičnejších mechanizmov programovacieho jazyka, ako sú volania procedúr. Najmä v architektúre orientovanej na služby časti zvyčajne nezdieľajú premenlivý stav (globálne premenné v tradičnom programe). Alebo, ak zdieľajú stav, je tento stav starostlivo uzamknutý v databáze, ktorá je sama osebe agentom a ktorá môže jednoducho spravovať viacero simultánnych klientov.

Vidím veľa odpovedí, ktoré ešte viac vysvetľujú architektúru orientovanú na služby (SOA). Ťažké slová a technické výrazy. Rád by som to rozobral pre laikov pomocou analógie v jednoduchej angličtine.

Najprv však popis SOA
SOA môže byť opísaná v troch vrstvách, ako je znázornené na obrázku nižšie. Na jednej strane máme Poskytovateľa a na druhej strane Spotrebiteľa oddeleného Mostom, kde obe strany komunikujú.

Spotrebiteľ používa množstvo aplikácií potrebných pre daný podnik a poskytovateľ používa Komponenty, ktoré týmto aplikáciám poskytujú informácie. Komunikujú prostredníctvom súboru služieb pomocou spoločnej architektúry.

Analógia
Predstavte si dom na severe, ktorý je z veľkej časti súčasťou väčšej komunity, ako je mesto alebo mesto. Mesto má vlastné komplexné systémy na zabezpečenie vody a elektriny, čistenie kanalizácie, zabezpečenie dopravy a iné komunálne služby. Spotrebiteľom tohto modelu je domácnosť, dodávateľom je mesto (alebo obec) a potrubia, kanalizácia, elektrické vedenie, optické vlákna atď. je infraštruktúra, v ktorej komunikujú.

Tento model je možné voľne porovnávať so SOA. Ľudia v domácnosti využívajú mnoho rôznych „aplikácií“ ako radiátory, počítače, toalety, lampy, podlahové kúrenie, vane atď. Tieto aplikácie sa nestarajú o to, ako mesto v priebehu času vyrába vodu, elektrinu alebo ako s odpadom nakladá. Súčasťou mesta sú generátory, vodné čerpadlá a sociálne zariadenia. Všetky tieto potreby poskytuje domu, ale pristupuje k domu, aby ho využil, ako uzná za vhodné.

Dúfam, že to aspoň niekomu poskytlo lepší obraz o SOA.

Povedzme, že máte štyroch kuchárov. V SOA predpokladáte, že sa navzájom nenávidia, takže sa ich snažíte nechať rozprávať sa čo najmenej.

Ako to robíš? Najprv definujte úlohy a rozhranie – šéfkuchár 1 pripraví šalát, šéfkuchár 2 pripraví polievku, šéfkuchár 3 pripraví steak atď. Potom položíte riad dobre zorganizovaný na stôl (takže toto sú rozhrania) a poviete: "Všetci, prosím, umiestnite svoj výtvor do prideleného riadu. Nestarajte sa o nikoho iného."

Štyria šéfkuchári by sa teda mali medzi sebou rozprávať čo najmenej, čo je pri vývoji softvéru veľmi dobré – nie nevyhnutne preto, že sa navzájom nenávidia, ale z iných dôvodov, ako je fyzická poloha, efektívnosť rozhodovania atď.

To tiež znamená, že jedlá (služby) môžete prekombinovať podľa vlastného uváženia. Napríklad môžete jednoducho použiť dezert na obsluhu kaviarne alebo jednoducho vziať polievku a skombinovať ju s chlebom, ktorý ste si kúpili od inej spoločnosti, aby ste poskytli lacnejšie menu, alebo povoliť iným reštauráciám používať vaše šaláty v kombinácii s ich jedlami atď. d ..

Jeden z najviac úspešné implementácie SOA bola na Amazone. Vďaka svojmu dizajnu môžu prebaliť celú svoju infraštruktúru a predávať ju ako Amazon Web Service.

*Toto je len jeden aspekt SOA.

SOA je architektonický štýl, ale aj vízie o tom, ako by sa mala vyvíjať a integrovať heterogénna aplikácia. Hlavným cieľom SOA je pohnúť sa z monolitické aplikácie a namiesto toho súbor opakovane použiteľných služieb, ktoré je možné vytvoriť na vytváranie aplikácií.

IMHO má SOA zmysel iba na podnikovej úrovni a pre jednu aplikáciu neznamená nič.

V mnohých podnikoch malo každé oddelenie svoju vlastnú sadu podnikových aplikácií, čo znamenalo

Podobná funkcia bola implementovaná niekoľkokrát

Údaje (napríklad údaje o zákazníkoch alebo zamestnancoch) sa musia zdieľať vo viacerých aplikáciách

Aplikácie boli decentralizované.

Cieľom SOA je poskytovať opakovane použiteľné služby v rámci celého podniku, aby sa z nich dala zostaviť a zložiť aplikácia. SOA prísľub:

Nie je potrebné znovu a znovu definovať podobné funkcie (napríklad poskytovanie služieb klientom alebo zamestnancom)

Uľahčuje integráciu aplikácií a prístup k zdieľaným údajom alebo funkciám

• Rozvoj, úsilie orientované na podnikanie.

Na zobrazenie SOA potrebujete technologický posun tiež organizačné posun. Zatiaľ čo niektoré problémy rieši, iné aj prináša, napríklad bezpečnosť je pri SOA s monolitickou aplikáciou oveľa náročnejšia. O SOA sa teda diskutuje, či funguje alebo nie.

Toto je 1000 stopový pohľad SOA. Tým to však nekončí. Existujú ďalšie koncepty, ktoré dopĺňajú SOA, ako napríklad inžinierstvo podnikových procesov (BPM), podniková servisná zbernica (ESB), komplexné spracovanie udalostí (CEP) atď. Riešia problém IT/obchodná orientácia, čím môže IT efektívne podporiť podnikanie.

SOA je skratka pre Service Oriented Architecture.

SOA sa vyvíja a píše softvérové ​​aplikácie tak, že jednotlivé softvérové ​​moduly možno bez problémov integrovať s vysokým stupňom opätovného použitia.

Väčšina ľudí obmedzuje SOA na písanie softvéru klient/server do webových služieb. Ale toto je tiež malý kontext pre SOA. SOA je oveľa väčšia ako v posledných rokoch letného prechodu webových služieb, čo je pravdepodobne dôvod, prečo ľudia považujú SOA za webové služby vo všeobecnosti obmedzujúce rozsah a význam SOA.

Môžete zvážiť vytvorenie modulu prístupu k databáze, ktorý je taký nezávislý, že môže bežať samostatne bez akýchkoľvek závislostí. Tento modul môže odhaliť triedy, ktoré môže použiť akýkoľvek hostiteľský softvér, ktorý potrebuje prístup k databáze. V hostiteľskej aplikácii nie je žiadna konfigurácia spúšťania. Všetko potrebné alebo požadované prechádza cez triedy poskytované modulom prístupu k databáze. Tieto triedy môžeme nazvať ako služby a modul považovať za službu.

Prax SOA dáva vysoký stupeň opätovné použitie pomocou DRY, výsledkom čoho je vysoko udržiavateľný softvér. Udržiavanie vecí v chode je prvá vec, ktorú robí softvérová architektúra – SOA vám to dáva.

Ako som pochopil, základný koncept je, že vytvárate malé „služby“, ktoré poskytujú niečo užitočné pre iné systémy a nevytvárajú veľké systémy, ktoré zvyčajne robia všetko v rámci systému.

Takže definujete protokol, ktorý budete používať na komunikáciu (povedzme, že by to mohli byť webové služby SOAP) a necháte svoj systém, aby interagoval s malými službami, aby ste dosiahli svoje veľké ciele.

čo sa zvykne diať v veľké organizácie, je, že v priebehu času ide buď o monolitické systémy, rôznorodé systémy na celom mieste, alebo trochu z oboch. Niekto nakoniec príde a povie, že sme neporiadni. Teraz chcete spätne analyzovať (peniaze niekomu), všetko, čo chcete navigovať ako monolitické, závisí od toho, komu platíte paradigmu, ale zároveň budete môcť pridávať časti a časti bez ohľadu na predlohu/monolit.

Takže si kúpite Oracle SOA a Oracle sa stane šéfom všetkých vašich častí. Všetci ostatní hráči musia interagovať so SOA prostredníctvom služby (webovej služby alebo niečoho iného). O všetko sa stará Oracle monolit (monolit nemá byť hanlivý). Ach áno, na prednej strane máte ASP.NET MVC alebo čokoľvek iné.

kľúčom je presúvať veci do systému a zo systému bez akéhokoľvek dopadu a podporovať poskytovateľa Oracle SOA, Microsoft WCF, ako mozgy toho všetkého. všetko, čo má oop/ood rád, tekuté, veci, ktoré sa pohybujú dovnútra a von bez akéhokoľvek dopadu, dokonca aj ľudské služby, nielen počítače.

Pre mňa to znamená len množstvo webových služieb (alebo ako ich v budúcnosti nazveme) s pekným rozhraním. A ak máte databázu, stačí kliknúť na databázu a prestať sa trápiť slovami. Všetko je v poriadku.

z blogu ittoolbox.

Nasledujúci text popisuje podobnosti a rozdiely oproti predchádzajúcim metódam návrhu:

SOA a štruktúrované programovanie o Podobnosti: Väčšina je podobná volaniam podprogramu, kde sa odovzdávajú parametre a funkcia funkcie sa abstrahuje od volajúceho – napr. CICS a vykoná a vyhradené slovo COBOL CALL. Písanky sa používajú na definovanie dátovej štruktúry, ktorá sa zvyčajne definuje ako schéma XML pre služby. o Rozdiely: SOA je voľne prepojená, čo znamená, že zmeny v službe majú menší vplyv na spotrebiteľa („volajúceho“) a služby spolupracujú naprieč jazykmi a platformami.

SOA vs OOA/OOD o Podobnosti: zapuzdrenie, abstrakcia a definované rozhrania o Rozdiely: SOA je voľne spojená s hierarchiou tried alebo dedičnosťou, abstrakcie na nízkej úrovni – úroveň triedy a obchodné služby

SOA a starší vývoj riadený komponentmi (CBD) – napr. CORBA, DCOM, EJB o Podobnosti: Opätovné použitie prostredníctvom komponentov zostavy, rozhraní, vzdialených volaní o Rozdiely: Široké prijatie štandardov, schém XML a usporiadaných objektov, orchestrácia služieb, jednoduchšie opätovné použitie dizajnu, služby sú orientované na obchod a IT, obchodné služby sú konečne veľké (široký rozsah)

SOA (pre integráciu) vs. Integrácia podnikových aplikácií (EAI) o Podobnosti: osvedčené postupy(dobre definované rozhrania, štandardizované schémy, architektúra riadená udalosťami), opakovane použiteľné rozhrania, spoločné schémy o Rozdiely: štandardy, prijatie a vylepšené nástroje

No vidíš. SOA je skratka pre Service Oriented Architecture... Jednoducho povedané, napíšete kus kódu, ktorý je veľmi všeobecný, t.j. robí niečo, čo sa dá použiť v mnohých aplikáciách... môže to byť niečo ako adresár alebo kalkulačka. a tento kód spustíte v IIS. Takže poskytujete službu prostredníctvom svojho kódu. Ste teda poskytovateľom služieb. Teraz chce niekto použiť podobný kód, potom nemusí kód písať znova. Jednoducho používa váš kód, možno prostredníctvom webovej služby. V dôsledku toho sa stáva spotrebiteľom služieb. Preto sa vytvorenie programu pomocou takýchto služieb nazýva SOA. A bezplatná komunikácia existuje, pretože poskytovateľ služieb a spotrebiteľ môžu komunikovať, aj keď používajú rozdielne programovacie jazyky. Dúfam, že chápete.

Architektúra orientovaná na služby (SOA) – tento článok popisuje spôsoby, ako zdôvodniť efektivitu, ako aj možnosti jej implementácie s minimálnymi nákladmi.

Každé IT oddelenie sa zaoberá optimalizáciou svojich interných procesov a technológií s cieľom znížiť náklady a zvýšiť dopyt po IT v spoločnosti. Riadenie požiadaviek, zmien, incidentov a problémov – všetky tieto procesy slúžia ako objekty na optimalizáciu, ale prax ukázala, že na tom sa veľa ušetriť nedá.

Účinok optimalizácie procesov riadenia informačných technológií pre podnikanie je zanedbateľný: ak by sa náklady na IT znížili o 5 %, a celková suma náklady firmy sú len 2 %, potom je celkový efekt optimalizácie 0,1 %. Dosiahnuté výsledky neprinášajú na úrovni biznisu očakávaný efekt, preto je nadšenie IT špecialistov často sprevádzané sklamaním.

Efekt využitia servisne orientovanej architektúry (SOA) pri budovaní IT riešenia môže byť oveľa výraznejší, keďže výhody SOA nespočívajú ani tak v krátkodobom znižovaní nákladov, ale v zvýšení adaptability informačných systémov a celej spoločnosti. ako celok. Adaptabilita je dnes veľmi dôležitou kvalitou, strategickou prioritou. Z dlhodobejšieho hľadiska, v strategickom horizonte, umožňuje využitie SOA aj optimalizovať náklady na IT vývoj vo firme o väčšie percento ako optimalizácia procesov IT oddelenia. Vynára sa však otázka: ako pomôcť firme využiť výhody implementácie SOA.

Každý projekt, vrátane projektu vývoja IT, keď je zahrnutý do obchodného plánu, sa teraz posudzuje z hľadiska návratnosti investícií (ROI). Vo všeobecnosti sa ROI vypočítava odhadom nákladov potrebných na vývoj nového riešenia, potom sa odhadne hodnota tohto riešenia z hľadiska efektívnosti a efektívnosti a času, ktorý novému riešeniu potrvá, kým vygeneruje príjmy alebo dosiahne úspory nákladov.

Tento algoritmus si napriek svojej zjavnej jednoduchosti vyžaduje podrobnú analýzu a posúdenie výhod používania SOA. Najdôležitejšie z nich:

• predĺženie životnosti existujúcich IT aplikácií, t.j. zachovanie existujúcich investícií do IT;
• poskytuje flexibilitu pri rýchlom vývoji nových aplikácií. Nerobí sa to písaním kódu, ale vytváraním nových riešení z existujúcich aktív. Toto je nová paradigma vývoja softvéru;
• typizácia a opätovné použitie IT komponentov, čo znižuje náklady na vývoj nových a podporu existujúcich IT riešení.

Pre výpočet ROI je potrebné tieto benefity kvantifikovať vhodnými ukazovateľmi a prostredníctvom nich sledovať ekonomickú efektívnosť využívania SOA počas celého projektu. Preto je pri implementácii SOA dôležité analyzovať výhody získané od prvých krokov, ktoré pomôžu získať schválenie a financovanie zo strany podniku.
Podľa odborníkov z Aberdeen Group očakávajú najväčšie svetové spoločnosti do piatich rokov vďaka implementácii SOA úsporu až 53 biliónov dolárov.

Servisne orientovaná architektúra – taktika implementácie

IT prostredia v mnohých spoločnostiach sa formovali počas dlhého obdobia, takže majú úzke miesta, pokiaľ ide o podporu a údržbu používaných aplikácií. Ich rozlúštenie si vyžaduje schopnosť riadiť náklady a riziká spojené s pokračovaním v používaní starších aplikácií v budúcnosti. Časté zmeny v obchodných požiadavkách však nútia tieto aplikácie integrovať s inými systémami a vytvoriť tak jediné IT riešenie. Ak predtým mnohí CIO dúfali, že nahradia staré systémy jedinou „škatuľovou“ aplikáciou, a tým vyriešia väčšinu problémov, teraz si mnohí z nich už nerobia žiadne ilúzie. Predstavte si, že sa rozhodnete vypnúť svoj starý systém a myslíte si, že nasledujúce ráno nový systém bude fungovať úplne rovnako. Povedzme, že sa vám to aj podarilo, no budúci mesiac bude potrebné zautomatizovať niekoľko ďalších procesov, čo si opäť vyžiada poriadne rozšírenie existujúceho IT riešenia výmenou ďalšej aplikácie.

Takéto časté výmeny môžu spoločnosť stáť veľké peniaze, a CIO má kariéru, takže sa musíte na existujúcu oblasť IT pozerať z pragmatického hľadiska. Čokoľvek iné môže slúžiť, nech slúži a Najlepšia cesta prechod z existujúceho IT prostredia na cieľový (založený na SOA) je rozčlenenie aplikácií na samostatné služby s jasne definovanými rozhraniami, ktoré vám umožnia naplánovať každú fázu prechodu. Výsledkom je adaptívne IT riešenie, ktorého hlavnými nákladmi je údržba, určenie hodnoty každého komponentu a rozhodnutie o jeho budúcom osude.

Akonáhle je aplikácia rozdelená na komponenty, agilnosť systému sa stáva zreteľnejšou, čo sa premieta do rýchlejších zmien v IT riešení. Vytvorením zloženej aplikácie založenej na SOA spoločnosť získa určitú flexibilitu pri rozhodovaní o tom, ako a kam sa pohnúť vpred, bez toho, aby bola viazaná vybranými IT platformami a starými informačnými systémami. Zároveň sa delená aplikácia ľahšie udržiava alebo v prípade potreby vymieňa. Toto oddelenie na jednotlivé komponenty pomáha zlepšovať kvalitu informačného systému ako celku, keďže závislosti medzi komponentmi sa stávajú jasnejšie a dosah zmien je predvídateľný.
Hmatateľné výhody modernizácie a integrácie aplikácií v súlade s princípmi SOA sú teda:
kontrolované náklady pri zmene funkčnosti informačných systémov;
skrátenie času potrebného na prispôsobenie zložitých informačných systémov neustále sa meniacim obchodným procesom spoločnosti;
systematizácia komponentov IT architektúry a zvýšenie stupňa integrácie informačných systémov spoločnosti;
rýchle výsledky pri automatizácii nových funkčných oblastí;
zníženie nákladov na podporu informačného systému prostredníctvom unifikácie komponentov.
Tieto ciele nie sú také protichodné, ako by sa na prvý pohľad mohlo zdať, a odrážajú prirodzenú túžbu podniku mať efektívnu IT podporu, t.j. transparentné, flexibilné a spoľahlivé informačné systémy, v ktorých je možné okamžite vykonávať zmeny.

Servisne orientovaná architektúra – stratégia implementácie

Prvým efektom implementácie princípov SOA je zvýšenie rýchlosti vývoja novej funkcionality. To sa však nestane samo o sebe, pokiaľ nevyviniete vhodnú stratégiu nasadenia SOA a striktne ju nevykonáte. Cieľom by malo byť vytvorenie konzistentného prístupu s dôrazom na interoperabilitu a opätovné použitie služieb.

Stratégia nasadenia SOA by mala ponúkať aj organizačné stimuly, ako napríklad propagovanie výhod SOA prostredníctvom školení a stimulov. Schopnosť motivovať dokáže zabezpečiť úspech implementácie SOA bez podpory zhora – metódou zdola nahor. Prvou skupinou, ktorej treba venovať pozornosť, sú poskytovatelia služieb. V spoločnosti, ktorá je zvyknutá vyvíjať požadovanú funkcionalitu formou samostatných aplikácií, sa môžu zamestnanci prechodu na služby brániť. Výhody práce so službami pre nich nie sú zrejmé a jednoducho sa nechcú viazať ďalšou zodpovednosťou, takže motivácia je nevyhnutná. Druhou skupinou sú spotrebitelia služieb. Myšlienku využívania služieb od iných poskytovateľov alebo ich viazanie interne môžu spotrebitelia vnímať ako hrozbu, že ich požiadavky nebudú primerane zohľadnené.

Motivačný systém by mal obsahovať tieto základné princípy:

• čím viac štandardných služieb sa vytvorí, tým lepšie pre projekt a tým vyššia produktivita vývojára;
• tí, ktorí najviac využívajú štandardné služby znižujúce náklady, by mali byť odmenení;
• poskytovateľ služieb by mal byť odmenený za využívanie jeho služieb;
• Líder SOA je ten, kto produkuje službu, ktorú spotrebitelia najčastejšie používajú.

Preto je potrebné prijať koncept hodnoty služby. So správnymi stimulmi môže spoločnosť začať riadiť prijatie SOA zvnútra, namiesto toho, aby ju poháňala zhora. Je tiež dôležité pravidelne merať úspešnosť nasadenia vašej stratégie SOA prostredníctvom kvantitatívnych metrík.

V praxi je už preukázané, že vytváranie kompozitných riešení vybudovaním infraštruktúry na báze SOA vedie k skráteniu času vývoja produktu, ako aj k zvýšeniu adaptability IT riešenia. Čím skôr tieto informácie predložíte firme, tým väčšia je šanca na úspech.

Servisne orientovaná architektúra a technológie BPM, ESB

Architektúra orientovaná na služby – aké technológie sú potrebné na implementáciu? V prvom rade nástroj na modelovanie obchodných procesov, ktorý vám umožní popísať procesy, informačné systémy a dáta. Takouto formalizáciou, realizovanou na základe jasnej metodiky popisu podnikových procesov, je možné ich previesť do spustiteľného kódu a výrazne skrátiť čas na automatizáciu a zmeny procesov, na rozdiel od tradičných metód vývoja.

Implementácia SOA nie je možná bez technológie Business Process Management (BPM), ktorá vám pomôže rýchlo vybudovať nové automatizované procesy zohľadňujúce existujúce služby. Kombinácia princípov SOA s technológiou BPM a systémom BPM zaisťuje konzistentnosť vykonávania procesov bez toho, aby bola striktne viazaná na kódovanie. Systém BPM zase umožňuje určiť rozsah použitia komponentov a potrebu ich typizácie.

Ďalej, pri implementácii SOA budete potrebovať súpravu nástrojov SOA Governance – knižnicu zjednotených služieb, ktorá bude poskytovať všeobecný prístup komponentom zloženého prostredia na ich opätovné použitie. SOA musí byť podporovaná aj špecifickými integračnými nástrojmi (Enterprise Service Bus, ESB), navrhnutými na integráciu rôznych IT zdrojov a zefektívnenie výmeny dát pomocou servisnej zbernice. A hoci v zásade môže byť SOA postavená bez ESB, podľa väčšiny analytikov je to práve integračná zbernica, ktorá slúži ako kľúčové riešenie pre architektúru orientovanú na služby.

A. Koptelov
Vedúci praxe implementácie obchodných aplikácií IDS Scheer Rusko a krajiny SNŠ