DE10295699T5 - Eine Anordnung und ein Verfahren in Bezug auf Sitzungsverwaltung in einer Portalstruktur - Google Patents

Eine Anordnung und ein Verfahren in Bezug auf Sitzungsverwaltung in einer Portalstruktur Download PDF

Info

Publication number
DE10295699T5
DE10295699T5 DE10295699T DE10295699T DE10295699T5 DE 10295699 T5 DE10295699 T5 DE 10295699T5 DE 10295699 T DE10295699 T DE 10295699T DE 10295699 T DE10295699 T DE 10295699T DE 10295699 T5 DE10295699 T5 DE 10295699T5
Authority
DE
Germany
Prior art keywords
portal
session
external
service
application
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE10295699T
Other languages
English (en)
Inventor
Thomas Papanikolaou
Jan Åkerfeldt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of DE10295699T5 publication Critical patent/DE10295699T5/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/954—Navigation, e.g. using categorised browsing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2871—Implementation details of single intermediate entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Remote Sensing (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Portalstruktur, die Endnutzerstationen mit Zugriff auf Dienste/Anwendungen versieht, umfassend einen Portalkern, (Dienstbefähigungsmittel, Konnektivitätsmittel, über die Endnutzerzugriff vorgesehen wird) und eine Anzahl von Diensten/Anwendungen, wobei der Portalkern umfasst eine Präsentationsanordnung, Portalsitzungsverwaltungsmittel, die sitzungsbezogene Information generieren, z.B. Sitzungsidentifikationen, Portalspeichermittel zum Speichern sitzungsbezogener Information (und Teilnehmerverwaltungsmittel), wobei mindestens einige der Dienste/Anwendungen externe Dienste/Anwendungen umfassen oder durch externe Systeme vorgesehen werden, die externe Sitzungsverwaltungsmittel implementieren, die externe Sitzungsidentifikationen generieren,
gekennzeichnet dadurch, dass
die Portalstruktur ferner Sitzungsvereinheitlichungsmittel zum Abbilden zwischen Portalsitzungsidentifikationen und externen Sitzungsidentifikationen umfasst und dadurch, dass für eine Kommunikation zwischen dem Portalkern und externen Diensten/Anwendungen die externe Identifikation eines externen Dienstes/Anwendung als Sitzungsidentifikation verwendet wird, wohingegen in einer Kommunikation zwischen einer Endnutzerstation und dem Portalkern nur die Portalsitzungsidentifikation als Sitzungsidentifikation verwendet wird.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung bezieht sich auf Sitzungsverwaltung und Portalstrukturen, insbesondere Internetportale, die Endnutzerstationen mit Zugriff auf Dienste/Anwendungen versehen. Die Erfindung bezieht sich auch auf eine Anordnung in einer Portalstruktur, die für eine Sitzungsverwaltung verwendet wird. Die Erfindung bezieht sich ferner auf ein Verfahren zur Sitzungsverwaltung in einer Portalstruktur für Endnutzer, die auf Dienste/Anwendungen über die Portalstruktur zugreifen.
  • Die Erfindung bezieht sich insbesondere auf eine Handhabung von Sitzungsverwaltung, wenn unterschiedliche Entitäten, wie etwa Portale, Dienste oder eine Anwendung durch unterschiedliche Sitzungsverwaltungsmittel verwaltet werden.
  • STAND DER TECHNIK
  • Wenn auf ein Portal verwiesen wird, ist allgemein ein Internetportal gemeint. Internetportale, die mit Endnutzern interagieren, sehen gewöhnlich eine Sitzungsverwaltung vor, um in der Lage zu sein, die Aktivitäten der Endnutzer zu verfolgen und eine Steuerung von ihnen beizubehalten, und um endnutzerspezifische Information, wie Authentifizierungsstatus, Information, wie etwa Listen und Reihenfolge von begonnenen Aktionen und resultierenden Ereignissen etc. zu speichern. Heute muss ein Portal häufig in der Lage sein, Funktionalität von anderen Softwaresystemen oder selbst anderen Portalen zu integrieren. Manchmal haben jedoch derartige andere Systeme, wie etwa Dienste/Anwendungen oder andere Portale, ihre eigene Sitzungsverwaltung. Dies bedeutet, dass auf einem Weg oder einem anderen eine Sitzungsverwaltung, wie durch unterschiedliche Sitzungsverwaltungsmittel vorgesehen, integriert oder kombiniert werden muss.
  • Es gibt auch einen wachsenden Bedarf, den Weg zu personalisieren oder anzupassen, auf dem ein Endnutzer auf Dienste ungeachtet von dem tatsächlichen Standort der Dienste oder Anwendungen oder wer der Dienstanbieter ist, zugreifen kann. Auch erlangt die Nachfrage nach Zugriff auf mobile Internetdienste an Wichtigkeit, d.h. dass Endnutzer wünschen können, auf eine rasche und unkomplizierte Art und Weise in der Lage zu sein, Zugriff auf Dienste von einer beliebigen Endnutzerstation zu erhalten, d.h. auch von mobilen Vorrichtungen; es kann sich auch auf Senden und Empfangen von E-Mails, Kurznachrichten, Zugriff auf web-basierte Information von einem Mobiltelefon ebenso wie von stationären Endnutzervorrichtungen auf eine benutzerfreundliche, schnelle und einfache Art und Weise beziehen. Dies wird das mobile Internet genannt.
  • Browsen unter Verwendung einer mobilen Vorrichtung ist jedoch schwieriger als Browsen unter Verwendung eines PC, da die mobile Vorrichtung im Vergleich zu dem PC begrenzte Eingabe- und Ausgabefähigkeiten aufweist. Dies bedeutet somit, dass es noch schwieriger wird, mobile Endnutzer mit einer befriedigenden Personalisierung zu versehen, und Verwaltung von Diensten ebenso wie Sitzungsverwaltung werden noch komplizierter. Gleichwohl gibt es eine wachsende Nachfrage im Namen von dem Endnutzer, stets auf Anwendungen und Dienste zugreifen zu können. Ein Portal ist ein derartiger Eingang zu dem Inhalt von Diensten und Anwendungen, der insbesondere maßgeschneidert werden sollte, um auf die Endnutzerpräferenzen zu passen.
  • Beispiele im Portalinhalt sind Informationsdienste (inkludierend auch Anstoßinhalt, der sich auf eine Internettechnik bezieht, durch die alle Information, die ein Benutzer abonniert, automatisch dem Benutzer bereitgestellt wird, oder Information, von der der Dienstanbieter oder Betreiber meint, dass sie dem Benutzer bereitgestellt werden sollte). Beispiele von Informationsdiensten sind Wettervorhersagen oder Wetterinformation im allgemeinen, kommerzielle Dienste, wie etwa Einkaufszentren, oder allgemein eine beliebige Art von Information, Multimediadienste, wie etwa Audio-/Video-Streaming, Spiele, Sofortnachrichten, Newsgroups (Nachrichtengruppen), web-basierte Post, Zugriff auf bestimmte Gemeinschaften durch Chat-Rooms (Gesprächsräume). Es ist auch wünschenswert in der Lage zu sein, anziehende grafische Benutzerschnittstellen zum Darstellen von Anwendungen und Menüs auf PC's, und insbesondere auch für WAP-befähigte Vorrichtungen, im Fall, dass ein Portal mobil ist, vorzusehen. Es wird viel Anstrengung für eine Personalisierung der Struktur und des Inhalts von persönlichen Portalen vollbracht, und um eine Möglichkeit vorzusehen, die Interaktion und das Verhalten von einzelnen Diensten und Anwendungen durch Einstellen persönlicher Präferenzen zu steuern. Es ist jedoch schwierig, befriedigende Zugriffsmöglichkeiten ungeachtet dessen vorzusehen, welcher Art eine Vorrichtung ist, die durch einen Endnutzer verwendet wird. Insbesondere wenn unterschiedliche Systeme integriert werden müssen, kann, so weit wie Probleme von Sitzungsverwaltung betroffen sind, d.h. wenn die unterschiedlichen Systeme (Portale, Dienste/Anwendungen, andere Portale etc.) ihre eigene Sitzungsverwaltung haben, die Situation sehr kompliziert werden.
  • Bis jetzt werden viele Anwendungen im Prinzip ausschließlich für die 2G-Telekommunikationsumgebung gestaltet und sie wurden als monolithische Blöcke implementiert oder mit einem proprietären Dienstnetz, um die speziellen QoS-Anforderungen für die jeweiligen Anwendungen zu handhaben. Dies hat zur Folge, das derartige Anwendungen befriedigend als isolierte Anwendungen arbeiten, sie aber schwierig mit anderen Anwendungen zu integrieren sind, die auf ähnlichen Wegen entwickelt werden. Anwendungen, die für die Internet- (Internetprotokoll) Umgebung entwickelt wurden, basierten zu einem großen Ausmaß auf hergestellten und offenen de facto Standards, die eine extensive Integration von unterschiedlichen Anwendungen unterstützen. Viele derartige Standards wurden in der 2G-Umgebung für nicht-echtzeitkritische Anwendungen verwendet. Durch die Einführung von 3G-Netzwerken (3GPP) werden zukünftige Anwendungen jedoch eine Mischung von Telekommunikations- und Datenkommunikationsdiensten enthalten, wobei höhere und niedrigere Bitraten ebenso wie Echtzeit- und Nicht-Echtzeit-Verkehr gemischt werden. Die heutigen Dienstnetze sind nicht gestaltet, derartige Mischungen zu handhaben, noch sind die existierenden IP-basierten Anwendungen für die speziellen Charakteristika gestaltet, die drahtlose Netze betreffen. Wie gesehen werden kann, gibt es viele Komplikationsfaktoren, die die Bereitstellung von einem zufriedenstellenden Zugriff für Endnutzer auf Dienste betreffen, insbesondere wenn Sitzungsverwaltung durch unterschiedliche Sitzungsverwalter für unterschiedliche Systeme/Entitäten gehandhabt wird.
  • Sitzungsverwaltung von homogenen Portalumgebungen kann klar spezifiziert werden und kann z.B. basierend auf der Servlet-Sitzungs-API-(Anwendungsprogrammierschnittstelle)Spezifikation oder der Sitzungs-EJB-(Enterprise Java Beans)Spezifikation durchgeführt werden. Diese Spezifikationen definieren die Basisoperationen für eine Sitzungsverwaltung, um nämlich eine Sitzung zu erstellen/zu zerstören und um ein Schlüsselwertpaar in einer aufgebauten Sitzung zu erhalten, einzustellen und zu entfernen.
  • Internetportale sind gewöhnlich mit einem Sitzungsverwaltungssystem versehen, das eine Verfolgung der Aktionen erlaubt, die durch einen Endnutzer begonnen werden. Derartige Aktionen können z.B. die Aktionen inkludieren ein Endnutzer betritt das System, Authentifizierung des Endnutzers, Zugriff durch den Endnutzer auf einen Portaldienst etc. Solange wie der Endnutzer innerhalb des Portals navigiert, d.h. Zugriff zu Diensten/Anwendungen innerhalb des Portals anfordert, was hier Dienste/Anwendungen bedeutet, für die eine Sitzungsverwaltung zentral innerhalb des Portals gehandhabt wird, kann eine Sitzungsverwaltung einfach gehandhabt werden, da jeder Portaldienst bei einem zentralen Sitzungsverwalter, d.h. dem Portalsitzungsverwaltungsmittel, nachfragen kann, um Information abzurufen, die in der Sitzung von dem Endnutzer gespeichert ist. Die Sitzungen werden insbesondere in Speichermitteln gespeichert. Die Situation ist jedoch anders, falls ein Endnutzer Zugriff auf ein externes System oder auf einen Dienst oder eine Anwendung anfordert, die mit dem Portal integriert ist, oder einen externen Dienst/eine Anwendung, was hier einen Dienst/eine Anwendung mit einer externen oder seiner/ihrer eigenen speziellen Sitzungsverwaltung bedeutet. Die Situation kann dann sehr kompliziert sein. Ein ernstes Problem ist, dass falls ein Dienst oder eine Anwendung (oder ein anderes Portal), auf das ein Endnutzer über eine Portalstruktur zugreifen möchte, seine/ihre eigene Sitzungsverwaltung hat, die externe Sitzungsverwaltung zu der Portalsitzungsverwaltung inkompatibel sein kann. Dies ist häufig der Fall, wenn Anwendungsdienstanbieter Portalbesitzern Dienste anbieten. Aus verschiedenen Gründen kann es nicht wünschenswert sein, dem Endnutzer die externe Sitzungsverwaltung offenzulegen. Weiter noch tendieren die Sitzungen, die unter Inbetrachtnahme auch der externen Sitzungsverwaltung erstellt werden, dazu, sehr lang zu werden, d.h. die Sitzungsidentität, die in einer Kommunikation mit dem Endnutzer verwendet wird, muss nicht nur die Portalsitzungsidentität enthalten, sondern zusätzlich dazu auch die externe Sitzungsidentität. Häufig können derartige langwierige Sitzungsidentifizierungen nicht durch die Clients gehandhabt werden, die durch das Portal bedient werden. Dies ist insbesondere gravierend, falls die Endnutzerstation eine mobile Vorrichtung ist, wie etwa eine WAP-Vorrichtung, die einfach nicht in der Lage sein kann, derartige große Datenmengen zu handhaben. Selbst für eine Endnutzerstation, die in der Lage ist, derartige Datenmengen nur für Identifikationszwecke zu handhaben, bezieht es eine Verschwendung von Ressourcen und Zeit ein.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Was benötigt wird, ist deshalb eine Portalstruktur, durch die eine Sitzungsverwaltung auf eine einfache und effiziente Art und Weise gehandhabt werden kann, auch wenn die Sitzungsverwaltung der Systeme/Dienste/Anwendungen, auf die zugegriffen wird, durch andere verschiedene Sitzungsverwaltungssysteme gehandhabt wird. Insbesondere wenn eine Portalstruktur ihr eigenes Portalsitzungsverwaltungsmittel hat und ein anderes System, wie etwa ein Dienst, eine Anwendung oder ein anderes Portal, zu dem ein Endnutzer Zugriff anfordert, sein eigenes, hier als extern bezeichnetes oder proprietäres Sitzungsverwaltungsmittel hat, wird eine einfache und effiziente Sitzungsverwaltung benötigt. Es wird insbesondere eine nahtlose Vereinheitlichung von Sitzungsverwaltung zwischen Portalen und extern sitzungsverwalteten (externen) Systemen benötigt. Es wird auch eine Portalstruktur benötigt, durch die die Sitzungsverwaltung, die in anderen Systemen existiert, wie etwa Dienste/Anwendungen oder Portale, die durch Sitzungsverwaltungsmittel von einem Drittanbieter sitzungsverwaltet werden, oder externe Sitzungsverwaltungsmittel mit der Portalsitzungsverwaltung kombiniert und integriert werden kann.
  • Es wird auch eine Anordnung benötigt, durch die eine Portal-(interne) Sitzungsverwaltung und verschiedene Sitzungsverwaltungsverfahren von einem Drittanbieter oder externe sitzungsverwaltete Systeme in eine vereinheitlichte Sitzungsverwaltung vereinheitlicht werden können. Es wird insbesondere eine Portalstruktur benötigt, die in der Lage ist, einen Endnutzer mit Zugriff auf Dienste/Anwendungen zu versehen, für die eine Sitzungsverwaltung durch ein externes Sitzungsverwaltungsmittel (Sitzungsverwaltungsmittel eines Drittanbieters) gehandhabt wird, d.h. nicht das gleiche Sitzungsverwaltungsmittel wie das Portalsitzungsverwaltungsmittel, ebenso wie auf interne Dienste/Anwendungen. Ein Endnutzer sollte somit mit Zugriff auf Dienste etc. ungeachtet dessen versehen werden, ob sich die Dienste/Anwendungen (Inhalt) innerhalb der Portalstruktur selbst befinden oder ob die Anwendungen/Dienste und deren Inhalt außerhalb des Portals angesiedelt sind, d.h. durch externe Dienstanbieter vorgesehen werden und/oder durch externe Sitzungsverwaltungsmittel sitzungsverwaltet werden.
  • Es wird insbesondere eine Portalstruktur benötigt, die Zugriff durch mobile Endnutzerstationen (zusätzlich zu stationären Endnutzerstationen) ungeachtet dessen erlaubt, ob die Dienste/Anwendungen etc., auf die zugegriffen wird, intern oder extern sitzungsverwaltet werden. Es wird auch eine Portalstruktur benötigt, durch die die Anzahl von Parametern, die in einer Kommunikation mit Endnutzern verwendet werden müssen, im Vergleich zu bisher bekannten Strukturen verringert wird, und ungeachtet dessen, ob die Dienste/Anwendungen, auf die zugegriffen wird, innerhalb des Portals angesiedelt sind oder nicht, und ungeachtet dessen, ob sie separat oder extern sitzungsverwaltet werden. Es wird insbesondere eine Portalstruktur benötigt, die zum Integrieren verschiedene Sitzungsverwaltungsverfahren zur gleichen Zeit fähig ist, wie sie Internet- und WAP-basierte Dienste integriert, sodass Zugriff von einem beliebigen mit dem Internet verbundenen PC, WAP-Vorrichtung oder einer beliebigen anderen mobilen Vorrichtung unter Verwendung eines beliebigen mobilen Zugriffsnetzes ermöglicht wird.
  • Es wird auch eine Anordnung zum Handhaben und Integrieren einer Sitzungsverwaltung in einer Portalstruktur benötigt, durch die ein oder mehr der oben erwähnten Ziele verwirklicht werden können. Weiter noch wird ein Verfahren zum Handhaben einer Sitzungsverwaltung in einer Portalstruktur benötigt, ebenso wie ein Verfahren zum Versehen eines Endnutzers mit Zugriff auf Dienste/Anwendungen ungeachtet dessen, ob sie durch das Portalsitzungsverwaltungsmittel oder durch externe Sitzungsverwaltungsmittel sitzungsverwaltet werden, wodurch ein oder mehr der oben erwähnten Ziele verwirklicht werden können.
  • Durch Verwendung einer generischen Textauszeichnungssprache in einem Portal kann ein Inhalt von Anwendungen und Diensten unabhängig von einer Benutzerstation oder einer Benutzervorrichtung gespeichert werden, und bevor der Inhalt einer Anwendung oder eines Dienstes angezeigt wird, kann der Inhalt in das Format transformiert werden, d.h. die Textauszeichnungssprache, das durch die Endnutzervorrichtung verstanden werden kann. Ein Beispiel einer derartigen generischen Textauszeichnungssprache ist die XML (erweiterte Textauszeichnungssprache, Extended Markup Language). Als ein Standard für eine Navigation in einem XML-basierten Portal wird die verwendete XLink-Spezifikation verwendet, die erlaubt, dass Elemente in XML-Dokumente eingefügt werden, um Verweise zwischen Ressourcen zu erstellen und zu beschreiben. XLink sieht ein Rahmenwerk zum Erstellen von sowohl grundlegenden unidirektionalen Verweisen als auch komplexeren Verweisstrukturen vor. Sie erlaubt XML-Dokumenten, Verweisbeziehungen zwischen mehr als zwei Ressourcen zu erklären, Metadaten mit einem Verweis zu assoziieren und Verweise auszudrücken, die sich an einem Standort befinden, der sich von den verknüpften Ressourcen unterscheidet. XML wird in der W3C-Empfehlung vom 6. Oktober 2000, Extensible Markup Language (XML) 1.0 (zweite Ausgabe) beschrieben, die hiermit hierin durch Bezugnahme einbezogen ist.
  • In dem folgenden werden einige Konzepte, die in diesem Dokument verwendet werden, beschrieben oder definiert. Ein Portal ist allgemein eine nicht-physische Entität in der Internet-Domäne, die als ein "elektronischer Veröffentlichungsraum" beschrieben werden kann, der im Besitz durch ein Individuum oder eine Organisation ist, und der entweder direkten Zugriff auf Information und Dienste vorsieht oder Verweise auf andere Entitäten in dem Internet oder private Intranet-Domänen, die autorisierten Endnutzern Information und Dienste vorsehen. Ein Portal ist in seiner einfachsten Form eine reguläre Homepage oder eine Liste von Verweisen, wohingegen es in fortgeschritteneren Formen interaktive Dienste anbieten kann, nicht nur jenen, die konsumieren, was veröffentlicht wird, sondern auch jenen, denen das Recht durch den Herausgeber erteilt wird, in dem Portal zu veröffentlichen, ebenso wie dem Herausgeber selbst, unter Betrachtung verschiedener Aspekte darüber, wie das Portal verwendet wird.
  • Drahtlosen Endnutzern wird Zugriff durch ein "Dienst"-Portal gegeben. Ein derartiges "Dienst"-Portal unterscheidet sich von einem traditionellen stationären Internetportal für PCs, und Endnutzer fordern, dass personalisierte Dienste mindestens als eine Option zugestellt werden zu und präsentiert werden auf ihrem mobilen Endgerät. Im folgenden wird jedoch nicht die Bezeichnungsweise "Dienst"-Portal verwendet, sondern ein Portal (eine Struktur) in diesem Dokument bedeutet entweder ein konventionelles Portal oder ein "Dienst"-Portal.
  • Eine Anwendung ist eine oder mehrere kooperierende Softwareentitäten, wobei der funktionale Schwerpunkt Benutzerinteraktion und Nützlichkeit für den Endnutzer ist. Eine Anwendungsplattform ist eine definierte Kombination von Software- und Hardwareentitäten, die verwendet wird, um Anwendungen einer bestimmten Art zu implementieren, die durch die Funktionalität und Qualität ihrer Bestandteile charakterisiert sind.
  • Mit Portalinfrastruktur ist im allgemeinen Sinne die Software- und Hardwareentitäten gemeint, die benötigt werden, um ein spezielles Portal entweder unterzubringen oder zu erzeugen oder zu generieren. Speziell enthält sie einen Portalkern, eine IP-Infrastruktur und Dienstbefähiger.
  • Ein Dienstbefähigungsmittel, auch ein Dienstbefähiger genannt, ist eine Unterstützungsfunktionalität, auf die über APIs (Anwendungsprogrammierschnittstelle) zugegriffen wird, was die Abstraktionsebene anhebt und die Aufgabe eines Anwendungsentwicklers vereinfacht. Ein Portalkern ist der Kern einer Portalinfrastruktur, d.h. ein Portalkern ist der zentrale Teil einer Portalstruktur, der benötigt wird, um ein Portalrahmenwerk zu entwickeln, innerhalb dessen Inhalt und Anwendungen offengelegt und durch Endnutzer auf eine gesteuerte und vereinheitlichte Art und Weise abgerufen werden können. Mit einem Dienstnetz ist allgemein ein IP-basiertes Netz gemeint, das aus Knoten besteht, die Anwendungsserver, Dienstbefähigungsserver, Anwendungsunterstützungsserver, IP-Infrastrukturserver etc. unterbringen. Anwendungsunterstützungsserver verbinden mit Dienstnetzressourcen oder anderen externen Ressourcen als Kernnetze, wohingegen Dienstbefähigungsserver mit Ressourcen und Funktionalität in Kernnetzen verbinden.
  • In der vorliegenden Anmeldung ist eine Portalstruktur gedacht, einen Portalkern, eine Vielzahl von Diensten und An wendungen mit ihrem Inhalt und Dienstbefähigungsmitteln (Dienstbefähiger) zu bedeuten. Für das Funktionieren der vorliegenden Erfindung sind jedoch die Komponenten von dem Portalkern wichtig. Die zu lösenden Probleme sind insbesondere vorhanden, wenn Dienste/Anwendungen, auf die zugegriffen wird, durch andere Mittel als die Sitzungsverwaltungsmittel der Portalstruktur selbst sitzungsverwaltet werden.
  • Deshalb sieht die Erfindung eine Portalstruktur vor, die Endnutzerstationen mit Zugriff auf Dienste/Anwendungen versieht, die einen Portalkern umfasst (und Dienstbefähigungsmittel, Konnektivitätsmittel, über die Endnutzerzugriff vorgesehen wird). Der Portalkern umfasst eine Präsentationsanordnung, ein Portalsitzungsverwaltungsmittel, das sitzungsbezogene Informationen generiert und handhabt, z.B. Sitzungsidentifikationen, und Speichermittel zum Speichern sitzungsbezogener Information. Der Portalkern inkludiert auch Teilnehmerverwaltungsmittel, die nicht weiter beschrieben werden. Mindestens einige der Dienste/Anwendungen umfassen externe Dienste/Anwendungen, die durch externe Sitzungsverwaltungsmittel sitzungsverwaltet werden, die sitzungsbezogene Information einer externen Anwendung/Dienstes generieren und handhaben, z.B. externe Sitzungsidentifikationen.
  • Das Portalsitzungsverwaltungsmittel umfasst eine Sitzungsvereinheitlichungsanordnung zum Abbilden oder Transformieren zwischen Portalsitzungsidentifikationen und Sitzungsidentifikationsinformation eines externen Dienstes/Anwendung. Für eine Kommunikation zwischen dem Portalkern und externen Diensten/Anwendungen werden die externen (proprietären) Sitzungsidentifikationen eines externen Dienstes/Anwendung verwendet, wohingegen für eine Kommunikation zwischen einer Endnutzerstation und dem Portalkern nur die Portalsitzungsidentifikationen verwendet werden. Insbesondere generieren die Dienste/An wendungen eine generische Textauszeichnungssprache, die noch genauer die XML-Sprache sein kann.
  • In einer vorteilhaften Implementierung wird externe Identifikationsinformation für die externen Dienste/Anwendungen, die in einer Sitzung aktiv sind, in dem Portalspeichermittel gespeichert, mindestens innerhalb der Dauer der jeweiligen Sitzung oder während einer gesamten vordefinierten Zeitdauer. Eine Zeitdauer kann z.B. derart bestimmt sein, dass wenn es für die gegebene Zeitdauer in der Sitzung keine Aktivität gegeben hat, die Information nicht länger gespeichert werden muss.
  • In einer bestimmten Implementierung ist die Portalstruktur mobil, was hier bedeutet, dass sie Zugriff durch mobile Endnutzerstationen, wie etwa z.B. WAP-Vorrichtungen, zusätzlich zu stationären Endnutzerstationen unterstützt. Die Portalstruktur inkludiert Wiedergabemittel zum Übersetzen von Dienst-/Anwendungsdaten in einer generischen Textauszeichnungssprache in eine andere Textauszeichnungssprache, wie sie durch eine Endnutzerstation verwendet wird oder für sie verständlich ist. Falls eine generische Textauszeichnungssprache verwendet wird, insbesondere XML, werden Daten von Diensten/Anwendungen in einer Dokumenttypdefinitions-(Document Type Definition, DTD)Sprache mit einem URL-Attribut (einheitlicher Ressourcen-Lokator, Uniform Resource Locator) definiert. DTD ist (hier) ein XML-Dokument, das alle Elemente und ihre Attribute beschreibt, die in allen Dokumenten erlaubt sind, die als zu der bestimmten DTD gehörend gesehen werden können. In einer Implementierung umfasst ein externes System (Dienst/Anwendung) mit seinem eigenen oder externen Sitzungsverwaltungsmittel ein anderes Portal. In einer bestimmten Implementierung arbeitet die Portalsitzungsverwaltung gemäß der Servlet-Sitzungs-API- oder den Sitzungs-EJBs-Spezifikationen zum Definieren von grundlegenden Sitzungsver waltungsoperationen. Dies bedeutet, dass die Spezifikationen verwendet werden können, um eine Sitzung von einem extern sitzungsverwalteten System zu erhalten. In dieser Spezifikation wird es auch als ein nachgestelltes System (Backend-System) bezeichnet, was so ein Dienst/eine Anwendung sein kann, der/die extern ist, mindestens in dem Sinn, dass er/sie extern sitzungsverwaltet wird. Es kann auch ein anderes Portal mit seinem eigenen (proprietären) Sitzungsverwaltungsmittel sein.
  • Gemäß der Erfindung speichert das Portalsitzungsverwaltungsmittel insbesondere Information in Bezug auf Aktionen, die durch einen Endnutzer begonnen werden, wie etwa ein Endnutzer betritt das Portal, Endnutzerauthentifizierung, Endnutzerzugriff auf einen Dienst/eine Anwendung etc., in das Portalspeichermittel.
  • Wenn eine Endnutzerstation einen Dienst/eine Anwendung von dem Portal anfordert, wird gemäß der Erfindung eine Sitzung mit einer Portalsitzungsidentifikation durch das Portalsitzungsverwaltungsmittel erstellt. Die Anforderung wird anschließend zu dem angeforderten Dienst/Anwendung weitergeleitet, der falls es ein interner Dienst/Anwendung ist, die Portalsitzungsidentifikation verwendet. Falls der Dienst/die Anwendung andererseits extern sitzungsverwaltet wird, wird eine externe Sitzungsidentifikation für den Endnutzer generiert, die in einer Kommunikation zwischen dem Portal und dem Dienst/der Anwendung verwendet wird. Für einen extern sitzungsverwalteten Dienst/Anwendung speichert das externe Sitzungsverwaltungsmittel die externe Sitzungsidentifikationsinformation, die für einen anfordernden Endnutzer für eine definierte Zeitdauer, d.h. während der ganzen Sitzung, oder bis die Sitzung für eine gegebene Zeitdauer "inaktiv" gewesen ist, generiert wird.
  • Wenn eine anschließende Rufanforderung von dem Portal empfangen wird, d.h. ein anschließender Ruf durch den gleichen Endnutzer in der gleichen Sitzung für den gleichen Dienst/Anwendung, wird die generierte externe Sitzungsidentifikation verwendet, um die Sitzung in dem Dienst/der Anwendung zu finden. Es werden Anwendungsdaten generiert und Anwendungsinformationsdaten werden zu dem Portal unter Verwendung der externen Sitzungsidentifikation gesendet, die durch das Portalsitzungsvereinheitlichungsmittel konvertiert wird in/abgebildet wird auf die Portalsitzungsidentifikation.
  • In einer Implementierung wird ein Namensraum innerhalb der Portalsitzung erstellt, und für jede abgerufene externe Dienst-/Anwendungssitzung werden Informationsdaten innerhalb des Namensraums gespeichert. In einer besonders vorteilhaften Ausführungsform erstellt ein externer Dienst/Anwendung oder ein externes Sitzungsverwaltungsmittel eine externe (oder proprietäre) Sitzung mit einer (proprietären) externen Sitzungsidentifikation eines Dienstes/einer Anwendung für einen Endnutzer, der Zugriff auf den externen Dienst/Anwendung über das Portal anfordert und führt ein Metainformationstag, das mindestens die proprietäre oder externe Sitzungsidentifikation enthält, in die Daten in der generischen Textauszeichnungssprache ein, die zu dem Portalkern zu senden sind. Es werden insbesondere alle Daten von dem Metainformationstag in der entsprechenden Portalsitzung für den anfordernden Endnutzer gespeichert.
  • In einer bestimmten Implementierung wird Endnutzerstationen ungeachtet dessen, wo sich der Dienst-/Anwendungsinhalt befindet, d.h. ob er intern oder extern ist, durch die Einführung von Metaverweisen (metalinks) auf Dienst-/Anwendungsdaten in einer generischen Textauszeichnungssprache, z.B. XML, zu denen die Portalsitzungs-Id als ein Parameter hinzugefügt wird, eine kontinuierliche Navigation bereitge stellt. Für diesen Zweck umfasst der Portalkern (erste) Übersetzungsmittel zum Bearbeiten derartiger Metaverweise, die in den Dienst-/Anwendungsdaten enthalten sind. Der Portalkern umfasst ferner Wiedergabemittel mit (zweiten) Übersetzungsmitteln zum Transformieren der Daten in der generischen Textauszeichnungssprache in eine Textauszeichnungssprache, die durch die anfordernde Endnutzerstation verstanden wird, die mobil oder stationär ist. Kontinuierliche Navigation, wie oben benannt, bezieht sich auf eine besonders vorteilhafte Implementierung, die mit Vorteil mit der vereinheitlichten Sitzungsverwaltung kombiniert werden kann, wie in der vorliegenden Erfindung beschrieben. Die Bereitstellung von kontinuierlicher Navigation mittels Einführung von Metaverweisen auf die Dienst-/Anwendungsdaten durch die Dienste/Anwendungen wird in der gemeinsam anhängigen schwedischen Anmeldung "An arrangement and a method relating to access of applications/services" durch den gleichen Anmelder und eingereicht an dem gleichen Tag wie die vorliegende Erfindung beschrieben, und deren Inhalt hiermit durch Bezugnahme einbezogen wird.
  • Somit ist in einer am vorteilhaftesten Ausführungsform die Portalstruktur mobil, und sie unterstützt Zugriff durch mobile Endnutzerstationen über ein mobiles Kommunikationsnetz, wie etwa GSM (globales System für mobile Kommunikationen, Global System for mobile Communications), WCDMA (Breitband-Vielfachzugriff im Codemultiplex, Wideband Code Division Multiple Access), GPRS (allgemeiner Paketfunkdienst GSM, GSM General Packet Radio Service), UMTS (universelles mobiles Telekommunikationssystem, Universal Mobile Telecommunications System), Bluetooth (was eine Funktechnologie im Kurzbereich ist), WAP (drahtloses Anwendungsprotokoll, Wireless Application Protocol) etc. Vorteilhafter Weise unterstützt die Portalstruktur Zugriff durch Breitbandvorrichtungen, wie etwa PCs, oder allgemeiner stationäre Vorrichtungen ebenso wie mobile Vorrichtungen, wie etwa WAP-Vorrichtungen.
  • In anderer Hinsicht unterstützt die Portalstruktur Zugriff durch stationäre ebenso wie mobile Endnutzerstationen, die unterschiedliche Zugriffsformate verwenden, oder die unterschiedliche Textauszeichnungssprachen für eine Kommunikation mit der Portalstruktur verwenden.
  • Gemäß einer bestimmten Ausführungsform kann optional ein Dienst oder eine Anwendung mit einem oder mehr Metainformationstags zusätzlich zu Metainformationstags versehen werden, die externe Sitzungsidentifikationsinformation enthalten.
  • Obwohl die Erfindung darauf nicht begrenzt ist, kann die generische Textauszeichnungssprache XML sein, falls eine generische Textauszeichnungssprache verwendet wird. Die XML-Daten und mögliche Metaverweise werden in einer Dokumenttypdefinitionssprache (DTD) definiert. Ein Metaverweistag in XML-Daten umfasst Information über einen Metaverweistyp, ein Referenz- und Adressierungsattribut (URL), das Dienst-/Anwendungsstandortinformation enthält. Das Übersetzungsmittel (von dem Wiedergabemittel) übersetzt XML-Daten durch Durchführung einer Transformation (XSL), d.h. die XML-Daten werden zusammen mit einem Transformations-Stylesheet (XSL-Transformation) bearbeitet, um ein Ausgabeformat zu erzeugen, d.h. eine Textauszeichnungssprache, die für die zugreifende Endnutzerstation geeignet ist, z.B. HTML (Hypertext-Textauszeichnungssprache, Hypertext Markup Language) für eine stationäre Endnutzerstation und WML (drahtlose Textauszeichnungssprache, Wireless Markup Language) für eine mobile Endnutzerstation. XSL wird in XSL-Transformations (XSLT) Version 1.0, was eine W3C-Empfehlung vom 10. November 1999 ist, und XSL-Transformations (XSLT) Version 1.1, was ein W3C-Arbeitsentwurf vom 12. Dezember 2000 ist, beschrieben, wobei die Dokumente hiermit durch Bezugnahme hierin einbezogen werden.
  • Insbesondere wird bei einem anschließenden Zugriff des gleichen Dienstes/Anwendung durch den gleichen Endnutzer in der gleichen Sitzung die gespeicherte Metainformation, die die externe (proprietäre) Sitzungsidentifikation enthält, von dem Portalsitzungsverwaltungsmittel durch das Sitzungsvereinheitlichungsmittel zu dem externen Dienst/Anwendung (externes Sitzungsverwaltungsmittel) derart weitergeleitet, dass die externe Sitzung, wie durch die externe Sitzungs-ID angezeigt, gefunden werden kann.
  • Die Erfindung legt auch eine Anordnung in einer Portalstruktur offen umfassend einen Portalkern mit einer Präsentationsanordnung, Portalsitzungsverwaltungsmittel, das sitzungsbezogene Information, z.B. Sitzungsidentifikationen, generiert und handhabt, und Speichermittel zum Speichern sitzungsbezogener Information. Die Anordnung umfasst ferner eine Sitzungsvereinheitlichungsanordnung zum Vereinheitlichen einer Verwaltung von Portalsitzungen und externen Sitzungen, die durch externe Sitzungsverwaltungsmittel generiert werden, die externe Dienste/Anwendungen verwalten. Die Portalsitzungsidentifikation (nur) wird in einer Kommunikation zwischen dem Portal und einer zugreifenden Endnutzerstation verwendet, und die externe Sitzungsidentifikationsinformation wird in einer Kommunikation zwischen dem Portal und dem externen Dienst/Anwendung verwendet. Das Vereinheitlichungsmittel umfasst Mittel zum Abbilden zwischen Portalsitzungsidentifikationen und externen Sitzungsidentifikationen. Vorteilhafter Weise wird Identifikationsinformation eines externen Dienst/Anwendung in dem Portalspeichermittel in der jeweiligen Portalsitzung für eine definierte Zeitdauer gespeichert, z.B. während einer gesamten Sitzung. Die Anordnung umfasst insbesondere Wiedergabemittel zum Übersetzen von Dienst-/Anwendungsdaten in einer generischen Textauszeichnungssprache in andere Textauszeichnungssprachen, abhängig von dem Typ einer anfordernden Endnutzerstation, für eine Wiedergabe einer Dienst-/Anwendungs datenausgabe zu Endnutzerstationen mit angefordertem Zugriff auf einen Dienst/Anwendung. Eine derartige generische Textauszeichnungssprache ist insbesondere XML.
  • In einer bevorzugten Ausführungsform wird externe Sitzungsidentifikationsinformation in Metainformationstags vorgesehen, die in die externen Dienst-/Anwendungsdaten eingeführt werden, und genauer werden die Metainformationsdaten in der Portalsitzung in dem Portalspeichermittel gespeichert, das Portalsitzungsinformation speichert. Die Portalsitzungsidentifikation wird insbesondere den externen Anwendungs-/Dienstdaten als ein Parameter hinzugefügt.
  • Bei einer anschließenden Anforderung zu dem Portal für den gleichen externen Dienst/Anwendung durch einen Endnutzer während einer laufenden Sitzung wird die Metainformation in die Anforderung durch das Sitzungsvereinheitlichungsmittel beim Weiterleiten der Anforderung zu dem externen Dienst/Anwendung inkludiert, d.h. nach Abbildung/Transformation vom Portal zu externer Sitzungsidentifikation.
  • Die Erfindung legt auch ein Verfahren für eine Sitzungsverwaltung in einer Portalstruktur offen, wenn auf externe Dienste/Anwendungen, die extern sitzungsverwaltet werden, zugegriffen wird. Die Portalstruktur umfasst einen Portalkern mit einer Präsentationsanordnung, Portalsitzungsverwaltungsmittel, das sitzungsbezogene Information handhabt, und Portalspeichermittel zum Speichern sitzungsbezogener Information. Das Verfahren inkludiert die Schritte: Erstellen einer Portalsitzung mit einer Portalsitzungsidentifikation, wenn ein Endnutzer Zugriff auf einen Dienst/eine Anwendung anfordert, es sei denn, es existiert bereits eine Portalsitzung; Weiterleiten der Anforderung zu dem angeforderten externen Dienst/Anwendung; Erstellen, in oder für den externen Dienst, durch das externe Sitzungsverwaltungsmittel einer externen Dienst-/Anwendungssitzung, wodurch eine externe Dienst-/Anwendungssitzungsidentifikation generiert wird, es sei denn, die Sitzung existiert bereits für den anfordernden Endnutzer; wodurch in dem Dienst/der Anwendung die folgenden Schritte durchgeführt werden: Generieren von Dienst-/Anwendungsdaten; Einführen von Information über die externe Sitzungsidentifikation in die Dienst-/Anwendungsdaten; Rückgabe von Dienst/Anwendungsdaten inkludierend die externe Sitzungsidentifikation zu dem Portal; wodurch in dem Portal die folgenden Schritte durchgeführt werden: Abbilden der externen Sitzungsidentifikation auf die Portalsitzungsidentifikation; Speichern der externen Sitzungsidentifikation in die Portalsitzung in dem Portalspeichermittel; Senden der Dienst-/Anwendungsdaten zu dem anfordernden Endnutzer unter Verwendung nur der Portalsitzungsidentifikation.
  • Das Verfahren inkludiert ferner die Schritte: Nachschauen der Portalsitzung in dem Portalspeichermittel bei einer anschließenden Anforderung durch den Endnutzer nach dem externen Dienst/Anwendung; Feststellen, ob die auf eine Portalsitzung bezogene Information eine externe Sitzungsidentifikation enthält; falls ja, Weiterleiten der Anforderung inkludierend die externe Sitzungsidentifikation zu dem angeforderten externen Dienst/Anwendung; Nachschauen der externen proprietären Dienst-/Anwendungssitzung in dem Dienst/der Anwendung oder in einem externen Sitzungsverwaltungsmittel unter Verwendung der externen Sitzungsidentifikation; Generieren von Dienst-/Anwendungsdaten; Hinzufügen der externen Sitzungsidentifikation zu den Dienst-/Anwendungsdaten; Senden der Dienst-/Anwendungsdaten mit der externen Sitzungsidentifikation zu dem Portalsitzungsverwaltungsmittel etc. In einer bevorzugten Implementierung generiert der externe Dienst/Anwendung eine generische Textauszeichnungssprache, z.B. XML. Vorzugsweise umfasst der Schritt zum Hinzufügen externer Sitzungsidentifikation eine Generierung und Einführung von einem Metainforma tionstag, das mindestens externe Sitzungsidentifikation enthält, zu den externen Dienst-/Anwendungsdaten.
  • Die Erfindung legt auch ein Verfahren zum Integrieren einer Portalsitzungsverwaltung mit der externen Sitzungsverwaltung von einem extern sitzungsverwalteten System offen, welches die Schritte umfasst: Abbilden zwischen Portalsitzungsidentifikationen und externen Sitzungsidentifikationen; Speichern von Information in Bezug auf externe Sitzungsidentifikationen in einem Portalspeichermittel in einer generierten Portalsitzung; Verwenden der Portalsitzungsidentifikation in einer Kommunikation mit einer Endnutzerstation; Verwenden von Information in Bezug auf die externe Sitzungsidentifikation in einer Kommunikation mit extern sitzungsverwalteten Systemen.
  • DETAILLIERTE BESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird im folgenden auf eine nicht-begrenzende Art und Weise und mit Bezug auf die begleitenden Zeichnungen weiter beschrieben, in denen:
  • 1 eine Übersicht einer Portalstruktur gemäß einer Implementierung der Erfindung schematisch veranschaulicht,
  • 2 eine konzeptionelle Unterteilung der Präsentationsanordnung (Schicht) in eine Wiedergabefunktionsschicht und eine Dienstfunktionsschicht veranschaulicht,
  • 3A ein Blockdiagramm eines Portals ist, durch das ein Endnutzer zuerst Zugriff auf eine externe Anwendung anfordert,
  • 3B ein Blockdiagramm wie in 3A ist, wenn der Endnutzer während der Sitzung erneut auf die Anwendung zugreift,
  • 4 ein Flussdiagramm ist, das schematisch eine allgemeine Implementierung des erfinderischen Konzepts beschreibt,
  • 5 ein Flussdiagramm ist, das den Fluss beschreibt, wenn ein Endnutzer auf ein Portal zugreift, wobei Zugriff auf einen externen Dienst/Anwendung angefordert wird, wenn es keine Sitzung gibt,
  • 6 ein Flussdiagramm ist, das die Prozedur beschreibt, wenn ein Endnutzer nachfolgend auf die gleiche Anwendung in der gleichen Sitzung zugreift, und
  • 7 ein Diagramm ist, das die Sitzungsabbildungsinteraktionen in der Sitzungsvereinheitlichungsprozedur veranschaulicht.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Mit Bezug auf 1 und 2 wird eine beispielhafte Portalstruktur auf eine ziemlich detaillierte Art und Weise beschrieben. Eine derartige Portalstruktur kann in der Implementierung des erfinderischen Konzepts verwendet werden, das mit Bezug auf 3–7 beschrieben wird. Es sollte auch klar sein, dass die Erfindung keineswegs darauf begrenzt ist, in einem Portal implementiert zu werden, wie in 1 und 2 beschrieben, wobei dieser Abschnitt der Beschreibung hauptsächlich zum Beschreiben einiger beispielhafter zu Grunde liegender Konzepte und des Funktionierens einer Portalstruktur als solche inkludiert ist.
  • 1 zeigt somit ein Beispiel in einer Portalstruktur 10 gemäß der Erfindung. Die Portalstruktur 10 umfasst einen Portalkern 1, der Präsentationsfunktionalitäten, Abonnement- und Sitzungsverwaltungsfunktionalitäten handhabt, eine Anzahl von Diensten und Anwendungen 2, umfassend z.B. persönliche Kommu nikationsdienste, persönliche Informationsdienste und mobile E-Kommerzdienste. Kurz gesagt ist es nicht wichtig, Dienste welcher Art vorgesehen werden und das erfinderische Konzept ist auf eine beliebige Art von Dienst, Inhalt und Anwendung anwendbar. Wenn das erfinderische Konzept auf eine detailliertere Art und Weise erläutert wird (3–7), wenn ein Endnutzer Zugriff auf einen Dienst oder eine Anwendung anfordert, ist ein beliebiger Dienst oder Anwendung (oder Inhalt) gemeint und kann als konzeptionell in die Portalstruktur inkludiert gesehen werden, obwohl sich einige der Dienste und Anwendungen tatsächlich außerhalb der Portalstruktur befinden und durch einen beliebigen externen Dienstanbieter vorgesehen werden, die in diesem Dokument jedoch als extern bezeichnet werden in einem Fall, wenn sie extern sitzungsverwaltet sind, d.h. falls sie nicht durch das Portalsitzungsverwaltungsmittel sitzungsverwaltet werden.
  • Die Portalkernstruktur 1 inkludiert ferner eine Schicht 3 inkludierend eine Zahl von Dienstbefähigungsmitteln, auch Dienstbefähiger genannt, 31–37, 38A–38D. Die Dienstbefähiger sind unter anderem in Authentifikations- und Basisdienste involviert, wie etwa Gateways und IP-Infrastruktur. In dieser Figur sind einige Beispiele an Dienstbefähigern angegeben, wie etwa vereinheitlichte Mitteilungsübermittlung 31, IP-Infrastruktur 32, AAA-Server 33, Benachrichtigungsunterstützung 34, Gebührenerfassungsunterstützung 35 und Operations- und Wartungsunterstützung 36. Weitere Beispiele von Dienstbefähigern sind ein mobiles Positionierungssystem 37, WAP-Gateway 38A, SMS- C-Gateway 38B, Multimedia-Proxy 38C, mobile E-Bezahlung 38D etc. Es sollte klar sein, dass einige von diesen Dienstbefähigern mehr oder weniger zwingend notwendig sind, wohingegen andere optional sind.
  • Die Portalstruktur wird hier auch gesehen als inkludierend eine Konnektivitäts- oder eine (mobile) Trägerschicht umfas send die mobilen Basisstationen und Vermittlungsknoten, wie etwa Knoten mit BTS (Basis-Transceiver-Station), BSC (Basisstationssteuervorrichtung), MSC (mobile Vermittlungsstelle) etc. Was die Knoten sind hängt davon ab, über welches Mobilnetz Zugriff vorgesehen wird, z.B. über GSM. Für GPRS oder UMTS sind entsprechende Knoten in dieser Schicht inkludiert; z.B. GGSN (Gateway-GPRS-Unterstützungsknoten). Was immer das Netzwerk ist, das Netzwerk ist der Datenträger für das Portal für einen Zugriff von mobilen Vorrichtungen, wie etwa WAP-Vorrichtungen (drahtloses Anwendungsprotokoll). In 1 wird vorausgesetzt, dass die zugreifende Endnutzerstation ein WAP-Telefon 5 umfasst.
  • Ein Beispiel einer Portalstruktur ist das Ericsson WISETM Portal.
  • Interne Anwendungen oder Dienste können als Anwendungen gesehen werden, die die Dienstbefähiger und Konnektivitätsschichten wirksam einsetzen, um mobilen Internet-Anwendungen verschiedener Kategorien, z.B. mobile Dienste, persönliche Kommunikationen wie vereinheitlichte Mitteilungsübermittlung oder Postdienste und persönliche Informationsdienste, anwendungsspezifische Werte hinzuzufügen. Die Information kann durch den Benutzer durch Suche abgerufen werden, aber die Information kann dem Endnutzer auch mittels der Anstoßtechnologie bereitgestellt werden. Dies ist für eine Benutzeranpassung offen.
  • Es wird vorteilhafter Weise vorausgesetzt, dass das Portal Zugriff durch mobile Endnutzerstationen, wie etwa WAP-Telefone 5, über ein mobiles Netzwerk unterstützt. Deshalb müssen Knoten oder Komponenten von dem relevanten mobilen Netzwerk in einer Mobilnetz-Konnektivitäts- und Datenträgerschicht vorgesehen werden. In 1 wird eine Komponente, die als ISP-Netz, Internetdienstanbieternetz (Internet Service Provi der Network) bezeichnet wird, offengelegt. Dies ist eine optional Komponente, die inkludiert sein kann oder nicht.
  • In der Schicht, die die Dienstbefähiger 3 umfasst, sind einige Typen von Dienstbefähigern zwingend notwendig, wohingegen es andere nicht sind. Einige von den Dienstbefähigern werden als wichtige Komponenten zum Vorsehen von mobilen Internet-Funktionalitäten gesehen. Einige der Dienstbefähiger werden als ein Teil der Schnittstellenkomponenten zwischen Internet und dem Mobilnetz gesehen. Eine Komponente wird hier als IP-Infrastruktur 32 bezeichnet. Ein optionaler Dienstbefähiger umfasst die Benachrichtigungsunterstützung 34, die allgemein eine optionale Komponente ist, die Anwendungen ermöglicht, ausgefilterte Benachrichtigungen an Endnutzer unter Verwendung des SMS- (Kurznachrichtendienst, Short Message Service) Kanals zu senden, sie kann aber auch angepasst sein, andere Kanäle zu inkludieren, die WAP-Technologie und 3G-(3GPP)Technologie unterstützen. Gebührenerfassungsunterstützungsbefähiger 35 kann vorgesehen sein, um eine flexible Auswahl von Gebührenerfassungsereignissen zu erlauben. Ein anderer Dienstbefähiger 36 bezieht sich auf Operations- und Wartungsunterstützung und ist allgemein eine zwingend erforderliche Komponente. Ein Dienstbefähiger WAP-Gateway 38A ist ein optionaler Dienstbefähiger WAP-Gateway/Proxy, der den Zugriffspunkt zwischen der drahtlosen Welt und der Internet-Welt bildet. Er unterstützt mobile Clients, die auf das WAP-Gateway/Proxy unter Verwendung von GSM-schaltungsvermittelten Daten oder WAP über SMS (SMS über MAP (mobiles Anwendungsprotokoll, Mobile Application Protocol)) zugreifen. Der Client verwendet einen WAP-befähigten Browser in der mobilen Vorrichtung, um sich mit dem WEB-Server zu verbinden, wo sich die gewünschte WAP-Anwendung befindet. Ein anderer Dienstbefähiger, ein mobiles Positionierungssystem, 37 ist eine optional Komponente, die Senden der Position eines Benutzers zu der Anwendung, die sie anfordert, erlaubt. Ein anderer Dienstbefähiger ist ein Multimedia-Proxy 38, der für eine Sendung von Multimediadaten über GPRS oder UMTS verantwortlich ist. Dies ist jedoch ein optionales Dienstbefähigungsmittel. Ein SMS-C (Zentrum) Gateway 38B ist auch eine optionale Komponente, die für eine Sendung oder einen Empfang, Speicherung und Weiterleitung von Kurznachrichten zwischen mobilen Stationen und Servern verantwortlich ist. Für eine Kommunikation mit Anwendungen werden proprietäre Protokolle verwendet. Mobile E-Bezahlung 38D ist eine Komponente, die die Basisfunktionalität für mobilen E-Kommerz bietet und ist eine optionale Komponente. AAA-Server 33 ist eine Dienstbefähigungskomponente in Bezug auf Authentifikation, Autorisierung und Abrechnung. Diese Funktionalitäten können auf andere Art und Weise vorgesehen werden, sie können aber auch in einem Funktionalitätsserver integriert sein, der z.B. verkehrsbasierte Gebührenerfassung und Periodengebührenerfassung ermöglicht. Eine derartige Komponente, entweder falls sie in unterschiedliche Komponenten gesplittet ist oder eine einzelne Komponente umfasst, die einer Anzahl von Funktionalitäten gemeinsam ist, ist zwingend erforderlich, und wird in einer vorteilhaften Implementierung für Sitzungsverwaltungsfunktionalitäten verwendet.
  • Es sollte jedoch klar sein, dass 1 lediglich Beispiele in Dienstbefähigungsmitteln zeigt, die in einer Dienstbefähigungsschicht 3 vorgesehen sein können. Mindestens einige der veranschaulichten Dienstbefähiger können ausgeschlossen sein, noch andere können inkludiert sein etc.
  • Der Portalkern, oder die Portalkernschicht, handhabt, wie oben angeführt, Präsentation, Abonnement und Sitzungsverwaltung und Dienststufen umfassend eine Anzahl von internen (und externen) Anwendungsservern. Der Kern 1 umfasst eine Präsentationsanordnung 11, die eine mobile Portalpräsentation auf mehrfachen Vorrichtungen unter Verwendung mehrfacher Proto kolle ermöglicht. Sie kann z.B. XML-angesteuert sein (oder allgemeiner durch eine generische Textauszeichnungssprache angesteuert sein). In einer Implementierung ist sie ein durch JavaTM und XML angesteuerter Präsentationsmodul, der zu Multitextauszeichnungssprache fähig ist.
  • Die Präsentationsanordnung 11 umfasst ein Wiedergabemittel (eine Wiedergabe-Engine (Maschine)), das in einer Implementierung XML/XSLT-Technologien verwendet, um sicherzustellen, dass Information, die durch Dienste innerhalb des Portals präsentiert wird, auf einem standardisierten Weg angezeigt wird, ungeachtet dessen, von welchem Typ eine Endnutzerstation (oder Browser) ist, die ein Endnutzer verwendet, wenn er auf die Portalstruktur zugreift. Durch die Verwendung einer generischen Textauszeichnungssprache, z.B. XML/XSLT, kann das "Aussehen und Gefühl" ("look and feel") vom Inhalt, der Endnutzern präsentiert wird, angepasst werden. XSL ist eine Abkürzung für erweiterbare Stylesheet-Sprache (Extensible Style Sheet Language). Die schwedische Patentanmeldung "An arrangement and a method for presentation customization in a portal structure", die eine Anmeldung ist, die an dem gleichen Datum und durch den gleichen Anmelder wie die vorliegende Anmeldung eingereicht ist, und deren Inhalt hiermit durch Bezugnahme hierin einbezogen wird, bezieht sich auf Benutzeranpassung in einer Portalstruktur, wie hierin beschrieben, und befasst sich insbesondere mit einer Anpassung von "Aussehen und Gefühl".
  • Die Funktionalitäten innerhalb des Portalkerns 1 und der Präsentationsanordnung 11 insbesondere werden ferner mit Bezug auf 2 beschrieben.
  • Der Portalkern 1 inkludiert auch den Abonnementverwalter. In einer Implementierung wird Abonnementverwalter-Komponenteninformation in einem LDAP- (leichtgewichtiges Verzeichniszu griffsprotokoll, Lightweight Directory Access Protocol) Verzeichnis gespeichert und wird durch einen Dienst verwaltet, der Abonnementverwalter genannt wird. Der Abonnementverwalter inkludiert Funktionen für den Betreiber, um Teilnehmerinformation in der Teilnehmerdatenbank zu erstellen, zu unterhalten und zu löschen. Er ermöglicht auch dem Endnutzer des Systems, die Dienste in dem System zu abonnieren. In einer bestimmten Implementierung wird ein Konzept für Selbst-Registrierung und Selbst-Service unterstützt, um Kosten durch Minimierung der Arbeitsbelastung in einem Kundenbetreuungszentrum zu minimieren. Information über verfügbare Dienste kann auch in dem Verzeichnis unterhalten werden, auf das oben verwiesen wird, und durch den Abonnementverwalter gehandhabt werden. Wie ein neuer Dienst in das Verzeichnis eingetragen wird, wird er unverzüglich für ein Abonnement durch die Endnutzer verfügbar sein. In dem Verzeichnis können Endnutzer derart gruppiert sein, um neue Dienste nur definierten Mengen von Endnutzern verfügbar zu machen. Der Abonnementverwalter 12 kann mit einem existierenden Kundenbetreuungszentrum durch die Anwendungsprogrammierschnittstelle (API), die es verwendet, in Verbindung stehen.
  • Der Sitzungsverwalter 13 ist ein allgemeiner Mechanismus, der durch Anwendungen und Dienste verwendet werden kann. Er umfasst eine Schnittstelle zu einem Teilsystem zum Verfolgen aller Besucher des Portals und um die Profilinformation der Besucher bereitzustellen. Wenn sich ein Endnutzer im System/Anwendung anmeldet, wird eine Sitzungs-Id-Entität zugeordnet und sie wird für diesen bestimmten Endnutzer bis zur Abmeldung von dem Dienst oder wenn der Endnutzer für eine voreingestellten Zeitdauer untätig gewesen ist gespeichert. Wenn eine beteiligte Anmeldung startet, überprüft sie zuerst, ob es eine aktive Sitzungs-Id für einen bestimmten Nutzer gibt und falls es eine gibt, würde sie in der Lage sein, von dort fortzusetzen, wo die Sitzung unterbrochen wurde. Die Sitzungsverwaltungsfunktionalitäten gemäß dem erfinderischen Konzept werden nachstehend mit Bezug auf 3A–7 beschrieben.
  • Schließlich umfasst die Portalkernstruktur 1 hier zwei "interne" Anwendungsserver 14A, 14B und einen oder mehr externe Anwendungsserver 14C. Der externe Anwendungsserver 14C enthält Verweise auf externe Anwendungsserver, die existierende Dienste betreiben. In einer Implementierung umfasst die Dienststufe drei Klassen von Diensten, von denen eine erste in Übereinstimmung mit den Portalkernspezifikationen entwickelt wird, die unter Verwendung der Portalkernumgebung implementiert sind. Eine zweite Dienstklasse bezieht sich auf Dienste, die nicht notwendigerweise in der Portalkernumgebung implementiert sind, wie etwa z.B. ein externes E-Mail-System, das in einer Nicht-Portalkernumgebung läuft, angepasst, sich selbst durch die Portalkernpräsentation zu präsentieren. Die dritte Dienstklasse bezieht sich auf externe Dienste, die nicht mit der Portalkerndienstentwicklung oder Präsentationsarchitekturen übereinstimmen. Dies wird weiter mit Bezug auf 2 erläutert.
  • Im folgenden werden der Portalkern, und spezieller die Präsentationsanordnung, die in der Präsentationsschicht beinhaltet ist, gründlicher beschrieben, zuerst mit einem allgemeinen Verweis auf 2.
  • Die Dienststufe in einer vorteilhaften Implementierung umfasst drei Dienstklassen. Der Dienstklassen-Portalkerndienst (pcoreservice) entspricht den Spezifikationen von dem Portalkern und er wird verwendet, um die Portalkerncharakteristika wirksam einzusetzen. In einer Implementierung sind die Dienste unter Verwendung der J2EE IBM WEBSphere Environment implementiert (es wird ein Anwendungsserver verwendet, um programmatische Dienste zu entwickeln, die Logik, Algorithmen etc.
  • einbeziehen). Derartige Dienste haben im allgemeinen Architekturen mit drei oder vier Stufen, die JSP (Java Server Pages, Java-Server-Seiten) auf dem Front-End, Java-Servlets und Enterprise Java Beans (EJB) in der mittleren Schicht und verschiedene Entitäten auf dem Back-End aufstellen. Die zweite Dienstklasse sind die integrierten Portalkerndienste (integrierte pcore-Dienste), die pcore-Präsentationsdienste wirksam einsetzen, die aber nicht notwendigerweise in der J2EE-Umgebung vom Portalkern implementiert sind, z.B. ein externes E-Mail-System, das in einer Nicht-Portalkern-Umgebung läuft, aber angepasst ist, sich selbst durch die Portalkernpräsentation zu präsentieren. Die dritte Dienstklasse, externe pcore-Dienste, entspricht weder der Portalkerndienstentwicklung noch den Präsentationsarchitekturen, sondern die Dienste, die in dieser Klasse inkludiert sind, können zum Beispiel zu dem Portalkern getriggert werden.
  • In einer Implementierung sind zwei Typen von Dienstoptionen innerhalb der Dienstschicht verfügbar. Einer kann aus Diensten bestehen, die durch Broadvision (CORBA) vorgesehen werden zum Erstellen optimierter regelbasierter und personalisierter Dienste, die mit Kommerz und Einzelhandel verbunden sind, und für eine Inhaltsabgabe durch eine passende Engine (Maschine) optimiert sind, die in Inhalt, Profil und Geschäftsregeln arbeitet. Der andere Diensttyp bezieht sich auf programmatische Dienste, die z.B. Algorithmen, Logik etc. erfordern, die nicht einfach in ein optimiertes Inhaltsabgabesystem eingebaut sind. Falls diese Dienste von der pcore-Dienstklasse sind, dann können sie für die IBM WEBSphere J2EE Umgebung fertig gebaut sein, und falls sie von einer integrierten Dienstklasse sind und in einem externen Dienstserver laufen, werden sie an die Portalkernpräsentation angepasst.
  • Ein Dienst benötigt Spezifikationen inkludierend Elemente in der Wiedergabefunktionalität der Präsentationsschicht ebenso wie in Bezug auf die Dienstschichtfunktionalität, d.h. Schemata und Logik. Die Portalkernpräsentationsarchitektur kann, wie oben verwiesen, in einer vorteilhaften Ausführungsform die J2EE-Architektur für die Mechanismen zum Erstellen und Einsetzen von Diensten in speziellen Elementen oder zum Definieren von Diensten implementieren. Die Erfindung ist jedoch nicht auf eine Portalstruktur unter Verwendung von J2EE und Broadvision begrenzt, die lediglich als Beispiele angegeben werden.
  • Die Präsentationsschicht ist konzeptionell in zwei Stufen gesplittet, eine Wiedergabeschicht, die sich in dem Portalkern selbst befindet, und eine Dienstschicht, die einem beliebigen Dienst zur Verfügung steht, der seinen Inhalt durch die Portalkernpräsentationsstruktur präsentieren will. Die Wiedergabeschicht verwendet in einer vorteilhaften Implementierung XML-/XSLT-Technologien. Dadurch ist auch sichergestellt, dass Information, die durch Dienste innerhalb des Portals präsentiert wird, auf einem standardisierten Weg angezeigt werden kann, ungeachtet dessen, was die Endnutzerstation ist, d.h. ungeachtet dessen, welche Art von Endnutzerstation der Endnutzer verwendet, wenn er auf das Portal zugreift. Durch die Verwendung von XML/XSLT kann sichergestellt werden, dass ein vereinheitlichtes "Aussehen und Gefühl" vom Inhalt innerhalb des Präsentationsraums präsentiert wird.
  • Falls XML als eine generische Textauszeichnungssprache verwendet wird, erzeugt ein Dienst eine Ausgabe in der Form von einem XML-Dokument, das unter Verwendung von Strukturinformation von einer pcore-DTD formatiert ist. Die XML-Ausgabe von dem Dienst wird dann verwendet, um die Präsentationsengine der Präsentationsanordnung zu versorgen. Die Präsentationsengine verwendet pcore-SS und pcore-Gitterinformation, die mit der pcore-DTD von dem XML-Dokument in Verbindung steht, das durch den Dienst geliefert wird, um die gewünschte Schnitt stelle zu generieren. Dienste, die nicht XML aus einer pcore-DTD erzeugen, sind insbesondere auch in der Lage, sich selbst durch die Präsentationsdienste zu präsentieren.
  • Wie zuvor berichtet, kann die Portalstruktur vorteilhafter Weise verschiedene Vorrichtungen handhaben, wie etwa WAP-Telefone, und Breitbandvorrichtungen, wie etwa PCs, oder den Browser, der dadurch verwendet wird. Eine Portalkernstrukturplattform und die Logik in ihr sind insbesondere vollständig von der Präsentationsschichtfunktionalität getrennt, was es sehr einfach macht, Unterstützung für alle unterschiedlichen Typen von Clients zu implementieren, sogar Stimmen- und Sprachsynthesizer. Durch Verwendung von z.B. XML/XSL ist es sehr einfach, Unterstützung z.B. für einen neuen Typ einer WAP-Anzeigegröße zu implementieren. Es ist auch möglich, den Wiedergabeprozess auf verschiedene WEB-Vorrichtungen, existierende und zukünftige in der Hand gehaltene Vorrichtungen, Sprach-Browsen und interaktives TV anzupassen.
  • In einer bestimmten Implementierung besteht die WEB-Schnittstelle aus Quadratelementen, die auch als Ziegel (bricks) bezeichnet werden. Ein Ziegel ist ein Container von einem Dienst, ein Bild oder eine Anwendung, der auf dem Bildschirm der Endnutzerstation angezeigt wird. Unter Verwendung derartiger Ziegel oder Container ist es möglich, das Portal anzupassen. Ein Ziegel ist somit eine Anwendung, die erstellt wird, um innerhalb der Portalstruktur verwendet zu werden, die einen Verweis auf die Anwendung hat. Die Anwendung muss dem Portal Anzeigeinformation bereitstellen, wenn gewünscht wird, den Ziegel wiederzugeben. Vorteilhafter Weise kann ein Ziegel in mehr als einem Format erscheinen. Die Anordnung der Ziegel oder Container stellt eine sogenannte Ziegelschnittstelle dar. Um eine einfache Navigation zu ermöglichen, kann die WAP-Schnittstelle in einer Implementierung auf dem gleichen Weg strukturiert sein. In der WEB-Schnittstelle wird dem Benutzer eine Liste verfügbarer Ziegel präsentiert. Jeder Ziegel enthält eine Anwendung, Dienst oder Hintergrundbild, was in dem aufgebauten WEB-Standort eines Benutzers inkludiert sein kann. Ein Ziegel kann auch ein vorkonfigurierter Dienst von einer externen Firma oder einem Dienstanbieter sein. Ein Ziegel-Gitter ist eine nicht-visuelle Darstellung von einem angepassten Portal. Abhängig von einer Vorrichtung wird das Ziegel-Gitter auf einem Weg dargestellt, der für die in Verwendung befindliche Vorrichtung am besten geeignet ist. Das Gitter kann auf vielen Wegen gestaltet sein ebenso wie der Weg, auf dem die Ziegel präsentiert und organisiert sind, z.B. mit Tags. Das Ziegel-Gitter wird in einem generischen Format gespeichert und es ist von einer Vorrichtung/Endnutzerstation unabhängig.
  • Vorzugsweise authentifiziert sich der Endnutzer selbst gegenüber dem Portal mit einer Einmalanmeldung, die dem Endnutzer Zugriff auf die ganze Funktionalität innerhalb des Portals geben wird. Eine beliebige Authentifikation zu verbundenem oder externem Inhalt oder Dienstanbietern wird durch das Plattformsicherheitssystem gehandhabt. Vorteilhafter Weise kann jede Anwendung oder Dienst innerhalb des Portals personalisiert werden, um zu den Bedürfnissen von dem Endnutzer zu passen, und jede Anwendung kann für unterschiedliche Vorrichtungen personalisiert werden. Dies ist insbesondere von Vorteil, wenn ein Endnutzer den Umfang von Daten begrenzen möchte, die zu einer anderen Endnutzerstation mit begrenzter Kapazität gesendet werden, um größere Datenmengen zu präsentieren, z.B. ein WAP-Telefon. Es ist möglich, eine Anwendung mehr als ein Mal auszuwählen und jeder der verschiedenen Instanzen ihre eigene Personalisierung zu geben.
  • Oben wurde ein Beispiel in einer Portalstruktur beschrieben, in der das erfinderische Konzept implementiert werden kann. Die Erfindung als solche ist jedoch natürlich nicht darauf begrenzt, in einem derartigen Portal implementiert zu werden, sondern basiert auf der Annahme, dass eine Portalstruktur vorgesehen wird, die in der Lage ist, Endnutzer, d.h. Entitäten, die auf das Portal zugreifen, mit Zugriff auf Dienste/Anwendungen zu versehen. Für jeden Endnutzer wird durch das Portal eine Sitzung erstellt und jede Sitzung enthält endnutzerspezifische Daten. Ein Dienst/eine Anwendung kann extern oder intern sein. In diesem Zusammenhang ist eine interne Anwendung oder Dienst als eine Anwendung oder Dienst definiert, die/der die Sitzungsverwaltung des Portals verwendet, wohingegen eine externe Anwendung oder Dienst als eine Anwendung oder Dienst definiert ist, die/der eine externe Sitzungsverwaltung verwendet, was bedeutet, dass sie/er die Sitzungsverwaltung selbst bereitstellen kann oder durch eine dritte Seite sitzungsverwaltet werden kann.
  • Das erfinderische Konzept wird im folgenden detailliert mit Bezug auf 3A–6 beschrieben.
  • 3A, 3B zeigen eine Implementierung, in der vorausgesetzt wird, dass die Portalstruktur Zugriff durch mobile ebenso wie stationäre Endnutzerstationen unterstützt. In einer vorteilhaften Implementierung wird Zugriff auf die Portalstruktur selbst für unterschiedliche Typen von Endnutzerstationen ermöglicht, selbst wenn die Typen der Portalstruktur nicht bekannt sind. Dies kann ausgeführt werden wie in der schwedischen Patentanmeldung "Arrangement and method relating to end user stations accessing a portal" beschrieben, eingereicht zum selben Datum und durch den gleichen Anmelder wie die vorliegende Erfindung, und deren Inhalt hiermit hierin durch Bezugnahme einbezogen wird.
  • 3A ist eine schematische Veranschaulichung einer Endnutzerstation 5, die hier eine WAP-Vorrichtung ist, die auf den Portalkern 1 einer Portalstruktur zugreift, um Zugriff auf eine externe Anwendung 26 zu erhalten. In dem Portalkern werden nur die Mittel veranschaulicht, die für das Funktionieren der vorliegenden Erfindung von Interesse sind, nämlich Präsentationsanordnung 11 mit Wiedergabemittel 15, Anforderungsvermittler 16, Portalsitzungsverwaltungsmittel 13, Sitzungsvereinheitlichungsmittel 50 und Portalsitzungsspeichermittel 51.
  • Falls die Endnutzerstation 5 Zugriff auf eine externe Anwendung 26 wünscht, wird dem Sitzungsvereinheitlicher 50 eine Anforderung (I0) bereitgestellt, und da es die erste Transaktion der Verbindung ist, d.h. für Endnutzer 5 ist in Bezug auf die externe Anwendung 26 keine Sitzung verfügbar, wird durch Portalsitzungsverwalter 13 eine Sitzung erstellt, die die Anforderung (II0) von dem Sitzungsvereinheitlicher 50 empfängt. Die Sitzung enthält benutzerspezifische Daten und wird in das Portalspeichermittel 51 gespeichert. Eine Portalsitzungsidentifikation, oder kurz eine Portalsitzungs-Id, wird erstellt. Der Sitzungsvereinheitlicher 50 leitet auch die Anforderung (III0) zu dem Anforderungsvermittler 16 weiter, der sie zu der externen Anwendung 26 weitergibt (IV0). Die externe Anwendung erfasst, dass es keine (externe) Sitzung für den anfordernden Benutzer gibt, generiert Daten (z.B. XML), erstellt eine externe Sitzung mit einer externen Sitzungs-Id und führt die externe Sitzungs-Id als ein Metainformationstag in die (XML) Daten ein, die nachfolgend als eine Antwort zu dem Portalanforderungsvermittler 16 gesendet werden (V0), die das Metainformationstag enthalten. Die Daten mit dem Metainformationstag werden zu dem Wiedergabemittel 15 weitergereicht (VI0), das das Metainformationstag erfasst und es zu dem Sitzungsvereinheitlicher 50 weiterreicht, der es in die Portalsitzungs-Id transformiert, die dann zu dem Wiedergabemittel zurückgegeben wird (VII0). In dem Wiedergabeprozess wird die Portalsitzungs-Id in die Antwortdaten geschrie ben, die zu dem Anforderungsvermittler 16 weitergereicht werden (IX0), um sie zu der Endnutzerstation 5 zu senden.
  • In 3B wird vorausgesetzt, dass eine Sitzung bereits existiert und Endnutzerstation 5 erneut versucht, auf Anwendung 26 in der gleichen Sitzung zuzugreifen (I). Der Sitzungsvereinheitlicher 50 fragt die Benutzerportalsitzung von dem Portalsitzungsverwalter 13 (Portalspeichermittel) ab (II). Der Sitzungsvereinheitlicher 50 fragt Dienst-/Anwendungsdaten für den Dienst/die Anwendung ab, auf den/die zuzugreifen ist, z.B. die externe (Back-End) Sitzungs-Id (III). Die externe Sitzungs-Id wird dann zu dem Anforderungsvermittler 16 weitergereicht (IV), der die externe Anwendung 26 aufruft (V). Die Anwendung generiert Daten (z.B. XML), die die externe Sitzungs-Id in dem Metainformationstag inkludieren und sendet sie zu dem Portal (VI). Der Anforderungsvermittler leitet die Daten zu dem Wiedergabemittel 15 für eine Wiedergabe weiter (VII). Das Wiedergabemittel 15 kommuniziert mit dem Sitzungsvereinheitlicher 50, der die externe Sitzungs-Id auf die Portalsitzungs-Id abbildet und die letztere zu dem Wiedergabemittel 15 zurückgibt (VIII). Das Wiedergabemittel schreibt dann die Portalsitzungs-Id in die Antwort, die für die Endnutzerstation 5 gedacht ist (IV). Über den Anforderungsvermittler wird die Antwort zu der Endnutzerstation 5 gesendet (X).
  • Für einen Zugriff einer internen Anwendung wird die Portalsitzungs-Id sowohl für eine Kommunikation zwischen dem Portal und der internen Anwendung als auch für eine Kommunikation zwischen der Endnutzerstation und dem Portalkern verwendet.
  • Falls die Anwendung eine generische Textauszeichnungssprache generiert, z.B. XML, werden die XML-Daten auch in dem Wiedergabemittel 15 übersetzt und zu der Endnutzerstation 5 in der Textauszeichnungssprache wiedergegeben und ausgegeben, die für die Endnutzerstation verständlich ist, z.B. HTML, falls es ein PC ist, und WML, falls es eine WAP-Vorrichtung ist.
  • Dies bedeutet, das für eine Kommunikation zwischen der Endnutzerstation und dem Portal nur die Portalsitzungs-Id verwendet wird, sobald sie zugewiesen ist, wohingegen zwischen dem Portal und einer externen Anwendung nur die externe Anwendungssitzungs-Id verwendet wird, sobald sie generiert ist.
  • In einer Portalstruktur, die das erfinderische Konzept implementiert, wird ein Sitzungsverwaltungsvereinheitlichungsrahmenwerk vorgesehen, das aus dem Sitzungsvereinheitlicher besteht. Der Sitzungsvereinheitlicher sieht einen generischen 1:n (einer auf viele) Sitzungsabbildungsmechanismus vor, d.h. falls es eine Vielzahl von externen Systemen (Anwendungen, Dienste, Portale) mit ihrer eigenen Sitzungsverwaltung gibt, ist der Sitzungsvereinheitlicher in der Lage, Portalsitzungen auf die Sitzungen von externen Systemen und umgekehrt zu transformieren.
  • Die Prozedur wird in allgemeinen Begriffen mit Bezug auf das Flussdiagramm von 4 beschrieben. Es wird somit vorausgesetzt, dass eine Anforderung für eine Anwendung, hier als C bezeichnet, in der Portalstruktur von Endnutzer U empfangen wird, 100. Das Portal überprüft, ob es eine Sitzung gibt, die in dem Speichermittel für Endnutzer U in Bezug auf Anwendung C verfügbar ist, 101. Falls nicht, wird eine Portalsitzung erstellt, der eine Portalsitzungs-Id zugeordnet wird, 102. Es wird festgestellt, ob Anwendung C extern sitzungsverwaltet ist, 103. Falls nicht, wird die Anwendung die Portalsitzungs-Id in einer Kommunikation mit Anwendung C und mit Endnutzer U verwenden, 104, und es gibt keine Notwendigkeit einer Vereinheitlichung von Sitzungen. Falls jedoch Anwendung C extern sitzungsverwaltet ist, wird die Anforderung zu Anwendung C weitergeleitet, 106 (natürlich auch, falls die Anwendung in tern sitzungsverwaltet ist, d.h. die Portalsitzungsverwaltung verwendet, wird die Anforderung zu der Anwendung weitergeleitet etc., aber dies ist für das erfinderische Konzept nicht relevant und wird deshalb hierin nicht weiter erörtert). In Anwendung C (oder allgemeiner dem externen System) wird untersucht, ob es eine Sitzung gibt, die für Endnutzer U verfügbar ist, 107. Falls nicht, wird eine proprietäre Sitzung einer externen Anwendung mit einer externen Sitzungs-Id, auch als eine externe (Anwendungs-)Id bezeichnet, generiert, 108. Es werden Anwendungsdaten generiert, die mit Information über die externe Sitzungs-Id versehen werden. Es wird eine Antwort zu dem Portal gesendet, die die Anwendungsdaten und die Information über die externe Sitzungs-Id enthält, 109.
  • Wenn die Antwort innerhalb des Portals empfangen ist, wird die externe Sitzungs-Id-Information in der Portalsitzung gespeichert, die für Endnutzer U für Anwendung C erstellt wird, wobei die Portalsitzung in dem Portalsitzungsspeichermittel gespeichert wird, 110. Anschließend wird für eine weitere Kommunikation zwischen dem Endnutzer und dem Portal die Portalsitzungs-Id verwendet. Es ist Information über die externe Sitzungs-Id in einer Kommunikation mit Anwendung C enthalten, 111.
  • Falls im obigen Schritt 101 festgestellt wurde, dass es eine Sitzung gab, die in dem Speichermittel verfügbar ist, wird insbesondere für eine externe Anwendung die Information über die externe Sitzungs-Id gefunden, 105. Dann wird die Portalsitzungs-Id in einer Kommunikation zwischen dem Endnutzer und dem Portal verwendet, wohingegen die externe Sitzungs-Id für eine Kommunikation zwischen dem Portal und der Anwendung verwendet wird, wie oben berichtet, 111. Falls jedoch keine Information über eine externe Sitzungs-Id in der Portalsitzung gespeichert ist, die in dem Portalspeichermittel gespeichert wird, 105, kann es anzeigen, dass die Anwendung intern ist und die Portalsitzungs-Id wird in einer Kommunikation sowohl mit Anwendung C als auch mit Endnutzer U verwendet.
  • Der obige Schritt 103 kann den Eindruck vermitteln, dass es eine separate Erfassung bezüglich dessen geben muss, ob eine Anwendung extern ist. Dies kann jedoch inhärent für eine bereits existierende Sitzung erfasst werden, wenn die Portalsitzung durch das Sitzungsvereinheitlichungsmittel von dem Portalspeichermittel über das Portalsitzungsverwaltungsmittel abgefragt wird. Für eine neue Sitzung kann es erfasst werden, da die Antwort von der Anwendung empfangen wird, die dann ein Metainformationstag mit der externen Sitzungs-Id enthält, insbesondere durch das Wiedergabemittel.
  • 5 ist ein Flussdiagramm, das für eine bestimmte Ausführungsform die Prozedur etwas detaillierter beschreibt, wenn eine Anforderung von einem Endnutzer U1 in dem Portal in Bezug auf eine externe Anwendung A zum ersten Mal empfangen wird, d.h. es gibt keine Sitzung, 200. Das Portalsitzungsverwaltungsmittel erfasst, dass es für U1 in Bezug auf Anwendung A keine Sitzung gibt, 201. Das Portal erstellt dann eine Sitzung für Endnutzer U1 und Anwendung A mit einer Portalsitzungs-Id, 202. Anschließend wird die Anforderung zu Anwendung A weitergeleitet, 203. Anwendung A erfasst, dass es keine Sitzung für U1 gibt, 204. Anwendung A erstellt dann eine proprietäre externe Sitzung für U1 und ein Metainformationstag mit mindestens einer externen Sitzungs-Id, d.h. mit der Identität der erstellten Sitzung, 205. Die Anwendung generiert auch Anwendungsdaten, in dieser Ausführungsform in XML, und sendet die Anwendungsdaten mit dem Metainformationstag zu dem Portalkern, 206. Somit gibt es in den XML-Daten ein Metainformationstag, das die Anwendungssitzungs-Id enthält. Sie kann z.B. wie folgt aussehen:
    <metainfo name="application_session_id" value="4711" />
  • Das Portalsitzungsvereinheitlichungsmittel bildet die externe Sitzungs-Id auf die Portalsitzungs-Id für U1 ab, 207. Das Portalsitzungsverwaltungsmittel speichert die Metainformationsdaten, insbesondere alle Metainformationsdaten, falls in einer vorteilhaften Implementierung nicht nur Metainformation in Bezug auf die Sitzungs-Id inkludiert ist, sondern auch andere Daten, in die Portalsitzung, 208. In einer Implementierung enthalten die Anwendungsdaten auch Metaverweise, die auf andere Dienste/Anwendungen verweisen, die durch ein Übersetzungsmittel bearbeitet und übersetzt werden können, wie weiter in der gemeinsam anhängigen Patentanmeldung "An Arrangement and A Method Relating to Access of Applications/Services" erörtert, und die Sitzungs-Id des Portals wird als ein Parameter hinzugefügt.
  • Das Wiedergabemittel von dem Portalkern gibt die Anwendungsdaten wieder, d.h. übersetzt sie in ein Format, das für die Endnutzerstation geeignet ist, und sendet sie zu Endnutzer U1 nur unter Verwendung der Portalsitzungs-Id, 209.
  • 6 ist ein Flussdiagramm, das die Prozedur beschreibt, wenn Endnutzer U1 versucht, auf Anwendungen A während der gleichen Sitzung noch einmal zuzugreifen. Somit wird vorausgesetzt, dass eine nachfolgende Anforderung für Anwendung A in dem Portal von U1 empfangen wird, 210. Dies bedeutet z.B., dass der Endnutzer U1 auf einen Verweis in seinem Browser zu Anwendung A klickt, wobei der Verweis einen Parameter zu der Portalsitzungs-Id hat. Über den Sitzungsvereinheitlicher schlägt das Portalsitzungsverwaltungsmittel die Portalsitzung für U1 unter Verwendung der Portalsitzungs-Id nach, 211. Es wird erfasst, dass es Metainformation in Bezug auf Anwendung A gibt, die in der Portalsitzung für U1 enthalten ist, 212. Der Portalanforderungsvermittler kontaktiert die Anwendung und inkludiert die Metainformation als Parameter und leitet die Anforderung zu Anwendung A weiter, 213. Die Metainformation umfasst die externe Sitzungs-Id, die somit zu der Anwendung gesendet wird, d.h. in einer Kommunikation mit Anwendung A verwendet wird. Anwendung A verwendet ihre externe Sitzungs-Id, wie in der Metainformation inkludiert, um die externe Sitzung für den Endnutzer U1 nachzuschlagen, 214. Die Anwendung erstellt Anwendungs-(XML-)Daten, inkludiert das Metainformationstag in die XML-Daten und sendet XML-Daten mit dem Metainformationstag zu dem Portal, 215. Dann fährt der Fluss wie in Schritten 207, 208 von 5 (216) fort etc.
  • Gemäß einer Implementierung sieht die externe Anwendung, oder allgemeiner das externe System, auch als das Backend-System bezeichnet, die folgenden Operationen vor, um das Sitzungsvereinheitlichungsmittel (Sitzungsvereinheitlicher) funktionsfähig zu machen:
    • 1. BackendSession bs = backend, createSession()
    • 2. Bs.updateSession()
    • 3. Stream s = backend.serializeSession(BackendSession bs)
  • Der Sitzungsvereinheitlicher implementiert die folgenden Operationen:
    • 1. PortalSession ps = Portal.getSession()
    • 2. BackendSession bs = Ps.getBackendSession(backendService)
    • 3. ps.callBackendService(backendService, bs)
    • 4. ps.storeBackendSession(backendService, bs)
  • Die Sitzungsvereinheitlichungsprozedur funktioniert gemäß dieser Implementierung somit wie folgt:
    • 1. Der Vereinheitlicher ruft ps.getSession() auf, um die Portalsitzung abzufragen, die mit der Anforderung/Aufruf für den Dienst/Anwendung in Verbindung steht.
    • 2. Der Vereinheitlicher ruft bs = ps.getBackendSession(backendService) auf
    • 3. Der Vereinheitlicher ruft ps.callBackendService(backendService, bs) auf
    • 4. Falls es für den Benutzer (bs = 0) keine Backend-Sitzung gibt, ruft das Backend bs = backend,createSession() auf und sendet diese Sitzung zusammen mit der Antwort zu dem Portal. Anderenfalls ruft das Backend bs.updateSession() auf und sendet dies zusammen mit der Antwort zu dem Portal. Senden der Backend-Sitzung wird durch Aufrufen von backend.serializeSession(bs) bewerkstelligt.
    • 5. Das Portal speichert die Backend-Sitzung durch Aufrufen von ps.storeBackendSession(backendService, bs).
  • 7 ist ein Interaktionsdiagramm, das die Schritte der oben beschriebenen Sitzungsvereinheitlichungsprozedur beschreibt.
  • P.getSession() kann durch ein beliebiges Sitzungsverwaltungssystem z.B. der Servlet-Sitzungs-API folgend implementiert werden.
  • P.getBackendSession(backendService) kann durch Erstellen eines Namensraums innerhalb der Portalsitzung für jeden abgeru fenen backendService und Speichern innerhalb des Namensraums der auf backendService bezogenen Daten implementiert werden.
  • Um die Bandbreiteanforderungen zu reduzieren, kann B.serialiseSession() durch Senden nur eines Identifizierers der Sitzung von dem Backend-System implementiert werden.
  • Es ist ein Vorteil der Erfindung, dass durch Bereitstellung einer Sitzungsvereinheitlichung eine nahtlose Integration von unterschiedlichen Sitzungsverwaltungssystemen in eine vereinheitlichte Sitzungsverwaltung ermöglicht wird. Für Portalstrukturen kann dies die Integrationszeit zwischen Portal und Dienstanbietern einer externen Anwendung beträchtlich verringern. Insbesondere für mobile Portale, die Zugriff auch durch Mobilstationen unterstützen, sieht eine derartige Vereinheitlichung einer Sitzungsverwaltung ein mächtiges Mittel vor, um den Umfang an Daten zu reduzieren, die zu drahtlosen Endnutzerstationen zu senden sind, durch Konvertieren langer Backend-Sitzungsdaten in kurze vereinheitlichte Sitzungen. Zugriff durch mobile Endnutzerstationen, wie etwa WAP-Vorrichtungen, auf extern sitzungsverwaltete Systeme kann sogar anderenfalls wegen dem großen Umfang an Daten nicht möglich sein, die im Fall transferiert werden müssen, dass sowohl eine Portalsitzungs-Id als auch eine externe Sitzungs-Id in einer Kommunikation mit der Endnutzerstation inkludiert werden müssen, da ein derartiger Umfang an Daten für eine mobile Endnutzerstationen nicht akzeptabel sein kann. Selbst wenn eine Endnutzerstation in der Lage ist, derartige Datenmengen nur für Identifikationszwecke zu handhaben, ist es eine Verschwendung von Ressourcen und Zeit.
  • Es sollte klar sein, dass die Erfindung nicht auf die speziell veranschaulichten Ausführungsformen begrenzt ist, sondern innerhalb des Bereichs der angefügten Ansprüche auf einer Anzahl von Wegen variiert werden kann.
  • ZUSAMMENFASSUNG
  • Die vorliegende Erfindung bezieht sich auf eine Portalstruktur, die Endnutzerstationen (5) mit Zugriff auf Dienste/Anwendungen (26) versieht, umfassend einen Portalkern (1) und eine Anzahl von Diensten/Anwendungen (26). Der Portalkern umfasst eine Präsentationsanordnung, Portalsitzungsverwaltungsmittel (13), das sitzungsbezogene Information generiert, z.B. Sitzungsidentifikationen, und Portalspeichermittel (51) zum Speichern sitzungsbezogener Information. Mindestens einige der Dienste/Anwendungen (26) sind extern mit externen Sitzungsidentifikationen. Sitzungsvereinheitlichungsmittel (50) sind zum Abbilden zwischen Portalsitzungsidentifikationen und externen Sitzungsidentifikationen vorgesehen. Für eine Kommunikation zwischen dem Portalkern (1) und externen Diensten/Anwendungen (26) wird die externe Identifikation verwendet, wohingegen in einer Kommunikation zwischen einer Endnutzerstation (5) und dem Portalkern (1) nur die Portalsitzungsidentifikation verwendet wird.

Claims (27)

  1. Portalstruktur, die Endnutzerstationen mit Zugriff auf Dienste/Anwendungen versieht, umfassend einen Portalkern, (Dienstbefähigungsmittel, Konnektivitätsmittel, über die Endnutzerzugriff vorgesehen wird) und eine Anzahl von Diensten/Anwendungen, wobei der Portalkern umfasst eine Präsentationsanordnung, Portalsitzungsverwaltungsmittel, die sitzungsbezogene Information generieren, z.B. Sitzungsidentifikationen, Portalspeichermittel zum Speichern sitzungsbezogener Information (und Teilnehmerverwaltungsmittel), wobei mindestens einige der Dienste/Anwendungen externe Dienste/Anwendungen umfassen oder durch externe Systeme vorgesehen werden, die externe Sitzungsverwaltungsmittel implementieren, die externe Sitzungsidentifikationen generieren, gekennzeichnet dadurch, dass die Portalstruktur ferner Sitzungsvereinheitlichungsmittel zum Abbilden zwischen Portalsitzungsidentifikationen und externen Sitzungsidentifikationen umfasst und dadurch, dass für eine Kommunikation zwischen dem Portalkern und externen Diensten/Anwendungen die externe Identifikation eines externen Dienstes/Anwendung als Sitzungsidentifikation verwendet wird, wohingegen in einer Kommunikation zwischen einer Endnutzerstation und dem Portalkern nur die Portalsitzungsidentifikation als Sitzungsidentifikation verwendet wird.
  2. Portalstruktur nach Anspruch 1, gekennzeichnet dadurch, dass die Dienste/Anwendungen eine generische Textauszeichnungssprache generieren.
  3. Portalstruktur nach Anspruch 2, gekennzeichnet dadurch, dass die generische Textauszeichnungssprache XML ist.
  4. Portalstruktur nach einem beliebigen der Ansprüche 1–3, gekennzeichnet dadurch, dass proprietäre externe Sitzungsidentifikationsinformation eines externen Dienstes/Anwendung für alle externen Dienste/Anwendungen, die in einer Sitzung aktiv sind, in der entsprechenden Portalsitzung in dem Portalspeichermittel für eine definierte Zeitdauer gespeichert sind, z.B. während der gesamten Dauer der jeweiligen Sitzung.
  5. Portalstruktur mindestens nach Anspruch 2, gekennzeichnet dadurch, dass die Präsentationsanordnung Wiedergabemittel zum Übersetzen von Dienst-/Anwendungsdaten in der generischen Textauszeichnungssprache in eine andere Textauszeichnungssprache, die durch eine Endnutzerstation verwendet wird, umfasst.
  6. Portaldienst nach Anspruch 5, gekennzeichnet dadurch, dass er mobil ist, d.h. er Zugriff durch mobile Endnutzerstationen, z.B. WAP-Vorrichtungen, zusätzlich zu stationären Endnutzerstationen unterstützt.
  7. Portalstruktur mindestens nach Anspruch 2, gekennzeichnet dadurch, dass Daten, die Dienste/Anwendungen in der generischen Textauszeichnungssprache darstellen, in einer Dokumenttypdefinitions-(DTD)Sprache mit einem URL-Attribut definiert sind.
  8. Portalstruktur nach einem beliebigen der vorangehenden Ansprüche, gekennzeichnet dadurch, dass ein externes System mit einem externen proprietären Sitzungsverwaltungsmittel ein anderes Portal umfasst.
  9. Portalstruktur nach einem beliebigen der vorangehenden Ansprüche, gekennzeichnet dadurch, dass die Portalsitzungsverwaltungsmittel gemäß der Spezifikationen von Servlet-Sitzungs-API oder Sitzungs-EJB:s arbeiten, die Basissitzungsverwaltungsoperationen definieren.
  10. Portalstruktur nach einem beliebigen der vorangehenden Ansprüche, gekennzeichnet dadurch, dass das Portalsitzungsverwaltungsmittel Information in Bezug auf durch einen Endnutzer initiierte Aktionen, wie etwa ein Endnutzer, der das Portal betritt, Endnutzer-Authentifikation, Endnutzerzugriff eines Dienstes/Anwendung etc., in das Portalspeichermittel speichert.
  11. Portalstruktur nach einem beliebigen der vorangehenden Ansprüche, gekennzeichnet dadurch, dass bei Empfang einer Endnutzeranforderung für einen Dienst/Anwendung eine Portalsitzung mit einer Sitzungsidentifikation durch das Portalsitzungsverwaltungsmittel erstellt wird, und wenn die Anforderung zu dem Dienst/Anwendung weitergeleitet wird, der Dienst/Anwendung die Portalsitzungsidentifikationsinformation verwendet, falls es ein interner Dienst/Anwendung ist, wohingegen der Dienst/Anwendung mit einer externen (proprietären) Sitzungsidentifikation versehen wird, falls er durch ein externes Sitzungsverwaltungsmittel verwaltet wird.
  12. Portalstruktur nach Anspruch 11, gekennzeichnet dadurch, dass für einen Dienst/Anwendung, der/die durch ein externes Sitzungsverwaltungsmittel verwaltet wird, das externe Sitzungsverwaltungsmittel die externe Sitzungsidentifikationsinformation, die für einen anfordernden Endnutzer generiert wird, für eine definierte Zeitdauer speichert, z.B. während der gesamten Dauer der Sitzung, und dadurch, dass wenn eine nachfolgende Aufrufanforderung von dem Portal während der Sitzung empfangen wird, Dienstanwendungsdaten generiert werden und eine Antwort zu dem Portalkern zurückgegeben wird umfassend die Dienst-/Anwendungsdaten und die externe Sitzungsidentifikation, durch das Vereinheitlichungsmittel auf die Portalsitzungsidentifikation derart konvertiert/abgebildet wird, dass die Dienst-/Anwendungsdaten zu dem Endnutzer durch Verwendung nur der Portalsitzungsidentifikation weitergeleitet werden können.
  13. Portalstruktur nach Anspruch 12, gekennzeichnet dadurch, dass ein Namensraum innerhalb der Portalsitzung für jeden Dienst/Anwendung, auf den/die zugegriffen wird, erstellt wird und dadurch, dass die externen Sitzungsinformationsdaten, die mindestens externe Sitzungsidentifikation inkludieren, innerhalb des Namensraums gespeichert werden.
  14. Portalstruktur nach Anspruch 2, 11 oder 12, gekennzeichnet dadurch, dass ein externer Dienst/Anwendung eine externe proprietäre Sitzung mit einer externen (proprietären) Id eines externen Dienstes/Anwendung für einen Endnutzer erstellt, der Zugriff auf den externen Dienst/Anwendung über das Portal anfordert und ein Metainformationstag, das mindestens die externe (proprietäre) Sitzungsidentifikation enthält, in die Dienst-/Anwendungsdaten in der generischen Textauszeichnungssprache einführt, um zu dem Portalkern zurückgegeben zu werden.
  15. Portalstruktur nach Anspruch 14, gekennzeichnet dadurch, dass alle Daten von dem Metainformationstag in der ent sprechenden Portalsitzung für den anfordernden Endnutzer gespeichert sind.
  16. Portalstruktur nach Anspruch 15, gekennzeichnet dadurch, dass der Portalkern ein erstes Übersetzungsmittel zum Bearbeiten möglicher Metaverweise, die in den Dienst-/Anwendungsdaten in der generischen Textauszeichnungssprache inkludiert sind, denen die Portalsitzungsidentifikation als ein Parameter hinzugefügt wird, umfasst, und dadurch, dass der Portalkern ferner ein Wiedergabemittel mit einem zweiten Übersetzungsmittel zum Transformieren der Daten in der generischen Textauszeichnungssprache zu einer Textauszeichnungssprache, die für die anfordernde Endnutzerstation verständlich ist, umfasst.
  17. Portalstruktur nach Anspruch 16, gekennzeichnet dadurch, dass für einen nachfolgenden Zugriff auf den gleichen Dienst/Anwendung durch den gleichen Endnutzer in der gleichen Sitzung die gespeicherte Metainformation, die die externe Sitzungsidentifikation enthält, von dem Portalsitzungsvereinheitlichungsmittel zu dem externen Dienst/Anwendung derart weitergeleitet wird, dass der externe Dienst/Anwendung in der Lage ist, die externe Sitzung zu finden, wie durch die externe Sitzungsidentifikation angezeigt.
  18. Anordnung in einer Portalstruktur umfassend einen Portalkern mit einer Präsentationsanordnung, Portalsitzungsverwaltungsmittel, das sitzungsbezogene Information generiert, mindestens Portalsitzungsidentifikationen und Portalspeichermittel zum Speichern von portalsitzungsbezogener Information, gekennzeichnet dadurch, dass sie Sitzungsvereinheitlichungsmittel zum Vereinheitlichen einer Verwaltung von Portalsitzungen und externen Sitzungen, die durch externe Sitzungsverwaltungsmittel generiert werden, die externe Dienste/Anwendungen verwalten, umfasst, dass nur die Portalsitzungsidentifikation in einer Kommunikation zwischen dem Portal und einer zugreifenden Endnutzerstation verwendet wird, und dadurch, dass die externe Sitzungsidentifikation in einer Kommunikation zwischen dem Portalkern und dem externen Dienst/ Anwendung verwendet wird, und dadurch, dass die Vereinheitlichungsmittel zum Abbilden/Transformieren zwischen Portalsitzungsidentifikationen und externen Sitzungsidentifikationen von externen Diensten/Anwendungen verwendet werden.
  19. Anordnung nach Anspruch 18, gekennzeichnet dadurch, dass die proprietäre externe Sitzungsidentifikationsinformation eines externen Dienstes/Anwendung in der Portalsitzung gespeichert wird, auf die sie für eine definierte Zeitdauer abgebildet wird, z.B. während einer gesamten Sitzung.
  20. Anordnung nach Anspruch 18, gekennzeichnet dadurch, dass die Präsentationsanordnung Wiedergabemittel umfasst zum Übersetzen von Dienst-/Anwendungsdaten in einer generischen Textauszeichnungssprache in andere Textauszeichnungssprachen in Abhängigkeit von dem Typ einer anfordernden Endnutzerstation für eine Wiedergabe einer Dienst-/Anwendungsdatenausgabe zu Endnutzerstationen, die Zugriff auf einen Dienst/eine Anwendung angefordert haben, in eine Textauszeichnungssprache, die für die Endnutzerstation verständlich ist.
  21. Anordnung nach Anspruch 20, gekennzeichnet dadurch, dass die generische Textauszeichnungssprache XML ist.
  22. Anordnung nach einem beliebigen der Ansprüche 18–21, gekennzeichnet dadurch, dass die externe Sitzungsidentifi kationsinformation in einem Metainformationstag vorgesehen ist, das in die externen Dienst-/Anwendungsdaten eingeführt wird, und dadurch, dass die Metainformationsdaten in der entsprechenden Portalsitzung in dem Portalspeichermittel gespeichert werden, das Portalsitzungsinformation speichert, und dadurch, dass die Portalsitzungsidentifikation den externen Anwendungs-/Dienstdaten als ein Parameter in einer Kommunikation mit der Endnutzerstation hinzugefügt wird, was die externe Sitzungsidentifikation ersetzt.
  23. Anordnung nach Anspruch 22, gekennzeichnet dadurch, dass für eine anschließende Anforderung zu dem Portal für den gleichen externen Dienst/Anwendung durch einen Endnutzer während einer Sitzung die Metainformation in die Anforderung inkludiert wird, wenn von dem Portalkern zu dem externen Dienst/Anwendung weitergeleitet.
  24. Verfahren für eine Sitzungsverwaltung in einer Portalstruktur umfassend einen Portalkern umfassend eine Präsentationsanordnung, Portalsitzungsverwaltungsmittel, das sitzungsbezogene Information handhabt, und Portalspeichermittel zum Speichern sitzungsbezogener Information, die Schritte umfassend: – Erstellen einer Portalsitzung mit einer Portalsitzungsidentifikation, wenn ein Endnutzer Zugriff auf einen Dienst/Anwendung anfordert, es sei denn, es existiert bereits eine Portalsitzung; – Weiterleiten der Anforderung zu dem angeforderten externen Dienst/Anwendung, falls der angeforderte Dienst/ Anwendung extern sitzungsverwaltet wird; – Erstellen in dem externen Sitzungsverwaltungsmittel von proprietärer Sitzungsidentifikation eines externen Dienstes/Anwendung für den anfordernden Endnutzer, es sei denn, es existiert bereits eine Sitzung; – Generieren von Dienst-/Anwendungsdaten in dem Dienst/Anwendung; – Einführen von Information über die externe Sitzungsidentifikation in die Dienst-/Anwendungsdaten; – Rückgabe von Dienst-/Anwendungsdaten inkludierend externe Sitzungsidentifikation zu dem Portal; – Abbilden der externen Sitzungsidentifikation auf die Portalsitzungsidentifikation; – Speichern der externen Sitzungsidentifikation in dem entsprechenden Portalsitzungsmittel; – Senden der Dienst-/Anwendungsdaten zu dem anfordernden Endnutzer unter Verwendung nur der Portalsitzungsidentifikation.
  25. Verfahren nach Anspruch 24, gekennzeichnet dadurch, dass es die Schritte umfasst: In dem Portal: – Nachschlagen der Portalsitzung in dem Speichermittel in einer nachfolgenden Anforderung durch einen Endnutzer nach einem externen Dienst/Anwendung während der Sitzung; – Feststellen, ob die auf eine Portalsitzung bezogene Information eine externe Sitzungsidentifikation enthält, falls ja: – Weiterleiten der Anforderung inkludierend die externe Sitzungsidentifikation zu dem angeforderten externen Dienst/Anwendung; In dem externen Sitzungsverwaltungsmittel oder in dem externen Dienst/Anwendung: – Nachschlagen der externen Dienst-/Anwendungssitzung; – Generieren von Dienst-/Anwendungsdaten; – Hinzufügen der externen Sitzungsidentifikation zu den Dienst-/Anwendungsdaten; – Rückgabe der Dienst-/Anwendungsdaten mit der externen Sitzungsidentifikation zu dem Portalsitzungsverwaltungsmittel; In dem Portal: – Ersetzen der externen Sitzungsidentifikation durch die entsprechende Portalsitzungsidentifikation; – Senden der Dienst-/Anwendungsdaten zu der Endnutzerstation unter Verwendung nur der Portalsitzungsidentifikation.
  26. Verfahren nach Anspruch 24 oder 25, gekennzeichnet dadurch, dass der externe Dienst/Anwendung eine generische Textauszeichnungssprache generiert, z.B. XML.
  27. Verfahren nach Anspruch 26, gekennzeichnet dadurch, dass der Schritt zum Hinzufügen externer Sitzungsidentifikation eine Generierung von und Einführung von einem Metainformationstag, das mindestens externe Sitzungsidentifikation enthält, zu den Dienst-/Anwendungsdaten umfasst.
DE10295699T 2001-01-24 2002-01-24 Eine Anordnung und ein Verfahren in Bezug auf Sitzungsverwaltung in einer Portalstruktur Withdrawn DE10295699T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE0100187A SE519936C2 (sv) 2001-01-24 2001-01-24 Anordning och förfarande relaterade till sessionshantering i en portalstruktur
SE0100187-4 2001-01-24
PCT/SE2002/000113 WO2002059787A1 (en) 2001-01-24 2002-01-24 An arrangement and a method relating to session management in a portal structure

Publications (1)

Publication Number Publication Date
DE10295699T5 true DE10295699T5 (de) 2004-04-15

Family

ID=20282703

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10295699T Withdrawn DE10295699T5 (de) 2001-01-24 2002-01-24 Eine Anordnung und ein Verfahren in Bezug auf Sitzungsverwaltung in einer Portalstruktur

Country Status (6)

Country Link
US (1) US6941307B2 (de)
JP (1) JP2004518219A (de)
DE (1) DE10295699T5 (de)
GB (1) GB2386726B (de)
SE (1) SE519936C2 (de)
WO (1) WO2002059787A1 (de)

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6429784B1 (en) * 1999-02-19 2002-08-06 Dresser Industries, Inc. Casing mounted sensors, actuators and generators
WO2001061692A1 (en) * 2000-02-21 2001-08-23 Trek 2000 International Ltd A portable data storage device
WO2003003295A1 (en) * 2001-06-28 2003-01-09 Trek 2000 International Ltd. A portable device having biometrics-based authentication capabilities
TWI246028B (en) * 2001-06-28 2005-12-21 Trek 2000 Int Ltd A portable device having biometrics-based authentication capabilities
ATE335236T1 (de) * 2001-06-28 2006-08-15 Trek 2000 Int Ltd Verfahren und einrichtungen zum datentransfer
US6732105B1 (en) * 2001-07-27 2004-05-04 Palmone, Inc. Secure authentication proxy architecture for a web-based wireless intranet application
US20030055965A1 (en) * 2001-09-20 2003-03-20 International Business Machines Corporation User-defined units of context in a distributed computer environment
CN100520935C (zh) * 2002-02-07 2009-07-29 特科2000国际有限公司 一种能直接与计算机usb端口相连的便携式数据存储和图像记录器件
JP2006507556A (ja) * 2002-03-12 2006-03-02 トレック・２０００・インターナショナル・リミテッド ポータブル記憶デバイスを使用して電子通信にアクセスし、電信通信を移動させるシステムおよび装置
DE60209115T2 (de) * 2002-05-13 2006-10-26 Trek 2000 International Ltd. System und vorrichtung zum komprimieren und dekomprimieren von in einem tragbaren datenspeichergerät gespeicherten daten
US20040010542A1 (en) * 2002-07-11 2004-01-15 Intel Corporation Managed service apparatus, systems, and methods
TW588243B (en) 2002-07-31 2004-05-21 Trek 2000 Int Ltd System and method for authentication
US7389342B2 (en) * 2002-07-31 2008-06-17 Intel Corporation Service creator apparatus, systems, and methods
EP1552659B1 (de) 2002-10-16 2015-01-14 Aepona Limited A service access gateway
EP1568189B1 (de) 2002-12-02 2015-06-17 Sap Se Verfahren und sysem zur sessionrückkehr von zustandsbewahrenden webanwendungen
US8195714B2 (en) 2002-12-11 2012-06-05 Leaper Technologies, Inc. Context instantiated application protocol
US7925246B2 (en) 2002-12-11 2011-04-12 Leader Technologies, Inc. Radio/telephony interoperability system
US6914607B2 (en) * 2003-02-08 2005-07-05 Hewlett-Packard Development Company, L.P. Apparatus and method for buffering data
EP1473631A3 (de) 2003-05-01 2007-10-10 NCR International, Inc. Klient-Objekt für den Gebrauch in einem Selbstbedienungterminal
US20050131818A1 (en) * 2003-08-21 2005-06-16 Desal Nishith M. Method for performing Due diligence and legal, financial and other types of audits
DE60313187T2 (de) * 2003-12-08 2007-12-20 Research In Motion Ltd., Waterloo Verfahren und Vorrichtung für sofortigen Nachrichtendienst
US7958496B2 (en) * 2003-12-22 2011-06-07 Telefonaktiebolaget L M Ericsson (Publ) Method of and system for application service exchange across different execution environments
US7266806B2 (en) * 2004-03-02 2007-09-04 International Business Machines Corporation Portlet template based on a state design pattern
US9426651B2 (en) * 2004-08-18 2016-08-23 Sk Planet Co., Ltd. Method for providing contents in a mobile communication system and apparatus thereof
US7600027B2 (en) * 2004-09-16 2009-10-06 International Business Machines Corporation Managing multiple sessions for a user of a portal
US7502821B2 (en) * 2004-12-16 2009-03-10 Sap Ag Enhanced internet session management protocol
US8281014B2 (en) * 2004-12-28 2012-10-02 Sap Ag Session lifecycle management within a multi-tiered enterprise network
US8204931B2 (en) 2004-12-28 2012-06-19 Sap Ag Session management within a multi-tiered enterprise network
US7941544B2 (en) * 2005-03-18 2011-05-10 Sap Ag Session manager for web-based applications
US20060248199A1 (en) * 2005-04-29 2006-11-02 Georgi Stanev Shared closure persistence of session state information
US7853698B2 (en) * 2005-04-29 2010-12-14 Sap Ag Internal persistence of session state information
US8589562B2 (en) 2005-04-29 2013-11-19 Sap Ag Flexible failover configuration
US20060248283A1 (en) * 2005-04-29 2006-11-02 Galin Galchev System and method for monitoring threads in a clustered server architecture
US8762547B2 (en) * 2005-04-29 2014-06-24 Sap Ag Shared memory implementations for session data within a multi-tiered enterprise network
US8024566B2 (en) * 2005-04-29 2011-09-20 Sap Ag Persistent storage implementations for session data within a multi-tiered enterprise network
US20060270423A1 (en) * 2005-05-24 2006-11-30 Nokia Corporation Information and management service portal for subscribers of communication systems
US7904430B2 (en) * 2005-08-09 2011-03-08 At&T Intellectual Property I, L.P. End-user portal session logging by portlets
JP5738506B2 (ja) * 2005-09-29 2015-06-24 株式会社野村総合研究所 画面情報提供サーバ、プログラム
US8707323B2 (en) 2005-12-30 2014-04-22 Sap Ag Load balancing algorithm for servicing client requests
US8909748B1 (en) 2006-06-22 2014-12-09 Emc Corporation Configurable views of context-relevant content
US8898264B1 (en) 2006-06-22 2014-11-25 Emc Corporation Linking business objects and documents
US20080133569A1 (en) * 2006-12-01 2008-06-05 Amp'd Mobile, Inc. System and method for content handling and bundling for mobile handset device
US8191002B2 (en) 2007-10-15 2012-05-29 International Business Machines Corporation Summarizing portlet usage in a portal page
US7904818B2 (en) * 2007-10-15 2011-03-08 International Business Machines Corporation Summarizing portlet usage captured responsive to trigger events in a portal page
US20100017385A1 (en) * 2008-07-16 2010-01-21 International Business Machines Creating and managing reference elements of deployable web archive files
EP2209280A1 (de) * 2009-01-19 2010-07-21 Koninklijke KPN N.V. Verwaltung von assoziierten Sitzungen in einem Netzwerk
US8495048B2 (en) * 2009-08-26 2013-07-23 International Business Machines Applying user-generated deployment events to a grouping of deployable portlets
TWI418224B (zh) * 2010-06-30 2013-12-01 Htc Corp 自動設定網路推播服務之語言種類的方法、用戶端及伺服器
US9009239B1 (en) * 2011-01-27 2015-04-14 Amdocs Software Systems Limited System, method, and computer program for providing access to a plurality of services through a unified application
US9003141B2 (en) * 2011-11-14 2015-04-07 Ca, Inc. Enhanced software application platform
US11887128B1 (en) * 2021-01-25 2024-01-30 Stripe, Inc. Systems and methods for providing an end to end customer portal

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6587836B1 (en) * 1997-09-26 2003-07-01 Worldcom, Inc. Authentication and entitlement for users of web based data management programs
US6012098A (en) * 1998-02-23 2000-01-04 International Business Machines Corp. Servlet pairing for isolation of the retrieval and rendering of data
SE524391C2 (sv) * 1998-12-28 2004-08-03 Spyglass Inc Metod och system för innehållskonvertering av elektroniska dokument för trådlösa klienter.
AU4495400A (en) * 1999-04-27 2000-11-10 Firstpersom.Com Portal system and method
AU2112301A (en) * 1999-09-24 2001-04-24 Sun Microsystems, Inc. Mechanism for enabling session information to be shared across multiple processes
IES20001002A2 (en) * 1999-12-13 2001-07-11 Markport Ltd A service management access node
US6968449B1 (en) * 1999-12-15 2005-11-22 Microsoft Corporation Methods and arrangements for providing a mark-up language based graphical user interface for user identification to an operating system
JP2001265680A (ja) * 2000-03-15 2001-09-28 Fujitsu Ltd 複数メディアのセッションを管理する装置および方法
US20010047387A1 (en) * 2000-03-27 2001-11-29 Exoplex, Inc. Systems and methods for providing distributed cross-enterprise portals
US7088995B2 (en) * 2001-12-13 2006-08-08 Far Eastone Telecommunications Co., Ltd. Common service platform and software

Also Published As

Publication number Publication date
US20040049589A1 (en) 2004-03-11
SE0100187D0 (sv) 2001-01-24
SE0100187L (sv) 2002-07-25
US6941307B2 (en) 2005-09-06
JP2004518219A (ja) 2004-06-17
WO2002059787A1 (en) 2002-08-01
GB2386726B (en) 2005-06-15
GB0313425D0 (en) 2003-07-16
GB2386726A (en) 2003-09-24
SE519936C2 (sv) 2003-04-29

Similar Documents

Publication Publication Date Title
DE10295699T5 (de) Eine Anordnung und ein Verfahren in Bezug auf Sitzungsverwaltung in einer Portalstruktur
DE60119045T2 (de) Informationsverteilungssystem und Informationsverteilungsverfahren
DE69831904T2 (de) Dynamische Erstellung von Internetseiten
DE60218069T2 (de) Bereitstellung von gekoppelten diensten in einer verteilten rechnerumgebung
DE69913953T2 (de) Verfahren und vorrichtung zur verarbeitung von elektronischen post
DE60009309T2 (de) System und verfahren zum presentieren von kanalisierten daten
DE60314877T2 (de) Verfahren und vorrichtung zur bereitstellung elektronischer post an ein mobiles gerät
DE60306186T2 (de) Verfahren und system zur anordnung von dienste in einer webdienstarchitektur
DE602004003135T2 (de) Einheitliches management von netzressourcen für gleichzeitige teilnahme mehrerer nutzer an einer sitzung
DE69832057T2 (de) Datendienst in einem mobilen kommunikationsnetz
DE60028561T2 (de) Bereitstellung von kundendiensten, die daten aus datenquellen abrufen, wobei die datenquellen die vom kunden geforderten formate nicht notwendigerweise unterstützen
DE69935443T2 (de) Verfahren und Vorrichtung zum Schieben von Information von einem Wirtrechnersystem zu einem mobilen Datenkommunikationsgerät
DE60317917T2 (de) Verfahren und vorrichtung zum weiterleiten von sitzungsinformationen von einem portal-server
DE69838262T2 (de) Allgemeine benutzer-authentifizierung für netz-rechner
DE10003907B4 (de) Verfahren, Vorrichtung und Datenverarbeitungsprogramm für die Anwendung beim Zugriff auf Hypertext-Dokumente
DE69733802T2 (de) Datendienst in einem mobilen kommunikationsnetz
DE60112436T2 (de) Online-verzeichnisauskunftssystem
DE60008555T2 (de) Verfahren und vorrichtung zur effizienten übertragung von daten einer interaktiven anwendung zwischen klienten und server mit hilfe einer markup-sprache
DE60020518T2 (de) Verwaltung von Benutzerprofilen
DE60302627T2 (de) Verfahren und System zur Durchführung von augenblicklichem Nachrichtenverkehr
US20040113938A1 (en) An arrangement and a method for presentation customization in a portal structure
US20050183061A1 (en) Arrangement and a method relating to access of applications/services
DE10311074A1 (de) Verfahren und Anordnungen in einem Telekommunikationsnetz
WO1999055050A1 (de) Datenverbreitungssystem und datenverbreitungsverfahren
DE60003278T2 (de) Hierarchische Auflösung von Adressen in einem Datennetzwerk

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee