Öppna Program RA - XForms utredning

Features Orbeon Orbeon är en ajax-baserad, serverside XForms- implementation. – Stöd i browsern för XForms är inte nödvändigt. – Har även ett noscript-läge med begränsad funktionalitet. Open Source – Kommersiell support – Licens: LGPL Orbeon består av följande delar: – XForms Engine – XML pipeline Engine – Page Flow Controller (PFC) – XForms builder (Alpha)

Arkitektur Källa:

Versioner Senaste stabila: Orbeon 3.6 (dec 07) – Har en känd bugg ihop med Firefox 3 – Saknar stöd för att stänga av javascript – Ska enligt dokumentationen gå att deploya i JSR 168-portal (Liferay). Tycks dock ej fungera. Orbeon 3.7 Beta 1 (aug 08) – Fortfarande problem att deploya på portal. Latest build av 3.7 (20/3 2009) – Funkar på os-portal - dock ej på WebSphere Portal rakt av Frågetecken – när kommer Orbeon 3.7 i en (tillräckligt) stabil version?

Alternativa användningar 1.Använda hela Orbeon-sviten, inkl XML pipelines och PFC. – Innebär att man bygger hela ”applikationer” med Orbeon, inkl flödeslogik etc. – Applikationerna deployas ihop med/under orbeon.war. – Fördelar: De flesta exemplen/dokumentationen från Orbeon bygger på detta. – Nackdelar: Inlåsning till Orbeon. När ska detta resp. RAs teknikstack användas? 2.Integration med Java/RA där endast Orbeon XForms Engine används. – Fördelar: Vi kan byta ut Orbeon mot alt impl. Naturlig uppdelning mellan RA och Orbeon. – Nackdelar: De flesta exemplen och dokumentationen blir irrelevanta. Inga exempel/dok hur man åstakommer detta för portlets – Kommentar: Orbeon är monolitisk: Det är inte dokumenterat om/hur Orbeons Xforms Engine kan brytas ut och deployas för sig. Man får lösa det med guidelines/restriktioner inom RA.

2 Orbeon som en XForms Engine Två alternativa vägar: a)Separat deployment Orbeon.war och myWebApp.war deployas sida vid sida. Egenutvecklade XForms-formulär ligger i myWebApp, t ex under en specifik folder. Ett servletfilter används för att redirecta/forwarda requests rörande dessa sidor till orbeon. – För att detta skall vara tillåtet måste ”crossContext” slås på. MyWebApp behöver ha en jar-fil från Orbeon under web- inf/lib. b)Integrerad deployment Orbeon och myWebApp slås ihop i en war-fil. Formulären deployas i denna war-fil (snarlik alt 1s deploy).

2a Separat deployment Fördelar: – Lättare att uppgradera Orbeon om den deployas fristående – Slipper problem med krockar i 3:e partsbibliotek – Slipper problem med att Orbeon inte bygger på Maven Endast en orbeon-jar-fil behövs i myWebApp. Nackdelar: – Går ej att få till i portalmiljö (?). – ”CrossContext” måste tillåtas för webappen. Ej standard - Hur åstakomma detta på andra appservrar än Tomcat, t ex WebSphere? Något oklart vad det får för implikationer t ex säkerhetsmässigt, deploymentmässigt etc.

2b Integrerad deployment Fördelar: – Likartad setup funkar både för portlet och webapp. För portlets: oklart/odokumenterat hur man gör för att inte använda PFC – Vi slipper crossContext. Nackdelar: – Orbeon bygger ej på Maven – krock mot RA. – Ev problem med krockar för beroenden till 3:e partsbibliotek. Web-inf lib i orbeon.war > 70 jar-filer! – Krångligare vid uppgraderingar. Gemensam web.xml och portlet.xml. Kommentar: För detta alternativ rekommenderas att vi skapar en separat webapp där orbeon + formulär läggs. Kommunikation bakåt med (REST-baserade) tjänster deployade utanför denna webapp.

Deployment En gemensam installation (per portal/appserver) Innebär att alla system/komponenter använder samma orbeon. Orbeon ses som en ”plattformskomponent” Alla måste ligga på samma version och uppgraderas samtidigt. – Kan lösas genom att man deployar flera orbeoen – en per version. För portlets: Leder till konstiga beroenden mellan system/komponenter – ”deploy” av portlet-formulär i Orbeon innebär att man lägger saker under web-inf och ev uppdaterar web.xml/portlet.xml. En per verksamhetskomponent/system Orbeon.war måste döpas om/ges en annan path. Olika versioner kan användas i olika system/komponenter. Det blir upp till varje systemägare att bestämma när man uppgraderar.

Föreslagen integration med RA – Webapp 2a – Separat deployment rekommenderas – Rekommenderas av orbeon själva. – Slipper hantera alla jar-filer som orbeon för med sig. Vi kan använda maven ”som vanligt”. – Formulären deployas i web-projektet. En installation av Orbeon per Orbeon version rekommenderas – Orbeon deployas som en war med versionsnummer i pathen. – På så vis kan olika system använda olika versioner av Orbeon. Bakomliggande tjänster som servar formulären implementeras som enkla XML-baserade REST-tjänster – Mha JSR 311/JAX-RS. Obs RAs ”vanliga” teknikstack, inkl JSF kan ej användas för formulären – Formulär byggs som egna sidor, mha XHTML/JSP (ev facelets). – För en sammanhållet applikation går det bra att länka fram och tillbaka mellan formulärsidor och övriga sidor. Lösningen behöver verifieras ytterligare genom PoC/exempelapp

Föreslagen integration med RA – Portlet 2b - Integrerad deployment rekommenderas – Finns inga andra alternativ för portlets (?) – Vi minimerar nackdelen vid uppgraderingar genom att skapa en separat web- modul/war-fil för detta där vi endast deployar formlären. En installation/system eller verksamhetskomponent rekommenderas – Vi slipper konstiga beroenden mellan komponenter/system. – Beslut måste tas om det blir per system/verksamhetskomponent. I övrigt gäller samma som för webbappar: – Bakomliggande tjänster som servar formulären implementeras som enkla XML-baserade REST-tjänster Mha JSR 311/JAX-RS. – Obs RAs ”vanliga” teknikstack, inkl JSF kan ej användas för formulären Formulär byggs som egna sidor, mha XHTML/JSP (ev facelets). För en sammanhållet applikation går det bra att länka fram och tillbaka mellan formulärsidor och övriga sidor (som ligger i en annan webapp). – Lösningen behöver verifieras ytterligare genom PoC/exempelapp

Föreslagen arkitektur - webapp Applikationserver Formlär Orbeon war REST- tjänster myWebbApp.war Orbeon filter

Portalserver Föreslagen arkitektur - Portlet Applikationserver myWebbApp.wa r REST-baserat API Formlär myOrbeon.war

Föreslagen integration med RA – Webapp Verksamhetskomponent (CM-Struktur) Applications (EAR) Gui EarWs Ear Modules (WAR) WebPortletIntsvc Composites (JAR) Web- Comp SvcTypesSche-mas Tjänster byggs upp mha ett JAX-RS- baserat REST-ramverk. I webbappfallet läggs även formulären här och Orbeons filter- konfigureras in.

Föreslagen integration med RA – Portlet Verksamhetskomponent (CM-Struktur) Applications (EAR) Gui EarWs Ear Modules (WAR) WebPortlet My- Orbeon Intsvc Composites (JAR) Web- Comp SvcTypes Sche- mas Orbeon.war döps om och ges en unik path. Här deployas även formulären. Tjänster byggs upp mha ett JAX-RS- baserat REST-ramverk. OBS! Under utredning…

Fördelar och nackdelar Orbeon Fördelar: – Har funnits ett tag (släpptes som Open Source 2004) – Många exempel – Open Source men support går att köpa till – Har stöd för att stänga av javascript (?) och fungera både i webapp och i portalmiljö (två viktiga baskrav) Nackdelar: – Monolitisk, svårt att bryta ut bara XForms Engine. De flesta exemplen använder sig av alla delar (dvs ej bara Xforms Engine). Många 3:e parts beroenden. Odokumenterat vilka som används till vad. – Bygger ej på Maven. – Portlet-delarna är relativt odokumenterade Mer avancerade frågor i mailinglistan besvaras inte eller väldigt långsamt… – Fungerar ej ihop med JSF som RA bygger på. Formulär måste ligga på ”egna sidor”. – Osäkert när version 3.7 kommer i stabil version. – Xforms Builder är i Alpha-version.

Alternativa implementationer Förutom Orbeon har implementationen Chiba ( utvärderats. Bland dessa två har Orbeon valts främst av följande två anledningar: – Bättre stöd för deploy i portal-miljö (dock ej fungerande på WebSphere Portal 6.1 i dagsläget) – Orbeon uppfattas som ett "mer levande" open source- projekt inkl bättre dokumentation, större möjligheter till support mm. Dock skall Orbeon användas endast som en Xforms engine, dvs det ska gå att byta implementation i framtiden!

Utestående frågor Orbeon Vilken version av Orbeon ska vi köra på? Hur gör vi vid uppgraderingar? Deploy på WebSphere Portal 6.1 Oklart hur man gör i en portlet för att bara använda XForms Engine Säkerhet Utökat test av Noscript support – snabbt test gav ej önskat res.. Utökad test av File Upload – med annat än base64-encodning Hur skicka parametrar till ett formulär i en portlet (ex för felanmälan-formuläret)? Test med stylesheets i portalmiljö Debug/felsökning Göra en fullständig PoC/exempelapp inom ramen för RA

RA Utökad exempelapp/PoC – Undersöka var REST-”tjänsterna” ska placeras - i svc eller i web-projektet. – Vilken implementation av JAX-RS ska väljas? – Deployment – en installation per verksamhetskomponent eller system? – Test av länkar från och till andra sidor inom RA. – Det bör gå att bygga projektet med maven – även om dependencies inte sköts via maven. – Dokumenterad tillsammans med en detaljerad anvisning på google code wikin. – Ev genom första skarpa projektet?