Showing posts with label DMS. Show all posts
Showing posts with label DMS. Show all posts

Wednesday, 23 December 2009

... architektura v úložišti

Pokud bychom otočili zájem o architekturu naopak na vlastní úložiště nestrukturovaného obsahu (dále "ECM úložiště"), dostaneme se na relativně pevnější půdu Solution Architecture.

Základní přiblížení architektury se dá udělat dnes snad nejopakovanějším slidem v celém Oracle:

1. Pokud bychom začali úplně zespoda, nalezneme tam hardware, na kterém se ukládají nestrukturovaná data (v jazyce výrobců hardware znamená termín úložiště zpravidla právě a jenom toto). Podle objemu dat a dalších požadavků se může jednat o disk, pásku, diskové pole, či nejrůznější hybridní zařízení (např. na našem letošním hitu, Exadatě 2, která slouží jako úložiště - storage pro datové sklady a OLTP databáze se využívají z důvodu rychlosti kromě disků i flash paměti). Budiž však řečeno, že tato zařízení již dávno nejsou jen tupými boxy na odkládání informací (souborů) a že často obsahují velmi příjemné (bohužel však často též poměrně nákladné) doplňující funkce - např. pro podporu na tomto blogu diskutovaného konceptu garantovaného úložiště může úložiště - storage nabídnout redundantní uložení stejného souboru, které z pohledu vyšších vrstev (vč. uživatelů) transparentní, čímž výrazně sníží šanci ztráty obsahu z důvodu technického poškození úložného média.
Tato vrstva je pro jakýkoliv projekt úložiště nestrukturovaného obsahu nezbytná.
2. Na další vrstvě nalezneme to, čím je Oracle stále nejznámější - databázi. V našem ECM úložišti (Oracle UCM) může mít databáze dvojí roli - buď se využívá jen na ukládání metadat (tj. dat o souborech v úložišti - v tomto případě je možné využít i databáze od jiných dodavatelů, i jako důkaz toho, že řešení je skutečně otevřené), nebo slouží na ukládání metadat i vlastního obsahu.
Zejména v prostředí, kde již databázi Oracle znají, doporučujeme jako metodu první volby druhou možnost. Databáze totiž "v ceně" dodá do řešení spoustu funkcionalit (jen namátkou: fulltextové vyhledávání či stemming, a to v mnoha jazycích vč. češtiny, hierarchical storage management, unifikované zálohování a v neposlední řadě díky RAC i škálování výkonu). Za jistou nevýhodu by se mohlo považovat, že databáze zpravidla nedokáže plně využít, pravda často proprietární, "inteligence" hardwarových storage zařízení (někdy se funkcionalita zdvojuje, jako např. u HSM, jindy se ne plně využívá, jako např. u zmiňovaného redundantního ukládání). Přesto je možnost ukládat nestrukturované informace jistě velmi zajímavým doplňkem pro řadu řešení.
3. Na třetí úrovni, middleware, patří vlastní ECM úložiště, proto ji na okamžik vynechme.
4. Poslední vrstva nás pak přenese do širokého světa ostatních systémů a aplikací čerpající služby ECM úložiště. Tím bychom se vrátili k obsahu minulého týdne.

Pokud bychom se nyní zaměřili na detaily vlastního úložiště, můžeme pokračovat v naší logice definování jednotlivých vrstev a jejich role v rámci řešení.
a) na nejnižší vstvě najdeme využití služeb storage a databáze - pokud potřebuji najít či vložit dokument s identifikátorem XYZ, musím vědět, kde ho najdu a jak k němu přistupovat
b) na druhé nejnižší vrstvě najdeme pak poskytování základních dokumentačních služeb, jako je práce s metadaty, definování přístupů, podpora workflows atd., tedy úlohy, které se vyskytují prakticky v každém projektu
Kdysi, ještě za časů, kdy produkt vlastnila firma Stellent, se této vrstvě říkalo Content Server a její nasazení bylo nezbytnou podmínkou každého stellent projektu pro správu obsahu. Je třeba poznamenat, že ve své době se tímto Stellent lišil od řady svých konkurentů (jejichž portfolio často vznikalo akvizicemi velmi technologicky odlišných produktů, takže implementace ECM projektu pak představovala integrační projekt se všemi důsledky tohoto faktu - dnes už byla většina řešení redesignována a nová řešení již vznikají podle tohoto konceptu).
Tato vrstva může sloužit jako stand-alone řešení (např. pro oblast DMS) nebo poskytovat svoje služby dalším vrstvám nad ní.
c) řada těchto vyšších vrstev je standardně dodávána (kdysi ve stellentu byly licencovány odděleně) v rámci produktu Oracle UCM. Jedná se o komponenty pro disciplíny jako je Web Content Management, práci s multimediální obsahem, či podporu splnění nejrůznějších legislativních požadavků na uchovávání obsahu (spisová služba, records management). Zajímavostí z pohledu architektury je, že jsou postaveny tak, že čerpají služby základní komponenty a samy pak nabízejí další služby navenek. Stellent byl servisně orientován v době, kdy SOA ještě ani neexistovala.
Další příjemnou vlastností tohoto způsobu je, že jej je možné:
  • snadno rozšiřovat - na každou vrstvu je možné doplňovat další a další služby (ať už Oracle nebo komunity dodávají řadu již hotových komponent)
  • snadno měnit - pokud nějaká služba nedělá, co by bylo třeba, je možné ji upravit či úplně vyměnit

