Download - XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern1 Die Zukunft von Enterprise Portal Servern Was ist ein Portal? Einschätzungen

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?


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


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


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


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


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


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

Stefan Tilkov: http://www.innoq.com/blog/st/2009/09/q_should_you_use_a_portal_serv.html


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


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



Kopf-Bereich / Übergreifende Infos

Navigation Applikationen



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

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


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

Download - XP-UG, 10.2.2010 [email protected], Die Zukunft von Enterprise Portal Servern1 Die Zukunft von Enterprise Portal Servern Was ist ein Portal? Einschätzungen

Top Related