Med fremkomsten af et stigende antal virksomhedsportaler har forskellige leverandører oprettet forskellige API'er til portalkomponenter, kaldet portlets. Denne række inkompatible grænseflader genererer problemer for applikationsudbydere, portalkunder og portalserverleverandører. For at overvinde disse problemer blev JSR (Java Specification Request) 168, Portlet Specification, startet for at give interoperabilitet mellem portlets og portaler.
JSR 168 definerer portlets som Java-baserede webkomponenter, der administreres af en portletcontainer, der behandler anmodninger og genererer dynamisk indhold. Portaler bruger portlets som tilslutbare brugergrænsefladekomponenter, der giver et præsentationslag til informationssystemer.
JSR 168s mål er følgende:
- Definer runtime-miljøet eller portletbeholderen til portlets
- Definer API mellem portletcontainer og portlets
- Giv mekanismer til lagring af kortvarige og vedvarende data til portlets
- Giv en mekanisme, der tillader portlets at inkludere servlets og JSP (JavaServer Pages)
- Definer en emballage med portlets for at muliggøre let implementering
- Tillad binær portletportabilitet blandt JSR 168-portaler
- Kør JSR 168-portlets som fjernportlets ved hjælp af WSRP-protokollen (Web Services for Remote Portlets)
IT-branchen har bredt accepteret JSR 168. Alle større virksomheder i portalområdet er en del af JSR 168-ekspertgruppen: Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle , SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO og Vignette. Listen over officielle tilhængere er endnu længere.
I øjeblikket er JSR 168 i offentlig gennemgang, og den endelige version er planlagt til september 2003.
I denne artikel definerer vi først portaler og portlets og derefter forklarer begreberne JSR 168 introducerer, herunder API's grundlæggende objekter. Dernæst dykker vi ned i JSR's mere avancerede funktioner, såsom brugerinformation, lokalisering og caching. Vi dækker derefter udvidelsespunkterne, der giver portalleverandører mulighed for at udvide den aktuelt definerede funktionalitet i portlet-specifikationen. Artiklen afsluttes med beskrivelsen af indpakning og implementering af portlet-applikationer.
Læs hele serien om portlet-specifikationen:
- Del 1: Bliv dine fødder våde med specifikationens underliggende termer og koncepter
- Del 2: Portlet API's referenceimplementering afslører dens hemmeligheder
Grundlæggende definitioner
I dette afsnit forklarer vi de grundlæggende definitioner, der bruges i portletspecifikationen, herunder en portals grundlæggende arkitektur, portletbeholderen og en portalside.
Portal
EN portal er en webbaseret applikation, der giver personalisering, single sign-on og indholdsaggregering fra forskellige kilder og er vært for præsentationslaget for informationssystemer. Aggregering er processen med at integrere indhold fra forskellige kilder på en webside. En portal kan have sofistikerede personaliseringsfunktioner til at levere brugerdefineret indhold til brugerne. Portalsider kan have forskellige sæt portlets, der skaber indhold til forskellige brugere.
Figur 1 viser en portal grundlæggende arkitektur. Portalwebapplikationen behandler klientanmodningen, henter portlets på brugerens aktuelle side og kalder derefter portletcontaineren for at hente hver portlets indhold. Portletbeholderen tilvejebringer runlets miljø for portlets og kalder portlets via Portlet API. Portletbeholderen kaldes op fra portalen via Portlet Invoker API; containeren henter oplysninger om portalen ved hjælp af Portlet Provider SPI (Service Provider Interface).
Side
Figur 2 viser de grundlæggende portalsidekomponenter. Selve portalsiden repræsenterer et komplet markupdokument og samler flere portletvinduer. Ud over portlets kan siden også bestå af navigationsområder og bannere. Et portletvindue består af en titellinje med portletens titel, dekorationer og det indhold, der produceres af portleten. Dekorationer kan omfatte knapper til at ændre portletens vinduetilstand og tilstand (vi forklarer disse begreber senere).
Portlet
Som nævnt ovenfor er en portlet en Java-baseret webkomponent, der behandler anmodninger og genererer dynamisk indhold. Indholdet genereret af en portlet kaldes a fragment, et stykke markering (f.eks. HTML, XHTML eller WML (Wireless Markup Language)), der overholder visse regler. Et fragment kan aggregeres med andre fragmenter for at danne et komplet dokument som vist i figur 3. En portlets indhold aggregeres normalt med indholdet af andre portlets for at danne portalsiden. En portletcontainer administrerer en portlets livscyklus.
Webklienter interagerer med portlets via et anmodnings- / svarparadigme implementeret af portalen. Normalt interagerer brugerne med indhold produceret af portlets ved f.eks. At følge links eller sende formularer, hvilket resulterer i, at portlethandlinger modtages af portalen, som derefter videresendes til de portlets, der er målrettet af brugerens interaktioner.
Indholdet genereret af en portlet kan variere fra en bruger til en anden afhængigt af portletens brugerkonfiguration.
Portletbeholder
EN portletbeholder kører portlets og giver dem det krævede runtime-miljø. En portletcontainer indeholder portlets og administrerer deres livscyklus. Det giver også vedvarende lagringsmekanismer til portletpræferencer. En portletcontainer modtager anmodninger fra portalen om at udføre anmodninger på de portlets, der hostes af den. En portletcontainer er ikke ansvarlig for sammenlægning af det indhold, der produceres af portlets; selve portalen håndterer aggregering.
En portal og en portletcontainer kan bygges sammen som en enkelt komponent i en applikationspakke eller som to separate komponenter i en portalapplikation.
Begreber
Dette afsnit forklarer de grundlæggende programmeringskoncepter i JSR 168, såsom en portlets livscyklus, interface og tilstande og vinduetilstande samt sessionadgang, vedvarende lageradgang og hvordan man inkluderer servlets og JSP-sider.
Portlets livscyklus
Den grundlæggende portlet-livscyklus for en JSR 168-portlet er:
- I det: initialiser portlet'en og tag den i brug
- Håndter anmodninger: behandle forskellige former for handling- og render-anmodninger
- Ødelægge: sæt portlet ud af drift
Portletbeholderen administrerer portletens livscyklus og kalder de tilsvarende metoder på portletgrænsefladen.
Portlet-grænseflade
Hver portlet skal implementere portlet-interface eller udvide en klasse, der implementerer portlet-interface. Portletgrænsefladen består af følgende metoder:
init (PortletConfig config):for at initialisere portleten. Denne metode kaldes kun én gang efter at have startet portleten. Denne metode kan bruges til at oprette dyre objekter / ressourcer, der bruges af portleten.processAction (ActionRequest anmodning, ActionResponse svar):for at underrette portleten om, at brugeren har udløst en handling på denne portlet. Kun én handling pr. Klientanmodning udløses. I en handling kan en portlet udstede en omdirigering, ændre dens portlet-tilstand eller vinduetilstand, ændre dens vedvarende tilstand eller indstille gengivelsesparametre.gengive (RenderRequest anmodning, RenderResponse svar):for at generere markeringen. For hver portlet på den aktuelle side kaldes gengivelsesmetoden, og portlet'en kan producere markup, der kan afhænge af portlettilstand eller vinduetilstand, gengivelsesparametre, anmodningsattributter, vedvarende tilstand, sessionsdata eller backend-data.ødelægge():for at angive portletten livscyklusens afslutning. Denne metode giver portleten mulighed for at frigøre ressourcer og opdatere vedvarende data, der hører til denne portlet.
Portlet-tilstande
En portlettilstand angiver den funktion, en portlet udfører. Normalt udfører portlets forskellige opgaver og opretter forskelligt indhold afhængigt af de funktioner, de aktuelt udfører. En portlet-tilstand rådgiver portlet'en, hvilken opgave den skal udføre, og hvilket indhold den skal generere. Når der påberåbes en portlet, giver portletbeholderen den aktuelle portletilstand til portleten. Portlets kan programmatisk ændre deres tilstand, når de behandler en handlingsanmodning.
JSR 168 opdeler portlettilstande i tre kategorier:
- Nødvendige tilstande: Hver portal skal understøtte tilstande Rediger, Hjælp og Vis. En portlet skal mindst understøtte den visningstilstand, der bruges til at gengive markering for en side. Redigeringstilstanden bruges til at ændre indstillinger pr. Bruger for at tilpasse portlet-markeringen, og hjælpefunktionen bruges til at vise en hjælpeskærm.
- Valgfri brugerdefinerede tilstande: Dette er tilstande, som en portal muligvis understøtter; i en valgfri tilstand kaldes en portlet muligvis ikke. De valgfri tilstande inkluderer tilstanden Om for at få vist en "om" -meddelelse; konfigurationsfunktionen for at lade administratorer konfigurere portleten; Edit_defaults-tilstand for at lade en administrator forudindstille redigeringstilstandens værdier; Preview-tilstand for at vise portletens preview; og udskrivningstilstand for at gengive en visning, der let kan udskrives.
- Portalsælgerspecifikke tilstande: Disse tilstande er ikke defineret i specifikationen og er derfor leverandørspecifikke.
Vinduetilstande
En vinduetilstand angiver mængden af portalsideplads, der tildeles det indhold, der genereres af en portlet. Når der påberåbes en portlet, giver portletbeholderen portletens aktuelle vinduetilstand. Portlet'en bruger muligvis vinduetilstanden til at bestemme, hvor meget information den skal gengive. Portlets kan programmatisk ændre deres vinduetilstand, når de behandler en handlingsanmodning.
JSR 168 definerer følgende vinduetilstande:
- Normal: Angiver, at en portlet kan dele siden med andre portlets. Dette er standardvinduetilstanden.
- Maksimeret: Angiver, at en portlet kan være den eneste portlet på portalsiden, eller at portlet'en har mere plads i forhold til andre portlets på portalsiden og derfor kan producere rigere indhold end i en normal vinduetilstand.
- Minimeret: Angiver, at portleten kun skal gengive minimalt eller slet ikke output.
Ud over disse vindustilstande tillader JSR 168 portalen at definere leverandørspecifikke vinduetilstande.
En portlet kan kaldes i en hvilken som helst af disse tre vinduetilstande, men er fri til at producere den samme markering for alle tre stater.
Vedvarende butik
Portlet'en kan gemme vedvarende data for en bestemt bruger ved hjælp af PortletPræferencer objekt. Præferencer kan læses og skrives i handlingsfasen og læses i gengivelsesfasen. Den foretrukne tilstand til skriveindstillinger er redigeringstilstand, som giver brugeren en tilpasningsskærm. Præferencerne kan enten være strenge eller strengarrayværdier tilknyttet en nøgle af typen streng. Præferencer kan forudindstilles med standardværdier i installationsbeskrivelsen.
Præferencer og portlets definition i installationsbeskrivelsen definerer sammen en portlet, undertiden kaldet a portletenhed.
Sessioner
JSR 168's sessionskoncept er baseret på HttpSession defineret til webapplikationer. Da portletapplikationer er webapplikationer, bruger de den samme session som servlets. For at tillade portlets at gemme midlertidige data private til en portlet, er standard session omfanget portlet rækkevidde. I dette omfang kan portleten gemme de nødvendige oplysninger på tværs af brugeranmodninger og specifikke for en portletenhed. Attributter, der er gemt med dette omfang, er prefixet i sessionen af portletbeholderen for at undgå, at to portlets (eller to enheder med samme portletdefinition) overskriver hinandens indstillinger.
Ud over portletsessionens omfang understøtter JSR 168 Webapplikation session omfang. I dette omfang kan alle komponenter i webapplikationen få adgang til oplysningerne. Oplysningerne kan bruges til at dele forbigående tilstand mellem forskellige komponenter i den samme webapplikation (f.eks. Mellem portlets eller mellem en portlet og en servlet).
Inkl. Servlets / JSP-sider
For at understøtte Model-View-Controller-mønsteret skal portleten kunne inkludere indhold genereret fra servlets og JSP-sider. På denne måde kan portleten fungere som controller, fylde en bønne med data og inkludere en JSP-side for at gengive output.
I JSR 168 er inkluderingsmekanismen for servlets og JSP-sider den samme for Servlet API. Via portletkonteksten hentes en anmodningsforsendelse til en given sti; det omfatte() metode kaldes derefter på dette anmodning-afsender objekt:
PortletRequestDispatcher rd = getPortletContext (). GetRequestDispatcher (editJSP); rd.include (portletRequest, portletResponse);
Justering med WSRP
WSRP samler indhold produceret af portlets, der kører på eksterne maskiner, der bruger forskellige programmeringsmiljøer, som J2EE (Java 2 Platform, Enterprise Edition) og .Net. WSRP-tjenester er præsentationsorienterede, brugervenlige webtjenester, der plug-and-play med portaler eller andre applikationer. De lader virksomheder levere indhold eller applikationer uden at kræve nogen manuel indholds- eller applikationsspecifik tilpasning ved at forbruge portaler; portaler kan let samle WSRP-tjenester uden programmeringsindsats.
JSR 168-ekspertgruppen justerede omhyggeligt koncepterne mellem JSR 168 og WSRP. Følgende liste viser, hvor meget de vigtigste begreber er tilpasset mellem begge standarder:
