Chatty vs. chunky interface

V příspěvku věnovaném vícevrstvé architektuře bylo uvedeno, že komunikace mezi vrstvami by měla být omezena na minimum a proto je vhodnější používat chunky interface místo chatty.

Jaký je však mezi těmito dvěma interfacy rozdíl? Pro chatty interface (doslova ukecaný interface) je typické, že dochází k přenášení velkého množství zpráv o malé velikosti mezi vrstvami. Je tak náročnější na čas a na zdroje. Chunky interface je naopak navržen tak, aby komunikace mezi vrstvami byla minimální, to ale znamená, že je nutné přenést najednou větší objem dat. Nelze říci, že chatty interface je vyloženě špatný a chunky dobrý. Vždy jde o konkrétní případ, v jakém bude ten či onen interface nasazen.

Navrhujeme interface

Při návrhu interfacu je třeba uvažovat v širších souvislostech a kromě znovupoužitelnosti a bezpečnosti je třeba řešit i výkon, minimálně jaký bude počet současně komunikujících uživatelů, jaký bude objem přenášených zpráv a jaká je požadovaná odezva. To je otázka, na kterou vývojář dost často nezná odpověď, byť je pro něj naprosto klíčová. Hledat odpověď na tuto otázku je nutné již ve fázi získávání požadavků (requirement elicitation) a následně je zpracovat ve fázi analýzy a návrhu (analysis and design).

Znovupoužitelnost

Zatímco požadavek na opětovnou použitelnost je při návrhu poměrně často zohledněn, tak na bezpečnost a výkon se dost často zapomíná. Ostatně tento přístup je celkem pochopitelný. Většinu SW produktů si společnost nevyvíjí sama, ale nechává si je vyvinout. A každý softwarehouse se snaží mít co nejnižší náklady a proto znuvupoužitelnost komponent u jiného zákazníka a v jiném produktu je něco, co je především v jeho zájmu.

Bezpečnost

Bezpečnost je obecně podceňována, neboť z pohledu zadavatele jen zvyšuje náklady projektu a cenu SW produktu. Je zřejmé, že v okamžiku, když se v seznamu požadavků např. neobjeví požadavek na kontrolu znaků, které lze zadat do textového pole, tak dodavatel sám od sebe tuto kontrolu implementovat nejspíš nebude. Jedno je jisté, použití chatty interface se nejspíš nevyhneme, pokud bude požadováno jemné řízení přístupu (fain grain access control) na úrovni jednotlivých operací nebo atributů. Naproti tomu, pokud uživateli zpřístupníme veškeré operace a atributy, kterými objekt disponuje, může hovořit o hrubém řízení přístupu (coarse grain access control) a v takovém případě můžeme použít chunky interface.

Pro coarse grain access control je typické, že je řízen přístup k objektu, zatímco v případě fine grain access control je řízen přístup k atributům objektu, např. coarse grain mi umožňuje, že mohu do objektu zapisovat (např. pokud mám přiděleno právo WRITE na objekt klienta – mohu změnit cokoliv – jeho jméno, adresu, stav), fine grain mi umožní řídit zápis i na úrovni jednotlivých atributů třeba jen do pole adresa, jinam prostě nezapíši. Řídit přístup mohu samozřejmě vlastním kódem, pro tento účel vyvinutým dle čehokoli, co mám na straně služby k dispozici např. uživatelské jméno, parametry zprávy, mapovací tabulku v databázi, LDAP, apod. Ke službám jako celku však lze přiřazovat přístupová oprávnění mnohem snáze, neboť je pro to obvykle hotová podpora (dodávané řešení hostitele služeb).

Výkon

Měli bychom se zamyslet nad tím, zda je nutné data průběžně zpracovávat nebo je výhodnější zpracovat najednou větší objem dat. Je nevhodné, aby se např. na server přenášela informace o každém kliknutí nebo o tom, co uživatel vybral z menu nebo zadal do textového pole. Pokud budeme předávat jeden parametr po druhém, pak objem přenesených dat bude mnohem větší, než když bychom všechny uživatelem zadané parametry předali najednou. Důvod je prostý, pro každý předávaný parametr se musí vytvořit a přenést datový paket mezi danými vrstvami a obvykle i potvrzení o přijetí. Roste nám tak režie, neboť každý paket musí být odbavován. Kromě toho se přetěžuje síťový interface, neboť roste počet I/O operací. Síťový interface se tak může stát nejužším hrdlem aplikace. Obzvlášť v případě velkého počtu současně připojených klientů roste zatížení sítě a zhoršuje se průchodnost. Nároky na HW zdroje však vývojáře příliš netrápí. Důvod je celkem prostý, zákazník si v podstatě již zvykl na to, že většina aplikací je náročná na zdroje a tak dodavatele nic nenutí nějakou výraznou optimalizaci kódu provádět. V okamžiku, kdy vyvíjíte aplikaci, která má být dostupná přes internet a tedy i pomalé linky, může být špatně zvolený interface v případě WS (Web Services) hlavní příčinou, proč je aplikace tak strašně pomalá. Uveďme si jednoduchý příklad chunky interface:

CreateProfile (UserName, PersonalInformation, ContactInformation)

Všimněte si, že proběhne jen jedno volání a předají se všechny parametry najednou, zatímco v následujícím případě, kdy je použit chatty interface, proběhne volání několik, a přitom by se všechny parametry daly též předat najednou.

Set UserName

Set FirstName
Set LastName
Set BirthDate
Set PhoneNumber
Set EmailAddress
Set MailingAddress

Obzvlášť v případě OOP, kdy jednotlivé objekty obsahují velké množství metod get a set hrozí, pokud programátor nezmění své programátorské návyky, které si přinesl z vývoje desktopových aplikací, že vznikne strašně ukecaný interface.

Poznámka: Při použití chunky interface se musí přenášet všechna data o objektu (tedy ne jen ta, která byla updatována), při použitá chatty interface se přenáší jen ta data, která byla updatována. Je to především o tom, jak se předpokládá, že se s aplikací bude pracovat. Budou se většinou updatovat jen některé atributy objektu nebo všechny? Jak velký je objekt? Na první pohled se zdá, že je vždy lepší chunky interface, ale pokud ten objekt bude moc velký, tak pak při větším počtu klientů a pomalé licence, nebudou požadavky uživatele vyplněny včas a klient prostě vytimeoutuje.

Štítky: n-tier

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.