Co nového přinášejí moderní softwarové architektury?

Co nového přinášejí moderní softwarové architektury?

Článek představuje moderní řešení používaná v oblasti architektur informačních systémů a hodnotí jejich přínos ve srovnání se staršími technologiemi, čímž odpovídá na otázku položenou v názvu.

1. Úvod

Jedním z významných předmětů zájmu softwarového inženýrství jsou softwarové architektury. Ty mohou být definovány např. jako „soubor významných rozhodnutí o uspořádání programu, výběr strukturálních prvků a jejich rozhraní spolu s jejich chováním, spojení těchto prvků a styl, který toto uspořádání řídí“ [1], i když místo definice často postačí intuitivní chápání architektury jako hrubého uspořádání programu. Je zřejmé, že architektura má na výsledné vlastnosti programu velký vliv. Proto se již na úrovni architektury hledají ověřená řešení, která pomáhají dosahovat požadovaných vlastností programů.

Tento článek se zaměřuje právě na taková ověřená řešení na úrovni architektury, a to na řešení nabízená v současné době v oblasti informačních systémů. Mezi ně patří použití vícevrstvých a komponentových architektur jako principů při návrhu architektury spolu s použitím aplikačních serverů a webových služeb jako prostředků k realizaci těchto architektur. A protože uvedená řešení jsou často představována v rámci marketingových kampaní, a tedy spíše v pozitivním než v reálném světle, je cílem článku nejen představit je po technické stránce, ale také střízlivě zhodnotit jejich přínos a zodpovědět tak otázku položenou v názvu.

Článek se úzce dotýká softwarového inženýrství, a tak se nemůže vyhnout klasickému problému korektního překladu anglického názvosloví. Zatímco angličtina je v otázce použití stávajících slov v nových významech velmi otevřená, čeština ve stejných vazbách působí neobratně či směšně. Ke všem přeloženým termínům je proto v tabulce formou slovníčku uvedeno jejich původní znění, v další tabulce jsou pak shrnuty a stručně definovány výrazy a zkratky zmíněné v článku v původním znění.

2. Komponentové architektury

2.1 Princip
Základní myšlenkou komponentových architektur je snaha pojmout tvorbu programu jako skládání jinak do značné míry nezávislých komponent. Tuto myšlenku lze uplatnit jak na úrovni návrhu architektury, tak na úrovni implementace programu. Toto uplatnění však nabývá v každé úrovni jiné podoby, a proto zde bude uvažováno odděleně.

2.2 Komponenty v návrhu architektury
Na úrovni návrhu architektury je předním přínosem komponent možnost rozdělit řešení do menších, a tak snáze zvládnutelných částí. Při důsledném použití hierarchické dekompozice se pak návrh architektury na nejvyšší úrovni skládá z relativně malého počtu spolupracujících komponent. Na nižších úrovních je každá komponenta opět složena z dalších spolupracujících komponent atd. až na nejnižší úroveň, kde jsou komponenty svou velikostí blízké běžným modulům či třídám a není nutné je dále dělit.

Uvedenou hierarchickou dekompozici lze jen stěží označit za novou myšlenku, neboť je obsažena ve většině metodik tvorby programů. Běžně používané jednotky dekompozice jako moduly či třídy jsou však zatíženy vazbami na prostředí pro implementaci programu, ve kterém mají další, s dekompozicí nesouvisející funkce. Komponenty takové vazby nemají, a proto jsou jako koncepty pro dekompozici vhodnější.

Komponenty jsou použity v nových metodikách tvorby programů, které zpravidla kombinují objektově orientované programování a návrh architektury řízený modelem (MDA), vše zapsáno v notaci jednotného jazyka pro modelování (UML). Příkladem takové metodiky je Catalysis [2].

Základními konstrukcemi metodiky Catalysis jsou typy, kolaborace a zpřesnění. Typy reprezentují objekty, komponenty a další entity návrhu, kolaborace popisují spolupráci mezi typy. Typy a kolaborace jsou používány nejprve pro hrubý popis problému na doménové úrovni, kde typ může představovat např. zákazníka nebo zboží a kolaborace např. akt zakoupení nebo vrácení zboží. Následuje popis dekompozice na komponentové úrovni, kde typ zpravidla představuje komponentu a kolaborace spolupráci mezi komponentami, a nakonec popis implementace na interní úrovni, kde typ zpravidla představuje třídu a kolaborace posloupnost volání metod mezi třídami. Zpřesnění definuje vazby mezi popisy na jednotlivých úrovních tím, že vyjadřuje, jak typy a kolaborace na nižší úrovni modelují typy a kolaborace na úrovni vyšší.

V podobě typů, kolaborací a zpřesnění poskytuje metodika Catalysis programátorovi prostředky pro vyjádření způsobu, kterým chápe navrhovaný program, ale přitom toto chápání nepředurčuje ani neomezuje. Programátor může volně přecházet mezi jednotlivými úrovněmi návrhu a v závislosti na použitých nástrojích více či méně automaticky udržovat vazby mezi nimi, popř. i vazby mezi návrhem architektury a implementací programu.

Lze očekávat, že nové metodiky tvorby programů budou na použití komponent klást rostoucí důraz. Dokladem toho je připravovaný jednotný jazyk pro modelování (UML) ve verzi 2.0, který oproti předchozím verzím zdůrazňuje právě použití komponent pro hierarchickou dekompozici.

2.3 Komponenty v implementaci programu
Na úrovni implementace programu je nejviditelnějším rysem komponent podpora opakovaného použití již implementovaných komponent ve větším počtu programů. Takové opakované použití slibuje mnoho výhod, mezi jinými např.:

• zvýšení produktivity, neboť opakovaně použitý kód je možné převzít a není třeba vyvíjet nový,

• zvýšení kvality programů, neboť opakovaně použitý kód je častěji zkoušen a zjištěné chyby jsou současně odstraněny ve všech programech, ve kterých je kód použit,

• zvýšení výkonu programů, neboť opakovaně použitý kód se spíše vyplatí optimalizovat a každá optimalizace se současně projeví ve všech programech, ve kterých je kód použit,

• zvýšení schopnosti programů spolupracovat, neboť opakované použití kódu vede k použití stejných formátů dat ve všech programech, ve kterých je kód použit.

Zkušenost ovšem ukazuje, že zmíněné výhody jsou doprovázeny množstvím problémů. Ačkoliv lze očekávat, že opakované použití komponent zmenší celkové náklady na vývoj programu, některé částečné náklady naopak rostou. Zvýšené jsou např. celkové náklady dodavatelů komponent, kteří musí vyvíjet obecnější kód, nebo počáteční náklady dodavatele programu, který nejprve musí pořídit komponenty. Tyto náklady může být obtížné obhájit zejména s přihlédnutím k tomu, že s opakovaným použitím komponent jsou dobré zkušenosti jen v úzce vymezených aplikačních doménách nebo v základních knihovnách.

Dalším problémem opakovaného použití komponent je samotná schopnost vhodné komponenty vybrat, zejména proto, že v době výběru komponent existuje o vyvíjeném programu pouze hrubá představa. Ukazuje se také, že samotní programátoři nejsou nakloněni opakovanému použití komponent, které sami nevytvořili, neboť je cítí jako omezení své nezávislosti a tvořivosti.

Zřejmě nejvážnější překážka opakovaného použití komponent však souvisí s potřebou údržby vyvíjeného programu. Používaný program je třeba neustále měnit a doplňovat, ovšem dodavatel komponent má jiné priority než dodavatel programu, a tak není k této údržbě tolik motivován. Dodavatel programu je tudíž často nucen umístit změny nebo doplňky, které by přirozeně náležely do komponent, vně těchto komponent, protože nad komponentami samotnými nemá potřebnou kontrolu. Konflikt priorit dodavatele komponent a dodavatele programu může také nutit dodavatele programu k přijetí takových změn komponent, které jsou pro jím vyvíjený program nevhodné.

Samotné opakované použití již implementovaných komponent však není důvodem použití komponent na úrovni implementace programu, protože pak by komponenty nepřinášely nic nového oproti běžně používaným knihovnám či modulům. Důležitou vlastností komponent je také možnost spojovat komponenty s programem, který je používá, nikoliv při překladu tohoto programu, ale až při jeho instalaci, popř. za jeho běhu. To programu dovoluje zejména manipulovat s daty, jejichž formát nebyl v době jeho vývoje znám. Konkrétním příkladem využití této vlastnosti komponent je možnost vkládat různé externí objekty do dokumentů v programech jako Microsoft Office či Open Office nebo možnost otevírat objekty s různými formáty dat vložené do webových stránek v programech jako Internet Explorer či Mozilla.

Popsané spojování komponent s programem, který je používá, vyžaduje, aby komponenty měly přesně definované rozhraní, pomocí kterého komunikují se svým okolím. Specifikace takového rozhraní tak obsahuje nejen funkce, které komponenta nabízí svému okolí, ale také funkce, které komponenta od svého okolí požaduje. Formát specifikace rozhraní a další důležité vlastnosti komponent jsou zpravidla standardizovány komponentovým modelem, jehož příkladem je CCM ze standardu CORBA (obr. 1).

