načítání...
nákupní košík
Košík

je prázdný
a
b

Kniha: SOA Servisně orientovaná architektura -- Kompletní průvodce - Thomas Erl

SOA Servisně orientovaná architektura -- Kompletní průvodce
-15%
sleva

Kniha: SOA Servisně orientovaná architektura -- Kompletní průvodce
Autor:

Potřebuje váš web kompletní změnu architektury? Plánujete zavádění webových služeb ve velkém měřítku? Nastaly nečekané potíže při přechodu na servisně orientované prostředí? ... (celý popis)
Titul doručujeme za 4 pracovní dny
Vaše cena s DPH:  990 Kč 842
+
-
rozbalKdy zboží dostanu
28,1
bo za nákup
rozbalVýhodné poštovné: 29Kč
rozbalOsobní odběr zdarma

hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%hodnoceni - 0%   celkové hodnocení
0 hodnocení + 0 recenzí

Specifikace
Nakladatelství: » Computer press
Médium / forma: Tištěná kniha
Rok vydání: 2009-01-19
Počet stran: 672
Rozměr: 167 x 225 mm
Úprava: 671 stran : ilustrace
Vydání: Vyd. 1.
Název originálu: Service-oriented architecture : concepts, technology and design
Spolupracovali: překlad Ondřej Baše, Lukáš Krejčí
Vazba: vázaná s laminovaným potahem
ISBN: 9788025118863
EAN: 9788025118863
Ukázka: » zobrazit ukázku
Popis

Potřebuje váš web kompletní změnu architektury? Plánujete zavádění webových služeb ve velkém měřítku? Nastaly nečekané potíže při přechodu na servisně orientované prostředí? Pro všechny tyto potřeby, nutné změny a problémy je zde kompletní průvodce architekturou SOA. Publikace prochází veškerými důležitými kroky při zavádění a správě webových služeb: od plánování a analýzy přes technologii a návrh až po metadata, zabezpečení a zásadní pravidla při aplikaci standardů. Autor uvádípřes 120 konkrétních případových studií, na jejichž základě předává desítky praktických doporučení, varování a rad. Zkušený autor pokrývá mimo jiné tato témata: - Základy budování SOA, principy servisní orientace - Vzory výměny zpráv, orchestrace, choreografie, modelování služeb - Strategie zavádění SOA a servisně orientované modelování podniku - Vrstvy služeb aplikace, řízení, instrumentace, agnostické služby - Základy a využití jazyků XML, WSDL, SOAP, WS-BPEL - WS-Coordination a servisně orientovaný návrh řídicích procesů - Nástroje pro návrh rozhraní služeb - Podpora SOA ze strany platforem Java EE a .NET - Aplikace hlavních standardů SOA, pravidla pro návrh služeb - Pravidla a kroky pro kompozici SOA, rozšíření SOA Speciálně pro české čtenáře byl přeložen slovník pojmů včetně všech schémat z adresy www.soaglossary.com, aby byl první vhled do servisně orientované architektury co nejnázornější a nejprůhlednější. O autorovi: Thomas Erl je světově nejproslulejším a nejplodnějším autorem knih o SOA. Na kontě jich má již přes deset. Založil společnost SOA Systems (www.soasystems.com), která poskytuje konzultační a školicí služby více než 500 firmám po celém světě. Navštivte www.thomaserl.com. (kompletní průvodce)

Předmětná hesla
Kniha je zařazena v kategoriích
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky

KAPITOLA 15

Servisně

orientovaný návrh

(část 3: Návrh služeb)

Ještě před tím, než se můžeme pustit do vývoje služby, musíme definovat její rozhraní. Jedná se o klasické zaříkávadlo všeobecně přijímaného přístupu ve stylu „nejdříve

WSDL“ pro návrh webových služeb, a zároveň jde o základ pro každý ze tří procesů

návrhu služeb, které si popíšeme v této kapitole. Definování rozhraní služby před

vlastním vývojem je důležité pro ustavení vysoce standardizované servisně orientované

architektury a vyžaduje realizaci několika charakteristik, které jsme identifikovali jako

součásti současné SOA.

Konkrétně lze vytvořením kontraktu služby před její logikou získat následující výhody:

Služby mohou být navrženy tak, aby přesně reprezentovaly kontext funkci jim

odpovídajících kandidátů služeb.

Na názvy operací služeb lze aplikovat jisté konvence, což vede kestandardizovaným definicím koncových bodů.

Členění operací může být modelováno abstraktně, čímž získáme konzistentní a předvídatelné návrhy rozhraní, které mimo jiné ustavují poměr velikosti

a objemu zpráv vhodný pro cílovou komunikační infrastrukturu.

Základní aplikace se musejí přizpůsobit stylu návrhu služeb a ne naopak. (To

vede často k tvorbě fasádní řídicí vrstvy, která musí komponovat staršíkomponenty spoléhající na komunikaci v RPC stylu.)

S návrhem řídicích služeb mohou pomáhat podnikoví analytici, kteří se postarají

o přesnou reprezentaci řídicí logiky. Popisy procesů nabízené v této kapitole jsou ve své povaze obecné a navrhují pouze série určitých kroků pro dokončení návrhu rozhraní služeb. Je třeba na ně pohlížet jako na výchozí body, od nichž mohou organizace odvodit své vlastní, na míru šité návrhové procesy.

„

„

„

„

„


Část V – Budování SOA (technologie a návrh)408

Případové studie: Případové studie budou mít v této kapitole vyšší význam, neboť jejich

prostřednictvím se seznámíme s ukázkami ve značkovacích jazycích. Jistou podmnožinu

kandidátů služeb vytvořených v kapitole 11 v podstatě protáhneme návrhovými procesy

stanovenými v této kapitole.

Jako součást těchto procesů vytvoříme nejrůznější WSDL definice a s nimi spojená XSDschémata. Kompletní verze těchto souborů lze stáhnout na adrese www.serviceoriented.ws.

Poznámka

Výsledné WSDL dokumenty a XSD schémata z těchto příkladů byly testovány proti

verzi 1.1 specifikace WS-I Basic Profile.

Přehled návrhu služeb

Konečným cílem těchto procesů je dosažení vyváženého návrhu služby. To obvyklepředstavuje jistou webovou službu, která vyhovuje požadavkům a omezením reálného světa, a přitom zvládá:

zapouzdřit požadované množství logiky,

podřídit se principům servisní orientace,

vyhovět podnikovým požadavkům.

Nyní se možná díváte na svůj seznam kandidátů služeb a přemýšlíte, kde vlastně začít. Je

dobré si tuto otázku položit, neboť existuje preferovaná posloupnost pro tvorbu návrhůslužeb. Obecné pravidlo zní: začněte návrhově agnostickými, znovupoužitelnými službami. To

umožňuje službám, jež představují logiku specifickou pro nějaký proces, komponovatznovuoužitelné služby jako fixní prostředky (což také prověří kvalitu jejich znovupoužitelnosti).

V souladu se čtyřmi hlavními typy vrstev se službami, které jsme dříve identifikovali, vypadá

doporučená posloupnost při návrhu následujícím způsobem:

1. entitně zaměřené řídicí služby (kapitola 15),

2. aplikační služby (kapitola 15),

3. úlohově zaměřené řídicí služby (kapitola 15),

4. procesní služby (kapitola 16). Tato posloupnost je ve skutečnosti více než jen jakýmsi vodítkem, neboť proces návrhu služeb ve skutečnosti není vždy tak jasný. Například po vytvoření počáteční sady návrhů aplikačních služeb postoupíte k budování úlohově zaměřených služeb. Jenomže až při začleňovánínejrůznějších operací zjistíte, že pro jejich provedení potřebujete další funkce na úrovni aplikačních služeb. V důsledku pak musíte revidovat návrhy aplikačních služeb, abyste určili, zdali máte přidat operace nebo zcela nové služby.

„

„

„


409Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Návrhové standardy

Je důležité poznamenat, že pro dosažení úspěšné SOA je stálá sada návrhových standardů

naprosto kritická. Vzhledem k tomu, že návrh, který definujeme jako část této fáze, je konkrétní a permanentní, musí být každá vytvořená služba maximálně konzistentní. V opačném

případě budou klíčové výhody SOA, jako je znovupoužitelnost, komponovatelnost a především pružnost, ohroženy. Proto se předpokládá, že před zahájením této fáze jsou již návrhové

standardy stanoveny. (Část Pravidla pro návrh služeb na konci této kapitoly poskytuje určitá

doporučení, jež mohou pomoci při formování základů těchto standardů.)

V našem předchozím procesu servisně orientované analýzy jsme na návrhové standardy

nekladli tak silný důraz (nutnost standardů jsme sice zmínili, neustavili jsme je však jako

součást samotného procesu). To je především dáno tím, že kandidáti služeb mohou být

i po vývoji a implementaci odpovídajících služeb bez výrazného dopadu dále modifikováni

a vylepšováni. Standardy jsou pro servisně orientovanou analýzu stále důležité, ne však tolik,

jako pro servisně orientovaný návrh, jehož jsou integrální součástí.

O popisech procesů

Ukázkové procesy se v této části skládají z obecných sad kroků, jež zdůrazňují primárníčinitele pro tvorbu návrhů služeb. Jedná se o naši poslední šanci pro zajištění, aby služby náležitě

vyjadřovaly svůj účel a schopnosti.

U každého vytvořeného popisu abstraktní služby definujeme formálně následující části:

definice všech operací služby,

definice každé vstupní a výstupní zprávy operace,

definice souvisejících typů XSD schématu používaných pro reprezentaci obsahu

zprávy.

Všimněte si, že jednotlivé návrhy služeb složíme později (v kapitole 16) do definice WS-BPEL

procesů.

Předpoklady

Jak jsme si vysvětlili v kapitole 13, naše procesy návrhu služeb přistupují k tvorbě rozhraní

služeb z perspektivy manuálního programování. To znamená, že během popisů procesů se

nevyhneme řadě odkazů na značkovací jazyky WSDL a XSD schéma.

Kromě toho pro podporu našich procesů poskytují četné ukázky případových studií skutečné

příklady z oblasti značkovacích jazyků WSDL a XSD schéma. Pro co nejhlubší pochopení

popisů procesů a s nimi souvisejících příkladů je tedy vhodné pročíst tutoriály týkající se

jazyků WSDL a XSD nabízené kapitolou 13.

PŘÍPADOVÉ STUDIE

Obě naše smyšlené organizace dokončily fázi servisně orientované analýzy pro svou SOA.

Během toho obě ustanovily určitou sadu kandidátů služeb, které budou tvořit základ pro

jejich servisně orientovaný návrh. Pojďme se nyní podívat, které z těchto kandidátůzačleníme do příkladů roztroušených v této kapitole.

„

„

„


Část V – Budování SOA (technologie a návrh)410

Cvičení v modelování služeb provedené společností TLS vedlo k vytvoření následujících pěti

nových kandidátů služeb, jež představují nové řešení Předložení pracovních výkazů:

proces Předložení pracovních výkazů (proces),

Zaměstnanec (entitně zaměřená služba),

Pracovní výkaz (entitně zaměřená služba),

Faktura (entitně zaměřená služba),

Upozornění (aplikační služba). Podle navrhované posloupnosti při návrhu bude společnost TLS podrobovat odpovídajícímu procesu návrhu služeb nejdříve tři výše uvedené entitně zaměřené služby. Poté navrhne službu Upozornění společně s dalšími požadovanými aplikačními službami. Nakonec přinávrhu procesní služby Předložení pracovních výkazů pomocí definice WS-BPEL procesu definuje vlastní logiku obchodního procesu. Během všech těchto činností se naše příklady zaměří na návrh následujících dvou služeb:

Na kandidáta služby Zaměstnanec se budeme odkazovat v příkladech, které jsousoučástí popisu procesu Návrh entitně zaměřených řídicích služeb.

Kandidát procesní služby Předložení pracovních výkazů se stane základem pro logiku pracovního toku nezbytného k ustavení náležité kompozice služeb pro proces

Předložení pracovních výkazů. (Společnost TLS toho docílí v kapitole 16.) Mezi kandidáty služeb modelované společností RailCo patří následující čtyři aplikační služby a dvě úlohově zaměřené řídicí služby.

Zpracování faktur (úlohově zaměřená služba).

Zpracování objednávek (úlohově zaměřená služba).

Původní systém (aplikační služba).

Upozornění na aktualizace (aplikační služba).

Převod účetních dokumentů (aplikační služba).

Kontrola metadat (aplikační služba). V příkladech našeho popisu procesu návrhu budeme pracovat s dvěma kandidáty služeb:

Pomocí kandidáta služby Převod účetních dokumentů demonstrujeme popis procesu

Návrh aplikačních služeb.

Kandidáta služby Zpracování faktur použijeme v části Návrh úlohově zaměřených řídicích

služeb. SHRNUTÍ HLAVNÍCH POZNATKŮ

Tři návrhové procesy popsané v této kapitole jsou založené na přístupu „nejdříve

WSDL“.

Návrhové standardy hrají kritickou roli při utváření procesu návrhu služeb a při zajištění

konzistentně standardní SOA. „ „ „ „ „ „ „ „ „ „ „ „ „ „ „ „ „


411Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Návrh entitně zaměřených

řídicích služeb (krok za krokem)

Entitně zaměřené řídicí služby představují právě tu vrstvu služeb, která je nejméněovlivňována ostatními. Jejím účelem je přesně reprezentovat odpovídající datové entity definované

v rámci obchodních modelů organizace. Tyto služby jsou vzhledem k řešení a obchodnímu

procesu striktně agnostické, budují se pro opětovné použití jakoukoli aplikací, jež potřebuje

přistupovat nebo spravovat informace spojené s konkrétní entitou.

Obrázek 15.1. Entitně zaměřené služby utvářejí vrstvu řídicích služeb

Díky tomu, že ve vztahu k ostatním vrstvám služeb existují spíše atomicky, je výhodnénavrhovat entitně zaměřené řídicí služby před ostatními. Tím se ustaví abstraktní vrstva služeb,

kolem níž lze rozmístit procesní i základní aplikační logiku.

Popis procesu

