pátek 30. listopadu 2007

Čas online služeb

Nedávno jsem přecházel na Linux a protože mám dva notebooky, potřeboval jsem nějakým způsobem sdílet soukromou poštu a RSS agregátor. Po všech peripetiích a pokusech jsem nakonec skončil u Googlu a jeho aplikací Gmail a Reader. K tomu musím připočíst i další Google služby, které používám pravidelně - Notebook, Blogger a nepravidelně Analytics, Picasa a Docs. Když se podívám na strukturu těchto služeb, pak mi Google poskytuje: emailovou poštu, RSS agregátor, památníček na odkazy, možnost tvorby dokumentů a prezentací (články, fotoalba atd.).

Valnou většinu těchto služeb jsem měl dříve lokálně a poskytovaly mi je desktopové aplikace. Google si uvědomil, asi jako spousta jiných, že je možné všechny tyto služby nabízet online. Na rozdíl od ostatních tuto myšlenku dotáhnul nejdále. Podle jeho přístupu můžeme odvodit společnou charakteristiku pro online služby.

  • 1.)přístupnost z webového prohlížeče s minimálními požadavky
  • 2.)sdílení dat
  • 3.)částečná schopnost běžet offline
  • 4.)integrovatelnost - spolupráce s dalšími službami

Přístupnost z webového prohlížeče, bez zvláštních nároků na jeho vybavení, je základní charakteristikou online služby. Služba využívá na plno konceptu all-in-one, kdy prohlížeč nabízí vše potřebné pro její ovládání. Žádná instalace, upgrade, konfigurace. Díky webovému prohlížeči je zaručena široká dostupnost služby - není potřeba žádný speciální program-klient.

Google online služby jasně ukazují, že je důležité minimalizovat požadavky na webový prohlížeč. Každá minimální nutná součást, která vyžaduje instalaci, představuje celou řadu problémů - bezpečností počínaje a interoperabilitou konče. Služba vyžadující na klientu takový Flash či Javu se může spolehnout, s pravděpodobností hraničící s jistotou, že na mobilních zařízeních utře nos.

Služba nám umožňuje sdílení dat, které její pomocí spravujeme. Díky tomu, že jsou data sdílena přes službu, stačí k jejich dosažení opět pouze webový prohlížeč.

Částečná schopnost služby běžet offline sice dnes trochu odporuje zvýšeným požadavkům na prohlížeč, nicméně v budoucnosti by to zas až takový problém být nemusel. Třeba výše zmíněný Reader je možné přepnout do offline módu. Tím je možné pročítat jednotlivé kanály (feedy) pročítat s odpojeným prohlížečem od internetu.

Integrovatelnost umožňuje služby kombinovat do větších celků a nebo je adhoc využívat. Výsledná řešení přesahují rámec služby, například služba kalendáře se může nejen použít v kombinaci s poštou, ale můžete kolem ní postavit celou vlastní službu, která bude sloužit k časovým rozvrhům.

Z pohledu uživatele online služby přinášejí spoustu výhod a také několik vlastností, které je potřeba dobře zvážit. Zásadní změnou u online služeb je fakt, že většina rizikových faktorů leží na straně poskytovatele, o jehož infrastruktuře nemá uživatel žádné informace. Vzájemný vztah je založen na důvěře, případně ošetřen zákonem či smlouvou.

Někdo cizí má přístup k datům, které vlastním. Nevím nic o tom, jak jsou data zabezpečena, kdo další k nim má přístup a ani jaké procesy a postupy tyto data chrání. Znalost charakteru dat a jejich obsahu se na mě může zaměřit, například cílenou reklamou. Díky provázání služeb mezi sebou funguje takzvané SSO (Single Sign-On), kdy se autentizovaný uživatel považuje za autentizovaného i v dalších službách (nemusí prokazovat svou identitu). To ovšem znamená, že prolomení se do jedné služby otevírá částečně dveře do zbylých služeb. Záloha dat a nebo failover jsou rovněž faktory, které má v režii poskytovatel služby.

Poskytovatelům umožňují online služby daleko lepší kontrolu. Poskytovatel může bez větších problémů provádět údržbu služby. Další výhodou je možnost selektivně službu zapínat a vypínat např. pouze pro platící zákazníky. Poskytovatelé mohou lépe monitorovat a vyhodnotit chování uživatelů služeb a podle toho službu dále zlepšovat.

