Návrh distribuovaných systémů a webových služeb. Recenze technologie webových služeb. Správa služeb a aplikací
V tomto článku bych se rád věnoval otázkám souvisejícím s návrhem webových služeb určených pro meziprogramovou interakci. Takzvané integrační webové služby. V prvé řadě se jedná o služby, které budou fungovat v různých řešeních třídy Enterprise Applications Integration (EAI) i v B2B řešeních. Mnoho knih a článků je věnováno problematice vývoje webových služeb pomocí různých platforem, ale problematice designu se věnuje mnohem méně. Na téma SOA můžete najít spoustu článků s mantrami, které vám budou úplně k ničemu, když se pustíte do návrhu vaší webové služby.
Vezměme si tedy situaci, kdy máte dva fungující systémy (nebo projekty dvou systémů) a stojíte před úkolem zorganizovat interakci mezi nimi. Už vás nebaví synchronizační schémata založená na importu/exportu souborů a zvolili jste módní, moderní a pohodlnou technologii webových služeb. Pokusím se pohovořit o tom, na co si dát pozor a jak se vyhnout častým chybám při návrhu webové služby pro interakci dvou systémů.
Trochu SOA
A přesto nejprve pár slov o známé SOA. Termín Service Oriented Architecture (SOA) dosti utrpěl nevybíravým používáním pro marketingové účely. Používá se tak často v různých kontextech, že je nyní obtížné říci o SOA něco jiného než to, že se jedná o „architekturu orientovanou na služby“.SOA má však stejné právo na život jako „architektura klient-server“ nebo „vícevrstvá architektura“. Jako každá jiná „architektura“ i SOA zavádí řadu abstrakcí a pravidel, která nám pomáhají při vývoji určité třídy aplikací. V tomto konkrétním případě je užitečné řídit se principy SOA při vývoji mechanismů pro interakci a integraci aplikací napříč podnikem (Enterprise Applications Integration - EAI).
Začněme tedy tím, že SOA považuje aplikace za služby nebo kolekce služeb, které si vyměňují zprávy přímo nebo prostřednictvím některých integračních mechanismů. Tyto služby musí splňovat řadu podmínek nebo požadavků.
Za prvé, služba musí mít určitou „obchodní hodnotu“, jinými slovy, služba musí mít praktickou hodnotu. Pokud nedokážete jednoduchými slovy vysvětlit zákazníkovi nebo uživateli systému, k čemu je vaše služba potřebná, pak je to z pohledu SOA neúspěšná služba. Příklad špatné služby: „Služba pro získávání globálně jedinečných identifikátorů.“ Příklad dobrých služeb: „Služba pro data o zaměstnancích podniku“ nebo „Služba pro příjem a zpracování faktur k platbě“ (Závazky).
Za druhé, z pohledu SOA musí být služby autonomní a nezávislé. To je nutné, abychom, jak je v SOA zvykem, mohli kombinovat některé služby s jinými v závislosti na obchodních potřebách. Pokud bychom chtěli využít „Službu pro příjem a zpracování splatných faktur“ a zároveň zjistíme, že budeme muset nainstalovat a používat „Službu Rozpočtování a finanční plánování“, „Službu Hlavní kniha“ a tucet dalších služby, pak z pohledu SOA vše jen vypadá hnusně.
Za třetí, služba musí být z aplikačního hlediska funkčně kompletní. Tento požadavek je doplňkový k předchozímu. Například „Služba pro příjem a zpracování faktur k platbě“ vám umožňuje přidat aplikaci, ale neumožňuje sledovat její stav. V zásadě ale můžeme získat report o aplikacích, ze kterého se dozvíme o stavu aplikace. Není to známá situace? Z hlediska SOA az jakéhokoli pohledu to není správné. Služba musí zajistit provedení všech základních obchodních operací spojených s aplikační oblastí nebo obchodním procesem, který poskytuje.
Za čtvrté, všechny služby musí být schopny poskytovat svůj popis v nějakém standardizovaném formátu. WSDL a UDDI jsou varianty formátů popisu služby.
Za páté, služby by měly být orientovány na distribuovanou, bezstavovou a asynchronní komunikaci. To je typické pro většinu moderních distribuované systémy a to je velmi důležitý požadavek. Stačí si připomenout, že architektura klient-server je zaměřena na synchronní interakci se stavovým úložištěm a je to právě tato okolnost, která se stala klíčové omezení pro další rozvoj této architektury.
Za šesté, SOA předpokládá, že po splnění předchozích požadavků se služby budou moci kombinovat a vzájemně ovlivňovat pomocí různých integračních nástrojů, jako jsou zprostředkovatelé zpráv a směrovače, servery pracovních postupů atd. atd. Klíčovým bodem je zde skutečnost, že integrační scénáře budou založeny na konfiguraci, často vizuální, spíše než na vývoji speciálního „integračního“ kódu, jak je tomu ve většině případů nyní.
Zhruba takto vypadají hlavní milníky, na které bychom se měli zaměřit a které by měly omezit naše divoké designové myšlenky v procesu navrhování a vývoje integračních webových služeb.
Návrh servisní smlouvy.
Poté, co Microsoft použil termín „servisní smlouva“ ve své platformě Windows Communication Foundation – WCF (dříve Indigo), má všechny šance stát se de facto standardním pojmem.Servisní smlouva je popis podpisů všech jejích operací (metod) plus popis datových formátů, které provozuje jako vstupní a výstupní zprávy.
U webových služeb je smlouva komplexně popsána schématem služby WSDL. Souhlasíte však s tím, že WSDL není příliš dobře přizpůsobeno lidskému vnímání. Smlouvu lze mnohem jasněji zobrazit jako diagram tříd UML. Naštěstí většina moderní platformy pro vývoj webových služeb poskytují funkci pro automatické generování WSDL popisů služeb.
Správně navržená servisní smlouva je klíčem k úspěchu a zárukou, že vaše služba bude žít dlouhý a šťastný život a zemře přirozenou smrtí, protože bude nahrazena novou technologií, o které v současné době nic nevíme.
Společnost Microsoft nabízí speciální termín „smlouva nejprve“ k popisu přístupu k návrhu na základě smlouvy. Navrhuje, aby návrh služby začínal popisem XSD schémata zpráv (dat), následně je vytvořen WSDL popis servisních operací, podle kterého je vygenerován kód servisní třídy. A teprve poté začnou implementovat logiku. Myšlenka je správná, nicméně zopakuji, že práce s XSD a WSDL není příliš pohodlná, a to ani pomocí vizuálních nástrojů, jako je XmlSpy. Navíc samotný princip „kontaktujte nejdříve“ nezaručuje, že obdržíme správnou servisní smlouvu.
Princip „kontakt jako první“ pro mě znamená, že při navrhování služby bychom měli myslet nejprve na její smlouvu a až na poslední detaily implementace. Na budoucí službu byste se měli dívat zvenčí, očima spotřebitele dat této služby. Tento pohled zjednodušuje transpozici požadavků na službu do souboru operací, které poskytuje. Vyvíjíme například službu, která poskytuje data o zaměstnancích společnosti. Logické je do něj zařadit operaci, která vrací seznam všech zaměstnanců. Při analýze požadavků se však může ukázat, že spotřebitele našich servisních údajů bude zajímat především seznam zaměstnanců konkrétního oddělení. To nám říká, že bychom měli do smlouvy provozu přidat parametr, který vrátí seznam zaměstnanců, který nám umožní odfiltrovat zaměstnance konkrétního oddělení, nebo bychom měli tuto akci oddělit do samostatné servisní operace. Tento přístup bude v souladu se zásadou „smlouva nejprve“. Naopak bychom mohli přidělit spotřebiteli našich servisních dat odpovědnost za výběr zaměstnanců oddělení, které potřebuje z obecného seznamu. Držet se takové strategie při navrhování integračních služeb je špatný postup. Při analýze tohoto konkrétního případu lze říci, že takové řešení není optimální z hlediska zatížení služby nebo objemu provozu a také že takové řešení snižuje bezpečnost. Shrneme-li, můžeme říci, že při návrhu služby by neměly převládat principy jednoduchosti a univerzálnosti. Všestrannosti služby musí být dosaženo pečlivým návrhem. Dát v tomto směru nějaká praktická doporučení je nesmírně obtížné. Není jednoduché vytvořit službu, která by se neskládala z jedné metody, která vysype všechna interní data systému ven, a zároveň by byla dostatečně univerzální, aby ji mohl využívat nejen spotřebitel, pro kterého jste navrhli službou, ale i kýmkoli jiným. Abyste toho dosáhli, měli byste věnovat pozornost funkční úplnosti servisní smlouvy.
Podívejme se na příklad. Předpokládejme, že existuje určitý systém pro účtování a odsouhlasení závazků z kategorie těch, které jsou označeny pojmem závazky. Systém umožňuje zadávat fakturační údaje, zajišťuje obchodní proces pro jejich odsouhlasení a následně spolupracuje s účetním systémem za účelem generování plateb. Faktury se zadávají a schvalují prostřednictvím uživatelského rozhraní systému. Stojíme před úkolem: vytvořit webovou službu, jejímž prostřednictvím by ostatní systémy mohly vytvářet faktury a sledovat jejich stav.
Pro zjednodušení budeme předpokládat, že splatná faktura má následující strukturu:
Kde:
číslo - jedinečné čísloúčet přiřazený při vytvoření
RecipientID – odkaz na adresář protistran, kde jsou uloženy všechny údaje o příjemci platby
Částka – částka k úhradě
PaymentDate – datum platby
CategoryID – odkaz na adresář kategorií plateb
Vlastník – jméno zaměstnance, který účet vytvořil
Popis – popis
Stav – stav účtu, na kterém je postaven obchodní proces schvalování faktur.
Prvotní požadavky jsou nám tedy jasné. Přehledné je i datové schéma pro předložení faktury. Na základě prezentovaného diagramu bude vytvořeno následující XML schéma, které nám docela vyhovuje:
Nyní se pokusíme načrtnout signaturu servisních metod. Na základě požadavků je nám jasné, že služba musí obsahovat metody, které umožňují vytvářet, prohlížet a mazat faktury k platbě. Výsledkem je služba se třemi metodami:
Vypadá to prostě strašně! Pojďme zjistit, co je tady špatně.
Metoda AddPayment() pro přidání účtu bere jako parametr strukturu platby a vrací číslo přiřazené účtu. Platební struktura není pro parametr této metody příliš vhodným datovým typem, protože obsahuje řadu polí, jejichž vyplnění podléhá vnitřní obchodní logice systému. Jedná se o pole Číslo, Stát a Vlastník. Neznáme tato obchodní pravidla a nevíme, jak tato pole vyplnit. Pro vytvoření faktury musíme zadat: příjemce, částku platby, datum, kategorii a popis. Proto má smysl vytvořit metodu přesně s těmito parametry, která vytvoří fakturu k platbě a vrátí ji ve struktuře Platba.
Metoda ListPayments() vrací seznam účtů jako pole platebních struktur. Možná by měl systém vracet pouze faktury, které vytvořil daný uživatel. Absence odpovídajícího parametru v podpisu metody by vás však neměla překvapit. Spolehlivější a bezpečnější způsob, jak získat uživatelská data, je převzít je z autentizačních dat. Postupem času se v systému může nahromadit obrovské množství faktur a tato metoda Bylo by hezké mít nějaké možnosti filtrování seznamu podle data.
Nakonec metoda RemovePayment() vezme číslo účtu a vrátí hodnotu true, pokud bylo odstranění úspěšné, a v opačném případě vrací hodnotu false. Použití Boolean jako výsledku není v tomto případě nejlepší řešení. Důvody neúspěchu operace odstranění mohou být velmi odlišné od prosté absence účtu se zadaným číslem až po porušení logických omezení systému (například účet se stavem Committed nelze smazat). Situace je celkem běžná. Při provádění jakékoli metody webové služby může dojít k chybě a naštěstí framework webových služeb nabízí standardní přístup k řešení tohoto problému. Pro přenos chybových dat slouží SOAP zpráva, jejíž tělo obsahuje prvek Fault s informací o chybě. Díky tomu nemusíme prodlužovat naši smlouvu o poskytování webových služeb, abychom předávali chybové zprávy a v případě metody RemovePayment() se můžeme zcela obejít bez návratové hodnoty. Pokud se smazání účtu nezdaří, informace o důvodu se zobrazí v chybové zprávě.
Po všech změnách bude naše webová služba vypadat takto:
Vypadá to mnohem lépe, ale problémy přetrvávají.
Podívejme se na metodu CreatePayment(). Abychom mohli vytvořit účet, musíme předat pět parametrů. Nemáme problémy s parametry množství, datum, popis. Kde ale získáte odkazy na příjemce (příjemce) a kategorii (kategorii)? Jak jsem již uvedl, tato data jsou odkazy na prvky odpovídajících adresářů našeho systému. A nyní je nám jasné, že abychom mohli úspěšně používat naši webovou službu, musíme poskytnout přístup k hodnotám těchto adresářů.
Finální podoba naší smlouvy o poskytování webových služeb tak byla doplněna o dvě metody EnumRecipient() a EnumCategory() a dva datové typy RecipientInfo a CategoryInfo. V původní smlouvě nebyly a potřeba těchto metod není určena původními požadavky. Slouží k zajištění syntaktické úplnosti naší servisní smlouvy. Spotřebitel dat služeb nyní může volat metody EnumRecipient() a EnumCategory() a získat seznamy příjemců a kategorií, vybrat z nich požadované hodnoty a poté zavolat metodu CreatePayment() k vytvoření faktury.
Nyní můžeme říci, že jsme navrhli funkčně a syntakticky kompletní službu. Naše služba je navíc poměrně univerzální as vysokou pravděpodobností ji lze využít pro integraci s jinými systémy, které budou čelit podobným úkolům. Servisní smlouva a její popis WSDL navíc zahrnují kompletní datová schémata pro všechny zprávy. To je velmi důležité, aby naše služba mohla používat integrační nástroje, jako je BizTalk Server, Fiorano ESB, Sonic ESB atd.
Rád bych upozornil na poslední bod. Formát dat vyměňovaných službou je velmi důležitý. Vývojáři často spadají do jednoho ze dvou extrémů. První z nich je použití „nahého Xml“ jako formátu pro všechny zprávy. Důvody pro to mohou být velmi odlišné, od pokusů o použití existující kód import - export Xml dat, k příliš doslovnému chápání podstaty webových služeb jako mechanismu pro výměnu Xml zpráv. Nevýhoda tohoto přístupu je zcela zřejmá – datové schéma není zahrnuto v popisu WSDL servisní smlouvy, což ztěžuje použití. Podle mého názoru existuje pouze jeden případ, kdy je takový přístup oprávněný. To je případ, kdy předem neznáme formát přenášených dat. Ve všech ostatních případech by měly být použity psané zprávy.
Druhý extrém je opakem prvního a je vyjádřen tím, že se vývojáři snaží v servisní smlouvě využít interní formáty reprezentace dat existující v systému. Skutečně, pokud systém již definuje struktury a třídy pro reprezentaci dat (objekty přenosu dat), tak proč je nepoužít ve smlouvě o poskytování služeb? To není vždy dobrý nápad. Interní datové formáty nemusí být pro klienta služby vhodné. Mohou mít specifický formát, který není podporován na straně klienta. Příklad takového formátu DataSet z Microsoft ADO.NET. Data DataSet jsou dokonale převedena do XML a mohou být používána webovými službami ASP.NET. Jedná se však o interní formát společnosti Microsoft, který není průmyslovým standardem, má své vlastní funkce formátování XML, které mohou jiným softwarovým platformám webových služeb ztěžovat použití těchto dat. Existuje mnoho případů, kdy je použití DataSet oprávněné a pohodlné, ale integrační služby mezi ně nepatří.
Tedy, obecná doporučení pro navrhování formátů zpráv pro webové služby jsou následující. Vždy se snažte používat psané zprávy, jejichž formát je popsán konkrétním schématem Xsd. Navrhněte formát zprávy na základě funkčních požadavků a pouze v případě, že výsledný formát odpovídá internímu formátu dat systému, zvažte použití interního formátu.
Interakční protokol a jeho dopad na smlouvu
Interakčním protokolem webové služby rozumíme tu část požadavků, která popisuje posloupnost interakce mezi službou a klientem, směr přenosu dat a také takové aspekty chování služby, jako je transakčnost, asynchronnost atd. .Interakční protokol a servisní smlouva spolu velmi úzce souvisí. Kromě celkem jednoduchých případů, kdy existuje jedna služba a její klient, existují i složitější případy, kdy interakční protokol vyžaduje přítomnost dvou nebo více služeb. Příkladem takového protokolu je asynchronní komunikační protokol ASAP
Nebudu prozrazovat mnoho tajemství, když řeknu, že skvělým způsobem, jak vybudovat servisní kontrakt (alespoň co se týká operací, které s tím souvisí), je použití diagramů interakce UML. Můj osobní názor je, že nejlepších výsledků dosáhnete pomocí sekvenčního diagramu. Obrázek ukazuje Sekvenční diagram interakce mezi klientem a službou z výše uvedeného příkladu AccountsPayable. Bohužel je tento příklad dostatečně jednoduchý na to, abyste získali představu o tom, jak sekvenční diagramy usnadňují navrhování servisní smlouvy.
V nejsložitějších případech může být nutné sestrojit stavový diagram pro interakční protokol. V tomto případě budou přechody ve stavovém grafu představovat servisní operace.
Bezpečnostní problémy
Poté, co byla vypracována servisní smlouva, a někdy i dříve, projektant plná výška vznikají bezpečnostní problémy. Časy, kdy byly webové služby označovány za nevyspělou technologii, která nedokázala zajistit bezpečnost dat, jsou dávno pryč. Webové služby mohou být spolehlivé a bezpečné. Nebo nemusí. Vše záleží na nás.Pojďme si nastínit okruh problémů, které je třeba vyřešit, abychom mohli navrhnout zabezpečenou službu:
- Autentizace klientů služby
- Autorizace klientů služby
- Zabezpečení přenosu dat
- Ukládání identit pro připojení klientů ke službě
Autorizace je proces udělení oprávnění uživateli pro přístup k funkcím a datům. Přirozeně, aby uživatel mohl autorizovat, musí být nejprve autentizován. Pochopte rozdíl mezi autentizací a autorizací. Autentizace odpovídá na otázku „kdo“ klient je a autorizace odpovídá na otázku „co“ tento klient může dělat. V naprosté většině případů jsou obchodní pravidla, kterými jsou konkrétnímu uživateli udělena přístupová práva k určitým datům a operacím, definována v samotné aplikaci. A proto je autorizace odpovědností aplikace poskytující službu. Existuje mnoho metod, praktik a vzorů pro implementaci autorizačních mechanismů, jejichž popis by mohl být předmětem samostatného článku.
Kromě autentizace a autorizace je ochrana dat při jejich přenosu mezi službou a jejím klientem třetí složkou zajištění bezpečnosti webové služby. Stupeň ochrany je dán povahou dat. Existují dva způsoby ochrany dat: digitální podpis a šifrování.
K potvrzení pravosti dat se používá digitální podpis. Nechrání data před neoprávněným čtením, protože data nejsou šifrována. Digitální podpis umožňuje ověřit, že data patří vlastníkovi podpisu a také, že data nebyla od podpisu změněna. Mechanismus digitálního podpisu je poměrně jednoduchý. Je založen na použití asymetrických šifrovacích algoritmů, které využívají dvojici klíčů, z nichž jeden je soukromý (uzavřený) a druhý veřejný (otevřený). Zvláštností asymetrických algoritmů je, že data, která jsou zašifrována jedním klíčem, lze dešifrovat pouze jiným klíčem. Digitální podpis je vytvořen následovně. Pro data je vypočítán kontrolní součet (hash kód), který je zašifrován soukromým klíčem vlastníka digitálního podpisu. Jedná se o digitální podpis, který je přidán k datům. K datům lze také přidat veřejný klíč. Pomocí veřejný klíč, může každý uživatel dešifrovat digitální podpis a získat kontrolní součet, se kterým lze porovnat kontrolní součet vypočítat na aktuální data a tím zjistit, zda se data změnila.
V případech, kdy potřebujeme nejen zajistit neměnnost dat, ale také skrýt jejich obsah před cizinci, se používá šifrování. Obvykle se při přenosu dat používá schéma klíče relace, jehož mechanismem se nebudu zdržovat, protože je obvykle poskytován na úrovni infrastruktury. Digitální podpis a šifrování jsou tedy hlavními mechanismy ochrany dat během přenosu. Tyto mechanismy můžeme povolit na úrovni transportního protokolu nebo na úrovni zpráv SOAP. Každá metoda má své výhody a nevýhody.
Pro zajištění ochrany dat na úrovni transportního protokolu se obvykle používá osvědčený mechanismus SSL. V tomto případě je mezi klientem a serverem navázáno zabezpečené spojení, ve kterém je veškerý provoz šifrován. Výhodou tohoto přístupu je, že nevyžaduje prakticky žádné další úsilí ze strany vývojáře (snad s výjimkou některých funkcí při navazování spojení). Hlavní práce spočívající v nastavení zabezpečeného připojení SSL se provádí při nasazení aplikace. Nevýhody tohoto přístupu zahrnují skutečnost, že veškerý provoz je šifrován, nejen data, která jsou skutečně důvěrná, a to vyžaduje mnoho výpočetních zdrojů. Popis, jak používat SSL ve spojení s webovými službami ASP.NET 1.1, lze nalézt v mém článku na http://stump-workshop.blogspot.com/2006/10/web-https-ssl.html
Mechanismy ochrany dat na úrovni zpráv SOAP jsou založeny na použití rozšíření protokolu SOAP, jako jsou WS-SecureConversation, WS-Trust, WS-SecurityPolicy a WS-Security. Podpora těchto specifikací je obvykle zabudována na úrovni platformy, která implementuje webové služby, a jsou vývojáři k dispozici jak na deklarativní úrovni (atributy nebo konfigurace), tak jako API. Mezi výhody použití těchto mechanismů patří jejich flexibilita a všestrannost. Můžete použít jak šifrování, tak digitální podpis. Je možné chránit pouze zprávy jednotlivých servisních operací a dokonce i jednotlivé části zprávy SOAP. Bohužel ne všechny platformy webových služeb plně podporují tyto specifikace. Například široce používaný .NET Framework 1.1 nepodporuje WS-Security. Proto při používání této platformy budete muset implementovat ochranu na úrovni transportu.
Konečně je tu ještě třetí způsob – implementovat vlastní ochranný mechanismus, jak je například popsáno. Měli byste však pochopit, že tato cesta prudce snižuje možnosti využití vaší služby.
Na závěr stojí za to se pozastavit nad otázkou ukládání přihlašovacích údajů pro připojení k webovým službám. Již jsme řekli, že přístup k webovým službám by měl být poskytován pouze ověřeným uživatelům. Druhou stranou mince je, že musíme zadat přihlašovací údaje, když se klient připojí ke službě. A proto musíme tyto přihlašovací údaje někde uložit. Když náš systém musí interagovat s několika službami, z nichž každá vyžaduje svou vlastní identitu, problém se stává obzvláště akutním.
Co jsou certifikáty? Ve většině případů se jedná o dvojici hodnot: login - password. Někdy to může být klientský certifikát nebo jiný typ pověření v závislosti na použitém ověřovacím protokolu. Mělo by být jasné, že identity klientů odkazují na data, která mohou být použita k útoku na systém útočníkem. Proto tato data vyžadují ochranu. Tuto skutečnost byste měli vzít v úvahu ve fázi návrhu. Při implementaci integračních webových služeb budete pravděpodobně muset vynaložit určité úsilí na vývoj mechanismů pro bezpečné ukládání klientských identit a jejich konfiguraci/úpravu.
Problémy s implementací
Problémy s implementací webových služeb silně závisí na platformě, se kterou pracujete, a dnes jich existuje velké množství. Pouze Microsoft nabízí 4 platformy (ASP.NET 1.1, ASP.NET 2.0, WSE 1.0-3.0, WCF-Indigo). Ve světě Java je jich ještě více. Proto je velmi obtížné dávat konkrétní doporučení. Existují však body, na které byste měli v každém případě věnovat pozornost.Většina platforem se stará o generování WSDL popisu služby, což dává vývojáři možnost pracovat se službou jako s běžnou třídou. Proto je třeba věnovat neustálou pozornost těm detailům, které ovlivňují tvorbu správných popisů WSDL a datových schémat XSD. Tyto věci zahrnují používání jmenného prostoru a předpon Xml, řízení pořadí serializace dat a pořadí a styl generování WSDL.
Měli byste se pokusit oddělit obchodní logiku od implementace služby. Je dobré, když můžete použít jedinou obchodní logiku uvnitř aplikace a ve webové službě. V ideálním případě budou metody vaší webové služby postrádat jakoukoli jinou logiku než kontrolu parametrů, generování výsledků a zpracování chyb, jak je znázorněno na obrázku:
Závěr
V tomto článku jsme tedy zkoumali řadu problémů souvisejících s návrhem integračních webových služeb.Zastavili jsme se u obecné zásady SOA koncepty. Zvažovali jsme praktické otázky návrhu servisní smlouvy, zajištění její funkční a syntaktické úplnosti. Pozornost jsme věnovali vlivu interakčního protokolu na servisní smlouvu. Zvažovali jsme možnosti řešení bezpečnostních problémů webových služeb. A nakonec jsme se rozhodli pro některé praktické aspekty designu. Doufám, že vám tento článek bude užitečný při navrhování integračních webových služeb.
Zavolejme servis zdroj, který implementuje obchodní funkci a má následující vlastnosti:
je opakovaně použitelný;
definované jedním nebo více explicitními rozhraními nezávislými na technologii;
je volně propojen s jinými podobnými zdroji a lze jej vyvolat prostřednictvím komunikačních protokolů, které umožňují zdrojům vzájemnou interakci.
Webová služba nazývá se softwarový systém identifikovaný řetězcem URI, jehož rozhraní a vazby definuje a popisuje XML. Popis tohoto softwarového systému lze nalézt u jiných softwarových systémů, které s ním mohou interagovat podle tohoto popisu prostřednictvím zpráv na bázi XML přenášených pomocí internetových protokolů.
1.1 Základy webových služeb
Webové služby je nová slibná architektura, která poskytuje nová úroveň rozdělení. Namísto vývoje nebo nákupu komponent a jejich zabudování do IS se navrhuje koupit jejich provozní dobu a vytvořit softwarový systém, který volá metodu z komponent vlastněných a podporovaných nezávislými poskytovateli. Díky Webové služby funkce libovolného programu v síti lze zpřístupnit prostřednictvím internetu. Nejjednodušší příklad Webová služba- systém Pas na Hotmail, který vám umožňuje vytvořit ověření uživatele na vašem vlastním webu.
Webové služby jsou založeny na následujících univerzálních technologiích:
TCP/IP– univerzální protokol, kterému rozumí všechna síťová zařízení, od sálových počítačů po mobilní telefony a PDA;
HTML– univerzální značkovací jazyk používaný k zobrazování informací na uživatelských zařízeních;
XML(Extensible Markup Language) – univerzální jazyk pro práci s jakýmkoli typem dat.
Všestrannost těchto technologií je základem pro pochopení webových služeb. Jsou založeny pouze na obecně uznávaných, otevřených a formálně na dodavatele neutrálních technologiích. Jen tak lze dosáhnout hlavní výhody webových služeb jako konceptu pro budování distribuovaných IS - jejich univerzálnosti, tedy možnosti použití pro libovolné operační systémy, programovací jazyky, aplikační servery atd.
Webové služby tak řeší původní problém – problém integrace aplikací různého charakteru a budování distribuovaného IS. To je hlavní zásadní rozdíl mezi webovými službami a jejich předchůdci.
Webové služby - Tohle XML aplikace, propojení dat s programy, objekty, databázemi nebo celými obchodními transakcemi. Mezi webovou službou a programem se vyměňují dokumenty XML formátované jako zprávy. Standardy webových služeb definují formát takových zpráv, rozhraní, na které je zpráva odeslána, pravidla pro vazbu obsahu zprávy na aplikaci implementující službu a naopak, stejně jako mechanismy pro publikování a vyhledávání rozhraní.
XML(angličtinaEX napínatelný M arkup L jazyk- rozšiřitelný značkovací jazyk; vyslovováno [ x-em-el]). Doporučeno World Wide Web konsorcium(W3C). Specifikace XML popisuje dokumenty XML a částečně popisuje chování procesorů XML (programů, které čtou dokumenty XML a poskytují přístup k jejich obsahu). XML byl navržen jako jazyk s jednoduchým formálem syntax, vhodné pro stvoření a programy pro zpracování dokumentů a zároveň pohodlné pro lidi ke čtení a vytváření dokumentů, s důrazem na zaměření na použití na internetu. Jazyk se nazývá rozšiřitelný, protože neopravuje značkování použité v dokumentech: vývojář může vytvářet značkování podle potřeb konkrétní domény, omezeno pouze syntaktickými pravidly jazyka. Kombinace jednoduché formální syntaxe, vstřícnosti vůči lidem, rozšiřitelnosti a kódování Unicode pro reprezentaci obsahu dokumentů vedlo k širokému použití jak samotného XML, tak mnoha odvozených specializovaných jazyků založených na XML v široké škále softwarových nástrojů.
Standardní XML aplikace
XML lze použít pro více než jen popis jednoho dokumentu. Jednotlivec, společnost nebo výbor pro standardy může definovat požadovanou sadu prvků XML a strukturu dokumentu, které se mají použít pro konkrétní třídu dokumentů. Obdobná sada prvků a popis struktury dokumentu se nazývá XML aplikace nebo XML slovník. Organizace může například definovat aplikaci XML pro vytváření dokumentů popisujících molekulární struktury, multimediální prezentace nebo obsahující vektorovou grafiku.
Webové služby lze použít v mnoha aplikacích. Bez ohledu na to, zda webové služby běží ze stolních počítačů nebo notebooků zákazníků, lze je použít pro přístup k internetovým aplikacím, jako je předobjednávka nebo sledování objednávek.
Webové služby vhodné pro B2B integrace (business-to-business), uzavírání aplikací prováděných různými organizacemi do jednoho výrobního procesu. Webové služby může také řešit širší problém integrace podnikových aplikací (Integrace podnikových aplikací, EAI), propojení více aplikací z jednoho podniku s více dalšími aplikacemi. Ve všech těchto případech jsou technologie webových služeb „lepidlem“, které spojuje různé části softwaru.
Jak je vidět z Obr. 1, Webové služby jsou obal, který poskytuje standardní způsob interakce s prostředími aplikačního softwaru, jako je např systémy pro správu databází (DBMS), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), prodejci balíčků plánování podnikových zdrojů ( plánování podnikových zdrojů, ERP), integrační makléři atd.
Obr.1. Webové služby interagují s aplikačními systémy
Rozhraní webových služeb jsou získávána ze síťového prostředí standardní XML zprávy, transformovat XML data do formátu „pochopeného“ specifickým aplikačním softwarovým systémem a odeslat zprávu s odpovědí (druhá je volitelná). Implementace softwaru webové služby (základní software, nižší úroveň) lze vytvořit v libovolném programovacím jazyce pomocí libovolného operačního systému a jakéhokoli middlewaru ( middleware).
Jednoduchý příklad: vyhledávání informací
V současné době se většina služeb volá přes internet zadáním dat HTML formuláře a odeslání těchto dat do služby jejich přidáním do řetězce Uniform Resource Locator ( Uniform Resource Locator, URL):
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
Tento příklad ilustruje snadnost webové interakce (jako je vyhledávání, nákup akcií nebo vyžádání trasy jízdy), kde jsou parametry a klíčová slova vloženy přímo do adresy URL. V tomto případě je jednoduchý vyhledávací dotaz pro skate boty uveden v řetězci dotazu do vyhledávače Google. Klíčové slovo search představuje službu, ke které se bude přistupovat, a parametr Skate+boots je vyhledávací řetězec, který byl zadán do formuláře HTML na webové stránce Google. Vyhledávací služba Google předá tento požadavek různým vyhledávačům, které se vrátí seznam adres URL pro stránky, které odpovídají vyhledávacímu parametru Skate+boots. Tato neúčinná metoda vyhledávání na internetu je zcela založena na porovnávání zadaného textového řetězce s indexovaným HTML stránky.
XML - nejlepší způsob odesílání dat. XML poskytuje významné výhody při přenosu dat přes internet. Nyní může být předchozí dotaz reprezentován jako XML dokument:
xmlns:s="www.xmlbus.com/SearchService"> Odeslání poptávky ve formuláři XML dokument má následující výhody: schopnost definovat datové typy a struktury, větší flexibilita a rozšiřitelnost. XML může představovat strukturovaná data nebo data určitého typu (například je přijatelné zadat hodnotu pole velikosti jako řetězec čísel nebo číslo s plovoucí desetinnou čárkou) a obsahovat více informací, než umožňuje adresa URL. Tento příklad je prezentován ve formě zprávy SOAP (Simple Přístup k objektu Protokol, standardní forma výměny zpráv XML, je jednou z technologií, které jsou základem webových služeb. Ve zprávě SOAP jsou název požadované služby a vstupní parametry reprezentovány jako samostatné prvky XML. Tento příklad také ilustruje použití jmenných prostorů XML (xmlns:), dalšího důležitého prvku webových služeb. Protože dokumenty XML podporují více typů dat, složité struktury a agregaci schémat, moderní technologie webových služeb poskytují oproti stávajícím možnostem pro přístup k softwarovým aplikacím prostřednictvím HTML a URL významné výhody. Webové služby- nové slovo v technologii distribuovaných systémů. Specifikace Open Net Environment (ONE) Sun Microsystems Corporation a iniciativa. Microsoft's Net poskytuje infrastrukturu pro psaní a nasazení webových služeb. V přítomný okamžik Existuje několik definic webové služby. Webovou službou může být jakákoli aplikace, která má přístup k webu, například webová stránka s dynamickým obsahem. Ve více v užším slova smyslu Webová služba je aplikace, která poskytuje otevřené rozhraní, vhodné pro použití jinými aplikacemi na webu. Specifikace ONE Sun vyžaduje, aby webové služby byly přístupné přes HTTP a další webové protokoly, aby byla umožněna výměna informací prostřednictvím zpráv XML a aby bylo možné vyhledávat prostřednictvím vyhledávacích služeb. Pro přístup k webovým službám byl vyvinut speciální protokol - Simple Object Access Protocol (SOAP), který zavádí interoperabilitu založenou na XML pro mnoho webových služeb. Webové služby jsou obzvláště atraktivní, protože mohou poskytovat vysoký stupeň kompatibility mezi různými systémy. Hypotetická webová služba vyvinutá podle architektury Sun ONE by mohla mít podobu registru služeb zveřejňujícího popis webové služby jako dokument. . Obrovský potenciál webových služeb není určen technologií použitou k jejich vytvoření. HTTP, XML a další protokoly používané webovými službami nejsou novinkou. Interoperabilita a škálovatelnost webových služeb znamená, že vývojáři mohou rychle vytvářet větší aplikace a větší webové služby z menších webových služeb. Specifikace Sun Open Net Environment popisuje architekturu pro vytváření inteligentní webové služby Inteligentní webové služby využívají běžné operační prostředí. Sdílením kontextu mohou inteligentní webové služby provádět standardní ověřování finančních transakcí, poskytovat doporučení a pokyny na základě geografické polohy společností zapojených do transakce. e-business. Aby bylo možné vytvořit aplikaci, která je webovou službou, je nutné použít řadu technologií. Vztah mezi těmito technologiemi je konvenčně prezentován na Obr. 10.1.
Webové služby jsou ve skutečnosti jednou z možností implementace komponentní architektura, ve kterém je aplikace považována za soubor komponent, které se vzájemně ovlivňují. Jak již bylo mnohokrát řečeno, interakce komponent běžících na různých platformách je poměrně složitý úkol, zejména vyžaduje vývoj komunikační protokol s přihlédnutím k vlastnostem přenosu dat mezi různými platformami. Jednou z hlavních myšlenek, které jsou základem zvažované technologie webových služeb, je odmítnutí binárního kódu komunikační protokol. Zprávy jsou vyměňovány mezi komponentami systému prostřednictvím XML přenosy-zprávy. Protože XML zprávy jsou textové soubory, přenosový transportní protokol může být velmi odlišný - zprávy XML lze přenášet prostřednictvím protokolů HTTP, SMTP, FTP a použití různých transportní protokoly transparentní pro aplikace. Jak již bylo zmíněno, nazývá se protokol, který umožňuje interakci webových služeb MÝDLO (Simple Object Access Protocol). Je definován na založené na XML. MÝDLO zajišťuje interakci distribuovaných systémů bez ohledu na použitý objektový model nebo platformu. Data uvnitř MÝDLO přenášeny jako XML dokumenty speciálního formátu. MÝDLO neukládá žádný konkrétní transportní protokol. V reálných aplikacích se však nejčastěji realizuje přenos MÝDLO-zprávy přes HTTP protokol. Je také běžné používat SMTP, FTP a dokonce „čistý“ TCP jako přenosový protokol. Tak, MÝDLO definuje mechanismus, kterým si webové služby mohou navzájem volat své funkce. V jistém smyslu fungování tohoto protokolu připomíná vzdálené volání procedury – volající zná název webové služby, název její metody, parametry, které metoda přijímá, a formalizuje volání této metody ve tvaru MÝDLO-message a odešle ji webové službě. Popsaný přístup je však vhodný pouze v případě, že jsou předem známy „podpisy“ metod, které webová služba implementuje. Ale co když tomu tak není? K vyřešení tohoto problému byla do modelu webových služeb zavedena další vrstva - vrstva pro popis rozhraní služeb. Tato vrstva je prezentována jako popis WSDL. Podle definice W3C, " WSDL- Formát XML pro popis síťové služby jako soubor konečných operací fungujících pomocí zpráv obsahujících dokumentově orientované nebo procedurálně orientované informace.“ Dokument WSDL plně popisuje rozhraní webové služby s vnějším světem. Poskytuje informace o službách, které lze získat pomocí servisních metod a jak k těmto metodám přistupovat. Pokud tedy podpis metody webové služby není přesně znám (například se v průběhu času změnil), lze dotazovat cílovou webovou službu WSDL-description - soubor, ve kterém budou tyto informace obsaženy. Další vrstvou technologie je služba Univerzální popis, zjišťování a integrace (UDDI) Tato technologie zahrnuje udržování registru webových služeb. Připojením k tomuto registru může spotřebitel najít webové služby, které nejlépe vyhovují jeho potřebám. Technologie UDDI umožňuje vyhledávat a publikovat požadovanou službu a tyto operace může provádět buď osoba, nebo jiná webová služba nebo speciální klientský program. UDDI, je zase také webová služba. Další implementací systému jsou tedy webové služby middleware. Charakteristickým rysem této technologie je její nezávislost na použitém softwaru a hardwaru, stejně jako použití široce používaného otevřené standardy(jako je XML) a standardní komunikační protokoly. V současné době Web čas-služby jsou velmi aktivně propagovanou technologií a jsou umístěny jako prostředek k řešení řady problémů. Je třeba poznamenat, že pomocí nich lze budovat i tzv. „standardní“ aplikace, kde je serverová část navržena jako webová služba. Základní protokol, který zajišťuje interakci v prostředí webových služeb, je Specialita: 05.13.12 – Navrhování automatizačních systémů Petrohrad 2013 2 Práce byla provedena na federální státní rozpočtové vzdělávací instituci vysokého školství odborné vzdělání"St. Petersburg State Electrotechnical University "LETI" pojmenované po. V. I. Uljanova (Lenin), Katedra systému počítačově podporovaný design Vědecký školitel- lékař technické vědy, profesor Dmitrevič Gennadij Daniilovič Oficiální odpůrci: Doktor technických věd, profesor, St. Petersburg State Electrotechnical University "LETI" pojmenovaná po. V.I. Uljanov (Lenin), odd automatizované systémy zpracování a správa informací Kutuzov Oleg Ivanovič Kandidát technických věd, Otevřená akciová společnost "Koncern" Vedoucí organizace: Federální státní rozpočet vzdělávací instituce vyšší odborné vzdělání "St. Petersburg National Research University of Information Technologies, Mechanics and Optics" Obhajoba disertační práce se uskuteční dne 23. května 2013 v 16.30 na zasedání rady pro disertační práci D212.238.02 Petrohradské státní elektrotechnické univerzity „LETI“ pojmenované po. V.I. Uljanova (Lenin) na adrese: 197376, Petrohrad, st. Profesorka Popová, 5. Disertační práci lze nalézt v knihovně St. Petersburg State Electronic Technical University Abstrakt rozeslán „_“ 2013. Vědecký tajemník Rady pro disertační práci D212.238.02 N. M. Safyannikov OBECNÁ CHARAKTERISTIKA PRÁCE Řešením tohoto naléhavého problému může být decentralizace CAD architektury prostřednictvím přechodu na distribuované konstrukční systémy postavené na bázi internetových technologií, které implementují úkoly komunikace a výměna informací mezi aplikacemi. Tyto nezávisle spravované aplikace jsou autonomní a mohou spolu komunikovat za účelem plnění společného úkolu. Protokoly internetových technologií poskytují spolehlivý základ pro propojování subsystémů a nevyžadují koordinované využívání zdrojů umístěných v různých síťových uzlech, což výrazně zjednodušuje proces budování a provozování distribuovaného CAD systému. Hlavním požadavkem na možnost implementace takto distribuovaného systému je konzistence rozhraní, přes která jsou jednotlivé subsystémy propojeny. Pokud je tento požadavek splněn, mohou být jednotlivé distribuované CAD komponenty vytvářeny různými vývojáři a udržovány na různých místech, odkud budou dodávány (případně na komerční bázi) zákazníkům. Za nejúčinnější metodu kombinování subsystémů do distribuované aplikace by měla být považována organizace vzdálených volání procedur založených na architektuře orientované na služby využívající webové služby. Integrace založená na webových službách při vývoji decentralizovaných CAD systémů umožňuje přejít k popisu rozhraní a interakcí na bázi XML, poskytující možnost upravovat a vyvíjet vybudovaný software při zachování zvoleného rozhraní. To umožňuje díky volnému propojení jednotlivých subsystémů zajistit interakci mezi službami na libovolné platformě a přizpůsobit stávající aplikace měnícím se podmínkám návrhu. Hlavní zátěž provádění výpočetních operací s takovou architekturou leží na webových službách, které řeší všechny problémy modelování navrhovaných systémů klientským aplikacím jsou přiřazeny pouze ty nejjednodušší funkce přípravy dat a zobrazování výsledků modelování. Při vývoji CAD softwaru pomocí webových služeb je lze použít následující typy klientské aplikace: aplikace typu konzola, aplikace typu okna a webová aplikace. Charakteristickým rysem konzolových aplikací je absence grafického rozhraní, ale jejich použití může být užitečné při implementaci jednoduchých CAD systémů pro kapesní počítače s malou plochou obrazovky. Okenní aplikace poskytují nejlepší možnou grafickou implementaci a jsou nejvhodnější pro vývoj distribuovaných systémů založených na webových službách. Pro jakoukoli webovou službu je možné sestavit několik klientských aplikací s různými způsoby implementace dialogových interakcí. Webové aplikace poskytují možnost kompletně hostovat vše, co se používá software CAD na webu. Výhodou použití této struktury je otevřený přístup k použití distribuovaného CAD prostřednictvím libovolného typu prohlížeče, nevýhodou tohoto typu aplikace je prodloužení času potřebného k popisu komponent navrženého systému z důvodu čekání na odezvu při jednotlivých krocích zadávání dat. Pro klientskou aplikaci jakéhokoli druhu se nazývají webové služby stejně a pro každou webovou službu je možné použít libovolné metody implementace klientských aplikací napsaných v různých jazycích. V případě potřeby lze takové klientské aplikace snadno upravit tak, aby vyhovovaly měnícím se podmínkám návrhu, a také lze webovou službu rozšířit o další metody. Účel práce a hlavní cíle výzkumu Tato disertační práce je věnována výzkumu a vývoji metod pro konstrukci platformově nezávislých distribuovaných CAD systémů pomocí webových služeb. Pro konkrétní implementaci byl zvolen úkol vyvinout distribuovaný automatizační systém pro návrh obvodů. K dosažení tohoto cíle je třeba vyřešit následující úkoly: 1. Vytvořte obecnou metodiku pro vytváření, offline testování a nasazení na vybraný server webových služeb Java. Software webových služeb Java pro systém automatizace návrhu distribuovaných obvodů. 3. Výzkum a vývoj metodiky pro budování webových služeb Java pomocí technologie komprese dat. 4. Provádět výzkum a vývoj obecné metodologie pro vytváření šablon pro klientské aplikace konzolových a okenních typů a také klientské webové aplikace. 5. Vypracovat metodiku pro implementaci fungování webových služeb a klientských aplikací v heterogenních prostředích. Metody výzkumu Při řešení zadaných úkolů disertační práce byly využity základy obecné teorie CAD, teorie modelovacích systémů a základy teorie matic a grafů. Spolehlivost vědeckých výsledků potvrzují základní ustanovení obecné teorie CAD, teorie modelování, správnost použitého matematického aparátu a výsledky získané testováním vytvořeného softwaru pro webové služby a klientské aplikace. Nové vědecké výsledky distribuovaného CAD pomocí webových služeb. 2. Byla vyvinuta obecná metodika pro implementaci, offline testování a nasazení webových služeb Java na distribuovaném CAD serveru. 3. Výzkum a vývoj metod pro vytváření softwaru webových služeb Java pro řešení typických problémů návrhu elektronických obvodů. 5. Byla vyvinuta obecná metodika pro vytváření konzolových a okenních klientských aplikací, jakož i klientských webových aplikací. 6. Byla vyvinuta metodika pro implementaci distribuovaného CAD softwaru pro organizaci interakce v heterogenních prostředích webových služeb a klientských aplikací. Základní ustanovení 1. Architektura distribuovaného servisně orientovaného CAD založeného na webových službách. 2. Obecná metodika návrhu webových služeb Java zdola nahoru 3. Metodika implementace softwaru webových služeb Java založeného na kompresi dat. Praktická hodnota 1. Navrhovaná distribuovaná CAD struktura poskytuje možnost organizovat interakci mezi různými webovými službami na zvolené platformě a přizpůsobovat aplikace měnícím se podmínkám návrhu. 2. Vybudovaná knihovna pomocných funkcí založená na kompresi dat zvyšuje efektivitu tvorby softwaru webových služeb Java pro systémy automatizace návrhu obvodů. 3. Vyvinutá metodika pro implementaci interakce klient-server zajišťuje provoz distribuovaných CAD systémů v heterogenních prostředích. 4. Software vyvinutého distribuovaného automatizačního systému pro návrh obvodů obsahuje invariantní jádro pro organizaci jak symbolických, tak numerických fází programů Java, které lze použít jako základ pro budování návrhových systémů pro širokou škálu objektů. Implementace a implementace výsledků Distribuovaný CAD systém vyvinutý v dizertační práci pomocí webových služeb byl implementován na jazyk Java pomocí platformy WTP (Web Tools Platform). Praktickým výsledkem je platformově nezávislý CAD systém pro návrh distribuovaných obvodů, který provádí vícerozměrné modelování nelineárních obvodů ve stacionárním režimu, v dynamickém režimu, pro výpočet frekvenčních charakteristik a také poskytuje výpočet citlivosti přenosových funkcí a citlivosti stacionárního režimu. proměnné na variace parametrů. Výsledky disertační práce byly využity při výzkumu státního rozpočtu na téma „Vývoj modelů a metod pro analýzu a syntézu inteligentních systémů pro podporu rozhodování pro řízení složitých distribuovaných objektů“ (kód CAD-47 předmětový plán St. Petersburg State Economic University 2011) a na téma „Matematické a logické základy konstrukčních prostředí virtuálních přístrojů“ (kód CAD-49 tématický plán SPbGETU 2012) Výsledky disertační práce jsou zaváděny do inženýrské praxe vědecko-výrobní společnosti „Modem“ a jsou využíván ve výukovém procesu katedry CAD Petrohradské státní technické univerzity ke studiu metodiky konstrukce softwaru pro systémy automatizace návrhu obvodů při přípravě bakalářských a magisterských oborů „Informatika a informatika“. Schválení práce Hlavní ustanovení disertační práce byla oznámena a projednána na následujících konferencích: 1. 9. konference mladých vědců „Navigace a řízení dopravy – Petrohrad; 2. 5. mezinárodní konference „Výroba nástrojů v ekologii a lidské bezpečnosti – St. Petersburg, SUAI“; 3. XIII, XIV, XVII mezinárodní konference"Moderní vzdělávání: obsah, technologie, kvalita." – Petrohrad, 4. 60., 61., 63. vědeckotechnická konference pedagogického sboru SETU. Publikace Hlavní teoretický a praktický obsah disertační práce byl publikován v 16 vědeckých pracích, z toho 4 články v předních recenzovaných publikacích doporučených v aktuálním seznamu Vyšší atestační komise, 1 osvědčení o oficiální registrace počítačové programy registrované u Federální služby pro duševní vlastnictví, patenty a ochranné známky. Struktura a rozsah disertační práce Práce obsahuje úvod, čtyři kapitoly hlavního obsahu, závěr a bibliografii obsahující 69 zdrojů. Práce je prezentována na 154 stranách textu, obsahuje 21 obrázků a jednu tabulku. V první kapitole jsou zvažovány otázky výstavby architektury distribuované aplikace, který určuje obecnou strukturu, vykonávané funkce a vztah jednotlivých složek systému. Je ukázáno, že architektura distribuované aplikace pokrývá jak její strukturální a behaviorální aspekty, tak i pravidla integrace a použití, funkčnost, flexibilitu, spolehlivost, výkon, znovupoužitelnost, technologická omezení, problémy uživatelské rozhraní. Hlavní úkol integrace samostatné aplikace(subsystémy) v distribuované aplikaci je poskytovat funkční spojení poskytující požadované interakce s minimální závislostí mezi subsystémy. Disertační práce ukazuje, že takový mechanismus je nejúčinněji zajištěn při použití architektury založené na interakci mezi subsystémy pomocí vzdálených volání procedur, používaných pro výměnu dat a pro provádění určitých akcí. V případě, že aplikace potřebuje načíst nebo změnit jakékoli informace spravované jinou aplikací, přistupuje k nim prostřednictvím volání funkce. K vybudování distribuovaných CAD systémů práce navrhuje využít servisně orientovanou architekturu (SOA) založenou na modulární softwarové struktuře a standardizovaných rozhraních. SOA využívá sjednocení základních provozních procesů, principy opakovaného použití funkčních prvků a organizaci založenou na integrační platformě. Přestože architektura SOA není spojena s žádnou konkrétní technologií vzdáleného volání procedur, softwarové subsystémy navržené v souladu s SOA jsou obvykle implementovány jako kolekce webových služeb propojených pomocí základních protokolů (SOAP, WSDL). Systémy založené na architektuře orientované na služby patří do třídy multiagentních systémů (MAS), které jsou tvořeny několika interagujícími inteligentními agenty, kteří zajišťují autonomii, omezené zastoupení a decentralizaci jednotlivých subsystémů distribuovaného informačního výpočetního systému. Webové služby jsou založeny na standardu XML a umožňují uživatelům komunikovat s externími systémovými nástroji přes internet, protože jsou volně propojenými součástmi softwarového systému, které jsou dostupné pro použití prostřednictvím internetových protokolů. Z disertační práce vyplývá, že při praktické implementaci distribuovaných CAD systémů pomocí webových služeb je třeba věnovat významnou pozornost správnému rozdělení funkčních odpovědností přiřazených hlavní klientské aplikaci a webové službě, která s touto aplikací interaguje. Konkrétní metodika implementace webových služeb výrazně závisí na zvoleném programovacím jazyku. Práce ukazuje, že přednost při volbě programovacího jazyka pro tvorbu webových služeb je třeba dát jazyku Java, který maximálně zajišťuje platformovou nezávislost implementovaných řešení. Důležitým faktorem ve prospěch této volby je také dostupnost výkonných nástrojů pro podporu vývoje webových aplikací v Javě, kterou zajišťuje prostředí WTP (Web Tools Platform). Disertační práce provedla komparativní analýzu dvou hlavních metod budování Java webových služeb – zdola nahoru (Bottom-Up), kdy je nejprve vytvořena Java třída webové služby a následně je na jejím základě vygenerován WSDL dokument, a shora dolů (Top-Down), kdy je nejprve vytvořen požadovaný dokument WSDL a poté je na jeho základě vygenerován implementační kód webové služby. Na základě srovnávacího posouzení se ukazuje, že návrh webových služeb by měl být prováděn metodou zdola nahoru, protože v tomto případě je dokument WSDL tvořen na základě předem vytvořené třídy Java, která popisuje všechny parametry předávané metodu webové služby a hodnoty vrácené touto metodou. V tomto případě jsou všechny informace dostupné ve třídě Java automaticky převedeny do odpovídajícího dokumentu WSDL, jehož obsah přesně odpovídá základní struktura Specifikace WSDL a hlavní charakteristiky metody volané webové služby, která zajišťuje úplnou spolehlivost informací obsažených v dokumentu WSDL. Aby bylo možné prakticky realizovat návrh webových služeb metodou zdola nahoru, je v dizertační práci navržena metodika pro konstrukci dynamického webového projektu a třída Java pro implementaci webové služby v něm obsažené s popisem volaných metod. mezi nimiž musí kromě hlavních pracovních metod nutně obsahovat i pomocnou metodu bez argumentů, která vrací řetězcovou proměnnou obsahující všechny informace o hlavních metodách zajišťujících fungování webové služby a popis formátů webové služby. předané parametry, stejně jako vrácená data, což zajišťuje vlastní dokumentaci webové služby a možnost vytvářet a neustále vylepšovat klientské aplikace bez ohledu na vývojáře webové služby. Disertační práce poskytuje techniku pro organizaci volání informační metody webové služby přímo z integrovaného vývojového prostředí Java aplikací, ve kterém můžete pomocí adresy URL webové služby přistupovat k odpovědi Soap informační metody a obsahu jejího návratu. hodnota. V druhé kapitole jsou uvažovány metody pro konstrukci distribuovaných CAD webových služeb, s jejichž pomocí se počítají nelineární obvody ve stacionárním režimu, obvodové funkce lineárních a linearizovaných obvodů se počítají pro frekvenční oblast a nelineární obvody se počítají v dynamických režimech. Kromě toho subsystémy zahrnuté v distribuovaném systému zahrnují webovou službu pro výpočet citlivosti obvodových funkcí ve frekvenční doméně a webovou službu pro výpočet citlivosti proměnných v ustáleném stavu nelineárních obvodů na variace parametrů. Jako součástky obvodů navržených na základě vyvinutých webových služeb lze použít dvousvorková zařízení typu R, C, L, lineární frekvenčně závislé řízené zdroje, nelineární řízené zdroje, transformátory, bipolární a unipolární tranzistory, operační zesilovače, stejně jako hlavní zdroje proudu a napětí. Základem takových metod je obecná struktura matematického popisu systémů návrhu obvodů. Disertační práce poskytuje komparativní posouzení možných metod výběru souřadnicové báze pro vytvoření popisu linearizovaných obvodů s předností rozšířené báze uzlových potenciálů. Je třeba poznamenat, že spolu s nepochybnými výhodami je významným omezením tohoto základu nemožnost matematicky popsat součásti obvodu pomocí rovnic v implicitní formě, což často znesnadňuje a někdy znemožňuje praktická aplikace. Pro realizaci možnosti popisu součástek obvodů rovnicemi v implicitní formě poskytuje práce upravenou verzi rozšířené báze uzlových napětí, která je brána jako základ pro konstrukci softwaru webových služeb. Při zvažování otázek souvisejících s konstrukcí webových služeb pro problémy výpočtu frekvenčních vlastností elektronických obvodů je třeba poznamenat, že problémy tohoto typu lze rozdělit do dvou skupin. První skupina zahrnuje problémy výpočtu lineárních obvodů, jejichž parametry součástí mají pevné hodnoty, které v procesu řešení problému nezávisí na hodnotách souřadnic pracovních bodů součástí. Druhá skupina je spojena s výpočtem frekvenčních charakteristik linearizovaných obvodů, jejichž parametry závisí na souřadnicích pracovních bodů součástí a tyto souřadnice, stejně jako hodnoty odpovídajících linearizovaných parametrů, musí být předem vypočítané. Pro řešení první skupiny problémů výpočtu frekvenčních vlastností elektronických obvodů při provádění disertační práce byla vybudována webová služba ModService_Java. Umět pracovat s komplexní čísla při její konstrukci byla vytvořena vlastní třída Complex, protože v době této práce taková třída není součástí standardních nástrojů Java API. Třídní komplex obsahuje konstruktory a pomocné funkce pro zpracování složitých dat a všechny potřebné funkce pro provádění aritmetických a logické operace s komplexními čísly, protože jazyk Java nemá přepisovací operátor pro tyto operace. Webová služba obdrží popis součástí obvodu a direktivy výpočtu jako argumenty a vrátí pole popisující výsledky výpočtu frekvenčních charakteristik. Pro výpočet stacionárního režimu nelineárních systémů je v disertační práci navržena obecná metodika konstrukce softwaru pro příslušné webové služby, implementovaná při vytváření webové služby StaticService_Java. Webová služba také přijímá jako argumenty popis součástek obvodu a direktivy výpočtu a vrací pole popisující výsledky výpočtu základních proměnných a ustálených souřadnic pro všechny nelineární součástky (diody, bipolární tranzistory, unipolární tranzistory, operační zesilovače, nelineární kontrolované zdroje). Nulový prvek vráceného pole je vyhrazen pro přenos informací na stranu klienta v případě nedostatečné konvergence výpočetního procesu, což vyžaduje změnu direktiv výpočtu a opětovné volání metody webové služby. Disertační práce zkoumá možné přístupy k vývoji metodiky konstrukce webových služeb pro výpočet frekvenčních charakteristik linearizovaných obvodů, jejichž parametry závisí na souřadnicích pracovních bodů součástek. Na základě srovnávacího posouzení byla zvolena cesta k vybudování webové služby založené na integrovaném systému, jehož součástí je software pro linearizaci nelineárních složek ve vypočítaných pracovních bodech a pro následný výpočet frekvenčních vlastností linearizovaného obvodu. . Práce poskytuje obecnou metodiku řešení takového problému, jejíž implementace byla provedena ve webové službě StFrqService_Java. Webová služba dostává jako argumenty popis frekvenčně závislých a nelineárních součástí obvodu a také direktivy výpočtu a jako výsledek její práce je vráceno pole popisující výsledky výpočtu frekvenčních charakteristik. Stejným způsobem, jako při výpočtu v ustáleném stavu, je nulový prvek vráceného pole použit k přenosu informací na stranu klienta v případě nekonvergence procesu. Při vývoji metodiky pro konstrukci webové služby pro výpočet dynamických režimů nelineárních systémů se využívá matematický popis obvodu v upravené rozšířené bázi uzlových potenciálů, který umožňuje získat soustavu rovnic algebraicko-diferenciálního typu v nejobecnější forma. Eliminace derivací ze složkových rovnic se provádí na základě korekčních vzorců, které vyplývají z vícekrokových implicitních metod vyšších řádů, přičemž jako hlavní je převzata metoda druhého řádu Gear s možností zvýšení jejího řádu. Komponenty, z jejichž rovnic jsou vyloučeny derivace, jsou dvousvorkové sítě typu C a L, diody, transformátory, bipolární a unipolární tranzistory, operační zesilovače a také frekvenčně závislé řízené zdroje. Pro výpočet hodnot autonomních zdrojů, které zachovávají hodnoty odpovídajících proměnných v předchozích krocích, jsou vytvořeny pomocné vzorkovací funkce dis_cmp pro všechny uvedené komponenty cmp s frekvenčně závislými vlastnostmi. Vyvinutá metodika byla implementována při konstrukci webové služby Dyn2Service_Java, která vrací na stranu klienta pole popisující výsledky výpočtu dynamických charakteristik. Ve třetí kapitole Jsou zvažovány otázky budování webových služeb pomocí metod komprese dat. Relevantnost těchto problémů je dána skutečností, že struktura reálných systémů je charakteristická slabé spojení komponenty mezi sebou, výsledkem čehož je jejich matematický popis ve formě řídkých typových matic, ve kterých má smysluplnou informaci jen malá část prvků. Tato okolnost klade za úkol změnit obecně uznávané přístupy k tvorbě a řešení rovnic za účelem úspory paměti a zvýšení výkonu, který je pro fungování webových systémů zásadní. V rámci disertační práce byla provedena analýza účinnosti možné metody převod dat do kompaktních polí, na základě čehož byl učiněn závěr o vhodnosti volby metody založené na použití Shermanovy komprese a vyžadující k implementaci dvoustupňový postup provádění symbolického a numerického zpracování dat. Významnou výhodou přijatého dvoustupňového postupu je jeho rozdělení na dvě nezávislé části etapy symbolické a číselné. Protože téměř všechny reálné problémy návrhu obvodu jsou spojeny s vícerozměrným výpočtem obvodu nezměněné struktury, je symbolická fáze provedena pro každou strukturu pouze jednou, zatímco numerická fáze je implementována desítky, stovky a někdy i tisícekrát. Dvoustupňový postup se však vyznačuje poměrně složitou logikou konstrukce programového kódu a při přechodu na popis založený na kompresi dat výraznou změnou dříve vytvořeného úplný popisúkoly. Disertační práce zkoumá blokové schéma implementace dvoustupňového zpracování dat při budování Java aplikací, podle kterého se ve fázi symbolické analýzy vytvoří indexová matice celočíselného typu, pro kterou je určena symbolická fáze faktorizace LU. provádí, kde jsou řádky (sloupce) seřazeny tak, aby se minimalizoval počet opět se objevujících prvků s nenulovými hodnotami. V posledním kroku symbolické fáze jsou konstruovány souřadnicové matice, které obsahují informace o struktuře indexové matice, v důsledku čehož lze tuto matici vymazat. V numerické fázi jsou v souladu se známým formátem popisu vytvořeny kompaktní matice a jejich virtuální numerická LU faktorizace je provedena na základě algoritmu konstruovaného v práci. Po dokončení numerické etapy faktorizace LU vše systémové proměnné a jejich překódování podle permutací řádků (sloupců) provedených ve fázi symbolického zpracování. Tento problém se v souladu s obecnou technikou LU faktorizace obvykle řeší pomocí zpětných a dopředných pohybů po řádcích původní matice, ale protože při použití komprese dat neexistuje úplná matice, jsou pohyby vpřed i vzad prováděny pomocí speciálních algoritmů. které implementují tyto úlohy pomocí komprese dat. Práce ukazuje, že jsou možné dva různé přístupy k vývoji softwaru webových služeb založené na kompresi dat. První je spojen se zpracováním stávajícího softwaru, založeným na kompletním matematickém popisu ve formě počátečních matic s řídkou strukturou, za účelem konstrukce upravená metoda pomocí kompaktních polí. Mít prototyp značně zjednodušuje proces vytváření metody založené na kompresi dat, ale nejvíce efektivní využití Vzhledem k dostupnému materiálu je nutné mít metodiku pro vývoj upravených verzí webových služeb. Tato technika byla vybudována v dizertační práci a na jejím základě byly upraveny všechny výše diskutované webové služby. Výsledkem je framework webových služeb obsahující dvě hlavní pracovní metody, jednu založenou na úplném popisu modelovaného obvodu a druhou využívající technologii kompaktního zpracování dat. Druhý přístup se používá v případech, kdy neexistuje prototyp pro vývoj metody založené na kompresi dat. V tomto případě je jak symbolický, tak numerický stupeň implementován při absenci úplného popisu simulovaného obvodu ve formě řídké matice, což značně komplikuje proces programování. V disertační práci je druhý přístup použit k vybudování webových služeb, které počítají citlivost obvodových přenosů a proměnných stacionárních režimů obvodů na změny parametrů jejich komponent. Pro výpočet citlivosti frekvenčních charakteristik obvodových funkcí byla vybudována webová služba VaryService, která obsahuje metodu založenou na derivaci rovnic a metodu založenou na propojených obvodech. Metoda webové služby VaryService umožňuje na základě diferenciace rovnic vypočítat hodnoty absolutní a relativní vektorové citlivosti obvodových funkcí pro frekvenční oblast na zvolený parametr proměnné pro celou množinu základních proměnných. Variabilními parametry mohou být hodnoty odporu, kapacity nebo indukčnosti libovolného dvousvorkového obvodu typu R, C nebo L a přenosové parametry řízených frekvenčně závislých zdrojů jako ITUN, INUN, ITUT nebo INUT. Metoda webové služby VaryService pomocí připojených obvodů umožňuje vypočítat hodnoty absolutní i relativní skalární citlivosti obvodových funkcí pro frekvenční doménu s ohledem na všechny možné proměnné parametry pro vybranou hodnotu analyzované proměnné. Softwarové blokové schéma navržené v této práci umožňuje použít výsledky tvorby kompaktních polí hlavního obvodu pro výpočet připojeného obvodu. Proměnné parametry v metodě založené na přidruženém obvodu mohou být stejné parametry jako u metody založené na derivaci rovnic. Pro výpočet citlivosti proměnných, které definují stacionární režim nelineárních obvodů na změny jejich parametrů, byla vyvinuta webová služba StVaryService, která rovněž obsahuje dvě metody, z nichž jedna je založena na derivaci rovnic a druhá na připojeném obvod. Proměnnými parametry u obou metod mohou být hodnoty odporu rezistorů a přenosové parametry řízených zdrojů jako ITUN, INUN, ITUT nebo INUT. Algoritmus pro výpočet absolutní citlivosti základních proměnných stacionárního režimu metodou derivace rovnic umožňuje derivaci nelineární rovnice obvodu základními proměnnými a proměnnými parametry, což umožňuje získat rovnici citlivosti. , jehož řešení určuje požadovanou vektorovou citlivost proměnných stacionárního režimu. Praktická implementace metody je založena na derivování rovnic různých složek pomocí výsledků výpočtu základních proměnných stacionárního režimu nelineárního obvodu. Algoritmus metody, která vypočítává skalární citlivost proměnných stacionárního režimu pomocí připojeného obvodu, umožňuje výpočet základních proměnných stacionárního režimu hlavního obvodu a výpočet základních proměnných linearizovaného připojeného obvodu, který se provádí na základě dříve vygenerovaných kompaktních polí pro hlavní obvod. Výsledkem druhé metody je pole absolutních a relativních hodnot citlivosti vybrané proměnné obvodu pro všechny proměnné parametry součástek. Čtvrtá kapitola pojednává o metodách vytváření vlastních klientských aplikací, které poskytují interakci s webovými službami, které poté, co jsou zabudovány v nástroji pro vývoj aplikací Java, musí být nasazeny na distribuovaný CAD server. Chcete-li nasadit webovou službu, musíte znát její hlavní charakteristiky, včetně názvu služby, názvu třídy, názvů metod a typu dokumentu WSDL. Relevantní informace o webových službách vyvinutých a popsaných výše pro systém návrhu distribuovaných obvodů jsou uvedeny v práci a v informačních metodách s názvem getInf, které jsou obsaženy ve všech vyvíjených webových službách. Článek navrhuje jednoduchou techniku pro přímé nasazení webových služeb na server a diskutuje možné způsoby import souboru WSDL na stranu klienta. Na základě srovnávací analýzy práce ukazuje, že správnost operace doručení souboru WSDL ze vzdálené webové služby do klientské aplikace lze nejúčinněji zajistit pomocí nástroje Web Services Explorer a nejoptimálnější posloupnost pro import Je vytvořen soubor WSDL do počátečního rámce klientské aplikace. Jakmile je soubor WSDL dodán do projektu klientské aplikace, navrhuje se provést další transformaci původní kostry projektu na kompletní klientskou aplikaci ve dvou fázích. První fází této transformace je vytvoření proxy objektu v rámci počátečního projektu a druhou fází je vytvoření tříd obsahujících metody, které podporují fungování proxy objektu a interakci vzdálené služby s klientskou aplikací. Realizace první etapy spočívá v doplnění projektu o operátory vytvářející proxy objekt, druhá etapa je realizována pomocí nástroje Web Services platformy WTP, jehož nejefektivnější způsoby použití jsou uvedeny v disertační práci. Finalizaci počáteční kostry projektu do kompletní klientské aplikace lze provést různými způsoby různé typy tuto aplikaci. Nejjednodušší způsob spouštění klientských aplikací je navrhnout je na základě konzolových aplikací, které nemají grafické rozhraní. Práce navrhuje zobecněnou blokové schéma implementace distribuované CAD konzolové aplikace pro výpočet elektronických obvodů, kterou lze přes rozmanitost možných konkrétních řešení použít pro jakoukoli webovou službu. V průběhu práce byly implementovány klientské konzolové aplikace pro všechny výše uvedené distribuované CAD webové služby. Jejich zdrojové soubory mohou být doručeny standardní prostředky přes internet ke klientovi a byly použity jak k sestavení nejjednodušší verze konzolové aplikace pro interakci s distribuovanými CAD službami, tak jako učební pomůcka pro vývoj pokročilejších okenních aplikací. Okenní klientské aplikace poskytují největší možnosti fungování v distribuovaném CADu, protože umožňují maximálně využít grafické prvky. Pro tuto webovou službu můžete vytvářet různé verze klientských aplikací s různými způsoby organizace dialogu s uživatelem a zobrazování výsledků výpočtů. Práce stanovila minimální sadu dialogových nástrojů, které zajišťují plnou interakci se službou. Taková sada obsahuje nabídku okna a sadu dialogových oken pro zadávání dat a zobrazování výsledků výpočtů a také správu výpočtových direktiv. Disertační práce navrhuje metodiku budování klientských webových aplikací, na jejichž základě byly vyvinuty šablony stránek JSP, které plní funkce výběru a přesunu na jiné stránky, zadání určité množiny proměnných s přechodem na domovskou stránku, cyklicky zadávat určitou množinu proměnných s přechodem na další stránku podle hodnot těchto proměnných, volat požadovanou webovou službu a vypisovat výsledky její práce. Použití klientských webových aplikací umožňuje umístit celý programový kód distribuovaného systému do sítě a v závislosti na přijatém způsobu umístění klienta a serverové aplikace, službu lze volat z jedné nebo více webových stránek. Pozitivní vlastností této architektury je možnost organizovat přístup k distribuovanému CAD prostřednictvím libovolného webového prohlížeče bez nutnosti sestavování vlastní klientské aplikace nevýhodou tohoto přístupu k organizaci distribuovaného CAD je nevyhnutelné prodloužení časového intervalu potřebného k popisu systémové komponenty v procesu interaktivní interakce. Disertační práce buduje metodiku organizace procesu nasazování klientských aplikací, jejímž účelem je zajistit možnost spuštění klientské aplikace pomocí celosystémových nástrojů bez použití nástroje pro vývoj aplikací, a to jak pro klientské aplikace konzolového typu, tak pro klientské aplikace okenního typu by mělo být spuštění provedeno pomocí příkazového řádku a pro webové aplikace - z prohlížeče. Informace o umístění webové služby jsou přenášeny prostřednictvím objektu třídy proxy, který musí být nejprve nakonfigurován na příslušnou adresu URL. Práce poznamenává, že při nasazení konzolové aplikace je nejprve nutné změnit kódovou stránku projektu, pro kterou je nutné přejít z kódové stránky, ve které je ve všech integrovaných nástrojových systémech pracujících s Java kódem text v azbuce, na kódovou stránku ve kterém se text v azbuce bude normálně zobrazovat v okně příkazového řádku. Z disertační práce vyplývá, že při použití klientských webových aplikací lze v závislosti na zvolené komunikační struktuře mezi klientskými a serverovými počítači přenášet informace o umístění webové služby jak prostřednictvím objektu třídy proxy, tak prostřednictvím URL zadané z prohlížeče. V práci jsou diskutovány i odpovídající způsoby interakce klienta se službou při realizaci jejich funkčních úkolů pro vybranou komunikační strukturu. Standardizace SOAP poskytuje možnost propojovat volně vázané aplikace bez ohledu na jejich implementační platformu, což umožňuje využití webových služeb k zajištění efektivního a optimálního využití široké škály heterogenních, volně vázaných zdrojů v distribuovaných aplikacích. Disertační práce poskytuje obecnou metodiku pro tvorbu softwaru pro interakci objektu třídy proxy aplikace prostředí .NET se službou prostředí Java/J2EE. Na základě této metodiky byla implementována organizace interakce mezi vyvíjenými webovými službami Java a klientskými aplikacemi Windows postavenými v prostředí .NET na bázi jazyka C#. Schopnost provozovat distribuovaný CAD v heterogenních prostředích výrazně rozšiřuje rozsah jeho aplikace. Na závěr jsou formulovány hlavní vědecké a praktické výsledky získané na základě výzkumu provedeného v disertační práci. Hlavní výsledky Práce 1. Byla vyvinuta architektura pro CAD orientovaný na distribuované služby na základě webových služeb, vyznačující se decentralizovanou strukturou, nezávislostí na platformě a schopností provádět průběžnou modernizaci jednotlivých subsystémů za účelem přizpůsobení jejich vlastností měnícím se podmínkám návrhu. 2. Byla implementována obecná metodika pro vytváření webových služeb Java a odpovídajících dokumentů WSDL pomocí metody zdola nahoru a také jejich doručení na distribuovaný server CAD po offline testování ve vývojovém prostředí. 3. Byla vyvinuta metodika pro konstrukci softwaru pro webové služby Java pro řešení typických problémů modelování spojitých systémů v automatizovaném návrhu elektronických obvodů. 4. Byla vytvořena knihovna pomocných funkcí pro implementaci softwaru webových služeb Java založeného na kompresi dat. 5. Byla vyvinuta obecná metodika pro konstrukci šablon pro konzolové a okenní klientské aplikace systému automatizace návrhu distribuovaných obvodů a byla implementována organizace fungování distribuovaného CAD systému s klientskými webovými aplikacemi. 6. Byla vyvinuta metodika pro konstrukci distribuovaných CAD systémů, která zajišťuje interakci webových služeb Java a klientských aplikací jakéhokoli typu v heterogenních prostředích. 1. Anisimov D.A. Konstrukce počítačově podporovaných návrhových systémů založených na webových službách [Text] / Anisimov D.A. Gridin V.N., Dmitrevič G.D. // Automatizace v průmyslu – 2011. – č. 1 – s. 9-12. 2. Anisimov D.A. Konstrukce počítačově podporovaných návrhových systémů založených na webových technologiích [Text] / Gridin V.N., Dmitrevich G.D., Anisimov D.A. Informační technologie– 2011. – č. 5. – str. 23-27. 3. Anisimov D.A. Konstrukce webových služeb pro systémy automatizace návrhu obvodů [Text] / Gridin V.N., Dmitrevich G.D., Anisimov D.A. // Informační technologie a výpočetní systémy - 2012. - č. 4. – s. 79-84. 4. Anisimov D.A. Metody pro konstrukci automatizačních systémů pro návrh obvodů na základě webových služeb [Text] / Anisimov D.A // Novinky Petrohradské elektrotechnické univerzity "LETI" - 2012. - č. 10. – Petrohrad: Nakladatelství Petrohradské elektrotechnické univerzity „LETI“, – s. 56-61. 5. Anisimov D.A. Přístup k webovým zdrojům v CAD navigačních a řídicích systémech [Text] / Laristov D.A., Anisimov D.A. // Gyroskopie a navigace. 2007. č. 2. –P. 106. Plán 8.1. Základy webových služeb 8.2. Web 2.0 a webové služby 8.4. Interakce s webovými službami 8.6. Složení webových služeb 8.7. Webové služby v ASP.Net Koncept webových služeb
vznikla na konci 90. let XX století. Nyní se však tento koncept ustálil a architektura, kterou nabízí, se stala průmyslovým standardem v oblasti IT. Standardizaci architektury webových služeb provádějí pracovní skupiny výboru W3C. Standardy webových služeb definují formát zpráv, rozhraní, na které je zpráva zasílána, pravidla pro propojení obsahu zprávy s aplikací implementující službu a naopak a také mechanismy pro publikování a vyhledávání rozhraní. Mechanismus zasílání zpráv je definován v popisu služby (Web Services Description), který je specifikací rozhraní služby a zahrnuje formáty zpráv, datové typy, transportní protokoly používané při výměně mezi agenty zákazníka a poskytovatele služby. Popis služby dále obsahuje označení jednoho nebo více bodů v síti (koncového bodu), ze kterých je poskytovatel přístupný. Díky webovým službám lze přes internet zpřístupnit funkce libovolného programu v síti. Webové služby jsou založeny na následujících univerzálních technologiích: TCP/IP je univerzální protokol, kterému rozumí všechna síťová zařízení, od sálových počítačů po mobilní telefony a PDA; HTML je univerzální značkovací jazyk používaný k zobrazování informací na uživatelských zařízeních; XML (Extensible Markup Language) je univerzální jazyk pro práci s libovolným typem dat. Všestrannost těchto technologií je základem pro pochopení webových služeb. Jsou založeny pouze na obecně uznávaných, otevřených a formálně na dodavatele neutrálních technologiích. Jen tak lze dosáhnout hlavní výhody webových služeb jako konceptu pro budování distribuovaných IS - jejich univerzálnosti, tedy možnosti použití pro libovolné operační systémy, programovací jazyky, aplikační servery atd. Webové služby tak řeší původní problém – problém integrace aplikací různého charakteru a budování distribuovaného IS. To je hlavní zásadní rozdíl webové služby od svých předchůdců - technologie pro interakci distribuovaných aplikací, které umožnily implementovat výměnu dat mezi aplikacemi (Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) a Common Object Request Broker Architecture (CORBA)). Každý z nich byl ale poměrně složitý na implementaci, neměl potřebnou univerzálnost (tedy stále záleželo na volbě např. stejného operačního systému pro všechny účastníky směny) a co je obzvláště špatné, tyto technologie bylo velmi obtížné mezi sebou integrovat. Výhody a nevýhody webových služeb Výhody Nižší výkon a větší velikost síťového provozu ve srovnání s technologiemi RMI, CORBA, DCOM díky použití textových zpráv XML. Platformy Webové služby běží na aplikačních serverech. Tuto technologii dnes podporují téměř všechny servery webových aplikací: 8.2. Web 2.0 a webové služby Technologie webových služeb jsou základem Webu 2.0. Termín „Web 2.0“ navrhl v roce 2005 slavný americký vydavatel Tim O’Reilly k označení souboru progresivních trendů ve vývoji webových technologií. Dnes je tento pojem chápán ani ne tak jako soubor konkrétních technologií, ale spíše jako filozofie prezentace informací ve webově orientovaném prostředí a budování informační vztahy. Fenomén Web 2.0 lze rozdělit do několika obecných trendů ve vývoji webového prostředí. Web jako platforma. Tento koncept je jádrem filozofie Web 2.0. To se týká umožnění uživatelům používat softwarové aplikace přímo prostřednictvím webového prohlížeče. Jinými slovy, tento koncept zahrnuje provádění všech nezbytných výpočtů pouze pomocí těch softwarových nástrojů, které jsou integrovány s webovým prohlížečem. Protože webové služby umožňují jednomu webovému projektu používat softwarové aplikace jiného, organizace nemusí vytvářet mnoho podobných produktů, aby mohly provádět stejné úkoly. Webové služby tak umožňují spolupráci a koordinaci mezi různými institucemi v procesu tvorby webového obsahu. Zde již hovoříme o dalším důležitém principu Webu 2.0 – „mash-up“ (mixování). Tento princip znamená, že integrací softwarových možností několika na sobě nezávislých webových služeb je možné vytvořit nový, unikátní webový projekt. Rýže. 8.1. Zásobník technologií webových služeb Tyto technologie umožňují implementaci základní vlastnosti webová služba popsaná v její definici. Na jejich základě se vyvíjejí nové interakční jazyky a architektury orientované na služby. Interakce softwarových systémů s webovými službami je znázorněna na Obr. 8.2. Rýže. 8.2. Interakce s webovými službami Architektura orientovaná na služby má tři hlavní architektonické komponenty: Při vzájemné interakci provádějí komponenty architektury orientované na služby následující základní operace: Architektura, ve které jsou všechny aplikační funkce nezávislými službami s jasně definovanými rozhraními, která mohou být volána ve správném pořadí pro vytvoření obchodních procesů, se nazývá architektura orientovaná na služby (SOA). SOA je prostředek k reprezentaci podniku jako souboru vzájemně propojených služeb. Jednou z jeho výhod je flexibilita a snadnost vývoje nových aplikací. SOA vytváří komunikační prostředí pro moduly, které implementují aplikovanou obchodní logiku. Informace o modulech jsou zveřejňovány v takové podobě, aby jejich použití nevyžadovalo znalost řešení a technologií v nich použitých. Rýže. 8.3. Zásobník technologií pro pokročilé webové služby Technologie rozšířených webových služeb je v zásadě rozdělena do následujících dvou složek: Abychom pochopili účel vrstev, dejme tomu stručný popis každý z nich. Novinka: WS-ReliableMessaging, BEEP Novinka: REST Vznikající: ebXML Novinka: BPEL4WS, WCF, WF Vznikající: WS-Inspection Novinka: WS-Policy, WS-PolicyAssertions a WS-PolicyAttachment Novinka: WS-SecureConversation, WS-Federation, WS-Authorization, WS-Trust a WS-Privacy Výše uvedený zásobník technologií webových služeb zavádí hierarchii do více technologií webových služeb podle jejich funkčního účelu. V tabulce jsou však uvedeny pouze nejpoužívanější a zavedené technologie. Technologie, které získaly oficiální status standardů mezinárodních konsorcií pro vývoj IT standardů (W3C), se nazývají standardní. Funkčnost každé webové služby je určena jejími vstupy, výstupy, předpoklady a akcemi, které se označují jako IOPE (vstupy, výstupy, předpoklady a efekty). IOPE služby je obsažen v jejím popisu WSDL. Webové služby lze z hlediska jejich provedení rozdělit na atomické, které se nedělí na podprocesy a mohou být volány přímo uživatelem přes internet, a složené, které mají podprocesy propojené řídicími konstrukcemi. Obchodní úkoly uživatele jsou zpravidla realizovány kompozitními službami, které lze sestavit z existujících atomických. Z pojmu webové služby vyplývá, že jednotlivé služby mají svá specifika omezená funkčnost, přičemž řešení více či méně složitých problémů vyžaduje využití funkcionality více služeb. Proto se v průběhu vývoje architektury webových služeb začaly objevovat pojmy jako např složení a tok nebo, jak se teď říká, orchestraci a choreografii. Odrážejí se interakce a konzistence služeb jejich provádění; Aplikace vytvořené pomocí webových služeb jsou považovány za založené na Work Flow (WF). Podmínky orchestrace A choreografie popsat dva aspekty vývoje obchodních procesů založených na integraci webových služeb. Na Obr. Obrázek 8.5 obecně ukazuje vztah mezi těmito aspekty, které se do určité míry doplňují. Pod orchestrace pochopit, jak se služby vzájemně ovlivňují na úrovni zpráv, včetně obchodní logiky a spolupráce při provádění složitých procesů uvnitř jeden podnik (jeden obchodní proces). Choreografie pokrývá širší škálu účastníků interakce, včetně dodavatelů, spotřebitelů a partnerů podniku. Je spojena s veřejnou výměnou zpráv mezi více webovými službami, spíše než s jediným obchodním procesem prováděným v rámci jednoho podniku. K dnešnímu dni má největší váhu BPEL4WS (Business Process Execution). Jazyk pro Web Services), produkované společnostmi IBM, Microsoft a BEA Systems, a WSCI (Web Service Choreography Interface) společností Sun Microsystems. Jazyk BPEL4WS je určen k implementaci orchestrace služby. Jazyk WSCI odráží tento koncept choreografie služby. WSCI (Web Service Choreography Interface) je jazyk deskriptivního rozhraní založený na XML, který funguje ve spojení s WSDL. Jeho cílem je umožnit korporacím využít sílu webových služeb k vytvoření procesů, které odrážejí měnící se obchodní požadavky. Jazyk umožňuje společnostem prezentovat své aplikace a zdroje jako webové služby, aby je ostatní společnosti mohly rychle najít a použít ve svých obchodních procesech. BPEL definuje chování obchodních procesů na základě dt,-services. BPEL implementuje funkci exportu a importu výhradně pomocí rozhraní webových služeb. BPEL zapadá do základní architektury webových služeb postavené na UDDI, WSDL, XML a XML Schema. BPEL je postaven na třech klíčových vlastnostech: asynchronii, koordinaci vláken a zpracování výjimek. Všechny se týkají výzev, kterým vývojáři čelí při správě integrací. Asynchrony Asynchronie se zabývá asynchronními interakcemi, korelací zpráv a spolehlivostí. Podpora asynchronie je vyžadována pro umožnění webových služeb v integračních scénářích a je povinná pro optimální využití pracovní doby (pro lepší rozložení zpracování umožňuje uživatelům zasahovat během obchodního toku nebo zpožděného dávkové zpracování). Oddělením požadavků na služby od jejich odpovídajících odpovědí asynchronie zlepšuje škálovatelnost a pomáhá vyhnout se úzkým místům při spouštění aplikací. Navíc umožňuje nepřetržité spouštění, když jsou služby dočasně nedostupné a když jsou spuštěni klienti offline režimu nebo invalidní. Koordinace toku. (Koordinace vláken) Koordinace vláken zahrnuje paralelní vlákno provádění, vzory připojení a dynamická vlákna. V aplikacích reálného světa mohou obchodní toky zahrnovat vzorce složitých interakcí se synchronními i asynchronními službami. Koordinace vláken zahrnuje rozhraní k WSDL, akce vláken, proměnné XML a je zodpovědná za kompenzaci. BPEL používá WSDL k odkazování na vyměňované zprávy, vyvolané operace a typy portů. Akce toku používají sdílené proměnné XML, takže obslužné rutiny kompenzací musí ukládat snímky dat, které může obslužný program použít. Kompenzační procesory mohou vrátit zpět kroky, které již byly dokončeny. BPEL zahrnuje základní a strukturované činnosti. (BPEL zahrnuje základní a strukturované činnosti). Základní akce se skládají z jednotlivých kroků pro interakci se službou, manipulaci s vyměňovanými daty nebo zpracování výjimečných podmínek, které se vyskytly během provádění. Strukturované akce definují posloupnost provádění a popisují vytvoření procesu a převádějí akce, které provádějí, do struktur; Tyto struktury zahrnují datový tok, řídicí vzory, externí zpracování událostí, zpracování chyb a koordinaci zpráv. Správa výjimek. (Správa výjimek). Správa výjimek se zabývá synchronními chybami, asynchronní ovládání výjimečné situace a kompenzace za obchodní transakce. Za účelem automatizace obchodních procesů je velké úsilí zaměřeno na správu výjimek a BPEL zjednodušuje správu výjimek pro webové služby. Když nastanou výjimky, jsou vyvolány místní obslužné rutiny chyb přidružené k webovým službám a asynchronní služby jsou o těchto výjimkách informovány. Přes protokol HTTP (jednosměrné synchronní volání) - webové služby XML; Přes MCF (Microsoft Communication Fundation) – asynchronní obousměrné zasílání zpráv – webové služby MCF. Vytvoření webové služby (webové služby) v sadě Visual Studio je podobné jako vytvoření webové stránky. Můžete také použít nástroj pro vývoj webu Microsoft Visual Webový vývojář pro odkazy a používání webových služeb, které najdete v řešení Visual Web Developer místní počítač, stejně jako v místním nebo externím adresáři UDDI. Podíváme se na provádění následujících úkolů: 8.7.1. Vytvoření webové služby v ASP .Net. Průvodce krok za krokem http://msdn.microsoft.com/ru-ru/library/8wbhsy70.aspx Soubor – Nový web Otevře se dialogové okno Nový web Vytvoří se soubor Service.asmx s odkazem na servisní kód @ WebService Language="C#" CodeBehind="~/App_Code/Service.cs" Class="Service" %> A soubor s kódem služby: Service.cs pomocí systému; pomocí System.Linq; pomocí System.Web; pomocí System.Web.Services; Veřejná služba() ( // InitializeComponent(); Veřejný řetězec HelloWorld() ( Návrat "Ahoj světe"; Atribut určuje jmenný prostor pro webovou službu Atribut se týká způsobu, jakým je definován WSDL Přidání metody přístupné prostřednictvím webové služby se provede napsáním příslušného kódu a zadáním kvalifikátoru přístupu metody jako veřejnost. Metoda musí mít atribut 2. Kompilace a testování webové služby Uložte službu a spusťte prohlížeč Podporovány jsou následující operace. Pro formální definici viz Popis služby
. Z odkazu - Ahoj Světe
popis servisního volání. Struktura požadavku a odpovědi SOAP a jak budou vypadat při použití metod GET a POST HTTP. Chcete-li otestovat volání metody, klepněte na tlačítko Spustit. http://tempuri.org/"> Ahoj světe Příklad Služba, která obsahuje dvě metody. Metoda Example1() vrací řetězec "Hello from ASP.Net!"; Metoda Summa vrací součet dvou celých čísel předávaných parametry. pomocí systému; pomocí System.Web; pomocí System.Web.Services; pomocí System.Web.Services.Protocols; služba veřejné třídy: System.Web.Services.WebService Veřejná služba() ( //Pokud používáte navržené komponenty, odkomentujte následující řádek //InitializeComponent(); Veřejný řetězec Example1() ( Návrat "Ahoj z ASP.Net!"; Public int Summa(int a, int b) VS má vestavěný Web DeveloperServer, který je nutné spustit při volání služby. Vytvořená webová služba je hostována na tomto serveru. Pojďme vytvořit další webovou službu pro překlad teploty (příklad z MSDN) Potřebujeme vytvořit webovou službu, která převede teplotu Fahrenheita na teplotu Celsia a naopak. Tento příklad vytvoří dvě metody v jedné webové službě. První metoda převádí teplotu ve stupních Celsia na teplotu ve stupních Celsia a druhá metoda převádí teplotu ve stupních Celsia na teplotu ve stupních Fahrenheita. Všimněte si, že názvům funkcí předchází atribut (>) jako součást deklarace funkce. Po zadání funkcí soubor uložte. Kompletní kód je níže. pomocí System.Collections; pomocí System.Linq; pomocí System.Web; pomocí System.Web.Services; pomocí System.Web.Services.Protocols; pomocí System.Xml.Linq; /// Souhrnný popis pro Convert // Chcete-li povolit volání této webové služby ze skriptu pomocí ASP.NET AJAX, zrušte komentář na následujícím řádku. public class Převést: System.Web.Services.WebService ( public Convert() ( //Pokud používáte navržené komponenty, odkomentujte následující řádek //InitializeComponent(); Veřejný řetězec HelloWorld() ( Návrat "Ahoj světe"; Veřejný dvojitý FahrenheitToCelsius (dvojitý Fahrenheit) Návrat ((Fahrenheit - 32) * 5) / 9; Veřejný dvojnásobek Celsia na Fahrenheit (dvojnásobný stupeň Celsia) Návrat ((Celsius * 9) / 5) + 32; Nyní můžete testovat webovou službu ve Visual Web Developer. Jakmile dokončíte vytváření webové služby, dalším krokem je její použití. 8.7.2. Použití webové služby v aplikaci Nyní, když je webová služba vytvořena, vytvoříte webovou stránku, která bude používat vytvořenou webovou službu. Je třeba vytvořit samostatný web se stránkou, ze které se budou spouštět nově vytvořené metody webové služby. K tomu je potřeba vytvořit klientskou aplikaci (spotřebitele služby). Vytvořme si stránku ASP.Net jako takového klienta. Vytvořme si například stránku se dvěma tlačítky, po kliknutí se zavolají služby. Volání webové služby z klientské aplikace se provádí prostřednictvím zprostředkující třídy (proxy class). Webová služba je komponenta, na kterou lze v aplikaci odkazovat. Proto je nutné na něj vytvořit odkaz. Když Visual Web Developer najde webovou službu, zobrazí se informace o webové službě v dialogovém okně Přidejte webový odkaz. Poznámka. Musí běžet webový server Vývojářský server/ 3. Zavolejte službu ze stránky ASP Příklad 1: Výpočet součtu čísel 1. Vytvořte formulář se dvěma textovými poli a tlačítkem Částka. V obslužné rutině tlačítka přidejte volání metody. Připojte jmenný prostor localhost pomocí systému; pomocí System.Data; pomocí System.Configuration; pomocí System.Web; pomocí System.Web.Security; pomocí System.Web.UI; pomocí System.Web.UI.WebControls; pomocí System.Web.UI.WebControls.WebParts; pomocí System.Web.UI.HtmlControls; pomocí localhost; veřejná částečná třída _Default: System.Web.UI.Page Chráněné void Page_Load(odesílatel objektu, EventArgs e) Chráněné void Button1_Click(odesílatel objektu, EventArgs e) Služba myService= nová služba(); Label1.Text = myService.Example1(); Protected void Button2_Click(odesílatel objektu, EventArgs e) Int a, b, součet; A = int.Parse(txt_a.Text); B = int.Parse(txt_b.Text); // suma = a + b; Služba myService1 = nová služba (); Summa = mojeSlužba1.Summa(a,b); Txt_summa.Text = summa.ToString(); Příklad 2: Volání metod převodu teploty Vytvořte na stránce formulář s následujícími poli: protected void ConvertButton_Click(odesílatel objektu, EventArgs e) Localhost.Convert wsConvert = nový localhost.Convert(); Dvojitá teplota = System.Convert.ToDouble(TemperatureTextbox.Text); FahrenheitLabel.Text = "Fahrenheit na stupně Celsia = " + WsConvert.FahrenheitToCelsius(teplota).ToString(); CelsiusLabel.Text = "Celsius To Fahrenheit = " + WsConvert.CelsiusToFahrenheit(teplota).ToString(); Webovou službu můžete ladit stejným způsobem jako ladění webových stránek. Za prvé pomocí DISCO (zkratka slova discovery) – souborového mechanismu pro vyhledávání lokálních webových služeb, tedy mechanismu pro získání seznamu dostupných webových služeb ze souborů DISCO umístěných na webových serverech. Soubory DISCO navíc obsahují záznamy o umístění smluv WSDL o dostupných službách. Soubor DISCO je soubor XML se záznamy. Je také možné použít soubory VSDISCO, které jsou podobné souborům DISCO, ale jejich obsah je výsledkem dynamického vyhledávání webových služeb v určených adresářích a všech podadresářích. ASP .NET mapuje příponu souboru .vsdisco na obsluhu HTTP, která v daném adresáři a jeho podadresářích vyhledá asmx a disco a vrátí dynamicky generovaný DISCO dokument. Z bezpečnostních důvodů je dynamické vyhledávání v některých verzích rozhraní .NET Framework zakázáno, ale můžete jej povolit úpravou položek v souboru Machine.config. Jak vyhledáváte webové služby v globální síti? Pro vyhledávání webových služeb v globální síti vyvinuly společnosti Microsoft, IBM a Ariba společně UDDI (Universal Description Discovery and Integration) – specifikaci pro budování distribuovaných databází, která umožňuje vyhledávat webové služby. UDDI podporují stovky společností. Stránky UDDI jsou samy o sobě webovými službami. Každý může publikovat svůj registr založený na UDDI. Většina vývojářů nikdy nepoužívá UDDI API přímo. Místo toho k registrům UDDI přistupují vývojové nástroje. Generují také obalové třídy pro objevené a vybrané webové služby. Webové službyřešit problém integrace aplikací různého charakteru a budování distribuovaných informačních systémů. To je hlavní zásadní rozdíl mezi webovými službami a jejich předchůdci – technologiemi pro interakci distribuovaných aplikací, které tak či onak umožňovaly realizovat výměnu dat mezi aplikacemi (mezi nejrozvinutější patří Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI)) a Common Object Request Broker Architecture (CORBA)). Každý z nich byl ale poměrně složitý na implementaci, neměl potřebnou univerzálnost (tedy stále záleželo na volbě např. stejného operačního systému pro všechny účastníky směny) a co je obzvláště špatné, tyto technologie bylo velmi obtížné mezi sebou integrovat.
Rýže. 10.1.Simple Object Access Protocol (SOAP)
NÁVRH NA ZÁKLADĚ TECHNOLOGIE WEBOVÝCH SLUŽEB
"ASOCIACE VÝZKUMU A VÝROBY "AURORA",
vedoucí laboratoře Pakhomenkov Jurij Michajlovič
8.1. Základy webových služeb
Webová služba Webová služba (viz dokument W3C „Požadavky na architekturu webových služeb“) je softwarový systém identifikovaný řetězcem URI, jehož rozhraní a vazby jsou definovány a popsány v jazyk XML. Popis tohoto softwarového systému lze nalézt u jiných softwarových systémů, které s ním mohou interagovat podle tohoto popisu prostřednictvím zpráv, založené na XML a přenášené pomocí Internetové protokoly.
Nedostatky
webové služby zajišťují interakci softwarových systémů bez ohledu na platformu;
webové služby jsou založeny na otevřených standardech a protokolech. Díky použití XML je dosaženo snadného vývoje a ladění webových služeb;
Používání internetový protokol HTTP zajišťuje interakci softwarových systémů přes firewall.
Webové služby jsou podobné knihovnám DLL, ale mají následující charakteristické rysy:
Axis a Tomcat (oba jsou projekty Apache).
Mono vývojová platforma od Novellu
Servery Microsoft .NET od společnosti Microsoft
Java Web Services Development Pack (JWSDP) od Sun Microsystems (založené na Jakarta Tomcat)
Zope je objektově orientovaný webový aplikační server napsaný v Pythonu
Aplikační server od IBM (založený na platformě Apache a J2EE)
Cordys WS-AppServer
Software pro správu dokumentů infoRouter Web Services API
JOnAS (součást iniciativy ObjectWeb Open Source)
Web Application Server od společnosti SAP (Web AS je klíčovou součástí zásobníku SAP NetWeaver)
Pramati Application Server od Pramati Technologies Limited
Platforma OpenEdge od společnosti Progress Software
Oracle Application Server od společnosti Oracle Corporation
Zend Framework – od Zend Technologies
Pythomnic je platforma pro psaní distribuovaných síťových služeb.
Google App Engine je platforma pro vysoce škálovatelné aplikace využívající infrastrukturu Google.
spouštěné na straně serveru;
poskytovat sadu metod dostupných externím klientům;
provádět webové metody a vracet výsledky klientům;
webové služby a jejich klienti mohou být zapsáni různé jazyky a/nebo různé platformy. 8.3. Zásobník technologií webových služeb
Webové služby vyžadují použití několika souvisejících technologií XML, které tvoří technologický zásobník (obrázek 8.1).
XML je základem, na kterém jsou webové služby postaveny. Poskytuje jazyk pro definování dat a způsobu jejich zpracování. XML představuje rodinu souvisejících specifikací publikovaných a spravovaných Internetovým konsorciem (W3C) a dalšími organizacemi.
SOAP (Simple Object Access Protocol), vyvinutý konsorciem W3C, definuje formát požadavků na webové služby. Zprávy mezi webovou službou a jejím uživatelem jsou baleny do tzv. SOAP obálek (někdy také nazývaných XML obálky). Samotná zpráva může obsahovat buď požadavek na provedení nějaké akce, nebo odpověď – výsledek provedení této akce.
WSDL (Web Services Description Language) je technologie založená na XML, která definuje rozhraní webových služeb, typy dat a zpráv, stejně jako modely interakce a vazebné protokoly. Před nasazením služby vytvoří vývojář její popis ve WSDL, uvede adresu webové služby, podporované protokoly, seznam povolených operací, formáty požadavků a odpovědí.
Technologie UDDI (Universal Description, Discovery and Integration) je registr webových služeb a vyhledávač. Používá se k ukládání a organizování informací o webových službách a také k nalezení ukazatelů na rozhraní webových služeb.
8.4 Interakce s webovými službami
Rozhraní webových služeb přijímají standardní zprávy XML ze síťového prostředí, převádějí data XML do formátu, kterému „rozumí“ specifický aplikační softwarový systém, a odesílají zprávu s odpovědí (druhá možnost je volitelná). Softwarovou implementaci webových služeb (základní software, nižší úroveň) lze vytvořit v libovolném programovacím jazyce s použitím libovolného operačního systému a libovolného middlewaru. 
Každá komponenta může hrát buď pouze jednu roli (například být pouze uživatelem služby), nebo několik rolí současně (například být poskytovatelem některých služeb a uživatelem jiných).
uživatel služby: aplikace, softwarový modul nebo služba, která vyhledává a volá požadovanou službu z registru služeb podle popisu služby a zároveň využívá službu poskytovanou poskytovatelem služby v souladu s rozhraním služby;
poskytovatel služeb: aplikace, softwarový modul nebo služba, která implementuje službu ve formě webové služby, přijímá a provádí požadavky od uživatelů služby a také publikuje službu v registru služeb;
servisní registr: Knihovna služeb, která uživatelům služeb poskytuje prostředky k nalezení a volání požadované služby a přijímá požadavky poskytovatelů služeb na zveřejnění služeb.
Když uvažujeme o interakci komponent architektury orientované na služby, je nutné si všimnout přítomnosti (a rozdílu) následujících dvou artefaktů:
vydání: aby byla služba přístupná (volatelná) uživatelům služby, je nutné dát jim vědět její rozhraní;
vyhledávání: uživatel služby musí být schopen najít potřebnou službu v registru služeb, která splňuje zadaná kritéria;
otroctví a výzva: Po obdržení popisu služby by měl být uživatel služby schopen vyvolat a používat službu podle popisu služby.
popis služby: určuje formát požadavku a odpovědi během interakce mezi uživatelem služby a poskytovatelem služby a také požadovanou kvalitu služby;
servis: Samotná služba, kterou může uživatel služby vyvolat a používat podle publikovaného rozhraní služby.8.5. Architektura aplikací orientovaná na služby
8.5.1. Základy architektury orientované na služby
8.5.2. Technologie pro implementaci servisně orientované architektury
K vytváření složitých distribuovaných aplikací nestačí jeden zásobník základních technologií (SOAP, WSDL, UDDI). Je třeba řešit další problémy, jako je zajištění výkonu, zabezpečení, spolehlivé doručování zpráv, koordinace transakcí a další. Proto se tato technologie neustále rozšiřuje. Na Obr. 8.3 představuje rozšířenou sadu technologií webových služeb, včetně již standardizovaných i nových technologií. 
Tyto komponenty jsou zase tvořeny několika vrstvami:
technologie, které poskytují funkčnost Webové služby (Funkce);
technologie, které poskytují kvalitu služeb webové služby (Kvalita služeb).
technologie, které poskytují funkčnost webových služeb:
transportní vrstva;
servisní komunikační vrstva;
vrstva popisu služby;
servisní vrstva;
vrstva obchodních procesů;
vrstva servisního registru.
Technologie, které zajišťují kvalitu webových služeb:
politická vrstva;
bezpečnostní vrstva;
transakční vrstva;
vrstva správy.
№ p/p
Název vrstvy
Účel vrstvy
Technologie, které implementují vrstvu
Funkce
1
Transportní vrstva
Popisuje prostředky pro výměnu dat mezi webovými službami
Standard: HTTP, JMS (pro aplikace Java), SMTP
2
Komunikační vrstva služby
Popisuje prostředky pro formalizaci mechanismů pro používání transportních protokolů webovými službami.
Standard: SOAP
3
Vrstva popisu služby
Popisuje prostředky formalizace rozhraní webových služeb s cílem zajistit jejich fungování bez ohledu na softwarovou a hardwarovou implementační platformu nebo programovací jazyk.
Standard: XML, WSDL
4
Servisní vrstva
Popisuje software nazývaný pomocí WSDL popisy rozhraní webových služeb. Zejména se jedná o samotné webové služby
5
Vrstva obchodních procesů
Popisuje možnosti organizace webových služeb pro implementaci obchodních procesů a pracovních toků. Zároveň jsou definována pravidla, která specifikují posloupnost interakce webových služeb za účelem splnění obchodních požadavků
6
Vrstva servisního registru
Popisuje možnosti organizace webových služeb do hierarchických knihoven, které umožňují publikování, vyhledávání a volání webových služeb na základě jejich popisů rozhraní WSDL.
Standard: UDDI
Kvalita služeb
7
Politická vrstva
Popisuje podmínky, za kterých lze webové služby používat. Jelikož se tyto obchodní podmínky týkají jak funkčního aspektu webových služeb, tak aspektu kvality služeb na Obr. 8.3 je tato vrstva společná pro oba aspekty
Standardní: Momentálně žádný
8
Bezpečnostní vrstva
Popisuje možnosti zajištění bezpečnosti webových služeb a bezpečnosti jejich provozu (autorizace, autentizace a sdílení přístupu)
Standard: WS-Security
9
Transakční vrstva
Popisuje transakční vlastnosti distribuovaných systémů založených na webových službách, aby byla zajištěna spolehlivost jejich fungování
Standardní: Momentálně žádný
Novinka: WS-Transaction a WS-Coordination
10
Vrstva správy
Popisuje možnosti správy webových služeb a charakteristiku jejich fungování
Nový:8.6. Složení webových služeb
Složitelnost webových služeb je často považována za jednu z hlavních výhod technologie, která zajišťuje jejich opakované opětovné použití. Obecně řečeno, složení webových služeb je nalezení sady atomických služeb potřebných k implementaci uživatelského požadavku a určení pořadí, ve kterém jsou vykonávány.
Choreografie a orchestrační standardy jsou založeny na WSDL. Na úrovni modelu podnikových procesů byly navrženy takové standardy jako Wf-XML (Workflow Management Coalition), WSFL (IBM Web Services Flow Language), XLANG (Microsoft's XLANG: Business modeling language for BizTalk), PIPs (Partner RosettaNet). navrhovaný proces rozhraní).
BPEL definuje konstrukce potřebné pro sestavení sady služeb pro obchodní procesy spojené se spoluprací a transakcemi.
WSCI vyvíjí od roku 2002 pracovní skupina konsorcia W3C (organizovaná pracovní skupina pracovní skupina pro choreografii webových služeb);
Pro vývoj BPEL4WS byl v roce 2003 v konsorciu OASIS vytvořen technický výbor - OASIS Web Services Business Process Execution Language TC (WS-BPEL TC).8.7. Webové služby v ASP.Net
Technologie webových služeb v ASP.Net rozšiřuje možnosti vytváření webových aplikací. ASP.Net v současné době podporuje dva způsoby vývoje a volání webových služeb:
Tento úkol budeme realizovat formou dvou samostatných řešení.
vytvoření jednoduché webové služby XML ve Visual Web Developer;
vytvoření samostatné webové stránky pomocí webové služby.
Otevřete Visual Web Developer.
V nabídce Soubor vyberte položku Vytvořte web.
Webová služba ASP.Net
V sekci vyberte Webová služba ASP.NET.
Klepněte na tlačítko Recenze a vyberte cestu a název služby.
Na seznamu Jazyk vybrat C#
Klepněte na tlačítko OK.
Postupujte podle odkazu Popis služby na WSDL je popis službyVytvoření webové služby
V Průzkumníku řešení(Průzkumník řešení) klikněte pravým tlačítkem na názevvytvořená webová služba
(http://localhost/TemperatureWebService) a poté vyberte příkaz Přidat nový prvek.
Visual Web Developer vytvoří novou webovou službu sestávající ze dvou souborů. Soubor Convert.asmx je soubor, který lze volat k volání metod webové služby a ukazuje na kód webové služby. Samotný kód se nachází v souboru třídy (CONVERT.cs) ve složce App_Code. Soubor kódu obsahuje šablonu pro webovou službu. Soubor kódu obsahuje nějaký kód pro metodu webové služby.
V sekci Nainstalované šablony sady Visual Studio vyberte (Webová služba) a v poli Jméno zadejte Převést.
Ujistěte se, že je zaškrtávací políčko zaškrtnuté Umístěte kód do samostatného souboru a stiskněte tlačítko Přidat. Chcete-li vytvořit metody převodu, postupujte takto:
Přidejte následující kód do třídy bezprostředně za metodu HelloWorld: Chcete-li otestovat webovou službu, postupujte takto:
Zavolá se webová služba a v prohlížeči se zobrazí stránka, která zobrazuje metody poskytované webovou službou.
V Průzkumníku řešení vyberte Convert.asmx a stiskněte CTRL+F5.
Zobrazí se stránka s dotazem na hodnoty parametrů pro metodu CelsiusToFahrenheit.
Klepněte na tlačítko Celsia na Fahrenheit, který tuto metodu volá.
V novém okně se zobrazí data XML vrácená webovou službou při volání metody CelsiusToFahrenheit. Význam 212
zobrazeny v XML.
V terénu Celsia zadejte 100 a klikněte na tlačítko Volání.
Pokud zadáte 212, vrátí se metoda FahrenheitToCelsius 100
.
Zavřete prohlížeč obsahující výsledky metody.
V původní prohlížeč klikněte na tlačítko Zadní pro návrat na seznam metod.
Klikněte FahrenheitToCelsius a ujistěte se, že metoda vrací očekávaný výsledek.
Zavřete prohlížeč.1. Vytvořte web:
Visual Web Developer vytvoří nový místní web IIS a novou stránku s názvem Default.aspx.
V nabídce Soubor vyberte položku Vytvořte web.
V sekci Nainstalované šablony sady Visual Studio vybrat Web ASP.NET.
Zadejte název TemperatureWeb.
Na seznamu Jazyk vybrat C#
Klepněte na tlačítko OK. Chcete-li vytvořit odkaz na webovou službu, postupujte takto:
Otevře se dialogové okno Přidejte webový odkaz, jak je znázorněno na následujícím snímku obrazovky.
V nabídce webové stránky vybrat tým Přidejte webový odkaz. 
http://localhost/TemperatureWebService/Convert.asmx
Na seznamu URL zadejte následující adresu URL webové služby a klikněte na tlačítko Přechod:
Poznámka
Pokud nemůžete přidat odkaz na webovou službu, je možné, že proxy server není správně nakonfigurován. V aplikaci Microsoft Internet Explorer v nabídce Servis vyberte položku Možnosti internetu, vyberte kartu Spojení a poté klikněte na tlačítko Nastavení LAN. Zaškrtněte políčko Pro místní adresy nepoužívejte proxy. Také nastavte pole Adresa proxy serveru na přesný název serveru proxy, nikoli povolte aplikaci Internet Explorer detekovat server proxy sám. Další informace vám poskytne správce sítě.
Otevře se testovací stránka pro metodu.
Vyberte jeden z odkazů metody.
Visual Web Developer vytvoří složku App_WebReferences a přidá do ní složku pro nový webový odkaz. Ve výchozím nastavení je webovým odkazům přiřazen jmenný prostor, který odpovídá názvu jejich serveru (v tomto případě localhost). Poznamenejte si název jmenného prostoru webového odkazu. Visual Web Developer přidá soubor WSDL do složky, která odkazuje na webovou službu. Přidává také podpůrné soubory, jako jsou soubory zjišťování (soubory s příponami DISCO a DISCOMAP), které obsahují informace o umístění webové služby.
Klepněte na tlačítko Přidat odkaz. 
Chcete-li volat metody webové služby, postupujte takto:
Otevřete stránku Default.aspx a přepněte do návrhového zobrazení.
Ze skupiny Norma V panelu nástrojů přetáhněte na stránku následující ovládací prvky a nastavte jejich vlastnosti, jak je uvedeno v následující tabulce:
Stránka zobrazuje výsledek převodu hodnoty teploty mezi stupni Fahrenheita a Celsia.
Stisknutím kláves CTRL+F5 spustíte stránku.
Do textového pole zadejte hodnotu, například 100 ,
a stiskněte tlačítko Konvertovat.
Nejprve musíte nakonfigurovat web, který obsahuje webovou službu, aby bylo možné ladění.Chcete-li povolit ladění na webu webové služby, postupujte takto:
Nástroj pro správu webu vytvoří soubor Web.config pro web a nastaví možnosti konfigurace pro povolení ladění.
Nyní musíte povolit ladění pro web, který používá webovou službu.
Zavřete nástroj pro správu webu.Chcete-li povolit ladění na webu, postupujte takto:
Visual Web Developer otevře soubor kódu pro stránku.
Umístěte ukazatel na následující řádek:Zjištění webové služby
Jak ostatní vývojáři vědí o existenci webové služby? 8.8. Výsledky
Technologie Webové služby je moderní technologie, která poskytuje novou úroveň distribuce. Namísto vývoje nebo nákupu komponent a jejich zabudování do IS se navrhuje koupit jejich provozní dobu a vytvořit softwarový systém, který volá metodu z komponent vlastněných a podporovaných nezávislými poskytovateli.