Následuje popis procesu vedený krok za krokem, v rámci něhož ustavíme doporučovanou

posloupnost detailních kroků pro dosažení kvalitního rozhraní entitně zaměřených řídicích

služeb (viz obrázek 15.2).

entitně

zaměřené

řídicí služby

sídlí ve vrstvě

řídicích služeb

vrstva

řídicích procesů

vrstva

rozhraní služeb

aplikační

vrstva


Část V – Budování SOA (technologie a návrh)412

Obrázek 15.2. Návrhový proces entitně zaměřených řídicích služeb

Servisně

orientovaná

analýza

Přezkoumejte

stávající

služby

Servisně

orientovaný

návrh

Definujte

entitní

schéma

Komponujte

SOA

Vývoj

služeb

Odvoďte

abstraktní

rozhraní

Navrhněte

entitně zaměřené

řídicí služby

Testování

služeb

Aplikujte

servisní

orientaci

Navrhněte

aplikační

služby

Nasazení

služeb

Standardizujte

rozhraní

služby

Navrhněte

úlohově zaměřené

řídicí služby

Správa

služeb

Rozšiřte

návrh

služby

Navrhněte

řídicí

proces

Identifikujte

nezbytné

zpracování

Krok 7

Krok 6

Krok 5

Krok 4

Krok 3

Krok 2

Krok 1


413Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Všimněte si, že pořadí, v němž se tyto kroky objevují, není pevně dáno. Můžete tak například

definovat předběžné rozhraní služby před stanovením skutečných datových typů používaných

pro reprezentaci obsahu těla zprávy. Nebo můžete shledat efektivnějším provést spekulativní

analýzu k identifikaci možných rozšíření pro služby před prvním nástinem jejího rozhraní.

Všechny výše uvedené přístupy jsou legitimní. Klíčem je zajistit, aby se návrhové standardy

nakonec aplikovaly rovnoměrně na všechny operace služeb, a aby se přesně identifikovaly

veškeré požadavky na zpracování.

Začněme tedy návrhem našich entitně zaměřených řídicích služeb.

PŘÍPADOVÉ STUDIE

V příkladech nabízených vedle popisu tohoto procesu opět navštívíme prostředí společnosti TLS.

Konkrétně se znovu podíváme na kandidáta služby

Zaměstnanec, kterého jsme vymodelovali na konci

kapitoly 12 (viz obrázek 15.3).

Služba Zaměstnanec byla vymodelována záměrně,

aby usnadnila seskupování entitně zaměřených

operací. Jak součást procesu Předložení pracovních

výkazů je nutné, aby přispívala dvěma specifickými

funkcemi.

První vyžaduje, aby se provedl dotaz na záznam

zaměstnance pro získání maximálního počtu hodin,

které smí daný zaměstnanec odpracovat za týden.

Druhá část funkcionality poskytuje možnost posílat

aktualizace do historie zaměstnance. Jak si možná vybavíte z původního procesu Předložení

pracovních výkazů, tato akce je nezbytná pouze tehdy, když je pracovní výkaz zamítnut.

Výsledkem procesu modelování služeb společnosti TLS bylo vyjádření těchto dvou funkcí

prostřednictvím přiřazení následujících kandidátů operací:

vezmi týdenní hodinový limit,

aktualizuj historii zaměstnance.

Kandidát služby nám nyní poskytuje primární vstup, z něhož odvodíme návrh služby tak,

že budeme postupovat podle následujících kroků návrhového procesu entitně zaměřené

řídicí služby.

Poznámka

Kandidát operace „vezmi týdenní hodinový limit“ (z něhož se později stane operace

getWeeklyHoursLimit) představuje jistým způsobem neobvykle jemně členěnou operaci. Operace služeb mají obecně sklon k hrubšímu členění, aby překonaly vyšší režii

spojenou s výměnou zpráv protokolu SOAP. Pro zachování jednoduchosti nebudeme

členění této operace měnit, neboť naplňuje funkční požadavky našeho obchodníhoprocesu. Pro více informací souvisejících s členěním rozhraní služby nahlédněte do pravidla

Aplikujte vhodnou úroveň členění rozhraní na konci této kapitoly.

„

„

Obrázek 15.3. Kandidát služby

Zaměstnanec

vezmi týdenní hodinový limit

aktualizuj historii

zaměstnance

Zaměstnanec


Část V – Budování SOA (technologie a návrh)414

Krok 1: Přezkoumejte stávající služby

Při tvorbě entitně zaměřených služeb bere modelování vedoucí ke kandidátům služeb videálním případě v potaz jakékoli existující služby. Ovšem vzhledem k tomu, že kandidáti služeb

mají sklon obsahovat kandidáty operací související s podnikovými požadavky, jež formují

základ servisně orientované analýzy, stojí vždy za to zajistit, aby některé nebo všechnyprocesní funkční prvky reprezentované kandidáty operací nebyly také součástí jiných služeb.

Z tohoto důvodu je prvním krokem při návrhu nové služby ověření, je-li skutečně nezbytná.

Pokud existují i jiné služby, pak již mohou poskytovat některé nebo všechny funkční prvky

identifikované v kandidátech operací, nebo již mohly ustavit vhodný kontext, v rámci něhož

lze tyto nové kandidáty operací implementovat (jako nové operace stávajících služeb).

PŘÍPADOVÉ STUDIE

Jedná se teprve o druhé servisně orientované řešení společnosti TLS. První bylo vytvořeno

pro ustavení externího rozhraní s jejich účetním systémem přes prostředí B2B. Toto řešení

bylo vybudováno podle vývojové strategie shora dolů, a proto je výsledkem kolekce entitně

zaměřených řídicích služeb.

Architekti zapojení do návrhu služeb nové aplikace Předložení pracovních výkazů jsou si

docela jisti, že nová sada služeb se s těmi stávajícími žádným způsobem nekryje. Nicméně,

vzhledem k tomu, že řešení B2B bylo sestaveno úplně jiným projektovým týmem, architekti souhlasí, že před zahájením návrhového procesu stojí za námahu přezkoumat existující služby.

Jejich průzkum odhalil, že následující entitně zaměřené řídicí služby byly dodány jako součást projektu B2B (viz obrázek 15.4): služba Závazky (Accounts Payable Service), služba

Objednávky (Purchase Order Service), služba Účetní kniha (Ledger Service) a služba Profil

dodavatele (Vendor Profile Service).

Obrázek 15.4. Stávající inventář společnosti TLS

služba

Závazky

služba

Objednávka

služba

Účetní

kniha

služba

Profil

dodavatele


415Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Již podle samotného pojmenování je patrné, že každá služba představuje určitou entitu

odlišnou od entity Zaměstnanec navrhované současným kandidátem služby. Pro jistotu

ještě prozkoumají popisy každé služby (spolu s doplňujícími metadaty). Projektoví architekti

poté došli k závěru, že k žádnému překrývání nedochází, což jim umožnilo pokračovat v další

