Představujeme specifikaci portletu, část 1

Se vzrůstajícím počtem podnikových portálů vytvořili různí prodejci různá rozhraní API pro komponenty portálu, tzv portlety. Tato paleta nekompatibilních rozhraní generuje problémy pro poskytovatele aplikací, zákazníky portálu a dodavatele portálových serverů. K překonání těchto problémů byla spuštěna JSR (Java Specification Request) 168, specifikace portletu, která poskytuje interoperabilitu mezi portlety a portály.

JSR 168 definuje portlety jako webové komponenty založené na prostředí Java spravované kontejnerem portletu, které zpracovávají požadavky a generují dynamický obsah. Portály používají portlety jako zásuvné komponenty uživatelského rozhraní, které poskytují informační vrstvu informačním systémům.

Cíle JSR 168 jsou následující:

• Definujte běhové prostředí nebo kontejner portletu pro portlety
• Definujte API mezi kontejnerem portletu a portlety
• Poskytněte mechanismy pro ukládání přechodných a trvalých dat pro portlety
• Poskytněte mechanismus, který umožňuje portletům zahrnout servlety a JSP (stránky JavaServer)
• Definujte balení portletů, které umožní snadné nasazení
• Povolit přenositelnost binárního portletu mezi portály JSR 168
• Spouštějte portlety JSR 168 jako vzdálené portlety pomocí protokolu Webové služby pro vzdálené portlety (WSRP)

IT průmysl obecně přijal JSR 168. Všechny významné společnosti v portálovém prostoru jsou součástí skupiny odborníků JSR 168: Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle , SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO a Vignette. Seznam oficiálních podporovatelů je ještě delší.

V současné době je JSR 168 ve veřejné revizi a finální verze je plánována na září 2003.

V tomto článku nejprve definujeme portály a portlety, poté vysvětlíme koncepty, které JSR 168 zavádí, včetně základních objektů API. Dále se ponoříme do pokročilejších funkcí JSR, jako jsou informace o uživateli, lokalizace a ukládání do mezipaměti. Poté pokryjeme body rozšíření, které prodejcům portálu umožňují rozšířit aktuálně definované funkce ve specifikaci portletu. Článek končí popisem balení a nasazení portletové aplikace.

Přečtěte si celou sérii ve specifikaci portletu:

• Část 1: Promočte si nohy pomocí základních pojmů a konceptů specifikace
• Část 2: Referenční implementace rozhraní API portletu odhaluje jeho tajemství

Základní definice

V této části vysvětlíme základní definice použité ve specifikaci portletu, včetně základní architektury portálu, kontejneru portletu a stránky portálu.

Portál

A portál je webová aplikace, která poskytuje personalizaci, jednotné přihlášení a agregaci obsahu z různých zdrojů a hostí prezentační vrstvu informačních systémů. Agregace je proces integrace obsahu z různých zdrojů do webové stránky. Portál může mít propracované funkce přizpůsobení, aby uživatelům poskytoval přizpůsobený obsah. Stránky portálu mohou mít různé sady portletů vytvářejících obsah pro různé uživatele.

Obrázek 1 zobrazuje základní architekturu portálu. Portálová webová aplikace zpracuje požadavek klienta, načte portlety na aktuální stránce uživatele a poté zavolá kontejner portletu, aby načetl obsah každého portletu. Kontejner portletu poskytuje běhové prostředí pro portlety a volá portlety prostřednictvím rozhraní API portletu. Kontejner portletu je volán z portálu prostřednictvím rozhraní API portletového invokeru; kontejner načte informace o portálu pomocí rozhraní SPI poskytovatele portletů (Service Provider Interface).

Strana

Obrázek 2 zobrazuje základní součásti stránky portálu. Samotná stránka portálu představuje kompletní dokument značek a agreguje několik oken portletu. Kromě portletů se stránka může skládat také z navigačních oblastí a bannerů. Okno portletu se skládá z záhlaví s názvem portletu, dekoracemi a obsahem vytvářeným portletem. Dekorace mohou zahrnovat tlačítka pro změnu stavu a režimu okna portletu (tyto koncepty vysvětlíme později).

Portlet

Jak bylo uvedeno výše, portlet je webová komponenta založená na prostředí Java, která zpracovává požadavky a generuje dynamický obsah. Obsah generovaný portletem se nazývá a fragment, část označení (např. HTML, XHTML nebo WML (Wireless Markup Language)) dodržující určitá pravidla. Fragment lze agregovat s dalšími fragmenty a vytvořit tak kompletní dokument, jak je znázorněno na obrázku 3. Obsah portletu se obvykle agreguje s obsahem dalších portletů a vytvoří tak stránku portálu. Kontejner portletu spravuje životní cyklus portletu.

