xp-ug, 10.2.2010 [email protected], die zukunft von enterprise portal servern1 die zukunft...
TRANSCRIPT
1XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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?
2XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Was ist ein Portal?
Einheitliche Darstellung
Benutzer-verwaltung
Rechte-verwaltung
Content-Management Suchfunktionen
Personalisierung
Navigation +GUI-Integration
Single Sign On
Anwendungs-Integrations-Framew.
Betriebs-plattform
3XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Content Portals und Mashups
Veröffentlichung von „Content“
Suchfunktionen
Personalisierung
Mini-Apps (= Widgets)
4XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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)
5XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Application-Integration Portals
6XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Beispiel DKV
7XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Homepage-Center
8XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Homepage-Center
9XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Homepage-Center
10XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Homepage-Center
11XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Homepage-Center
12XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Beispiel Portal-Server Architektur
AddressValidation
UserClassification
ContentClassification
Data Export
Data Import
Statistics
SystemMonitoring
SMS ACPServer
SMS-ACP
SMSServer
E-MailServer
J2EEApplication ServerServlet Engine
ServiceBus
Monitoring Service
Admin Service
Cron Service
Content Service
Logging Service
User Admin Service
Personalization Service
Authentication Service
Billing Service
Accounting Service
VoiceServer
WAP Gateway
Search Service
ContentDatabase
HistoryDatabase
ProfileDatabase
Web Server
Billing System
Search Engine
Mer
ced
es-S
ervi
ces-
Ad
apte
r
DC
-TV
-Ad
apte
r
DC
-New
s-A
dap
ter
Xip
oli
s-A
dap
ter
T-O
nli
ne-
Ad
apte
r
Wet
ter-
On
lin
e-A
dap
ter
HR
S-A
dap
ter
PT
V-A
dap
ter
Teg
aro
n-A
dap
ter
Day
-By-
Day
-Ad
apte
r
HTML cHTMLE-MailSMS
WML
WML
XML
XML
XML
XML
XML
XML
ConfiguratorXML
Content EditorXML
Structure EditorXML
Call CenterClient
XML
Voice
XM
L
Legend
Adapter Component
Frontend Component
Base Component
Attached Component
Internal Component
Database
Internal Data Flow
External Data Flow
Runtime Environment
Bus
SMS ACP Service
SMS Service
E-Mail Service Portal Server
TransformationEngine
SessionManagement
LoginManagement
Classification Engine
WorkflowManagement
XML
13XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Meinungen zur Portal-Servern
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).
Stefan Tilkov http://www.innoq.com/blog/st/2009/09/q_should_you_use_a_portal_serv.html
14XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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
http://www.jroller.com/dmdevito/entry/portlet_life_looks_like_ejb
15XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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
16XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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”.
Stefan Tilkov: http://www.innoq.com/blog/st/2009/09/q_should_you_use_a_portal_serv.html
17XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Alternative Lösungsansätze
Einheitliche Darstellung
Personalisierung
Navigation +GUI-Integration
Single Sign On
Zentrale CSS, JS-Libs, Images, GUI-Controls
Einsatz von spezialisierten Mashup-Lösungen oderWeb-Content-Management-Systemen
Wirkliche Herausforderung!
OpenID, Sun OpenSSO, ...
18XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Personalisierung durch Mashups z.B Netvibes
Portalanbieter stellt nur Infrastruktur zur Verfügung
Portal-Module kommen von beliebigen Anbietern
19XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Personalisierung durch Mashups z.B Netvibes
Hunderte von Portal-Modulen können ad-hoc integriert werden
20XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
iGoogle
21XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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
22XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Navigation und GUI-Integration
Ansätze zum Selbstbau
23XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Navigation und GUI-Integration
Kopf-Bereich / Übergreifende Infos
Navigation Applikationen
24XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Navigation und GUI-Integration
Kopf-Bereich / Übergreifende Infos
Navigation
Applikationen
25XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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)
26XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
Lösungsansatz: Server-Side Includes
Web-Server(= Mini-Portal-Server)
Session-Server
PersonalizationServer
ApplicationServer
<html><head>...<head><body>
<include ...><include ...><include ...>
</body></html>
interpret
include include
Rudimentäre Lösung: Apache mod_ssi: http://de.wikipedia.org/wiki/Server_Side_Includes
27XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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
28XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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)
29XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern
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