práci na službě Zaměstnanec. Krok 2: Definujte entitní schéma Je užitečné začít návrh rozhraní určité služby formální definicí zpráv, které má služba zpracovávat. K tomuto účelu musíme formalizovat struktury zpráv, jež jsou definovány v rámci WSDL konstruktů types. SOAP zprávy přenášejí datový obsah v rámci sekce Body SOAP obálky. Tato data je nutné uspořádat a otypovat. Pro tento účel se spoléháme na XSD schémata. Samostatné schéma lze vložit do konstruktu types, v rámci něhož můžeme definovat každý element představující data v těle SOAP zprávy. V případě entitně zaměřených služeb je zvláště užitečné, pokud použité XSD schéma přesně reprezentuje informace spojené s entitou služby. Toto „entitně zaměřené schéma“ se může stát základem pro WSDL definici služby, neboť u většiny operací služeb se očekává, že přijímají či vysílají dokumenty definované tímto schématem. Všimněte si, že mezi entitně zaměřenými službami a entitami tvořícími entitní modelnemusí nutně být vzájemně rovnocenný vztah. Možná si vybavíte, že jsme v příkladu modelování služby v kapitole 12 kombinovali entity Zaměstnanec a Historie zaměstnance do jedinéslužby Zaměstnanec. V takovém případě můžete buď vytvořit dvě samostatná schémata, nebo je zkombinovat do jediného. Druhá možnost je doporučovaná pouze tehdy, když jste si jisti, že již nikdy nebudete chtít tyto entity znovu rozdělit.

Poznámka

Jak si ukážeme v nadcházejícím příkladu, WSDL definice umí importovat schémata do

oblasti types. To může být užitečné zvláště tehdy, když pracujeme sestandardizovanými schématy, jež představují entity. (Více informací najdete v pravidle Zvažte používání

modulárních WSDL dokumentů.)

PŘÍPADOVÉ STUDIE

Společnost TLS již před nějakou dobou investovala do vytvoření standardizovanéarchitektury pro reprezentaci XML dat (pouze pro jejich účetní prostředí). To znamená, že inventář

entitně zaměřených XSD schémat představujících informace související s účetnictvím již

existuje.

Na první pohled to vypadá, že tím pádem bude tento krok snazší. Nicméně po bližšímprostudování bylo objeveno, že stávající XSD schéma je velmi rozsáhlé a složité. Po určité diskusi

se architekti společnosti TLS rozhodli, že existující schéma s touto službou nepoužijí. Místo

toho se rozhodli dodat odlehčenou (ale přitom plně vyhovující) verzi tohoto schématu, aby

tak lépe vyšli vstříc jednoduchým procesním požadavkům služby Zaměstnanec.


Část V – Budování SOA (technologie a návrh)416

Začali identifikací druhů dat, jež bude třeba vyměňovat pro naplnění procesních požadavků

kandidáta operace „vezmi týdenní hodinový limit“. Skončili definováním dvou složených

typů: jeden obsahuje vyhledávací kritéria nezbytná pro správu požadavku přijatého službou Zaměstnanec a druhý obsahuje výsledky dotazu vrácené touto službou. Tyto typy jsou

náležitě pojmenovány, takže je patrná jejich spojitost s příslušnými zprávami. Tyto dva typy

pak tvoří nový soubor schématu Employee.xsd.

<xsd:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema“

targetNamespace=

„http://www.xmltc.com/tls/employee/schema/accounting/“>

<xsd:element name=“EmployeeHoursRequestType“>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“ID“ type=“xsd:integer“/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name=“EmployeeHoursResponseType“>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“ID“ type=“xsd:integer“/>

<xsd:element name=“WeeklyHoursLimit“ type=“xsd:short“/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Výpis 15.1. Schéma Employee (zaměstnanec) poskytující konstrukty complexType použité

pro stanovení předpokládané datové reprezentace pro kandidáta operace „vezmi týdenní

hodinový limit“

Poznámka

Konstrukty complexType jsou obalené konstrukty element, aby vyhovovalypožadavkům specifikace WS-I pro SOAP zprávy ve stylu dokument + literál. Jakmile se však architekti pokoušeli odvodit typy nezbytné pro kandidáta operace „aktualizuj historii zaměstnance“, objevil se jiný problém. Objevili totiž, že schéma, od něhož odvodili soubor Employee.xsd, nereprezentuje entitu Historie zaměstnance, kterou tento kandidát služby také zapouzdřuje.


417Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Další návštěva archivu s účetním schématem odhalila, že informace o historii zaměstnance

není řízena účetním řešením, ale je součástí prostředí pro správu lidských zdrojů, pro něž

nebylo vytvořeno žádné schéma.

Obrázek 15.5. Dvě schémata pocházející ze dvou různých datových zdrojů

Aby nebyl narušen již standardizovaný návrh schématu Employee (zaměstnanec), tak bylo

rozhodnuto, že se vytvoří druhá definice schématu (viz obrázek 15.5). Zapojili se takéanaly

tici a vytvořili následující schéma EmployeeHistory.xsd:

<xsd:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema“

targetNamespace=

„http://www.xmltc.com/tls/employee/schema/hr/“>

<xsd:element name=“EmployeeUpdateHistoryRequestType“>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“ID“ type=“xsd:integer“/>

<xsd:element name=“Comment“ type=“xsd:string“/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name=“EmployeeUpdateHistoryResponseType“>

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“ResponseCode“ type=“xsd:byte“/>

Účetní

systém

Systém správy

lidských zdrojů

Schéma

Employee

WSDL definice

služby Employee

Schéma

EmployeeHistory


Část V – Budování SOA (technologie a návrh)418

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

Výpis 15.2. Schéma EmployeeHistory (historie zaměstnance) s odlišnou hodnotou atributu

targetNamespace pro identifikace jeho rozdílného původu

K podpoře znovupoužitelnosti a pro umožnění, aby byl každý soubor schématu udržován

odděleně od WSDL dokumentu, se pomocí příkazů XSD schématu import dodají obsahy

obou schémat do WSDL konstruktu types služby Zaměstnanec.

<types>

<xsd:schema targetNamespace=

„http://www.xmltc.com/tls/employee/schema/“>

<xsd:import namespace=

„http://www.xmltc.com/tls/employee/schema/accounting/“

schemaLocation=“Employee.xsd“/>

<xsd:import namespace=

„http://www.xmltc.com/tls/employee/schema/hr/“

schemaLocation=“EmployeeHistory.xsd“/>

</xsd:schema>

</types>

Výpis 15.3. WSDL konstrukt types naplněný importovanými schématy

Krok 3: Odvo te abstraktní rozhraní

V dalším kroku analyzujeme navrhované kandidáty operací služeb a podle následujících

kroků definujeme rozhraní služby:

1. Ověřte, že každý kandidát operace je vhodným způsobem generický aznovupoužitelný, a to tak, že zajistíte patřičné členění zapouzdřené logiky. Prostudujte datovéstruktury definované v kroku 2 a stanovte sadu názvů operací. 2. Uvnitř WSDL-dokumentu vytvořte oblast portType (či interface) a naplňte ji konstrukty operation, jež odpovídají kandidátům operací. 3. Formalizujte seznam vstupních a výstupních hodnot nezbytných pro správné zpracování logiky každé operace. Toho docílíte tak, že definujete náležité konstruktymessage, jež odkazují na typy XSD-schématu v rámci podřízených elementů part.


419Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

