WebCenter - kompozitní aplikace, 2. část

A jak do toho celého zapadá WebCenter?

Před zodpovězením této otázky je ještě na chvíli zastavme u termínu integrace. Máme-li připravené moduly, propojitelné pomocí otevřených standardů, pořád ještě někdo tyto stavební kostky pospojovat. Zůstanete-li v oraclovském světě, uděláme to za vás, pro některé neoraclovské systémy, se kterými se setkáváme často to uděláme také, pro jiné však budete potřebovat systémového integrátora či pár vlastních architektů a vývojářů.

Pokud bychom šli odspodu, pro kompozitní aplikace může být zajímavá i datová integrace, tj. sloučení mnoho, často heterogenních zdrojů, aby uživatel mohl dostat jednotný pohled na data organizace. To jsme ve světě BI, DWH či data miningu a na toto téma najdete spoustu zajímavého čtení na blogu kolegů.

Další vrstvou integrace je integrace na úrovni aplikací, což dnes zpravidla znamená využití web services, SOAP či XML messages. Pokud se jedná o orchestrované systémy, tady samozřejmě musí přiložit ruku k dílu jejich tvůrci. O backend processing se však už dokáží postarat komponenty middleware (u Oracle to je Oracle BPEL Process Manager). Kromě backendu je však potřeba občas interagovat i s uživatelem - a to je přesně místo pro WebCenter. Tím, že součástí licence WebCenter Suite je limitovaná licence BPEL PM, jsou v rámci WebCentra dodávány i hotové komponenty pro tzv. "human workflows", tj. pracovní seznamy apod.

Poslední vrstvou, kdy je možné integraci provést, je prezentační vrstva. Zde může WebCenter přispět dvěma způsoby:
1. pro již hotové aplikace je možné využít produkt Ensemble, který umí na úrovni proxy "smíchat" výstupy z několika výstupu (mashup) a dosáhnout tak efektu kompozitní aplikace tak říkajíc ad-hoc. Tento přístup se dá použít i při přechodu z existujících aplikací na nový framework (umí nejen Java a .NET aplikace, ale i skriptovací jazyky jako Perl či PHP). Jeho evidentním nedostatkem bude výkonnost. Výhodou je naopak to, že "smíchání" může provést zkušenější uživatel - vůbec tedy na něj nepotřebujete vývojáře!
2. pro vytvářené aplikace je možné využít WebCenter Framework a tím připravit aplikaci, aby jak uměla začlenit zdroje třetích stran (portlety či jiné zdroje), ale také aby se sama prakticky bezpracně stala takovýmto zdrojem. Není asi tajemstvím, že tímto způsobem jsou či budou upraveny i aplikace Oracle jako je Siebel, Peoplesoft či EBS. Postranním efektem je pak obohacení těchto aplikací o Web2.0 funkce jako je tagging, diskuze, online messaging apod.

Základní myšlenkou kompozitních aplikací je poskytnout uživatelům takovou funkcionalitu, jakou měli či mají ERP systémy, ale při zachování uživatelského komfortu a flexibility, na kterou jsou uživatelé zvyklí z portálových řešení a WebCenter je produkt, který pro tento požadavek nabízí unikátní výhody.

Tím, že odjíždím na dovolenou, se s Vámi až do září loučím. Užijte si konec prázdnin.

Jak integrovat s UCM?

Jednou z nejčastějších otázek, zejména ze strany partnerů, je jak integrovat s UCM. Aby se na ni dalo odpovědět, je nejprve třeba vědět, za jakým účelem má integrace probíhat - jen pro příklad: jiné požadavky budou, je-li předmětem zájmu vyhledávání dokumentů uložených v UCM v organizaci, kde takovýchto úložišť je více, a jinak tomu bude, slouží-li úložiště pro ukládání nestrukturovaných dat pod velké systémy typu ERP.

Nicéně, velmi pěkný přehled na toto téma je možné nalézt v prezentaci jednoho z UCM guru Briana "Bexx" Huffa, která je k nalezení na tomto linku. Prezentace se jmenuje 10 nejoblíbenějších způsobů integrace s UCM a nabízí téměř kompletní (dnes je již 2 roky stará) výčet způsobů, jejich výhody i nevýhody, i jakési doporučení v jaké situaci který způsob užívat. Podle prezentace je 10 nejoblíbenějších způsobů těchto:

1. Secure Enterprise Search - pro federované vyhledávání (i) v UCM
2. SOAP
3. CIS/CSP (Content Integration Suite / Content Portal Suite)
   
4. Open WCM
5. JCR Adaptér
6. AJAX/Mashup
7. Aqualogic Ensemble
8. Records Management Adapters
9. BPEL Workflows
10. Custom components & Security Integrations

To, co bych dnes ještě doplnil, je

1. WebDAV (zejména spolu s využitím komponenty Folders)
2. RIDC (Remote Intradoc Client)

K některým způsobům ještě pár poznámek.

SOAP
SOAP volání je možné buď napřímo, nebo s využitím komponenty WSDL Generator s pomocí WSDL. Zajímavou volbou je i možnost přidání IsSoap=1 ke kterémukoliv URL - což jak píše Brian Huff, je jakási obdoba volání REST (ve své jednoduchosti).
Nevýhodami tohoto způsobu integrace jsou:

• bezstavovost
• to, že volaným je web server (HTTP resp. HTTPS request) se všemi plusy a mínusy, které jsou s tím spojeny
• "ukecanost" (verbosity) protokolu, která se může odrážet na výkonnosti

Výhodou je naopak to, že tento protokol je možné využít prakticky z kteréhokoliv programovacího jazyka a pro vývojaáře např. v .NETu je metodou první volby.
Normou WSDL je WSDL 1.1.
Integrace přes Web Services je explicitně vyřazena ze Standard Edice UCM.

JCR Adaptér
...splňuje normu JCR 170 na úrovní Level 1 (Read-Only repository). Využívá se při integraci UCM s portálovými prostředími. Kromě omezení jen na čtení píše ještě Brian Huff, že adaptér funguje jen s java aplikacemi (tedy např. ne s MS SharePointem, kde se užívají jiné technologie) a že se obecně od tohoto standardu ustupuje ve prospěch CMIS (Content Management Interoperability Services). Uvidíme...

CIS/CPS, RIDC
Je-li SOAP metodou první volby pro .NET, pak tyto technologie jsou naopak první volbou pro integraci s java aplikacemi.

• CIS - užívá UCPM API pro přístup ke službám k serveru. Pro inicializaci se využívají servlety, jedná se tedy o výrazně výkonnější rozhraní než SOAP
• CPS - pak užívá CIS pro přístup z portálů. CPS fakticky představuje sadu základních portletů (vyhledávání, check-in/out, vkládání, workflows, administrace)
• RIDC - představuje způsob, jak volat standardní Java API (využívané například v komponentách Content Serveru) z vnějších aplikací

Custom Components
Nakonec nesmíme zapomínat ani na možnost vytvářet vlastní komponenty. Dle Briana Huffa jsou nejlepšími kandidáty třídy odvozené z FilterEvents, které mohou obohatit jakoukoliv operaci nad dokumentem (vkládání, aktualizaci metadat, workflows). V případě volání SOAP se může část logiky přenést do komponenty - tím je možné odlehčit protokolu při zachování funkčnosti. Přesto doporučuji držet se zásady, že lze-li něco udělat standardními prostředky, mělo by se psaní vlastních komponent omezit jen na nejnutnější minimum.