kontakt

+49 421 20696 - 0
info@team-neusta.de

Ein Portal, ein Tor zum personalisierten Content – Teil 8

Request-Orientierte Protokolle
Die wichtigste Grundlage für alle Arten von Webanwendungen erlaubt die
Implementierung von HTTP, welches ja auch Basis beinahe des gesamten
weltweiten Internetverkehrs ist. Deshalb ist HTTP der quasi de-facto
Standard aller heutzutage gängigen und verbreiteten Portallösungen.

Zusätzlich hat sich bei einigen Portallösungen in der letzten Zeit das WSRP
Protokoll immer mehr durchgesetzt. Dieses Protokoll erlaubt auf einfache Weise 
markupbasierte externe Anwendungen in ein Portalsystem – z.B. mittels
XML – einzubinden. Die Nutzung von WSRP setzt allerdings voraus, dass
sowohl die einzubindende, externe Anwendung als auch die gewählte
Portallösung direkt eine native Unterstützung für dieses Protokoll bieten
und mitbringen.

Die Architektur von WSRP Applikationen und ihren dazugehörigen Komponenten
ähnelt sehr den traditionellen HTTP-Konnektoren.

Blog #1.2

 

Applikationen, die WSRP unterstützen, bieten deshalb ihre
Schnittstellen fertig nutzbar als eine Sammlung von Funktionalitäten
innerhalb eines Portlet-Containers an.

Mittels SOAP erfolgt danach die Integration dieser Portlets in den WSRPConsumer
im Zielportal, welches sich anschließend um die graphische
Aufbereitung und Ausgabe kümmert.

Beispiel: Einbindung von HTTP-Quellen

Die einfachste Methode, HTML-Inhalte in ein Portal einzubinden, kann über iFrame Tags realisiert werden. Diese Art der Einbindung von Inhalten verlagert die eigentliche Arbeit des visuellen Aufbereitung des Contents weiter an den Webbrowser. Da allerdings HTML Frames im Hinblick auf die User- Experience (z.B. durch „verlieren“ einer Portalsitzung nach dem Klick auf externe Links) sehr großen, funktionellen Limitationen unterworfen sind, sollte von dieser Methode nur im Notfall gebrauch gemacht werden.

Ferner können auch dedizierte Applets dazu eingesetzt werden, HTML-Inhalte
unabhängig vom durch den Benutzer verwendeten Browser, zu
rendern. Allerdings fordert dieser Lösungsansatz deutlich höhere Client-
Spezifikationen und mehr Leistung und sollte nur komplexen Anwendungen
vorbehalten bleiben, die sowieso eine permanente Kommunikation mit dem
Backend benötigen.

Die dritte Möglichkeit besteht aus der Anbindung der Quelle über einen
HTTP-Handler, der als Reverse-Proxy inklusive eines Content-Rewritings
fungiert. Dieser Ansatz erlaubt die nahtlose Integration externer Inhalte in
das Portal unter gleichzeitiger Beibehaltung maximaler Kompatibilität. Da
HTML allerdings heterogen ist, ist diese Lösung bei weitem auch die
komplexeste.

Die grundlegenden Funktionalitäten eines solchen externen HTTP-Handlers
sind im Ablauf die folgenden:

Blog #1.3

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Das Thema „Performance“ ist bei der Konzeption solcher Handler (Konnektoren) von Anfang an sehr wichtig und sollte einen hohen Stellenwert und Beachtung bei deren Konzeption finden.

Ein in das Portal integrierter Handler, egal ob dieser nun zu 100% mit
eigenen Lösungen oder zum Großteil auf einer bestehenden API des
jeweiligen Portalanbieters aufbaut, sollte eigene Caching-Routine und
intelligente Content-Indizierungsmechanismen mitbringen.

Vorbehalte gegenüber Open-­‐Source-­‐Lösungen

Viele Unternehmen hegen insbesondere bei Portalen starke Vorbehalte und
Bedenken gegenüber Open-Source-Lösungen. Meistens sind diese
Bedenken allerdings weitestgehend unbegründet, denn die Logik hinter den
positiven Aspekten des Einsatzes von Open-Source ist folgende: Der
technische Reifegrad der auf Open-Source basierten und im Rahmen
kommerzieller Lizenzen vertriebener Portallösungen ist um ein vielfaches
höher als bei vergleichbarer, nicht quelloffener Software. Durch
kommerziellen Support für Open-Source-Produkte bedarf keiner speziellen
Kenntnisse innerhalb des Unternehmens während der Integrations- und Erweiterungsphase. Studien zeigen ferner das durch die große Entwicklercommunity marktdynamische Tendenzen viel schneller berücksichtigt werden oder die Integration zusätzliche Dienste. wie etwa die sprachliche Lokalisierung von Komponenten, sehr viel schneller erfolgt.

Als Beispiel hierfür sei einmal Liferay genannt: Die über 1,7 Million Zeilen
Code repräsentieren über 500 Mannjahre an Arbeit für ein Produkt, das in
unzähligen produktiven und prototypischen Installationen tagtäglich
Anwendung findet.

Das von vielen Kritikern oftmals angeführte Argument ist, dass die Open-
Source-Bewegung relativ jung sei. Demnach existieren nur eingeschränkte
Aussagen über deren längerfristigen Fortbestand und den Support von
solchen Produkten und ihre technische Weiterentwicklung existieren wird
zerstreut von dem Erfolg vieler kommerzieller Firmen, die ein robustes
Dienstleistungsangebot und Support um vertriebene Open-Source Software
herum aufbauen und langfristig am Markt etablieren können.

Open-Source-Portallösungen sind daher genauso sicher, aus investitionstechnischer
Sicht, wie vergleichbare, kommerzielle, nicht quelloffene Lösungen,
da eine fortlaufende Wartung auch selbst dann weiterhin möglich ist
wenn die ursprüngliche Firma inzwischen nicht mehr existieren sollte.

Dank des implementationszentrischen Ansatzes ist es aber ebenfalls auch
nicht ausgeschlossen, quelloffene und nichtquelloffene Lösungen von
verschiedenen Anbietern im Rahmen eines benutzerorientierten Portals
gemeinsam zu betrieben.

Fortsetzung in Teil 9:

Im nächsten Teil geht es dann um die Performance von Unternehmensportalen unterteilt in z.B. die Systemanalyse, Think Times und Benutzeraktivitäten.

Lesen Sie hier ab dem 16.10 den Teil 9

Share