Web Center - Patch Set 3

Začátkem prosince zorganizoval product management (PM) několik akcí na téma Patch Set 3 pro Web Center. Původně měl být tou dobou již k dispozici ke stažení; současný očekávaný termín je někdy v lednu - únoru.

Z prezentací a živých ukázek se zdá, že tento Patch Set, který ve skutečnosti dodává řadu nových funkcí, bude z pohledu produktu Web Center poměrně zásadní událostí.

Asi nejzásadnější novinkou je tzv. Web Center Portal, který do značné míry vychází a nahrazuje zavedený Weblogic Portal. Jak tomuto produktu rozumět? Při vytváření portálových aplikací je možné portál "spíše konfigurovat" (tj. hlavní podíl na jeho tvorbě mají business uživatelé - na tyto potřeby odpovídají Web Center Spaces) a nebo "spíše programovat"; a přesně k tomuto účelu slouží Web Center Portal. PM dokonce slibuje, že na základě prvních výkonostních testů by tento produkt mohl dosahovat ještě lepších výsledků, než Weblogic Portal, který je jinak prý držitelem všech světových rekordů při spracování transakcí zadávaných přes web. Tak uvidíme...

PS3 také jako první nabízí plnou integraci s Oracle UCM, zejména pak možnost využít funkce UCM 11g, jako je Site Studio for External Applications. Fakticky to znamená, že stránky tvořené čistě na základě obsahu (uloženého samozřejmě v UCM) jsou konstruovány prostředky UCM, ale zobrazovány v rámci portálu. Jakkoliv bylo možné tohoto efektu dosáhnout i v dřívějších verzích, nyní je vše možné zprovoznit doslova během pár kliknutí myší.

Z nových funkcionalit pak stojí za zmínku:

• Personalization Engine, který v rámci Web Centra umožňuje definovat pravidly řízené úpravy do obsahu stránky (např. bannery na základě údajů známých o přihlášené osobě)
• Business Users Mashups, což představuje mechanismus Data Control - Custom Visualizations - Reusable Mashups - Business Dictionary, tedy možnost portletizovat nejrůznější data z aplikací, dokonce je dávat k dispozici jako zdroje pro stránky ostatních uživatelů. Vzhledem ke konceptu Fusion Applications je již dnes možné získat řadu (otestovaných a podporovaných) data controls zejména nad Oracle Applications.
• zjednodušení správy stránek a dalších zdrojů a distribuovaná zodpovědnost (nominování správce odpovědného za určitou oblast)

Tolik aspoň k tomu nejdůležitějšímu.

Deployment aplikace Site Studio for External Applications

Vraťme se naposledy k problematice WCM v releasu 11g. V minulých článcích jsme si postupně představili základní koncepty a změny oproti 10g (užití JSP a Jdeveloperu jako IDE). Jak se ale bude chovat aplikace v produkčním prostředí?

Odpověď je, možná, nepřekvapující: jako J2EE aplikace

Aplikace se na aplikační server dodává v .EAR souboru, který má tuto strukturu:

+ -- My Application.ear
+ -- MySites.war
+ -- adf/META-INF/
+ -- connections.xml
+ -- META-INF/
+ application.xml
+ weblogic-application.xml


MySites.war obsahuje reference na jeden content server a sites (které jsou uloženy na něm jako obsahové položky, tj. soubory .xml; jinak je najdete podle kritéria "WebSiteObject matches Project")
connections.xml obsahuje odkaz na URL Content Serveru, který obsahuje užité položky obsahu (dokumenty, obrázky, multimédia); bez autentizace je možné přistupovat jen na položky z bezp. skupiny 'Public', které jsou navíc přiřazeny danému site (při výběrech)
weblogic-application.xml obsahuje odkazy na sdílené knihovny Site Studia (a RIDC) na daném Weblogic serveru

Soubor MySites.war má pak tuto strukturu:

+ -- MySites.war
+ -- wcm/templates/
+ -- WEB-INF/
+ web.xml
+ wcm-config.xml
+ weblogic.xml

/templates/ je adresář obsahující všechny JSP/JSPX registrované ve wcm-config.xml
wcm-config.xml je hlavní konfigurační soubor pro Site Studio
weblogic.xml obsahuje reference na sdílené WAR knihovny Site Studia
web.xml je standardní konfigurační soubor pro J2EE aplikace

Jak je vidět z popisu, v architektuře existují 2 servery, aplikační server, který provozuje WCM aplikaci (a má k dispozici některé knihovny) a UCM server, který slouží čistě jako poskytovatel obsahu. I toto je vlastně změna oproti 10g, kdy se UCM server "staral o všechno". Bohužel, i kdyby se jednalo o skutečně dva různé servery, neplatí, že na provozním aplikačním serveru nemusí být licence UCM - vzhledem k instalaci knihoven musí být i tento server licencován pro UCM. Na druhé straně je ale možné využít mechanismus cachování obsahu na provozním aplikačním serveru, čímž je možné dále optimalizovat jak rychlost odezvy, tak zátěž poskytovatele obsahu.
A stále pak existuje možnost vypublikovat statické stránky (což se často využívá u internetových stránek, kde žádná autorizace uživatele pro přístup k dalším sekcím nedává smysl) na web server, kde samozřejmě žádné licence potřeba nejsou.

Microsoft Sharepoint 2010 - opravdu je to tak levné řešení?

Jak jsme informovali před dvěma týdny, první místo v parametru Ability to Execute v gartnerovském magickém kvadrantu pro oblast ECM přenechala IBM Microsoftu, a to konkrétně produktu Microsoft Sharepoint (dále SP 2010). Tento produkt skutečně zaznamenává na trhu značný úspěch a dokonce už jej provází nimbus "ne snad tak robustního, ale levného řešení".

Osobně mám přinejmenším jednu zkušenost, kdy byl zákazník nucen poměrně brzy vystřízlivět. Jak to tedy vlastně je?

SharePoint se dodává ve třech různých verzích: "zadarmo" (Foundation), Standard a Enterprise

Pro všechny verze SP 2010 je předpokladem 64bitová verze Windows Serveru 2008 (či novějšího) a MS SQL 2005 (či novější). Pro klientskou stranu jsou třeba Windows Server CAL (Client Access License), ale především pak poslední verze MS Office 2010 (Standard či ProPlus). Především poslední fakt je pro řadu zákazníků jisté nemilé překvapení a oblíbená argumentace Microsoftu je prý, že k upgradu by stejně dříve nebo později došlo.
Jakmile si uživatelé na produkt "zadarmo" zvyknou, zjistí, že potřebují k jeho užívání další licence. Microsoft opět tvrdí (to jsem slyšel, možná v trochu parafrázované verzi, na vlastní uši): "pro většinu zákazníků stačí verze Standard a pro ty opravdu velké máme verzi Enterprise", což znamená serverové licence SP 2010 pro všechny (!) servery, které jsou součástí architektury (může jich být více: web server, app server, crawl/index server) a SP Standard nebo Enterprise CAL pro klientské stanice (vč. nutných předpokladů zmíněných výše).
Verze Standard obsahuje funkční moduly Portal, Doc/Rec. Mgmt, Social Computing, ECM/WCM, Enterprise Search a Legal Holds.
Verze Enterprise však začne být nutná:

• pokud chce zákazník využívat SP i mimo svoji organizaci - chcete-li, pro scénáře typu "extranet"; zde se navíc najednou objeví potřeba zakoupit i další licenci, tzv. SharePoint Server 2010 for Internet Sites, jehož ceníková cena je více než $40K
• pokud začne být položek hodně (stovky miliónů) - pak se nabízí FAST Search Server
• pokud chce zákazník využívat BI či Business Applications Integration (pilíř PerformancePoint Services, který je součástí pouze Enterprise licence)

Pokud umíte číst mezi řádky, pak už je vám asi jasný postup: začít relativně "s ničím" a postupně utahovat šrouby. Navíc zástupci tohoto přístupu jsou koncoví uživatelé, kteří vždy jakoby dostávájí "latest and greatest". Což neznamená, že pro spoustu organizací to stále nemusí být optimální varianta. Pokud už však má vaše organizace/obsluhovaná komunita (pozor na "extranet") několik set hlav, doporučuji si udělat výhled tak na 3-5 let dopředu. Možná už vám pak SP 2010 řešení zas tak levné připadat nebude. Jinak ale klobouk dolů před tím, kdo tuto strategii vymýšlel.

Dekompozice stránky ve WCM - odshora dolů (část 2.)

Schéma "prostřední" části definice stránky, tj. placeholderů a regionů, je opět nejlépe možné pochopit ze schématu:

Pokud budeme prozatím ignorovat nejnižší vrstvu, tj. elementy, a ponecháme stranou i subtemplates, zbydou nám 4 vzájemně úzce spojené objekty. Přibližme si je nejprve opět pomocí dalšího schématu:


Nejjednodušším objektem je placeholder. Vytváří se na úrovni stránky (tj. její šablony) buď přetažením příslušné ikony do designu stránky, nebo přidáním takovéhoto kódu:

Ke každému placeholderu musí existovat tři další objekty. Jeden, placeholder definition, určuje, jaké operace bude možné s daným placeholderem v přispěvovatelském módu provádět:


Druhým je pak Region Definition, která definuje "obsah" příslušného regionu - v našem příkladě z druhého obrázku má region 5 oblastí: Title, Subtitle, Intro Text, Body Text a Image. Na následujícím obrázku bude příklad regionu se dvěma oblastmi (elementy).


Aby to celé mohlo fungovat, je ještě nezbytné, aby bylo určeno, které oblasti regionu a v jaké podobě budou uživateli zobrazeny. K tomu pak slouží poslední objekt, Region Template, což je opět JSP definující podobu výstupu (při jeho definici je možné použít subtemplates, které opět mohou obsahovat další placeholdery).

Jak je také vidět z druhého obrázku, je teoreticky možné, že by k jedné existovalo více zobrazovacích šablon. V rámci definice definici placeholderu se pak určuje, která z nich se v dané situaci použije.

Poslední nutný link, mezi placeholderem a jeho definicí, se poněkud nelogicky provádí na úrovni site (tam, kde se příslušným stránkám přiřazují jejich primární a sekundární šablony), a to pomocí tlačítka s názvem Placeholder Definition Mappings.

Pro srovnání: dříve se v aplikaci SiteStudio prováděly všechny tyto operace na jednom místě. To je zřejmě daň za rozdělení formy (JSP) a pravidel chování/mapování mezi objekty (což je v podstatě XML).

(pokračování někdy příště)