Základem CCM [3] je jazyk pro definici rozhraní (IDL), který umožňuje popsat atributy komponenty přístupné z jejího okolí, sady komponentou nabízených a požadovaných rozhraní a komponentou odesílané a přijímané asynchronní zprávy. Popis rozhraní komponenty se z jazyka pro definici rozhraní (IDL) automaticky překládá do jazyka, v němž je komponenta naprogramována. K dispozici jsou standardní mapování pro překlad do běžných jazyků jako C++ nebo Java. Vedle formátu specifikace rozhraní standardizuje CCM také prostředí, které je komponentám dostupné za běhu, podobné dále popsaným aplikačním serverům. Implementací CCM existuje několik, např. OpenCCM [4] pro komponenty v jazyce Java nebo MicoCCM [5] pro komponenty v jazyce C++.

3. Vícevrstvé architektury

Koncept vícevrstvých architektur datuje své počátky do období rozvoje lokálních sítí. Programy využívající síť pro přístup k informacím v databázích jsou podle tohoto konceptu rozděleny do vrstev podle funkce. Spojení mezi vrstvami může být zprostředkováno po síti. Jednoduché uspořádání může mít vrstvy pouze dvě, to je pak označováno jako dvouvrstvá architektura, kde se rozlišuje:

• klientská vrstva, která obsahuje funkce uživatelského rozhraní (architektura může tíhnout spíše k tenkému pojetí klientu, pak je v klientské vrstvě pouze minimum dalších funkcí, nebo k tlustému pojetí klientu, pak je v klientské vrstvě ještě většina hlavních funkcí programu),

• vrstva serveru, jež obsahuje funkce umožňující přístup k informacím v databázích (v závislosti na pojetí klientu je ve vrstvě serveru buď většina hlavních funkcí programu, nebo jen minimum dalších funkcí).

Tenké pojetí klientu dovoluje lépe zvládnout situace, kdy je potřeba v rámci údržby vyvíjeného programu spravovat mnoho klientů. Klientskou vrstvu totiž může představovat např. webový prohlížeč se sadou appletů, který má pouze minimální nároky na údržbu. S tlustým pojetím klientu lze naproti tomu lépe zvládnout situace, kdy jsou hlavní funkce programu natolik složité, že by příliš zatěžovaly server. Vrstvu serveru může představovat např. samotná databáze. Výhody obou pojetí klientu v sobě spojuje třívrstvá architektura, u které se rozlišují (obr. 2):

• klientská vrstva, obsahující funkce uživatelského rozhraní,
• střední vrstva, která obsahuje hlavní funkce programu,
• vrstva serveru, obsahující funkce pro přístup k informacím v databázích.

Ve složitějších programech je možné definovat i více než tři vrstvy, i když hlavní rys dvouvrstvé architektury, kterým je oddělení klientské vrstvy a vrstvy serveru od hlavních funkcí programu, zůstává zachován. Příkladem může být vrstva správy uživatelů pro kontrolu přístupových práv a zabezpečení, vrstva správy kontextu pro obsluhu uživatelských nastavení či vrstva správy prostředků pro synchronizaci přístupu při sdílení.

Hlavním přínosem vícevrstvých architektur je standardizace architektury velké skupiny programů, mezi které patří většina informačních systémů. To dovoluje nabízet nástroje, které usnadňují vývoj těchto programů, jako např. mechanismy pro zprostředkování síťové komunikace mezi vrstvami pomocí volání procedur na dálku (RPC), mechanismy pro kontrolu přístupových práv, mechanismy pro přístup k informacím v databázích atd. Tyto nástroje se označují termínem middleware a patří mezi ně např. aplikační servery a webové služby.

4. Aplikační servery

Úkolem aplikačních serverů je poskytovat podpůrné funkce v prostředí vícevrstvých architektur, a to zejména jejich střední vrstvě. Tyto funkce zpravidla zahrnují komunikační mechanismy, databázové mechanismy a transakční mechanismy. Většina současných aplikačních serverů podporuje standard EJB v jazyce Java [6].

Aplikační server podle standardu EJB předpokládá třívrstvou architekturu, ve které klientská vrstva komunikuje se střední vrstvou pomocí vzdáleného volání procedur (RPC) podle standardů JNDI a RMI (obr. 3). Střední vrstvu tvoří komponenty nazývané beans, kterým je za běhu dostupné prostředí poskytované jejich kontejnerem. Toto prostředí zahrnuje služby související s vytvářením a rušením komponent, služby pro řízení transakcí a služby pro ukládání údajů o stavu komponent do databáze. Přístup k databázi, ať již zprostředkovaný kontejnerem nebo přímý podle standardu JDBC, připojuje vrstvu serveru.

Implementací aplikačního serveru podle standardu EJB je velké množství a lze mezi nimi najít i volně dostupné implementace jako JBoss [7] nebo JOnAS [8]. Aplikační servery nabízejí i další funkce, např. správu podle standardu JMX či zasílání zpráv podle standardu JMS.

5. Webové služby

Zatímco aplikační servery se soustřeďují na podporu jediného programu, cílem webových služeb je poskytnout technické prostředky pro propojení většího počtu programů v prostředí internetu. Webové služby jsou tak užitečné zejména v situacích, kdy je třeba integrovat několik informačních systémů. Základem webových služeb je trojice standardů SOAP, WSDL a UDDI pro komunikaci, popis služeb a vyhledávání služeb (obr. 4).

Simple Object Access Protocol (SOAP) je standard pro komunikaci v prostředí internetu vydaný konsorciem W3C [9]. Definuje kódování předávaných zpráv textovým zápisem v jazyce XML, kdy se každá zpráva skládá ze série hlaviček a těla s vlastním obsahem zprávy. Ačkoliv takto kódované zprávy mohou být delší, než je nezbytně nutné, jejich textový formát umožňuje předávat je prostřednictvím protokolu HTTP. To je velmi důležité v prostředí internetu, kde jiné protokoly než HTTP nemusí být kvůli různým technickým či bezpečnostním překážkám použitelné.

Web Services Description Language (WSDL) je standard pro popis webových služeb, také od konsorcia W3C [10]. Tento popis, opět v jazyce XML, obsahuje definice všech typů dat a formátů zpráv nutné pro komunikaci s webovou službou. Popis obsahuje také specifikaci přenosového protokolu, specifikaci kódování zpráv a informaci o tom, na kterých konkrétních adresách je daná webová služba k dispozici. Popis podle standardu WSDL tak obsahuje všechny údaje potřebné pro volání webové služby.

Universal Description, Discovery and Integration (UDDI) je standard konsorcia UDDI [11], který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb. UDDI se opírá o třídění služeb podle některého ze standardních katalogů, jako je registr DUNS nebo katalogy NAICS či UNSPSC. Záznam o každé webové službě obsahuje vedle zatřídění služby také informace o jejím poskytovateli a popis služby podle standardu WSDL.

Implementace podpory pro webové služby je dostupná např. v rámci známého projektu Apache [12]. Ten zahrnuje implementaci standardu SOAP pod názvem Axis a implementaci podpory pro volání služeb podle jejich popisu v jazyce WSDL. Další implementace jsou zpravidla dostupné v rámci aplikačních serverů, které standardy webových služeb nabízejí vedle standardu EJB.

6. Závěr

Přirozeným závěrem je návrat k otázce položené v názvu článku, totiž co nového moderní softwarové architektury přinášejí. Přísně vzato lze říci, že žádný z představených konceptů není převratně nový – komponenty mají mnoho společného s dlouho známými moduly, vícevrstvé architektury připomínají dřívější uspořádání počítačů s terminály, aplikační servery a webové služby pouze spojují již zavedené mechanismy, jako např. dálkové volání procedur (RPC) a databázové a transakční mechanismy. Stejně přísně lze konstatovat, že žádný z představených konceptů není magickým řešením otevřených problémů – údržba komponent není jednodušší než údržba knihoven či modulů, vícevrstvé architektury neodstraní inherentní složitost rozsáhlých informačních systémů, aplikační servery automaticky nezaručí velký výkon a rozšiřitelnost, webové služby neodstraní sémantické rozdíly v datech propojovaných programů.

Takto přísné hodnocení je však samo o sobě zavádějící, neboť nebere v úvahu skutečnost, že současný pokrok dovoluje uplatňovat představené koncepty s větší důsledností než dříve. Příklady je možné najít zejména v situacích, kdy je nutné učinit kompromis mezi koncepty návrhu představenými v tomto článku na jedné straně a rychlostí či velikostí programu na straně druhé – v těchto situacích se lze častěji přiklonit právě k představeným konceptům. Zanedbatelný není ani přínos nových vývojových nástrojů, které představené koncepty přímo podporují.

Celkově lze tedy říci, že koncepty uvedené v článku představují spíše evoluční než revoluční krok, což ale v žádném případě nesnižuje jejich přínos. To ostatně naznačují i iniciativy v oblasti automatizace, jako např. OPC či IDA, které se opírají právě o myšlenky komponentových a vícevrstvých architektur a používají prvky podobné těm ze stávajících aplikačních serverů a webových služeb, nebo dokonce prvky z nich přímo převzaté.

Ing. Dr. Petr Tůma,
katedra softwarového inženýrství,
Matematicko-fyzikální fakulta
Univerzity Karlovy v Praze
(petr.tuma@mff.cuni.cz)

Lektoroval: doc. Ing. Jiří Cendelín, CSc.