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ů.

No comments:

Post a Comment