Celkový obrázek architektury úložiště ECM tak může vypadat např. takto:


Vzhledem k tomu, že toto je poslední článek před Vánocemi, přeji Vám šťastné a příjemné prožití svátků.

Wednesday, 16 December 2009

Úložiště v architektuře...

V tomto týdnu jsme byli spolu s dalšími kolegy z oddělení presales posláni na školení o významu architektury. Na zpáteční cestě jsem se proto rozhodl, že dnešní téma věnuji otázkám spojující architekturu (spíše ve významu Enterprise Architecture) a problematiku ECM.

Ponechme stranou otázku samotného termínu architektura (na toto téma např. článek) - připustme, že je možné dosáhnout jakéhosi ucházejícího přenesení logiky obchodních procesů do IT infrastruktury. Jaké místo v tomto modelu tedy bude zaujímat ECM úložiště? Předně, nejprve bude nezbytné udělat ještě o jeden krok zpět (ve smyslu modelu "vodopádu") a zapátrat, proč by organizace měla vůbec něco takového chtít (tj. pokusit se definovat požadavky).

ECM primárně řeší správu nestrukturovaného obsahu (textových dokumentů, emailů, multimédiálních souborů, skenů atd.) a jakkoli jsme si nijak nespecifikovali o jaké organizaci se bavíme (ať už velikostně či oborově), troufnu si tvrdit, že správu, tj. zavedení jakýchsi základních pravidel, jak s tímto obsahem pracovat, bude muset dříve nebo později zavést každý - když už kvůli ničemu jinému, tak proto, že tento obsah má tendence skutečně nekontrolovaně (exponenciálně?) růst a velmi často obsahuje v záplavě balastu informace, (dokumenty, soubory) které potřebujeme a nebo o které si naopak nemůžeme dovolit přijít.

Požadavkem, který už do jisté míry souvisí s architekturou, je, aby úložiště bylo pokud možno jen jedno - tento požadavek v podstatě diktuje selský rozum (pokud něco budu hledat, vím, kde to najdu - nebo naopak, že to najít nemohu). V ideálním stavu by tomu tak být mělo, ale v realitě je často úložišť hned několik (se všemi problémy, které jsou s tím pak spojeny - dlouhé vyhledávání, různé triky, pravidla a administrátoři pro různé aplikace atd.) - stačí se jen podívat, jak často jsou v ECM úložišti ukládány a spravovány emaily.

Vzhledem ke zbytku světa (rozuměj dalším systémům v rámci Enteprise architektury) je pak ECM úložiště ne nepodobné databázi (osobně proto někdy užívám termín: "databáze dokumentů") - musí umět přijmout, vyhledat, modifikovat a někdy i smazat spravovaný obsah. A pak samozřejmě provádět uvnitř sebe sama některé další operace, které výše uvedené podporují (příkladem může být např. konverze do formátů, které dokáží zobrazit obsah bez nutnosti instalovat na klientskou pracovní stanici speciální software). Kromě procesů, kdy se (na rozdíl od databáze) počítá, že koncoví uživatelé pracují přímo s úložištěm (přes nějaké grafické rozhraní) je to však v zásadě všechno...

Možná Vás napadne, že vše z výše uvedeného se dá splnit i pomocí poměrně výrazně jednodušších (a levnějších) prostředků (jako jsou souborový systém či zmiňovaná databáze). To je pravda. Zatímco se dá bez újmy na obecnosti tvrdit, že úložiště nestrukturovaného obsahu má místo v každé organizace, není možné říct, že by tím úložištěm nutně musel být produkt s nálepkou ECM. Z čehož vyplývá, že kritéria výběru vhodného typu úložiště jsou dána spíše potřebami jednotlivých systémů (procesů či dokonce uživatelů) čerpajících služby úložiště. Tedy spíše úrovní označovanou jako Solution Architecture. "Letecký snímek" organizace může spíše přispět tím, aby se na nějaké řešení při vyhodnocování potřeb nezapomnělo a nebo naopak při dopadové analýze zavádění nového systému.