PŘÍPADOVÉ STUDIE

Architekti společnosti TLS se dohodli na následujících názvech operací: GetEmployeeWeek

lyHoursLimit a UpdateEmployeeHistory (viz obrázek 15.6).

Poté postoupili k definici zbývajících částí abstraktní definice, tedy konkrétně kekonstruk

tům message a portType.

<message name=“getEmployeeWeeklyHoursRequestMessage“>

<part name=“RequestParameter“

element=“act:EmployeeHoursRequestType“/>

</message>

<message name=“getEmployeeWeeklyHoursResponseMessage“>

<part name=“ResponseParameter“

element=“act:EmployeeHoursResponseType“/>

</message>

<message name=“updateEmployeeHistoryRequestMessage“>

<part name=“RequestParameter“

element=“hr:EmployeeUpdateHistoryRequestType“/>

</message>

<message name=“updateEmployeeHistoryResponseMessage“>

<part name=“ResponseParameter“

element=“hr:EmployeeUpdateHistoryResponseType“/>

</message>

<portType name=“EmployeeInterface“>

<operation name=“GetEmployeeWeeklyHoursLimit“>

<input message=“tns:getEmployeeWeeklyHoursRequestMessage“/>

<output message=“tns:getEmployeeWeeklyHoursResponseMessage“/>

Obrázek 15.6. Operace služby

Employee (zaměstnanec)


Část V – Budování SOA (technologie a návrh)420

</operation>

<operation name=“UpdateEmployeeHistory“>

<input message=“tns:updateEmployeeHistoryRequestMessage“/>

<output message=“tns:updateEmployeeHistoryResponseMessage“/>

</operation>

</portType>

Výpis 15.4. Části message a portType definice služby Employee (zaměstnanec), jež

implementují abstraktní podrobnosti definice dvou operací této služby

Poznámka

Společnost TLS postavila standardizaci na specifikaci WSDL 1.1, protože vyhovujepožadavkům diktovaným verzí 1.1 profilu WS-I Basic Profile, a protože žádná z jejích aplikačních platforem nepodporuje novější verzi jazyka WSDL. WSDL 1.1 používá místoelementu interface zavedeného od verze WSDL 2.0 element portType.

Krok 4: Aplikujte servisní orientaci

V tomto kroku revidujeme čtyři principy servisní orientace, jež jsme identifikovali v kapitole

8 jako ty, které neposkytuje technologická sada webových služeb:

znovupoužitelnost služeb,

autonomie služeb,

bezstavovost služeb,

zjistitelnost služeb.

Znovupoužitelnost a autonomie, což jsou dva principy, kterým jsme se již věnovali v procesu modelování služeb, jsou určitým způsobem přirozenou součástí entitně zaměřeného

návrhového modelu, protože operace předkládané entitně zaměřenými řídicími službami

bývají neodmyslitelně generické a znovupoužitelné (a protože se používání příkazu import

doporučuje pro opětovné používání schémat a vytváření modulárních WSDL definic).

Znovupoužitelnost je dále propagována v kroku 6, kde navrhujeme rozšíření návrhu pro

podporu požadavků ležících za hranicí těch, které byly identifikovány jako součást našeho

kandidáta služby.

Protože entitně zaměřené služby často musejí být složeny nadřazenou vrstvou služeb, a protože

se pro provádění své řídicí logiky opírají o vrstvu aplikačních služeb, je jejich bezprostřední

autonomie obecně dobře definována. Dokud nemají tyto služby ovládané entitně zaměřeným

řadičem neobvyklé požadavky na zpracování, nebo si nějakým způsobem nevynucují další

závislosti, tak si svou autonomii zpravidla udržují.

Bezstavovost je také relativně ovladatelná, a to z podobných, výše uvedených důvodů. Entitně

zaměřené služby obecně nevlastní nijak velkou část logiky pracovního toku a pro ty případy, kdy je třeba vyvolat vícero aplikačních či řídicích služeb pro provedení nějaké operace,

se preferuje, aby byla správa stavu v co nejvyšší míře odložena (například do SOAP zprávy

dokumentového stylu).

„

„

„

„


421Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Zjistitelnost je důležitou částí jak návrhu entitně zaměřených služeb, tak i jejich užívání

po samotném nasazení. Jak jsme zmínili v kroku 1, potřebujeme zajistit, aby návrh služby

neimplementoval logiku, která již existuje. Mechanismus zjistitelnosti by toto ověření značně

usnadnil. Jednou z věcí, kterou můžeme udělat, aby byla daná služba pro ostatní zjistitelnější,

je doplnit ji o podrobná metadata pomocí elementu documentation, jak si vysvětlíme vpravidle Dokumentujte služby pomocí metadat.

PŘÍPADOVÉ STUDIE

Po přezkoumání počátečních abstraktních rozhraní služeb bylo rozhodnuto, že pro lepší

podporu základních aspektů servisní orientace lze provést menší revizi. Konkrétně se k WSDL

definicím přidají metainformace pro lepší popis účelu a funkce každé ze dvou operací a s nimi

spojených zpráv.

<portType name=“EmployeeInterface“>

<documentation>

Operace GetEmployeeWeeklyHoursLimit (vezmi týdenní hodinový

limit zaměstnance) používá ID zaměstnance

pro načtení hodnoty WeeklyHoursLimit (týdenní hodinový limit).

Operace UpdateEmployeeHistory (aktualizuj historii zaměstnance)

používá ID zaměstnance pro aktualizaci hodnoty

Comment (komentář) v rámci entity

EmployeeHistory (historie zaměstnance).

</documentation>

<operation name=“GetEmployeeWeeklyHoursLimit“>

<input message=“tns:getEmployeeWeeklyHoursRequestMessage“/>

<output message=“tns:getEmployeeWeeklyHoursResponseMessage“/>

</operation>

<operation name=“UpdateEmployeeHistory“>

<input message=“tns:updateEmployeeHistoryRequestMessage“/>

<output message=“tns:updateEmployeeHistoryResponseMessage“/>

</operation>

</portType>

Výpis 15.5. Rozhraní služby doplněné o dodatečnou dokumentaci ve formě metadat Krok 5: Standardizujte a zdokonalte rozhraní služby V závislosti na vašich požadavcích může jít o víceaspektový krok zahrnující série návrhových činností. Následuje seznam doporučených akcí, které můžete provést pro dosaženístandardizovaného a moderního návrhu:


Část V – Budování SOA (technologie a návrh)422

Přezkoumejte stávající návrhové standardy a pravidla a všechny vhodné aplikujte.

(Jako výchozí bod použijte pravidla a navrhované standardy nabízené na konci této

kapitoly.)

Kromě dosažení standardizovaného návrhu rozhraní služby poskytuje tento krok také

příležitost k revizi návrhu služby pro podporu některých charakteristik současné SOA,

které jsme identifikovali v části Nepodporované vlastnosti SOA v kapitole 9.

Pokud mezi vaše návrhové požadavky patří splnění specifikace WS-I Basic Profile,

pak ji v této fázi může být nezbytné vzít v potaz. I když dodržení profilu Basic Profile

vyžaduje, aby byly všechny WSDL definice kompletní, lze verifikovat pouze to, co bylo

vytvořeno až do této chvíle. PŘÍPADOVÉ STUDIE Architekti společnosti TLS, kteří mají na starosti návrh služby Employee (zaměstnanec), se rozhodli provést úpravy abstraktního rozhraní této služby pro aplikaci současnýchnávrhových standardů. Konkrétně pro standardizaci jmen operací začlenili konvence pro pojmenování, jakznázorňuje obrázek 15.7. <operation name=“GetWeeklyHoursLimit“> <input message=“tns:getWeeklyHoursRequestMessage“/> <output message=“tns:getWeeklyHoursResponseMessage“/> </operation> <operation name=“UpdateHistory“> <input message=“tns:updateHistoryRequestMessage“/> <output message=“tns:updateHistoryResponseMessage“/> </operation> Výpis 15.6. Dva konstrukty operation s novými, standardizovanými názvy

Jak si vysvětlíme v pravidle Aplikujte standardy pro pojmenování, použití standardních názvů

poskytuje nativní podporu pro skutečnou interoperabilitu, což je klíčovou charakteristikou

současné SOA.

Krok 6: Rozšiřte návrh služby

Proces modelování služeb má sklon zaměřovat se na očividné podnikové požadavky. Zatímco

propagace znovupoužitelnosti je vždy podporována, často sklouzává do procesu návrhu, aby

bylo zajištěno, že dostatečná míra znovupoužitelnosti bude zapracována do každé služby. To

„

„

„

Obrázek 15.7. Revidované názvy operací

služby Employee (zaměstnanec)


423Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

je zvláště důležité pro entitně zaměřené řídicí služby, neboť jejich žadatelé od nich očekávají

kompletní rozsah běžně používaných operací.

Tento krok zahrnuje provedení spekulativní analýzy zaměřené na to, jaké další typy funkcí by

daná služba měla v rámci jejího předdefinovaného funkčního kontextu nabízet.

Novou funkcionalitu lze implementovat dvěma obvyklými způsoby:

přidat nové operace,

nebo přidat ke stávajícím operacím nové parametry.

Zatímco druhá možnost může zmodernizovat rozhraní služby, může být také neintuitivní,

a to v tom, že příliš mnoho parametrů spojených s jedinou operací může vyžadovat, abyžadatelé této operace museli k jejímu efektivnímu využití znát tuto službu přehnaně dobře.

Přidávání operací je přímočarým způsobem, jak poskytnout zřejmé funkce spojené s danou

entitou. Do klasické sady operací pro nějakou entitně zaměřenou službu patří:

GetSomething (něco vezmi),

UpdateSomething (něco aktualizuj),

AddSomething (něco přidej),

DeleteSomething (něco smaž).

Nehledě na bezpečnostní požadavky vytváří zavedení těchto standardních operací konzistentní úroveň interoperability do vrstvy řídicích služeb, což usnadňuje nahodilou znovuoužitelnost a kompozici.

Poznámka

Navzdory výše uvedeným návrhům pro pojmenování je často výhodné při návrhu

řídicích služeb odrážejících stávající entitní modely přenést již ustavené konvence pro

pojmenování (i když to znamená příslušným způsobem upravit existující standardy pro

pojmenování).

Jsou-li definovány úplně nové úlohy, pak mohou být začleněny novými operacemi, jež se drží

téhož návrhového standardu jako ty stávající. Jsou-li identifikovány nové funkční požadavky,

jež souvisejí s existujícími operacemi, pak je běžnou metodou pro rozšíření těchto operací

přidat vstupní a výstupní hodnoty. To umožňuje dané operace přijímat a odesílat pestrou

škálu kombinací zpráv. Je však třeba jisté opatrnosti, aby nedošlo k přílišnému zkomplikování

operací kvůli potenciální znovupoužitelnosti. Často je vhodné podrobit jakoukoli nověnavrhovanou funkcionalitu samostatnému procesu analýzy.

Kromě toho, i když je žádoucí a doporučované vytvářet entitně zaměřené služby, zcelasoběstačné při správě dat spojených s odpovídající entitní doménou, existuje klíčový praktický

činitel, který je třeba vzít v potaz. Pro každou novou operaci, kterou přidáte, je třebanavrhnout a implementovat také způsob, jakým tato operace dokončí své zpracování. To seredukuje na velmi pravděpodobný požadavek na dodatečné či rozšířené aplikační služby. Dokud jsou

režijní požadavky kladené na každou novou operaci odhadnuté a považované za přijatelné,

pak je tento krok rozumný.

„

„

„

„

„

„


Část V – Budování SOA (technologie a návrh)424

Všimněte si, že po identifikaci nových operací je pro řádné utvoření a standardizaci přidaných rozšíření nutné opakovat kroky 1 až 5.

PŘÍPADOVÉ STUDIE

Společnost TLS je s dodávkou řešení Předložení

pracovních výkazů v časové tísni. Proto jerozhodnuto, že v současné chvíli nebude návrh

služby rozšířen. Dosud aplikované standardy

jim zaručují snadno rozšiřitelný návrh služby,

do něhož mohou přidávat dodatečné operace,

aniž by narušili původní rozhraní služby.

Nicméně, pojďme pro demonstraci tohoto

kroku uvážit, jaké druhy operací by mohly být

do služby Employee (zaměstnanec) přidány.

Vyjdeme-li z toho, že tato služba představuje

dvě entity, pravděpodobně bude vyžadovat

mnohem více operací než většina entitně

zaměřených služeb, jak znázorňuje obrázek

15.8.

Následuje příklad, jenž ukazuje, jak by mohl

být konstrukt portType rozšířen doplňkovými

operacemi (pro ušetření místa byly elementy

documentation vynechány):

<portType name=“EmployeeInterface“>

<operation name=“GetWeeklyHoursLimit“>

<input message=“tns:getWeeklyHoursRequestMessage“/>

<output message=“tns:getWeeklyHoursResponseMessage“/>

</operation>

<operation name=“UpdateWeeklyHoursLimit“>

<input message=“tns:updateWeeklyHoursRequestMessage“/>

<output message=“tns:updateWeeklyHoursResponseMessage“/>

</operation>

<operation name=“GetHistory“>

<input message=“tns:getHistoryRequestMessage“/>

<output message=“tns:getHistoryResponseMessage“/>

</operation>

Obrázek 15.8. Služba Employee

(zaměstnanec) nabízející ucelený rozsah

operací


425Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

<operation name=“UpdateHistory“>

<input message=“tns:updateHistoryRequestMessage“/>

<output message=“tns:updateHistoryResponseMessage“/>

</operation>

<operation name=“DeleteHistory“>

<input message=“tns:deleteHistoryRequestMessage“/>

<output message=“tns:deleteHistoryResponseMessage“/>

</operation>

<operation name=“AddProfile“>

<input message=“tns:addProfileRequestMessage“/>

<output message=“tns:addProfileResponseMessage“/>

</operation>

<operation name=“GetProfile“>

<input message=“tns:getProfileRequestMessage“/>

<output message=“tns:getProfileResponseMessage“/>

</operation>

<operation name=“UpdateProfile“>

<input message=“tns:updateProfileRequestMessage“/>