Weboví klienti interagují s portlety prostřednictvím paradigmatu požadavek / odpověď implementovaného portálem. Uživatelé obvykle interagují s obsahem vytvářeným portlety například sledováním odkazů nebo odesíláním formulářů, což má za následek, že portál přijme akce portletu, které pak předají portletům, na které jsou zaměřeny interakce uživatele.

Obsah generovaný portletem se může u jednotlivých uživatelů lišit v závislosti na konfiguraci uživatele portletu.

Kontejner portletu

A kontejner portletu spouští portlety a poskytuje jim požadované běhové prostředí. Kontejner portletu obsahuje portlety a spravuje jejich životní cykly. Poskytuje také trvalé mechanismy úložiště pro předvolby portletu. Kontejner portletu přijímá z portálu požadavky na provádění požadavků na portletech, které tento server hostí. Kontejner portletu není odpovědný za agregaci obsahu produkovaného portlety; samotný portál zpracovává agregaci.

Portál a kontejner portletu lze sestavit společně jako jednu komponentu sady aplikací nebo jako dvě samostatné komponenty portálové aplikace.

Koncepty

Tato část vysvětluje základní koncepty programování v JSR 168, jako je životní cyklus portletu, rozhraní a režimy a stavy oken, stejně jako přístup k relacím, trvalý přístup k úložišti a jak zahrnout servlety a stránky JSP.

Životní cyklus portletu

Základní životní cyklus portletu JSR 168 je:

• Init: inicializujte portlet a dejte jej do provozu
• Zpracování požadavků: zpracovávat různé druhy požadavků na akce a vykreslení
• Zničit: vyřadit portlet z provozu

Kontejner portletu spravuje životní cyklus portletu a volá odpovídající metody v rozhraní portletu.

Rozhraní portletu

Každý portlet musí implementovat rozhraní portletu nebo rozšiřovat třídu, která implementuje rozhraní portletu. Rozhraní portletu se skládá z následujících metod:

• init (konfigurace PortletConfig): inicializovat portlet. Tato metoda je volána pouze jednou po vytvoření instance portletu. Tuto metodu lze použít k vytvoření drahých objektů / prostředků používaných portletem.
• processAction (požadavek ActionRequest, odpověď ActionResponse): informovat portlet, že uživatel spustil akci na tomto portletu. Je spuštěna pouze jedna akce na požadavek klienta. V akci může portlet vydat přesměrování, změnit jeho režim nebo stav okna, upravit jeho trvalý stav nebo nastavit parametry vykreslení.
• render (požadavek RenderRequest, odpověď RenderResponse): vygenerovat označení. Pro každý portlet na aktuální stránce je volána metoda vykreslení a portlet může vytvořit označení, které může záviset na stavu nebo okně okna, parametrech vykreslení, atributech požadavku, trvalém stavu, datech relace nebo datech back-endu.
• zničit(): indikovat portletu konec životního cyklu. Tato metoda umožňuje portletu uvolnit prostředky a aktualizovat veškerá trvalá data, která k tomuto portletu patří.

Režimy portletů

Režim portletu označuje funkci, kterou portlet provádí. Portlety obvykle provádějí různé úkoly a vytvářejí odlišný obsah v závislosti na funkcích, které aktuálně vykonávají. Režim portletu radí portletu, jaký úkol má provádět a jaký obsah má generovat. Při vyvolání portletu poskytuje kontejner portletu aktuální režim portletu portletu. Portlety mohou programově změnit svůj režim při zpracování požadavku na akci.

JSR 168 rozděluje režimy portletů do tří kategorií:

1. Požadované režimy: Každý portál musí podporovat režimy Úpravy, Nápověda a Zobrazení. Portlet musí alespoň podporovat režim zobrazení používaný k vykreslení značek pro stránku. Režim úprav se používá ke změně nastavení jednotlivých uživatelů za účelem přizpůsobení označení portletu a režim nápovědy k zobrazení obrazovky nápovědy.
2. Volitelné vlastní režimy: Toto jsou režimy, které portál může podporovat; v nepovinném režimu nemusí být portlet volán. Mezi volitelné režimy patří režim About pro zobrazení zprávy „about“; režim Konfigurace umožňující správcům konfigurovat portlet; Režim Edit_defaults, který umožní správci přednastavit hodnoty režimu Edit; režim Náhled pro zobrazení náhledu portletu; a režim tisku k vykreslení pohledu, který lze snadno vytisknout.
3. Režimy specifické pro dodavatele portálu: Tyto režimy nejsou ve specifikaci definovány, a proto jsou specifické pro dodavatele.