Podle mého soudu budou online služby pomalu, ale jistě, vytlačovat lokální aplikace, které používáme pro běžnou práci a nebo zábavu. Profitovat z toho budou jak uživatelé, tak i poskytovatelé. Jenom doufejme, že tu v budoucnosti nebude jedna jediná firma, která bude mít takřka monopol na většinu služeb...

úterý 27. listopadu 2007

Závislosti v Mavenu

Závislosti jsou jednou z vlastností, kterou na Mavenu oceňuji. Bohužel závislosti, především ty tranzitivní, mají i některé nevýhody. Pro neznalé Mavenu, tranzitivní závislosti jsou ty závislosti, na kterých váš kód závisí nepřímo. Příklad to osvětlí, máme komponentu A, která závisí na komponentě B a ta na C. Z pohledu A, je B přímá závislost a C nepřímá závislost.

Možná si říkáte, kde je problém. Problém nastane ve chvíli kdy se vám začnou do projektu tranzitivně dostávat závislosti, které nejsou potřeba (nechtěné) a nebo dojde ke konfliktu verzí. Klasickým příkladem je Commons Logging 1.1. Pokud se rozhodnete, že váš kód bude pro logování používat Commons Logging a zadefinujete tuto závislost, máte rázem problém. Problém se jmenuje nechtěná závislost na Servlet API 2.3, kterou tam zanese Commons Logging. Commons Logging má tuto závislost špatně nadefinovanou resp. je tam špatný scope. Podle scope se Maven rozhodne v jakých classpath je závislost potřeba. Pokud není uveden scope, je závislost propagována do všech classpath. To má pro vás ten důsledek, že se Servlet API 2.3 dostane například do výsledného packagingu což může být WAR, kde jistě nemá co dělat.

Dalším problém mohou být licence. Tranzitivní závislosti mohou zavléct do výsledného produktu licence, které nejsou úplně kompatibilní s licenční politikou produktu. No a aby těch možných konfliktů nebylo málo, tak si představme situaci kdy máme komponentu A, která závisí na komponentě X a Y. Jak X tak Y závisí na Commos Logging nicméně každý definuje jinou verzi této knihovny.

Pro ovlivnění tranzitivní závislosti máme pouze omezený výčet možností. Můžeme použít exclusion, kterým lze definovat, která tranzitivní závislost se má ignorovat. Další možností je využít znalosti Maven algoritmu pro řešení konfliktu verzí, takzvanou nejkratší cestu. Tím můžeme určit společnou verzi pro X a Y, a to tak že A bude záviset na konkrétní verzi Commons-Loggig. Bohužel všechny tyto možnosti nejsou příliš pohodlné pokud to musíme dělat pro více závislostí. Navíc je potřeba neustále brát na zřetel fakt, že jakákoliv závislost může zavléct něco nechtěného.

Když se nad tím zamyslím, tak tyto problémy nejsou chybou Mavenu, ale důsledkem špatné definice závislostí. Maven s tím těžko může něco dělat, kromě toho že poskytne prostředky pro jejich odhalení. Každopádně je tu problém, který je potřeba řešit. Jedině možné řešení je podle mého názoru vzít si závislosti kompletně pod svou kontrolu a to znamená:

  • Odpojení interní artefakt repository od internetu. Tím se nám do repository nedostane žádná závislost, kterou tam vlastnoručně nedáme. Bohužel tím taky odstřihneme Maven od nejnovějších pluginů, které jsou rovněž získávaný přes repository.
  • Post zpracování všech POM souborů v repository. To je práce, která může být pouze částečně zautomatizovaná. Nechtěné závislosti musí být ovšem vyhledány a opraveny ručně. Pro odstranění kolize verzí je možné využít takzvaný management závislostí. To znamená, že u všech tranzitivních závislostí se odstraní jejich verze případně se nahradí proměnnou. Její hodnota se nadefinuje v hlavním projektovém POM souboru, případně v profilu.

Když to vezmu a kolem, tak je s podivem, že při oblíbenosti Mavenu nevznikají komerční repository, které tyto služby profesionálně nenabízejí. Ty by mohly garantovat jednak konzistenci (verze, licence) daných stromů závislostí a jednak jejich původ - podepsané JARy. Navíc by zajistily to, že jsou k dispozici zdrojové soubory a javadoc závislostí. Další pěknou vlastností by byla možnost verzování repository. To znamená mít možnost různého stavu repository v čase a možnost se k nim vracet. Když vám dnes někdo prodává infrastrukturu jako je verzovací sýstém a nebo bug tracking systém či wiki, tak proč by nemohl nabídnout i artefakt repository.