<output message=“tns:updateProfileResponseMessage“/>

</operation>

<operation name=“DeleteProfile“>

<input message=“tns:deleteProfileRequestMessage“/>

<output message=“tns:deleteProfileResponseMessage“/>

</operation>

</portType>

Výpis 15.7. Rozšířený konstrukt portType

Tyto dodatečné operace poskytují pěkně vyzrálou sadu rozšíření pro zpracování dat, jež

umožňuje znovupoužití služby Employee (zaměstnanec) v nejrůznějších řešeních. Krok 7: Identifikujte nezbytné zpracování I když proces modelování služeb z naší servisně orientované analýzy snad identifikovalněkteré klíčové aplikační služby, nebylo možné, aby je definoval všechny. Nyní, když už máme skutečný návrh pro tuto novou řídicí službu, můžete blíže prostudovat procesní požadavky každé z jejích operací. Přitom byste měli být schopni určit, jsou-li pro provedení každé části exponované funkcionality potřebné ještě další aplikační služby. Pokud ano, pak musíte stanovit, zda již existují, nebo zda je třeba je přidat na seznam služeb, které budou dodány jako součást tohoto řešení.


Část V – Budování SOA (technologie a návrh)426

PŘÍPADOVÉ STUDIE

Pojďme se znovu podívat na dvě operace, které jsme navrhli ve službě Employee(zaměstnanec):

GetWeeklyHoursLimit (vezmi týdenní hodinový limit),

UpdateHistory (aktualizuj historii). První vyžaduje přístup k profilu zaměstnance. Ve společnosti TLS jsou informace ozaměstnancích uloženy na dvou místech:

Mzdová data jsou uchovávána v rámci repozitáře účetního systému společně skontaktními údaji zaměstnance.

Údaje o profilu zaměstnance včetně podrobností o jeho historii jsou uloženy v repozitáři

pro správu lidských zdrojů. Když byla ve společnosti TLS poprvé implementována architektura reprezentace XML dat, přemostily se některé ze stávajících nestejností mezi řadou datových zdrojů společnosti TLS pomocí entitně zaměřených XSD schémat. Architekti služeb si toho byli vědomi a pro stanovení procesních požadavků pro operace GetWeeklyHoursLimit (vezmi týdenní hodinový limit) prozkoumali původní schéma Employee.xsd používané jako součást definice Employee.wsdl. Objevili, že ačkoli toto schéma přesně vyjadřuje logickou datovou entitu, představujestrukturu dokumentu odvozenou od dvou odlišných fyzických úložišť. Následná analýza odhalila, že hodnota týdenního hodinového limitu je uložena v účetní databázi. Procesní požadavky pro operaci GetWeeklyHoursLimit jsou tedy zapsány takto: Aplikační funkce na úrovni služby schopná vydat následující dotaz na účetní databázi: „Vrať týdenní hodinový limit zaměstnance pomocí ID zaměstnance jako jediného vyhledávacího kritéria.“ Nyní bylo nutné prostudovat podrobnosti skrývající se za operací UpdateHistory (aktualizuj historii). Tentokrát je to poněkud snazší, neboť schéma EmployeeHistory.xsd je spojeno s jediným datovým zdrojem, kterým je repozitář správce lidských zdrojů s profilyzaměstnanců. Pročtením dokumentace původní analýzy architekti identifikovali jednu část informace, kterou toto konkrétní řešení bude potřebovat pro aktualizaci tohoto repozitáře. Z tohoto důvodu jde definice procesního požadavku za bezprostřední požadavky řešení: Aplikační funkce na úrovni služby schopná vydat pomocí ID zaměstnance jakožto jakožto jediného kritéria aktualizaci sloupce „komentář“ tabulky s historií zaměstnance v databázi správce lidských zdrojů v profilech zaměstnanců. Vypadá to, že řešení Předložení pracovních výkazů může potřebovat nové aplikační služby na podporu procesních požadavků služby Employee (zaměstnanec), jak ilustruje rozšířená kompozice na obrázku 15.9. Oba z těchto nově identifikovaných požadavků bude třeba podrobit procesu modelování služeb popsanému v kapitole 12. „ „ „ „


427Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Obrázek 15.9. Revidovaná kompoziční hierarchie identifikující nové potenciální aplikační

služby

Na konec bylo odhaleno, že pro službu Employee (zaměstnanec) bude potřeba pouze jedna

nová aplikační služba, která bude zabalovat správce lidských zdrojů, a jež může také pomoci

službě Timesheet (pracovní výkaz). Kromě toho bylo zjištěno, že zpracování vyžadované

službou Invoice (faktura) lze splnit pomocí stávající služby společnosti TLS Accounts Payable

(závazky).

PŘÍPADOVÉ STUDIE (PROCESS RESULTS)

Níže je uvedena finální verze definice služby Employee (zaměstnanec) se zapracovanými

změnami co se jmen elementů a všech předchozích revizí týče.

<definitions name=“Employee“

targetNamespace=“http://www.xmltc.com/tls/employee/wsdl/“

xmlns=“http://schemas.xmlsoap.org/wsdl/“

xmlns:act=“http://www.xmltc.com/tls/employee/schema/accounting/“

xmlns:hr=“http://www.xmltc.com/tls/employee/schema/hr/“

xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/“

xmlns:tns=“http://www.xmltc.com/tls/employee/wsdl/“

procesní

služba Timesheet

Process Service

(předložení

pracovních

výkazů)

služba

Employee

(zaměstnanec)

služba

Timesheet

(pracovní výkaz)

služba

Invoice

(faktura)

??

služba

Notification

(upozornění)

vrstva instrumentačních služeb

vrstva řídicích služeb

vrstva řídicích služeb

vrstva aplikačních služeb


Část V – Budování SOA (technologie a návrh)428

xmlns:xsd=“http://www.w3.org/2001/XMLSchema“>

<types>

<xsd:schema targetNamespace=

„http://www.xmltc.com/tls/employee/schema/“>

<xsd:import namespace=

„http://www.xmltc.com/tls/employee/schema/accounting/“

schemaLocation=“Employee.xsd“/>

<xsd:import namespace=

„http://www.xmltc.com/tls/employee/schema/hr/“

schemaLocation=“EmployeeHistory.xsd“/>

</xsd:schema>

</types>

<message name=“getWeeklyHoursRequestMessage“>

<part name=“RequestParameter“

element=“act:EmployeeHoursRequestType“/>

</message>

<message name=“getWeeklyHoursResponseMessage“>

<part name=“ResponseParameter“

element=“act:EmployeeHoursResponseType“/>

</message>

<message name=“updateHistoryRequestMessage“>

<part name=“RequestParameter“

element=“hr:EmployeeUpdateHistoryRequestType“/>

</message>

<message name=“updateHistoryResponseMessage“>

<part name=“ResponseParameter“

element=“hr:EmployeeUpdateHistoryResponseType“/>

</message>

<portType name=“EmployeeInterface“>

<documentation>

Operace GetEmployeeWeeklyHoursLimit (vezmi týdenní hodinový

limit zaměstnance) používá ID zaměstnance

pro načtení hodnoty WeeklyHoursLimit (týdenní hodinový limit).