Stavy oken

Stav okna označuje množství prostoru portálové stránky, které bude přiřazeno obsahu generovanému portletem. Při vyvolání portletu poskytuje kontejner portletu aktuální stav okna portletu. Portlet může použít stav okna k rozhodnutí, kolik informací by měl vykreslit. Při zpracování požadavku na akci mohou portlety programově změnit stav svého okna.

JSR 168 definuje následující stavy okna:

• Normální: Označuje, že portlet může stránku sdílet s jinými portlety. Toto je výchozí stav okna.
• Maximalizováno: Označuje, že portlet může být jediným portletem na portálové stránce nebo že portlet má více prostoru ve srovnání s jinými portlety na portálové stránce, a proto může vytvářet bohatší obsah než ve stavu normálního okna.
• Minimalizováno: Označuje, že portlet by měl vykreslovat pouze minimální nebo žádný výstup.

Kromě těchto stavů okna umožňuje JSR 168 portálu definovat stavy oken specifické pro dodavatele.

Portlet lze volat v kterémkoli z těchto tří stavů okna, ale pro všechny tři stavy může vytvořit stejné označení.

Trvalý obchod

Portlet může ukládat trvalá data pro konkrétního uživatele pomocí Předvolby portletu objekt. Předvolby lze číst a zapisovat ve fázi akce a číst ve fázi vykreslování. Preferovaným režimem pro psaní předvoleb je režim úprav, který uživateli poskytuje obrazovku přizpůsobení. Předvolby mohou být buď řetězce, nebo hodnoty pole řetězců spojené s klíčem typu řetězec. Předvolby lze přednastavit s výchozími hodnotami v deskriptoru nasazení.

Předvolby a definice portletu v deskriptoru implementace společně definují portlet, někdy nazývaný a entita portletu.

Session

Koncept relace JSR 168 je založen na HttpSession definované pro webové aplikace. Protože portletové aplikace jsou webové aplikace, používají stejnou relaci jako servlety. Chcete-li povolit portletům ukládat dočasná data soukromá do portletu, výchozí rozsah relace je portlet rozsah. V tomto rozsahu může portlet ukládat informace potřebné napříč požadavky uživatelů a specifické pro entitu portletu. Atributy uložené s tímto rozsahem mají v relaci předponu kontejner portletu, aby se zabránilo tomu, že dva portlety (nebo dvě entity stejné definice portletu) přepíšou nastavení toho druhého.

Kromě rozsahu relace portletu podporuje JSR 168 i webová aplikace rozsah relace. V tomto rozsahu může k informacím přistupovat každá součást webové aplikace. Tyto informace lze použít ke sdílení přechodného stavu mezi různými komponentami stejné webové aplikace (např. Mezi portlety nebo mezi portletem a servletem).

Včetně servletů / stránek JSP

Aby byl podporován vzor Model-View-Controller, musí portlet obsahovat obsah generovaný ze servletů a stránek JSP. Tímto způsobem může portlet fungovat jako řadič, vyplnit fazole daty a zahrnout stránku JSP k vykreslení výstupu.

V JSR 168 je mechanismus zahrnutí pro servlety a stránky JSP stejný pro API Servlet. Prostřednictvím kontextu portletu se načte dispečer požadavků pro danou cestu; the zahrnout() metoda je poté volána na tento objekt požadavku-dispečera:

 PortletRequestDispatcher rd = getPortletContext (). GetRequestDispatcher (editJSP); rd.include (portletRequest, portletResponse); 

Sladění s WSRP

WSRP agreguje obsah produkovaný portlety spuštěnými na vzdálených počítačích, které používají různá programovací prostředí, jako je J2EE (Java 2 Platform, Enterprise Edition) a .Net. Služby WSRP jsou prezentační webové služby orientované na uživatele, které se připojují a hrají s portály nebo jinými aplikacemi. Umožňují podnikům poskytovat obsah nebo aplikace, aniž by vyžadovaly jakékoli manuální přizpůsobení podle obsahu nebo aplikace pomocí konzumace portálů; portály mohou snadno agregovat služby WSRP bez úsilí programování.

Expertní skupina JSR 168 pečlivě sladila koncepty mezi JSR 168 a WSRP. Následující seznam uvádí přehled, do jaké míry byly hlavní koncepty sladěny mezi oběma standardy: