Die Zukunft von Enterprise Portal Servern

Präsentation zum Thema: "Die Zukunft von Enterprise Portal Servern"—  Präsentation transkript:

1 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?

2 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

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

4 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)

5 Application-Integration Portals

6 Beispiel DKV

7 Homepage-Center

8 Homepage-Center

9 Homepage-Center

10 Homepage-Center

11 Homepage-Center

12 Beispiel Portal-Server Architektur

13 Meinungen zur Portal-Servern
Stefan Tilkov 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).

14 Meinungen zur Portlet-Spezifikation
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

15 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

16 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”.

17 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, ...

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

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

20 iGoogle

21 Lösungen für Mashups auf Basis von GWT
sauer.com/com.allen_sauer.gwt.dnd.demo.DragDropDemo/ DragDropDemo.html#PuzzleExample Vergleich von JSR 168, 286 mit GWT:

22 Navigation und GUI-Integration
Ansätze zum Selbstbau

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

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

25 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)

26 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:

27 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

28 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)

29 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