Operace UpdateEmployeeHistory (aktualizuj historii zaměstnance)

používá ID zaměstnance pro aktualizaci hodnoty

Comment (komentář) v rámci entity

EmployeeHistory (historie zaměstnance).


429Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

</documentation>

<operation name=“GetWeeklyHoursLimit“>

<input message=“tns:getWeeklyHoursRequestMessage“/>

<output message=“tns:getWeeklyHoursResponseMessage“/>

</operation>

<operation name=“UpdateHistory“>

<input message=“tns:updateHistoryRequestMessage“/>

<output message=“tns:updateHistoryResponseMessage“/>

</operation>

</portType>

...

</definitions>

Výpis 15.8. Finální abstraktní definice služby

Poznámka

Výsledkem tohoto procesu je pouze abstraktní definice. Kompletní WSDL dokument

včetně konkrétních detailů definice společně s importovanými XSD schématy lzestáhnout na adrese www.serviceoriented.ws.

SHRNUTÍ HLAVNÍCH POZNATKŮ

Entitně zaměřené řídicí služby je nutné navrhovat tak, aby přesně reprezentovalystávající podnikové entity, a přitom zůstaly agnostické vzhledem k řídicím procesům.

Pro správnou výbavu entitně zaměřených řídicích služeb nezbytnou sadou generických

operací může být nutné provést spekulativní analýzu. „ „


Část V – Budování SOA (technologie a návrh)430

Návrh aplikačních služeb

(krok za krokem)

Aplikační služby jsou takovou tažnou silou SOA. Představují spodní podvrstvu složené vrstvy

služeb (viz obrázek 15.10) odpovědnou za provádění jakýchkoli požadavků na zpracování od

řídicí a instrumentační vrstvy.

Obrázek 15.10. Aplikační služby tvoří v rámci vrstvy služeb spodní podvrstvu

Na rozdíl od služeb v řídicích vrstvách nevyžaduje návrh aplikačních služeb odbornou

podnikovou analýzu. Vrstva aplikačních služeb je čistou, servisně orientovanou abstrakcí

technických prostředí organizace, kterou dovedou nejlépe definovat ti, když nejvíce rozumí

těmto prostředím.

Vzhledem k mnoha technologickým i praktickým činitelům, které je třeba vzít v potaz, může

být návrh aplikačních služeb jeden z nejobtížnějších. Kromě toho může kvůli modernizaci či

nahrazování technologií a sestavování či úpravě související aplikační logiky kontext ustavený

těmito službami vyžadovat neustálé řešení.

vrstva

řídicích procesů

vrstva

rozhraní služeb

aplikační

vrstva

vrstvu

aplikačních

služeb tvoří

aplikační

služby


431Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb

Popis procesu

Obrázek 15.11 nabízí navrhovaný proces návrhu služeb pro vytvoření rozhraní aplikačních

služeb. Všimněte si, že všechny odkazy na „aplikační služby“ v této i zbývajících kapitolách

vyjadřují, že jde o znovupoužitelné pomocné aplikační služby.

Obrázek 15.11. Proces návrhu aplikačních služeb

Servisně

orientovaná

analýza

Přezkoumejte

stávající

služby

Servisně

orientovaný

návrh

Ověřte

kontext

Komponujte

SOA

Krok 2

Krok 1

Vývoj

služeb

Odvoďte

počáteční

rozhraní

Navrhněte entitně

zaměřené

řídicí služby

Krok 3

Testování

služeb

Aplikujte

servisní

orientaci

Navrhněte

aplikační

služby

Krok 4

Nasazení

služeb

Standardizujte

rozhraní

služby

Navrhněte úlohově

zaměřené

řídicí služby

Krok 5

Správa

služeb

Přidejte

spekulativní

prvky

Navrhněte

řídicí

proces

Krok 6


Část V – Budování SOA (technologie a návrh)432

Při pohledu na obrázek 15.11 je patrné, že tento proces s předchozím procesem entitně

zaměřených řídicích služeb sdílí několik kroků. To je dáno tím, že jak aplikační, tak i entitně

zaměřené služby tvoří znovupoužitelnou logiku služeb, a proto se opírají o nadřazené řadiče,

které je skládají do úloh specifických pro konkrétní obchodní procesy.

Nicméně existují klíčové aspekty, v nichž se tyto dva procesy liší. Všimněte si napříkladvymezení ověření kontextu seskupení operací do samostatného kroku. Ustavení kontextu proaplikační služby je důležitou a mnohem méně zřejmou částí návrhu služeb.

Dále zde nejsou žádné kroky s definicí procesních požadavků. To je dáno především tím, že

aplikační služby jsou odpovědné za implementaci procesních detailů nezbytných kprovádění řídicí logiky jejich nadřazených řídicích služeb. To samozřejmě neznamená, že procesní

požadavky aplikačních služeb neexistují. Existují, ovšem jen jako část návrhu základní aplikační logiky služby. To ovšem není součástí procesu, protože v této fázi navrhujeme pouze

rozhraní služby.

Začněme tedy dávat dohromady rozhraní aplikačních služeb.

PŘÍPADOVÉ STUDIE

Nyní se přesuneme do prostředí společnosti RailCo,

kde se zaměříme na návrh kandidáta aplikační

služby Převod účetních dokumentů (Transform

Accounting Documents), kterého jsmevymodelovali v kapitole 12 (viz obrázek 15.12).

Tento kandidát ustavuje „kontext pro transformaci dokumentů“, což ospravedlňuje seskupení

jeho dvou velmi podobných kandidátů operací:

převeď XML dokumenty do nativního formátu,

převed nativní dokumenty do XML.

Uvedené dva řádky informací tvoří základ, z něhož

můžeme pomocí následujících kroků návrhového

procesu odvodit fyzický návrh služby. Krok 1: Přezkoumejte stávající služby U aplikačních služeb je více než u jakéhokoli jiného typu znovupoužitelných služeb důležité mít jistotu, že požadovaná funkcionalita daného kandidáta aplikační služby dosud v žádné formě neexistuje. Je tedy opravdu nezbytné přezkoumat stávající inventář aplikačních služeb, neobsahuje-li cokoliv, co by se podobalo chystanému návrhu. Kromě toho je v této fázi vzhledem k obecné funkcionalitě nabízené těmito službamivhodné prošetřit, zda by nebylo možné požadované funkce koupit či pronajmout od dodavatelů třetích stran. Díky tomu, že aplikační služby by měly být navržené pro maximální znovuoužitelnost, mohou být webové služby třetích stran (které jsou obvykle postavené jakoopětovně použitelné) skutečné vhodným řešením, pokud s nimi lze dosáhnout požadované úrovně kvality služeb.

„

„

Obrázek 15.12. Kandidát služby

Převod účetních dokumentů

(Transform Accounting Documents)

Převod

účetních dokumentů

převeď XML dokumenty do

nativního formátu

převed nativní dokumenty

do XML


433Kapitola 15 – Servisně orientovaný návrh (část 3: Návrh služeb)

15

Návrh služeb



       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.
ABZ knihy, a.s.
 
 
 

Knihy.ABZ.cz - knihkupectví online -  © 2004-2018 - ABZ ABZ knihy, a.s. TOPlist