Die Zukunft von Enterprise Portal Servern Was ist ein Portal? Einschätzungen zur Portal-Server-Technologie Betrachtung von Alternativen Eine Anwendung, die auf IBM/Oracle/Sun-Portal-Server oder Liferay, JBoss Portal/Jetspeed-2 basiert?

Navigation + GUI-Integration Was ist ein Portal? Benutzer- verwaltung Einheitliche Darstellung Rechte- verwaltung Personalisierung Content-Management Suchfunktionen Navigation + GUI-Integration Anwendungs- Integrations-Framew. Single Sign On Betriebs- plattform

Content Portals und Mashups Veröffentlichung von „Content“ Suchfunktionen Personalisierung Mini-Apps (= Widgets)

Application-Integration Portals GUI-Integration aller Anwendungen einer Nutzergruppe Anwendungen werden aus Einzelkomponenten zusammengesetzt Integration der Anwendungen untereinander Drag and relate (SAP Enterprise Portal) Click to action (WebSphere Portal-Server)

Application-Integration Portals

Beispiel DKV

Homepage-Center

Homepage-Center

Homepage-Center

Homepage-Center

Homepage-Center

Beispiel Portal-Server Architektur

Meinungen zur Portal-Servern Stefan Tilkov http://www.innoq.com/blog/st/2009/09/q_should_you_use_a_portal_serv.html Q. Should You Use a Portal Server? A. No. Allow me to elaborate: I can’t think of a reason I would suggest to any of our clients to use a portal server. In my personal experience, portal servers, especially commercial ones, are just gigantic bags of more or less related, often quite useless functionality that create far more problems than they solve. One could say that Portals are the ESBs of front-end technology (and many of the arguments for and against them apply).

Meinungen zur Portlet-Spezifikation http://www.jroller.com/dmdevito/entry/portlet_life_looks_like_ejb Well, I think the more important portlet's problem comes from it's a technology with ass between two chairs This technology sits within the architecture/framework/API different levels is both present into client/server side, is at the presentation/business interface... Then, portlets fight on all sides. So, they fight to compete with various solutions, and they are often shaken up by forward moves into connex/close domains (e.g. AJAX introduction). So, the portlet ROI is under pressure. Ergänzung: Portlet-Spezifikation enthält (noch?) kein OSGi Management von Abhängigkeiten Deployment-Modell

Zusammenfassung: Portal-Server-Probleme Unklare Positionierung und Abgrenzung zu Content-Management-System Mashups Security-Infrastruktur Skinning-Solution Anwendungsintegrationsplattform Technologische Eierlegende Woll-Milch-Sau vergleichbar zu EJB 2.x statt Remoting + OSGi + JPA Proprietäre Schnittstellen Portlet-API (JSR 168, JSR-286), Event-Verarbeitungs-Zyklus, Descriptoren, etc. Bestehende Anwendungen lassen sich schwer integrieren

Vorschlag von Stefan Tilkov My suggestion for any company looking at a portal server would be to instead a) hire a good Web designer to create some nice reusable CSS files and example HTML layouts and put them somewhere developers can include them from b) establish single sign-on functionality by means of a shared service, ideally supporting something like OpenID and OAuth c) offer a few URIs where people can pull useful HTML and/or JS fragments from to include in their Web apps. If needed, I’d make sure I get bonus points in the bullshit marketing category by labeling this a “pragmatic open portal strategy”.

Alternative Lösungsansätze Einheitliche Darstellung Zentrale CSS, JS-Libs, Images, GUI-Controls Personalisierung Einsatz von spezialisierten Mashup-Lösungen oder Web-Content-Management-Systemen Navigation + GUI-Integration Wirkliche Herausforderung! Single Sign On OpenID, Sun OpenSSO, ...

Personalisierung durch Mashups z.B Netvibes Portalanbieter stellt nur Infrastruktur zur Verfügung Portal-Module kommen von beliebigen Anbietern

Personalisierung durch Mashups z.B Netvibes Hunderte von Portal-Modulen können ad-hoc integriert werden

iGoogle

Lösungen für Mashups auf Basis von GWT http://allen- sauer.com/com.allen_sauer.gwt.dnd.demo.DragDropDemo/ DragDropDemo.html#PuzzleExample http://www.extjs.com/deploy/dev/examples/portal/portal.html http://code.google.com/p/gwtportlets/ Vergleich von JSR 168, 286 mit GWT: http://www.jroller.com/dmdevito/entry/the_portlet_gwt_comparison_is

Navigation und GUI-Integration Ansätze zum Selbstbau

Navigation und GUI-Integration Kopf-Bereich / Übergreifende Infos Navigation Applikationen

Navigation und GUI-Integration Kopf-Bereich / Übergreifende Infos Navigation Applikationen

Lösungsansatz: iFrames Browserunabhängig Alle Anwendungstypen lassen sich integrieren Klassische HTML-Anwendungen (JSP/struts, PHP, etc) RIAs mit Ruby, GWT, JSF Standardisierte Schnittstelle: Investitionsschutz Native Browser-Unterstützung (das OSGi des Front-Ends!) aber: Keine Suchmaschinenoptimierung Layout-Einschränkungen (Scrolling, Seitenaufteilung, etc)

Lösungsansatz: Server-Side Includes <html> <head>...<head> <body> <include ...> </body> </html> Web-Server (= Mini-Portal-Server) interpret include include Session- Server Personalization Server Application Server Rudimentäre Lösung: Apache mod_ssi: http://de.wikipedia.org/wiki/Server_Side_Includes

Lösungsansatz Server Side Includes Weitere Anforderungen (= Herausforderungen) Rekursives Auflösen von inlucudes Einfügen von HTML-Output an verschiedenen Stellen am Seitenanfang / -ende im header Layout-Management Request-Handling (GET/Post/Ajax-Calls an einzelne Portlets) Management von JS-Bibliotheken und Namespaces Caching Client2Client-Kommunikation (Java-Script) Session-/Cookie-Management Authentifizierung und Authentifizierungsinformationen

Server-Side Includes: Erfahrungen Starke Abhängigkeiten zwischen „Portlets“: gleiches Programmiermodell erforderlich (PHP-Anwendung, Java/Struts-RIA u.a. ließen sich nicht mischen) sehr breite Schnittstellen und häufige Änderungen Ansatz ist sehr proprietät Investitionsschutz? Resultat ist eine geschlossene Anwendung (mit intern modularem Aufbau)

Fazit? Bevorzuge stand-alone-Anwendungen (d.h. vermeide GUI-Integration) Single-Sign-On ist dennoch einfach möglich Frames / iFrames sind praktikabler Ansatz Wenn Einschränkungen akzeptiert werden Mash-ups über GWT anstatt Portal-Server realisieren m.E. aber wenig Bedarf im kommerziellen Umfeld