DE60218069T2

DE60218069T2 - Bereitstellung von gekoppelten diensten in einer verteilten rechnerumgebung

Info

Publication number: DE60218069T2
Application number: DE60218069T
Authority: DE
Inventors: James Apex FLETCHER; David Raleigh LINDQUIST; Michael Durham WANDERSKI; Ajamu Raleigh WESLEY
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-01-15
Filing date: 2002-12-11
Publication date: 2007-08-09
Anticipated expiration: 2022-12-12
Also published as: ES2278066T3; US7603469B2; WO2003060710A2; IL162438A0; AU2002347391A8; US20030135628A1; AU2002347391A1; WO2003060710A3; JP2005515540A; JP4594621B2; CN1608248A; KR100600959B1; EP1483671A2; CN1291318C; EP1483671B1; ATE353453T1; KR20040068106A; DE60218069D1

Description

HINTERGRUND DER ERFINDUNG
Zugrunde liegende Erfindungen
Die vorliegende Erfindung betrifft die US-Patentanmeldung RSW920010189 (US-A-2003/055 868, Seriennummer 09/955 788) mit dem Titel „Building Distributed Software Services as Aggregations of Other Services"; die US-Patentanmeldung RSW920010190 (US-A-2003/055 878, Seriennummer 09/956 268) mit dem Titel „Programmatic Management of Software Resources in a Content Framework Environment"; und die US-Patentanmeldung RSW920010144 (US-A-2003/055 624, Seriennummer 09/956 276) mit dem Titel „Dynamic, Real-Time Integration of Software Resources through Services of a Content Framework", die sämtlich an International Business Machines Corporation abgetreten und am 19. September 2001 eingereicht worden sind. Diese US-Patentanmeldungen werden hier als die „verwandten Erfindungen" bezeichnet.
GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft Computersoftware und behandelt vor allem Verfahren zur Bereitstellung gekoppelter Dienste in einer verteilten Rechnerumgebung.
BESCHREIBUNG DER ZUGRUNDE LIEGENDEN TECHNIK
Vor allem aufgrund der zunehmenden Nutzung des öffentlichen Internet und dessen als „World Wide Web" (oder einfach „Web") bekannten Teilbereichs durch Geschäftsleute und Privatpersonen haben verteilte Computernetze und die Datenverarbeitung in Netzen in den letzten Jahren große Beliebtheit erlangt. Auch andere Arten verteilter Computernetze wie beispielsweise interne (Intranet) und von außen zugängliche (Extranet) Unternehmensnetze werden immer beliebter. Indem sich Lösungsanbieter immer mehr auf die Bereitstellung verbesserter webgestützter Datenverarbeitungsleistungen konzentrieren, können viele der entwickelten Lösungen auf andere verteilte Datenverarbeitungsumgebungen angepasst werden. Somit dienen die Bezugnahmen auf das Internet und das Web lediglich zur Veranschaulichung und sind nicht als Einschränkung zu verstehen.
Ein Bereich, in dem die verteilte Datenverarbeitung Fortschritte macht, ist die so genannte Internetdienstinitiative („web services" initiative). Diese Initiative wird allgemein auch als „dienstorientierte Architektur" für verteilte Datenverarbeitung bezeichnet. Internetdienste stellen eine sich schnell entwickelnde Technologie für die Integration verteilter Anwendungen im Internet dar. Ein „Internetdienst" ist allgemein eine Schnittstelle, die einen Satz über das Netz verfügbarer Operationen beschreibt. Internetdienste führen eine bestimmte Aufgabe oder einen Satz Aufgaben aus. Sie können mit einem oder mehreren anderen Internetdiensten kooperieren, um ihren Anteil zum Arbeitsablauf oder einer geschäftlichen Transaktion beizusteuern. Zum Beispiel kann die Bearbeitung der Transaktion einer komplexen Bestellung eine automatisierte Zusammenarbeit zwischen einem Bestelldienst (d.h. der Bestellsoftware) beim bestellenden Unternehmen und einem Bestellungsbearbeitungsdienst bei einem oder mehreren Geschäftspartnern erfordern.
Viele Fachleute aus der Industrie sind der Meinung, dass die dienstorientierte Internetdienstinitiative die nächste Umwälzung des Internets darstellen wird. Durch Internetdienste wird für kooperierende Programme der Zugriff auf Software in verteilten Netzen ohne menschliches Eingreifen in großem Umfang verfügbar.
Internetdienste sind im Allgemeinen nach einem Modell aufgebaut, bei dem ein Unternehmen, das Dienste über das Netz anbietet, diese Dienste in einer über das Netz erreichbaren Registrierungsdatenbank bekannt macht, und andere Unternehmen, die solche Dienste benötigen, die Registrierungsdatenbank abfragen können, um die Verfügbarkeit der Dienste in Erfahrung zu bringen. Die Teilnehmer an diesem Datenverarbeitungsmodell werden im Allgemeinen als (1) Dienstanbieter (Service Provider), (2) Dienstanforderer (Service Requester) und (3) Dienstvermittler (Service Broker) bezeichnet. Diese Teilnehmer und die grundlegenden Arbeitsschritte beim Austauschen von Nachrichten zwischen den Teilnehmern sind in 1 dargestellt. Die Dienstanbieter 100 stellen diejenigen Einheiten dar, die Dienste bereithalten, und die Registrierungsdatenbank, in der diese Dienste veröffentlicht 110 werden, wird durch einen Dienstvermittler 120 verwaltet. Die Dienstanforderer 150 sind Einheiten, welche Dienste benötigen und die Registrierungsdatenbank des Dienstvermittlers abfragen 140. Wenn in der Registrierungsdatenbank ein gewünschter Dienst gefunden wurde, stellt der Dienstanforderer eine Verbindung zu ermittelten Dienstanbieter her 130, um den Dienst zu nutzen. Diese Arbeitsschritte erfolgen nach einem Programm ohne menschliches Eingreifen, sodass ein Dienstanforderer nach einem bestimmten Dienst suchen und diesen Dienst dynamisch, d.h. während der Laufzeit, nutzen kann. Das Modell der Internetdienste ist theoretisch für jede Art Datenverarbeitungsanwendung verfügbar. Die gegenwärtig über Registrierungsdatenbanken verfügbaren Internetdienste sind jedoch auf relativ einfache Programme wie beispielsweise Demoprogramme „Hello, World!", Programme, die für eine bestimmte Postleitzahl die aktuelle Temperatur angeben, Programme zur Ausführung von Währungsumrechnungen usw. beschränkt.
Zu den grundlegenden Standards, mit denen die Internetdienste arbeiten, gehören HTTP (Hypertext Transfer Protocol, Übertragungsprotokoll für Hypertext), SOAP (Simple Object Access Protocol, einfaches Zugangsprotokoll für Objekte) und/oder XML-Protokoll (Extensible Markup Language, erweiterte Auszeichnungssprache), WSDL (Web Services Description Language, Beschreibungssprache für Internetdienste) und UDDI (Universal Description, Discovery, and Integration; universelle Beschreibung, Erkennung und Integration). Das HTTP wird allgemein zum Austauschen von Nachrichten über TCP/IP-Netze (Transmission Control Protocol/Internet Protocol, Protokoll für die Übertragungskontrolle/Internetprotokoll) wie das Internet verwendet. Das SOAP ist ein auf XML beruhendes Protokoll für das Senden von Nachrichten zum Aufrufen von Verfahren in einer verteilten Umgebung. Das XML-Protokoll ist eine neuere Beschreibung des WWW-Konsortiums (W3C) für ein Übertragungsprotokoll der Anwendungsschicht, das die Übertragung von Nachrichten zwischen Anwendungen ermöglicht und mit dem SOAP verschmelzen kann. WSDL ist ein XML-Format zur Beschreibung verteilter Netzdienste. UDDI ist ein Registrierungsverfahren auf der Grundlage von XML, mit dessen Hilfe Unternehmen ihre Dienste auflisten und mit dessen Hilfe Dienstanforderer Unternehmen finden können, die bestimmte Dienste anbieten. (Nähere Informationen zu SOAP sind in „Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000" zu finden, das im Internet unter http://www.w3.org/TR/2000/NOTE-SOAP-20000508 erhältlich ist. Nähere Informationen zum XML-Protokoll und der Schaffung eines XML-Protokollstandards sind unter http://www.w3.org/2000/xp zu finden. Die Beschreibung der WSDL mit dem Titel (Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001) ist im Internet unter http://www.w3.org/TR/2001/NOTE-wsdl-20010315 zu finden. Nähere Informationen zu UDDI sind in der UDDI-Beschreibung mit dem Titel „UDDI Version 2.0 API Specification, UDDI Open Draft Specification 8 June 2001" zu finden, die im Internet unter http://www.uddi.org/specification.html erhältlich ist. Die HTTP wird in „Request For Comments" („RFC") der Internet Engineering Task Force unter dem Titel „Hypertext Transfer Protocol -- HTTP/1.1" beschrieben.
Die Integration von Anwendungen unter Anwendung dieser offenen Standards erfordert mehrere Schritte. Es muss die Schnittstelle zu einem Internetdienst beschrieben werden, die den Namen der Verfahren zum Aufrufen des Dienstes, die Eingabe- und Ausgabeparameter des Verfahrens und dessen Datentypen usw. beinhaltet. Diese Informationen werden durch WSDL-Dokumente bereitgestellt und unter Verwendung einer UDDI-Bekanntmachungsoperation an eine Registrierungsdatenbank gesendet, die gemäß der UDDI-Beschreibung aufgebaut ist. Sobald der Dienst in der UDDI-Registrierungsdatenbank registriert ist, können Dienstanforderer UDDI-Suchanfragen ausgeben, um verteilte Dienste ausfindig zu machen. Dann gibt ein Dienstanforderer, der auf diese Weise einen Dienst gefunden hat, eine UDDI-Verknüpfungsanforderung aus, die den Anforderer unter Verwendung der Dienstinformation aus dem WSDL-Dokument dynamisch mit dem gefundenen Dienst verknüpft. (Diese UDDI-Operationen sind in 1 als Prinzipdarstellung gezeigt.) Zur Übertragung der WSDL-Dokumente und der UDDI-Anforderungen werden im Allgemeinen SOAP/XML-Protokoll- und HTTP-Nachrichten verwendet. (Im Folgenden sind Bezüge auf SOAP so zu verstehen, dass sie gleichwertig und semantisch ähnliche Aspekte des XML-Protokolls bedeuten. Darüber hinaus wird darauf hingewiesen, dass Bezüge auf „HTTP" im allgemeingültigen Sinne HTTP-ähnliche Funktionen bedeuten sollen. Einige UDDI-Operationen beispielsweise erfordern HTTPS anstelle von HTTP, wobei HTTPS eine HTTP-Version mit erhöhter Sicherheit ist. Diese Unterschiede sind für die vorliegende Erfindung jedoch ohne Belang, sodass im Folgenden bei der Erörterung des HTTP kein Unterschied gemacht wird.)
Das Ziel von Internetdiensten besteht darin, Dienstanforderern einen transparenten Zugriff auf Programmkomponenten zu ermöglichen, die sich an einem oder mehreren fernen Standorten befinden können, selbst wenn diese Komponenten auf verschiedenen Betriebssystemen laufen und in anderen Programmiersprachen als denen des Anforderers geschrieben sind. Obwohl bereits umfangreiche Arbeit zum Definieren der Ziele, der Architektur und der Standards geleistet worden ist, auf die sich die Internetdienste stützen, bleibt noch viel zu tun, damit die Internetdienste wirksam und leistungsfähig arbeiten können.
Insbesondere ist zu berücksichtigen, dass sich Benutzer bei vielen Anwendungsdiensten, die auf herkömmliche Weise bereitgestellt werden, vor deren Nutzung einer Identitätsprüfung und einer Berechtigungsprüfung unterziehen müssen. Unter der Identitätsprüfung ist hier die Ermittlung der Tatsache zu verstehen, dass der Benutzer wirklich derjenige ist, für den er sich ausgibt, während unter der Berechtigungsprüfung normalerweise zu verstehen ist, mit welchen Zugriffsrechten dieser Benutzer ausgestattet ist oder ob dieser Benutzer auf einen bestimmten Dienst oder dessen Funktion zugreifen darf. D. Ferguson beschreibt in „Technical and Product Architecture and Roadmap", IBM Web Services, [Online] Mai 2001 (2001-05), S. 1 bis 42, XP002272181 ein solches Verfahren. Es ist beabsichtigt, dass in der Umgebung von Internetdiensten ein Dienstanbieter dynamisch ausfindig gemacht werden kann, um einen bestimmten Dienst auszuführen. Wenn mehrere Dienstanbieter zur Verfügung stehen, kann aus diesen Dienstanbietern anhand Kriterien wie beispielsweise des Preises für die Nutzung des Dienstes dieses Anbieters, der garantierten Antwortzeit dieses Anbieters usw. ein bestimmter Dienstanbieter ausgewählt werden. Jeder Dienstanbieter kann für die Identitäts- und Berechtigungsprüfungsinformationen unterschiedliche Formate sowie eigene Verfahren für den Zugriff auf die Identitäts- und Berechtigungsprüfungsfunktionen verwenden. Den Erfindern sind bislang keine Verfahren zum Zusammenschließen oder Koppeln unterschiedlicher Identitätssysteme in der Umgebung von Internetdiensten bekannt, die die Nutzung von miteinander verbundenen Internetdiensten deutlich befördern würden.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung ist in den anhängenden Ansprüchen definiert und stellt Verfahren, Systeme und Computerprogrammprodukte für miteinander verbundene Dienste in einem Datenverarbeitungsnetz bereit. Bei bevorzugten Ausführungsarten bieten eine oder mehrere Softwareressourcen einen gekoppelten Dienst, wobei dieses Verfahren folgende Schritte umfasst: Definieren einer Bereitstellungsschnittstelle des gekoppelten Dienstes; Beschreiben der Bereitstellungsschnittstelle in einem Dienstbeschreibungsdokument; Empfangen von Berechtigungsnachweisen eines Benutzers des gekoppelten Dienstes gemäß dem Dienstbeschreibungsdokument; Analysieren der empfangenen Berechtigungsnachweise; und Erteilen der Erlaubnis für den Benutzer, den gekoppelten Dienst zu nutzen, wenn dies durch die Analyse angezeigt wird.
Das Verfahren kann ferner das Definieren einer Bereitstellungsschnittstelle mindestens einer der einen oder mehreren Softwareressourcen des gekoppelten Dienstes oder jeder der mindestens einen Softwareressourcen umfassen, indem die Bereitstellungsschnittstelle eines durch die Softwareressource ausgeführten Dienstes im Dienstbeschreibungsdokument oder in einem oder mehreren anderen Dienstbeschreibungsdokumenten beschrieben wird. In diesem Fall können Berechtigungsnachweise des Benutzers gemäß dem Dienstbeschreibungsdokument oder gemäß dem einen oder den mehreren anderen Dienstbeschreibungsdokumenten nicht nur für den gekoppelten Dienst, sondern auch für die mindestens eine Softwareressource empfangen werden. Dann kann dem Benutzer vorzugsweise die Nutzung ausgewählter durch die Bereitstellungsschnittstelle der mindestens einen Softwareressource angebotener, Dienste erlaubt werden, wenn dies wiederum durch die Analyse dieser Berechtigungsnachweise angezeigt wird.
Bei bevorzugten Ausführungsarten umfasst die Analyse die (1) Identitätsprüfung und/oder (2) die Berechtigungsprüfung der Berechtigungsnachweise.
Somit können Identitätsinformationen durch Programme zwischen verteilten Diensten übertragen werden, die durch Softwareressourcen des gekoppelten Dienstes ausgeführt werden. Vorzugsweise umfasst das Übertragen durch Programme das Senden einer Nachricht, die in den Kopfdaten der Nachricht den Berechtigungsnachweis und in einem Hauptteil der Nachricht eine Dienstanforderung umfasst. Die Nachricht kann zum Beispiel eine SOAP-Nachricht (Simple Object Access Protocol, einfaches Zugangsprotokoll für Objekte) sein.
Die Markierungssprache wird vorzugsweise zum Beschreiben der Dienstbeschreibungsdokumente genutzt. Als Markierungssprache dient vorzugsweise die Beschreibungssprache für Internetdienste (Web Services Description Language, WSDL).
Das Verfahren kann ferner das Registrieren des Dienstbeschreibungsdokuments in einer Registrierungsdatenbank umfassen, bei der es sich um eine über das Netz erreichbare Registrierungsdatenbank handeln kann, auf die unter Verwendung standardisierter Nachrichten zugegriffen wird.
Im Folgenden werden bevorzugte Ausführungsarten lediglich beispielhaft unter Bezug auf die folgenden Zeichnungen beschrieben, wobei gleiche Bezugsnummern grundsätzlich dieselben Elemente bezeichnen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein Schaubild, das die beteiligten Parteien und die Grundoperationen eines dienstorientierten Architektur nach dem Stand der Technik veranschaulicht;
2 ist ein Blockschaubild, das ein Portlet gemäß den bevorzugten Ausführungsarten der verwandten Erfindungen veranschaulicht, das als Internetdienst-Proxy aufgebaut ist;
3A und 3B veranschaulichen den Inhalt von WSDL-Dokumenten, die eine Verteilerschnittstelle bzw. eine Systemschnittstelle gemäß bevorzugten Ausführungsarten der verwandten Erfindungen beschreiben;
4 veranschaulicht das Stapelmodell für Internetdienste zur Koppelung von Diensten gemäß der Beschreibung der verwandten Erfindungen;
5A bis 5E veranschaulichen als Beispiel einen Ausschnitt aus einem WSDL-Dokument gemäß bevorzugten Ausführungsarten der vorliegenden Erfindung, das eine Bereitstellungsschnittstelle eines Dienstes beschreibt;
6 zeigt ein Ablaufschaubild, das zur Ausführung bevorzugter Ausführungsarten der vorliegenden Erfindung verwendet werden kann; und
7A und 7B zeigen ein Beispiel einer SOAP-Nachricht nach dem Stand der Technik, die in ihren Kopfdaten eine digitale Signatur enthält.
BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSARTEN
Das Versprechen von Internetdiensten lautet, dass verteilte Anwendungen wie nie zuvor zusammenarbeiten können, indem sie durch die Offenheit und Konzentration von Unternehmenssystemen eine neue Generation nahtlos hochintegrierter Anwendungen bieten. Internetdienste stellen verteilte Softwareressourcen breiteren Kreisen zur Verfügung, sodass Software nun als Dienstleistung vermarktet werden kann. Dienste von einem oder mehreren Dienstanbietern werden dynamisch miteinander gekoppelt, um Benutzern die zum Ausführen einer Aufgabe oder eines Dienstes, der jedem betreffenden Benutzer gerade von Interesse ist, benötigte Funktionalität zu bieten. Zur wirksamen Nutzung dieser dynamisch integrierten Dienste muss es möglich sein, die von ihnen verwendeten heterogenen Identitätssysteme automatisch und dynamisch miteinander zu verknüpfen. Dies muss während der Laufzeit erfolgen können, damit (menschliche oder programmgesteuerte) Benutzer nahtlos auf Identität und Zugangsberechtigung für die Nutzung der Dienste geprüft oder „identifiziert" werden können. Darüber hinaus ist es wünschenswert, diese nahtlose Identitätsprüfung mit einmaliger Anmeldung durchzuführen, da mehrfache Identitätsprüfung während der Ausführung eines bestimmten Dienstes (einschließlich Diensten, die aus mehreren Teildiensten bestehen) zur Verärgerung führt und zeitaufwändig und unproduktiv ist. Die vorliegende Erfindung stellt gemäß der Beschreibung für diese Anforderungen eine Lösung bereit und verbessert die Leistungsfähigkeit einer Anzahl Verfahren nach dem offenen Industriestandard.
Vor der Erörterung der Einzelheiten der Ausführungsarten ist ein Blick auf Hintergrundinformationen hilfreich, darunter auf die Technologien, auf denen bevorzugte Ausführungsarten der Erfindung aufbauen. In den verwandten Erfindungen werden Verfahren zur Verwaltung von Internetdiensten und zum Bereitstellen eines Verknüpfungspunktes definiert, an dem Dienste zu neuen Diensten miteinander gekoppelt werden können, die dann verteilt werden können. Bevorzugte Ausführungsarten der verwandten Erfindungen bauen auf einem Inhaltssystem wie beispielsweise einer Portalplattform auf, da ein solches System viele integrierte Dienste für die Verwaltung von Inhalten und die Speicherung von Diensten bietet wie beispielsweise Nachhaltigkeit, Personalisierung und Codeumsetzung. Die in den verwandten Erfindungen beschriebenen Verfahren erweitern die Plattformen, um die Kopplung, Verteilung und Verwaltung von Internetdiensten zu ermöglichen. Es wurde ein Verknüpfungstool mit Modellcharakter beschrieben, das zum Definieren eines gekoppelten Dienstes verwendet werden kann; dann können Softwareressourcen gemäß dieser Definition für gekoppelte Dienste programmgesteuert integriert werden. Darüber hinaus können die gekoppelten Dienste automatisch verwaltet werden.
Die vorliegende Erfindung definiert Verfahren zum Bereitstellen der gekoppelten Dienste, die sieh aus der Anwendung der verwandten Erfindungen ergeben. Diese Verfahren können auch an gekoppelte Dienste angepasst werden, die anderweitig erzeugt werden, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen. Darüber hinaus ist anzumerken, dass in der vorliegenden Erörterung zwar von der Bereitstellung „gekoppelter" Dienste die Rede ist, aber ein gekoppelter Dienst wiederum ein (aus Teildiensten bestehender) Internetdienst ist und die vorliegende Erfindung deshalb vorteilhaft in Verbindung mit solchen Internetdiensten angewendet werden kann, die als elementare Dienste anzusehen sind (und deshalb einen Spezialfall von Kopplung darstellen, bei der der Satz gekoppelter „Teildienste" aus nur einem Element besteht).
Eine handelsübliche Portalplattform, auf welcher Ausführungsarten der vorliegenden Erfindung (wie auch der verwandten Erfindungen) aufgebaut werden können, ist der WebSphere^® Portal Server („WPS") von der International Business Machines Corporation („IBM"). („WebSphere" ist ein eingetragenes Warenzeichen von IBM.) Zu beachten ist jedoch, dass bei der Erörterung der verwandten Erfindungen und der vorliegenden Erfindung von einer Portalplattform die Rede ist, aber die erfindungsgemäßen Konzepte auf andere Arten von Inhaltssysteme angewendet werden können, die eine analoge Funktionalität bieten und auch auf andere Portale als WPS angewendet werden können, sodass die Nennung von Portalen und ihrer Portlet-Ausführung lediglich zur Veranschaulichung dient und nicht als Einschränkung aufzufassen ist.
Die dynamische Integration von Internetdiensten während der Laufzeit, die durch die verwandten Erfindungen ermöglicht wird, kann ein Verknüpfungs-Tool für die Kopplung neuer Internetdienste verwenden. Unter Verwendung dieses Verknüpfungs-Tool kann ein Systemadministrator (oder entsprechend ein Dienstentwickler oder eine andere Person) einen neuen Dienst definieren, der sich aus differenzierten Diensten zusammensetzt. Die differenzierten Dienste, aus denen sich andere Dienste zusammensetzen können, können lokal oder auf fernen Rechnern untergebracht sein, und die Verfahren der verwandten Erfindungen ermöglichen das Aufrufen und Nutzen dieser Dienste auf transparente weise unabhängig davon, ob sie lokal oder auf fernen Rechnern untergebracht sind. Die differenzierten Dienste können eine beliebige Form von Programmlogik einschließlich Scriptprogrammen, JavaTM-Klassen, Computer-Klassen, EJBs („Enterprise JavaBeans"^TM), gespeicherte Prozeduren, IMS oder andere Datenbanktransaktionen, herkömmliche Anwendungen usw. enthalten. („Java" und „Enterprise JavaBeans" sind Warenzeichen von Sun Microsystems, Inc.) Die auf diese Weise erzeugten Internetdienste können dann durch die Portalplattform automatisch verwaltet und auch zum rekursiven Erzeugen neuer Internetdienste verwendet werden, was in den verwandten Erfindungen beschrieben wird.
Die verwandten Erfindungen werten die Portlets zur Portalschnittstelle auf und bauen, auch auf dem Konzept einer fernen Portlet-Schnittstelle auf (wo diese Konzept auf programmgesteuerte Portlets erweitert wird), um den Zugriff auf Softwareressourcen zu ermöglichen. Auf diese Weise funktionierende Portlets können als „Internetdienstvermittler" oder als „Internetdienst-Proxys" bezeichnet werden. Das heißt, durch die verwandten Erfindungen wird ein Portlet in die Lage versetzt, als Vermittler zwischen einer Anwendung oder Softwareressource zu agieren, die einen bestimmten Dienst und eine diesen Dienst leistende Softwareressource anfordert. Die Softwareressource, die eine bestimmte Funktion ausführt, kann statisch mit einem Internetdienst-Proxy (zum Beispiel während der Entwicklung) oder mit einer Softwareressource gekoppelt sein, die dynamisch ausgewählt wird (zum Beispiel anhand von Kriterien, die während der Laufzeit geprüft werden). In beiden Fällen empfängt der Portlet-Proxy Anforderungsnachrichten und leitet sie an die Softwareressource weiter, mit der er verbunden ist; sobald die Softwareressource die angeforderte Funktion ausgeführt hat, sendet sie ihre Antwort an den Portlet-Proxy zurück, der diese wiederum an den Anforderer weiterleitet.
Anzumerken ist, dass die zum Ausführen eines gekoppelten Dienstes aufgerufenen Softwareressourcen für ein Zusammenwirken zwischen Programmen ausgelegt, alternativ aber ihrem Wesen nach auch visuell gestaltet sein können. Zum Beispiel können visuell gestaltete Ressourcen während der Ausführung eines Internetdienstes aufgerufen werden, der in erster Linie nur zwischen Programmen ausgeführt wird. Der hier gebrauchte Begriff „programmgesteuertes Portlet" bezeichnet im Allgemeinen Portlet-Proxys gemäß den verwandten Erfindungen und der vorliegenden Erfindung unabhängig davon, ob die zugrunde liegenden Softwareressourcen einen Code für visuelle Darstellung beinhalten.
2 zeigt ein Blockschaubild, das ein als Internetdienst-Proxy aufgebautes Portlet gemäß den verwandten Erfindungen veranschaulicht. Dabei beinhaltet der Portlet-Proxy 240 eine Verteilungsschnittstelle 210, eine Systemschnittstelle 220 und eine Funktionsschnittstelle 230. Der Portlet-Proxy tauscht über diese Schnittstellen Daten mit einer Portalplattform 200 aus und dient als Vermittler zwischen der Portalplattform und der Softwareressource 250, welche die gewünschte Funktion ausführt. Die Einzelheiten jeder Funktionsschnittstelle richten sich nach dem durch die Softwareressource 250 bereitgestellten Internetdienst und sind nicht Bestandteil der verwandten Erfindungen. Die verwandten Erfindungen stellen jedoch die Funktionsschnittstelle der Softwareressource 250 als Schnittstelle 230 des Portlet-Proxys zur Verfügung. (Die Nutzbarmachung der Funktionsschnittstelle unter Verwendung von WSDL-Definitionen und SOAP-Diensten kann mit Hilfe eines handelsüblichen Tools wie des IBM Web Services Toolkit („WSTK") während des Verteilungsprozesses erfolgen, was in den verwandten Erfindungen erörtert wurde.)
Die Verteilungsschnittstelle und die Systemschnittstelle werden in den verwandten Erfindungen detailliert beschrieben. Im Folgenden wird ein kurzer Überblick gegeben. Gemäß den bevorzugten Ausführungsart der verwandten Erfindungen sind eine Verteilungsschnittstelle und eine Systemschnittstelle für jedes Portlet definiert, das als Internetdienst-Proxy dient (obwohl bei alternativen Ausführungsarten nicht alle diese Schnittstellen genutzt werden müssen). Diese neuen Schnittstellen können auch als Verteilungsanschlusstyp deployment Port type) bzw. als Systemanschlusstyp (system Port type) bezeichnet werden. Ein Portlet gemäß den verwandten Erfindungen definiert somit einen Dienstanbietertyp, der die zur Integration der Softwareressourcen und zur Dienstzusammenarbeit und -verwaltung erforderlichen Anschlusstypen beinhaltet. („Anschlusstypen" ist ein in der Technik verwendeter Begriff zur Beschreibung der Funktionen eines Portlet und „Dienstanbietertyp" ist ein Begriff zur Bezeichnung einer Gruppe von Anschlusstypen.)
Die Verteilungsschnittstelle versetzt einen Portlet-Proxy (das heißt, einen gekoppelten Internetdienst, der durch einen Portlet-Proxy dargestellt wird), in die Lage, gemäß den verwandten Erfindungen rekursiv bei aufeinander folgenden Verknüpfungsoperationen des Internetdienstes verwendet zu werden. Die Verteilungsschnittstelle eines Portlet „A" liefert zum Beispiel während der Verknüpfung mit anderen Portlets zur Bildung eines neuen Internetdienstes „Z" Informationen über das Portlet A. Indem eine Verteilungsschnittstelle gemäß den verwandten Schnittstellen für den Internetdienst Z definiert wird, können anschließend Informationen über den Internetdienst Z bereitgestellt werden, während der Dienst Z zum Verknüpfen neuer Dienste verwendet wird.
Die Systemschnittstelle wird zur Laufzeitverwaltung von Portlets (das heißt, von durch Portlet-Proxys dargestellten Internetdiensten) durch die Portalplattform verwendet. Durch die Verwendung der Systemschnittstelle kann die Portalplattform Funktionen wie das Protokollieren von Ereignissen, Gebührenabrechnung und andere Arten administrativer Vorgänge ausführen, die mit der Ausführung von Internetdiensten verbunden sind. Zu diesem Zweck wird zwischen der Portalplattform und dem Portlet-Proxy eine Zweiwegekommunikation durchgeführt.
3A und 3B zeigen einfache WSDL-Dokumente, die die Beschreibung der Verteilungssoftware bzw. der Systemschnittstelle veranschaulichen. Gemäß bevorzugten Ausführungsarten der verwandten Erfindungen werden die Verteilungs- und Systemanschlusstypen in Form von WSDL-Dokumenten dargestellt, die dann in der Registrierungsdatenbank registriert werden können. In Element 310 des WSDL-Dokuments 300 in 3A heißt die beispielhafte Verteilungsschnittstelle „Deployment" und beinhaltet Arbeitsschritte (Operationen) wie „getDisplayName" und „getDisplayIcon16x16" (siehe Abschnitt 330). Diese Arbeitsschritte können zum Beispiel zum Abrufen eines Namens zur Beschreibung des Internetdienstes und zum Abrufen einer Grafik für die Darstellung des Internetdienstes in einer Menüleiste eines Verknüpfungstools für den Internetdienst verwendet werden. Gemäß der WSDL-Beschreibung werden die zur Datenübertragung mit einem Dienst dienenden Eingabe- und Ausgabenachrichten im Abschnitt „<message>"-Elemente 320 benannt, wo die durch diese Nachrichten verwendeten Parameter als „<parts>"-Elemente definiert sind. Somit ist ein Nachrichtenelement für jede Nachricht jedes Arbeitsschrittes definiert, der für diesen Anschlusstyp beschrieben ist. (Nähere Informationen zu den Einzelheiten eines WSDL-Dokuments siehe WSDL-Beschreibung.)
Das WSDL-Dokument 350 in 3B definiert die Systemschnittstelle, die im Beispiel als „System" bezeichnet wird (siehe Element 360). In diesem Beispiel wird der komplexe Datentyp mit der Bezeichnung „Event" definiert (siehe Element 370), der zwei Zeichenfolgeparameter und einen Datenparameter umfasst. Dieser Datentyp kann zum Beispiel verwendet werden, wenn Protokolldaten ausgetauscht werden, die in einer Prüfprotokolldatei aufgezeichnet werden sollen. Desgleichen wird ein Arbeitsschritt „logEvent" definiert (siehe Element 390), wobei in diesem Beispiel eine Einwegeoperation unter Verwendung einer Nachricht „logEventReceive" (siehe Element 380) aufgerufen wird, die einen Parameter vom Typ Event aufweist. Außerdem definiert das Beispiel einen Arbeitsschritt „reportUsage", die zwei Nachrichten „reportInput" und „reportOutput" aufweist.
Bevorzugte Ausführungsarten der vorliegenden Erfindung können die Verteilungsschnittstelle erweitern, damit sie die Bereitstellungsinformationen über den gekoppelten Internetdienst beinhaltet. Alternativ kann zu diesem Zweck eine separate Bereitstellungsschnittstelle definiert werden, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen. Eine Beschreibung 500 der Bereitstellungsschnittstelle für die Probe ist in den 5A bis 5E dargestellt. Durch die Darstellung des Bereitstellungsanschlusstyps oder der Bereitstellungsschnittstelle in Form eines WSDL-Dokuments gemäß der vorliegenden Beschreibung können die Bereitstellungsinformationen für einen Internetdienst dann programmgesteuert in einer Registrierungsdatenbank registriert und Informationen über die Bereitstellungsschnittstelle programmgesteuert während der Laufzeit gefunden und verknüpft werden.
Wenn die Bereitstellungsschnittstelle als Erweiterung der Verteilungsschnittstelle ausgeführt wird, beschreibt die Schnittstellenbeschreibung für einen bestimmten Internetdienst vorzugsweise seine Arbeitsschritte in einem Bereitstellungselement portType innerhalb einer Definition der Verteilungsschnittstelle. Zum Beispiel kann die Beschreibung 300 der Verteilungsschnittstelle in 3A so erweitert werden, dass sie ein Verteilungselement portType beinhaltet. Die in den 5A bis 5E dargestellten Nachrichtenbeschreibungen der Probe können zu anderen Nachrichten hinzugefügt werden, die bei Verwendung dieses Ansatzes in einer Verteilungsbeschreibung definiert sind (siehe Element 320 von 3A), und ein anderes Element wie das in den 5A bis 5E dargestellte Element portType kann zusammen mit dem portType 330 für Verteilungsoperationen beschrieben werden. Alternativ kann für die Bereitstellung ein separates WSDL-Dokument erzeugt werden, wobei dieses separate Dokument sein eigenes Element <types>, sein eigenes Element <schema> usw. aufweist. Bei dieser Alternative kann sich das Element <definitions> des WSDL-Dokuments aus Bereitstellungsnachrichten und -operationen zusammensetzen, wie sie in der Schnittstellenbeschreibung der 5A bis 5E dargestellt sind.
Gemäß der WSDL-Beschreibung sind die für den Datenaustausch mit einem Internetdienst verwendeten Eingabe- und Ausgabenachrichten in den Elementen „<message>" beschrieben, in denen die von diesen Nachrichten verwendeten Parameter als „<part>"-Elemente definiert sind. Somit ist für jede Nachricht jeder für diesen Anschlusstyp definierten Operation ein Nachrichtenelement definiert. (Nähere Informationen zu den Einzelheiten eines WSDL-Dokuments siehe die WSDL-Beschreibung.)
Gemäß der Beschreibung in den verwandten Erfindungen wird zur Modellierung der Operationen zur Ausführung aus anderen Internetdiensten (d.h. Teildiensten) bestehender gekoppelter Internetdienste ein Steuerungsgraph verwendet.
Die Knoten des Graphen stellen ausgewählte Portlet-Operationen dar, während die Verbindungslinien zwischen den Knoten mögliche Übergänge von einem Betriebszustand oder Prozess des Dienstes zu einem anderen darstellen. Diese Verbindungslinien des Dienstes können mit einer oder mehreren Übergangsbedingungen und erforderlichenfalls mit Datenzuordnungsinformationen verknüpft werden. Die Bedingungen geben an, unter welchen Bedingungen der nächste verknüpfte Dienst aufgerufen werden soll. Oft werden diese Bedingungen anhand der Ergebnisse eines vorhergehenden Aufrufs eines Dienstes festgelegt. Unter Datenzuordnung ist zu verstehen, dass Operationen zwischen Portlet-Anschlusstypen verknüpft und Daten von einer Operation zur nächsten übertragen werden. Zum Beispiel können die Datenzuordnungsinformationen anzeigen, dass die Ausgabeparameter eines Dienstes den Eingabeparametern eines anderen Dienstes zugeordnet werden.
Vorzugsweise wie die Web Services Flow Language („WSFL) erweitert, um den Steuerungsgraphen zu unterstützen. Insbesondere können zu einem Stapel von Internetdiensten WSFL-Permanentspeicherverfahren und Laufzeitbewertungsverfahren unter Verwendung von Steuerungsgraphen hinzugefügt werden, damit sie gemäß den Graphen abgearbeitet werden, die durch eine Verknüpfungseinheit zur Verknüpfung von Diensten erzeugt wurden. Eine ausführliche Erörterung der WSFL ist in der WSFL-Beschreibung mit dem Titel „Web Services Flow Language (WSFL 1.0)" von Prof. Dr. Leymann (Mai 2001) zu finden, die über das Internet von IBM unter http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf erhältlich ist.
4 veranschaulicht den Ansatz der Stapelung von Internetdiensten für die Kopplung von Diensten, die in den verwandten Erfindungen beschrieben wird. Der Stapel 400 von Internetdiensten wird vorzugsweise durch den WSFL-Dienstablauf 410 zum Definieren und Ausführen gekoppelter Dienste unterstützt, während die Diensterkennung 420 und die Dienstveröffentlichung 430 vorzugsweise unter Verwendung von UDDI erfolgen. Der Stapel von Internetdiensten umfasst auch eine WSDL-Schicht 440, um Dokumente zur Dienstbeschreibung zu unterstützen. Zur Nachrichtenübertragung auf Grundlage von XML 450 kann SOAP verwendet werden. Zur Netzunterstützung 460 können Protokolle wie HTTP, FTP (File Transfer Protocol, Dateiübertragungsprotokoll), eMail, MQ (Message Queuing, Steuerung von Nachrichtenwarteschlangen usw. verwendet werden. Gemäß der Erörterung in den verwandten Erfindungen wird die WSDL verwendet, um Internetdienstanschlusstypen zu definieren und ferner zu definieren, wie Operationen dieser Anschlusstypen aufgerufen werden, während WSFL zur Koppelung der Internetdienste (und somit zur Koppelung ihrer Schnittstellen) verwendet wird. Während der Laufzeit werden Dienste innerhalb einer Registrierungsdatenbank unter Verwendung des UDDI-Diensterkennungsprozesses ermittelt und mit der Verwendung von Informationen aus ihren WSDL-Definitionen verknüpft. Dann verwendet die WSFL diese Definitionen (des Anschlusstyps) während der Laufzeit zur Koppelung der Dienste. (Da die Signaturen der Operationen normalerweise nicht mehr eins zu eins zusammenpassen, kann in einem Proxy-Modell ein in den WSFL-Beschreibungen definierter „Modulverbindungs"-Mechanismus (plug link) verwendet werden, um Schnittstellen gemäß der Beschreibung in den verwandten Erfindungen auf einfache Weise zuzuordnen und so eine Beziehung zwischen den Arbeitsschnittstellen herzustellen. Die verwandten Erfindungen beschreiben die Verwendung dieses Plug-Link-Mechanismus als unveränderliche Definition für die Integration von Portlet-Proxys für die Ausführung von Internetdiensten.)
Ein Entwickler, der den Quellcode für eine als Internetdienst zu verbreitende Softwareressource entwickelt, beschreibt das durch diesen Dienst bereitzustellende Identitätsprüfungs-, Berechtigungsprüfungs- und/oder Konfigurierungsverfahren. Die Dienste können dann gemäß der Beschreibung in den verwandten Erfindungen miteinander gekoppelt und die Verfahren der vorliegenden Erfindung zur Bereitstellung des gekoppelten Dienstes durchgeführt werden. Beispielsweise sei angenommen, dass der gekoppelte Dienst dafür ausgelegt ist, einem menschlichen Benutzer eMail-Dienste bereitzustellen. Ein Teildienst kann zum Einrichten eines eMail-Kontos für den Benutzer bereitgestellt werden. Üblicherweise müssen für diesen Teildienst zur Einrichtung des Kontos Informationen wie Vor- und Nachname des Benutzers, eine zu dieser Person gehörende eMail-Adresse, ein Passwort für den Zugriff dieser Person auf ihr eMail-Konto und möglicherweise Konfigurierungsinformationen eingegeben werden, zum Beispiel wie viel Speichervolumen für die eMail-Nachrichten dieses Benutzers reserviert werden soll. (Das gespeicherte Passwort kann dann zusammen mit der Benutzerkennung zur Überprüfung der Identität dieses Benutzers verwendet werden, wenn er unter Verwendung eines anderen Teildienstes des gekoppelten eMail-Dienstes auf seine eMail-Nachrichten zugreift.) Auch die Informationen über die Zugriffsrechte können durch eine Eingabe für den Teildienst zur Kontoeinrichtung bereitgestellt werden. Einem Benutzer, der gleichzeitig auch Systemadministrator ist, können zum Beispiel erweiterte Zugriffsrechte gewährt werden, damit er zum Beispiel das Speichervolumen für einen anderen Benutzer vergrößern, die E-Mail eines anderen Benutzers löschen kann usw. Dann können WSDL-Dokumente dafür verwendet werden, die durch jeden Teildienst bereitgestellten Arbeitsschritte und die Nachrichten und Parameter zu definieren, die zum Aufrufen dieser Arbeitsschritte dienen.
Gemäß der Erörterung in den verwandten Erfindungen kann das WSDL-Dokument durch einen menschlichen Benutzer oder programmgesteuert oder durch eine Kombination von beiden erstellt werden. (Zum Beispiel kann der menschliche Benutzer zum Eingeben Informationen wie des Anschlusstypnamens, der Speicherplätze des Namensbereichs usw. aufgefordert werden, während für die Veröffentlichungsverfahren einer Softwareressource die Elemente <operation> und <message> programmgesteuert erzeugt werden. WSTK von IBM ist ein Beispiel für ein handelsübliches Produkt, das zur programmgesteuerten Erzeugung der WSDL für eine bestimmte Softwareressource verwendet werden kann. Siehe auch „The Web services (r)evolution: Part 4, Web Services Description Language (WSDL)", G. Glass (Februar 2001), veröffentlicht von IBM im Internet unter http://www-106.ibm.com/developerworks/webservices/library/wspeer4, wo ein Beispiel für die programmgesteuerte Erzeugung eines WSDL-Dokuments für einen einfachen Wetterdienst mit den Funktionen „getTemp" und „setTemp" dargestellt wird.
Um eine Verbindung zwischen Identitätssystemen von dynamisch integrierten Diensten herzustellen, wird gemäß der vorliegenden Erfindung die Bereitstellungsschnittstelle jedes Dienstes unter Verwendung eines WSDL-Dokuments einer UDDI-Registrierungsdatenbank mitgeteilt. Dann kann die Bereitstellungsschnittstelle des gekoppelten Dienstes entweder durch manuelle oder programmgesteuerte Auswahl der Schnittstellen der Teildienste des gekoppelten Dienstes rekursiv erzeugt werden, und ein WSDL-Dokument für diese neue Bereitstellungsschnittstelle kann erzeugt und veröffentlicht werden.
Aufgrund des dynamischen Charakters sowohl der Ermittlung als auch des Aufrufens von verteilten Diensten lassen sich gemeinsame Identitätsprüfungs- und Berechtigungsprüfungsoperationen nur schwer ausführen. Die hier beschriebenen Verfahren beheben diese Schwierigkeit, indem sie die Bereitstellung eines gekoppelten Dienstes innerhalb des Arbeitsablaufs eines Internetdienstes ermöglichen, wobei die Arbeitsschritte unter Verwendung von WSDL-Dokumenten erkannt und unter Verwendung von SOAP-Nachrichten innerhalb einer Arbeitsablaufdefinition aufgerufen werden.
Gekoppelte Dienste können den Zugriff auf ihre angebotenen Funktionen auf diejenigen Benutzer beschränken, die über ausreichende Berechtigungsnachweise verfügen und diese Berechtigungsnachweise unter Verwendung einer angebotenen Berechtigungsprüfung erfolgreich vorlegen. Es kann auch von Vorteil sein, Benutzerprofile für das Angebot eines gekoppelten Dienstes zu erzeugen und wahlweise das Abfragen, Ändern und/oder Löschen dieser Benutzerprofile unter Verwendung entsprechender Funktionen des Dienstes zuzulassen.
Im Folgenden werden die in den 5A bis 5E dargestellten Nachrichten und Arbeitsschritte der Probe beschrieben und zur Veranschaulichung verwendet, wie die vorliegende Erfindung die Bereitstellung von gekoppelten Diensten in einer verteilten Rechnerumgebung bewerkstelligt. (Dem Fachmann ist klar, dass die in den 5A bis 5E dargestellten Nachrichten und Arbeitsschritte – sowie deren Parameter – nur der Veranschaulichung dienen. Eine reale Bereitstellungsschnittstelle kann andere Nachrichten und Arbeitsschritte enthalten, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen.)
Die Nachricht „InResolveProvisioningIDRequest" 502 veranschaulicht eine Nachricht zur Eingabeaufforderung, mit der ein Dienst abgefragt werden kann, welchen bestimmten Benutzer oder welche Einheit er als identifiziert betrachtet. (Wenn nicht anders angegeben, kann der Begriff „Benutzer" im vorliegenden Zusammenhang gleichermaßen als menschlicher Benutzer oder als programmgesteuerte Einheit wie beispielsweise ein automatischer Dienst verstanden werden.) In der Nachrichtenbeschreibung 502 wird festgestellt, dass die Anforderung als Parameter eine Zeichenfolge „authToken" verwendet. Zum Beispiel sei angenommen, dass sich ein menschlicher Benutzer bei einem gekoppelten Dienst angemeldet hat und der gekoppelte Dienst für diesen menschlichen Benutzer ein Identitätsprüfungs-Token „X" bereithält. Ferner sei angenommen, dass der gekoppelte Dienst programmgesteuert ermitteln möchte, inwieweit dieser menschliche Benutzer einem bestimmten Teildienst „ServiceABC" bekannt ist. Der gekoppelte Dienst muss nach einem Bereitstellungssystem suchen, das Informationen über den Benutzer enthält. Die Nachrichten 502 und 504 können zur Bereitstellung dieser Funktionalität verwendet werden, indem das Token „X" (vorzugsweise unter Verwendung einer SOAP-Nachricht, wie unter Bezug auf die 7A und 7B beschrieben wird) der Funktion „ResolveProvisioningID" von „ServiceABC" zugeleitet wird. 5D zeigt eine Funktion „ResolveProvisioningID" 552 mit einer Nachricht „InResolveProvisioningIDRequest" (siehe Element 502 von 5A) sowie einer Nachricht „OutResolveProvisioningIDResponse" (siehe Element 504 von 5A). Die Nachricht „OutResolveProvisioningIDResponse" 504 ist so definiert, dass sie einen Parameter mit der Bezeichnung „Identifier" (Kennung vom Typ Zeichenfolge) zurückgibt. Vorzugsweise ist die zurückgegebene Kennung eine Kennung des fernen Bereitstellungssystems. Diese Kennung kann dann als Eingabeparameter für nachfolgende Arbeitsschritte (siehe zum Beispiel die unten beschriebenen Nachrichten 506, 510 und 526) verwendet werden, um das Bereitstellungssystem zu bezeichnen, welches die Informationen zum Benutzerprofil oder die Konfigurierungsinformationen des Dienstes verwaltet.
Bevorzugte Ausführungsarten der vorliegenden Erfindung gemäß den 7a und 7B verwenden SOAP-Nachrichten für den Datenaustausch zwischen den Internetdiensten. Die beispielhafte SOAP-Nachricht 700 umfasst einen SOAP-Rahmen nach dem Stand der Technik mit einer digitalen Signatur in seinen Kopfdaten. 7A zeigt die Kopfdaten 710 und die digitale Signatur 720. Diese digitale Signatur kann zur Überprüfung der Identität des Anfordernden verwendet werden, der die Anforderung nach einem Dienst im SOAP-Textkörper übermittelt. 7B zeigt den Textkörper 730 und die Anforderung 740. Bei dieser Nachricht 700 der Probe gibt der Textkörper der Nachricht eine Nachricht „GetLastTradePrice" an, für welche das Kindelement <m:symbol> einen Wert „IBM" hat. Es kann angenommen werden, dass hierdurch ein Dienst für Aktienkurse aufgerufen wird und dieser Dienst die Anmeldung des Benutzer verlangt; deshalb ist die digitale Signatur des Benutzers in die SOAP-Kopfdaten eingefügt worden. (Weitere Informationen über diese Verwendung von SOAP-Nachrichten finden sich in dem Artikel „SOAP Security Extensions: Digital Signature, W3C NOTE, 6. Februar 2001", der im Internet unter http://www.w3.org/TR/SOAP-dsig/aufgerufen werden kann.
Die vorliegende(n) Ausführungsart(en) steigern die Wirksamkeit des Verfahrens mit digitalen Signaturen zum Übertragen von Identitätsinformationen für die Identitätsprüfung von Benutzern von gekoppelten Internetdiensten, zur Ermittlung der Berechtigung dieser Benutzer und/oder zum Konfigurieren gekoppelter Internetdienste.
Anknüpfend an die Erörterung der Nachrichten der Bereitstellungsschnittstelle der Probe in 5A veranschaulicht die Nachricht „InResolveUsersRequest" 506 eine eingegebene Anforderungsnachricht, die zum Ermitteln einer Reihe von Benutzern verwendet werden kann, die für den Zugriff auf einen bestimmten Dienst berechtigt sind. Bei diesem Beispiel wird dem abgefragten Dienst ein Identitätsprüfungs-Token zugeleitet, und diese Nachricht dient vorzugsweise zur Prüfung der Identität des die Information Anfordernden (das heißt, der programmgesteuerten Einheit oder des menschlichen Benutzers, der die für Benutzer mit geprüfter Identität bestimmte Information anfordert). Der Parameter „provID" kann zum Erstellen einer Adresse (zum Beispiel einer Einheitlichen Ressourcenkennung, URI) eines durch einen Dienstanbieter betriebenen Bereitstellungssystems verwendet werden. Die Operation „ResolveUsers" (siehe Element 554 von 5D) eines Dienstes empfängt die Nachricht „InResolveUsersRequest" 506 und antwortet mit einer Nachricht „OutResolveUsersResponse" 508. Bei diesem Beispiel ist diese Ausgabenachricht 508 dadurch definiert, dass sie eine Matrix mit der Bezeichnung „UserSet" zurückgibt. Die Syntax „SOAP-ENC" im Teilelement der Nachricht 508 ist ein Präfix für den Namensbereich und dient zur Bezeichnung der Matrixdefinition. (Es wird davon ausgegangen, dass diese Ausgabematrix die berechtigten Benutzer des bestimmten Dienstes kennzeichnet, der diese Operation „ResolveUsers" 554 ausführt, die unter Verwendung der UDDI verknüpft und unter Verwendung einer SORP-Nachricht aufgerufen wurde. Wenn die Operation „ResolveUsers" ausgeführt wurde, kann sie ein Bereitstellungssystem angefordert haben, um die berechtigten Benutzer zu ermitteln.)
Die Nachricht „InCreateUserProfileRequest" 510 zeigt, wie die Schnittstelle einer eingegebenen Anforderungsnachricht, die ein Benutzerprofil erstellt, gestaltet sein kann. Ebenso wie bei den anderen beispielhaften Nachrichten ist es von Vorteil, ein Identitätsprüfungs-Token als einen der Eingabeparameter einzufügen, die an den fernen Dienst weitergeleitet werden, sodass der ferne Dienst den die Information Anfordernden überprüfen und ermitteln kann, ob dieser Anfordernde zur Nutzung des Dienstes „CreateUserProfile" 556 berechtigt ist, der die Nachricht „InCreateProfileRequest" 510 ausgibt. Der Parameter „provID" kann zum Erstellen einer URI oder einer anderen Adresse eines Bereitstellungssystems gemäß der obigen Erörterung verwendet werden, wobei das Benutzerprofil im Bereitstellungssystem gespeichert werden muss. Der Parameter „userID" kennzeichnet vorzugsweise den Benutzer, für den (im Fall eines menschlichen Benutzers) oder für das (im Fall eines programmgesteuerten Benutzers) das Profil erstellt wird. Ein Parameter „password" kann bereitgestellt werden, um das diesem Benutzer zugewiesene Passwort zu erstellen. (Auf Wunsch können anstelle eines Passworts andere Berechtigungsnachweise verwendet werden.) Je nach den Anforderungen des zugrunde liegenden Dienstes können in einem Parameter „FullName" Vorname und Nachname des Benutzers übermittelt werden. Und schließlich werden in dieser Probennachricht die Zugriffsrechte des Benutzers in Form einer Matrix bereitgestellt. Die Operation „CreateUserProfile" 556 empfängt die Nachricht „InCreateUserProfileRequest" 510 und antwortet mit einer Nachricht „OutCreateUserProfilejResponse" 512. Bei diesem Beispiel gibt diese Ausgabenachricht 512 einen Booleschen Wert zurück, der anzeigt, ob das Profil erfolgreich erstellt wurde.
Die Nachricht „InQueryUserProfileRequest" 514 zeigt eine beispielhafte Schnittstelle für eine eingegebene Nachricht einer eingegebenen Anforderung, die zum Abrufen von Informationen von einem zuvor gespeicherten Benutzerprofil verwendet wird. Die Parameter der Nachricht beinhalten ein Identitätsprüfungs-Token „authToken" zur Überprüfung der Identität des die Informationen Anfordernden, eine Bereitstellungskennung „procID" zur Kennzeichnung eines Bereitstellungssystems, in welchem das Profil gespeichert ist, und einer Benutzerkennung „userID° zur Kennzeichnung des Benutzers, für den die Profilinformationen angefordert werden. Diese Nachricht 514 wird als Eingabeschnittstelle für einen Dienst „QueryuserProfile" 558 bereitgestellt, und die Nachricht „OutQueryUserProfileResponse" 516 in diesem Beispiel gibt das Passwort, Vorname und Nachname und Zugriffsrechte des Benutzers aus dem gespeicherten Profil zurück.
Die Nachricht „InUpdateUserProfileRequest" 518 ist der Nachricht „InCreateUserProfileRequest" 510 analog und verwendet beim vorliegenden Beispiel dieselben Parameter. Die Operation „UpdateUserProfile" 560 empfängt die Nachricht „InUpdateUserProfileRequest" 520 und antwortet mit einer Nachricht „OutUpdateUserProfileResponse" 520, die der Nachricht „OutCreateUserProfileResponse" 512 analog ist. Beim vorliegenden Beispiel gibt diese Ausgabenachricht 512 einen Booleschen Wert zurück, der anzeigt, ob das Profil erfolgreich erstellt wurde.
Die Nachricht „InDeleteUserProfileRequest" 522 und die Nachricht „OutDeleteUserProfileResponse" 524 werden als Eingabe- und Ausgabeschnittstelle der Operation „DeleteUserProfile 562 (siehe 5E) bereitgestellt und ermöglichen das Löschen eines Benutzerprofils in ähnlicher Weise die das Profil durch die Operation „CreateUserProfile" 556 und die Operation „UpdateUserProfile" 560 erstellt oder aktualisiert werden kann.
Zusätzlich zu den beschriebenen Identitätsprüfungs- und Berechtigungsprüfungsnachrichten kann es von Nutzen sein, Nachrichten und Operationen zum Konfigurieren von gekoppelten Internetdiensten zu definieren. Beispiele der Operationen „SetConfigParameter" 564 und „GetConfigParameter" 566 sind in 5E veranschaulicht.
Die Probeneingabenachricht für die Operation „SetConfigParameter" 564 ist „InSetConfigParameterRequest" 526 und für die Probenausgabenachricht „OutSetConfigParameter Response" 528. Die Eingabenachricht 526 bei diesem Beispiel enthält Eingabeparameter, zu denen das Identitätsprüfungs-Token „authToken" für den Anfordernden, die Bereitstellungskennung „provID" zur Kennzeichnung des Bereitstellungssystems, in welchem der Parameterwert zu speichern ist, die Benutzerkennung „userID" zur Kennzeichnung des Benutzers, dem dieser Parameter zugewiesen werden soll, sowie der Name des Konfigurierungsparameters „parameterName" und der Wert „parameter Value" gehören. Die Ausgabenachricht 528 gibt einen Booleschen Wert „result" zurück, der anzeigt, ob die Operation „SerConfigParameter" erfolgreich ausgeführt wurde.
Die Probeneingabenachricht für die Operation „GetConfigParameter" 566 ist „InGetConfigParameterRequest" 530 und für die Probenausgabenachricht „OutGetConfigParameterResponse" 532. Die Eingabenachricht 530 im vorliegenden Beispiel enthält Eingabeparameter, die denen der Nachricht „InSetConfigParameterRequest" 526 identisch sind, wobei lediglich der Parameter „parameterValue" weggelassen wird. Die Ausgabenachricht 532 gibt den Wert des angeforderten Parameters in Form des Parameters „parameterValue" zurück.
Die in 6 gezeigte Logik kann zur Ausführung eines gekoppelten Dienstes und der Identitäts- und/oder Konfigurierungsoperationen seiner Teildienste im Arbeitsablauf eines Internetdienstes gemäß den bevorzugten Ausführungsarten der vorliegenden Erfindung verwendet werden.
Eine Funktion „vereinheitlichte Anmeldung" oder Einzelanmeldung kann gemäß der vorliegenden Erfindung für einen gekoppelten Dienst bereitgestellt werden, wobei die Bereitstellungsschnittstelle des gekoppelten Dienstes zu Beginn der Ausführung des gekoppelten Dienstes alle erforderlichen Informationen von einem Benutzer abfragen kann. (Es kann natürlich passieren, dass bestimmte Informationen während der Ausführung vom Benutzer abgefragt werden müssen, sodass der Vorteil der vorliegenden Erfindung darin zu sehen ist, dass sie die Anzahl solcher Abfragen so gering wie möglich halten kann.
Die im WSFL-Arbeitsablauf eines gekoppelten Dienstes nacheinander definierten Operationen werden gemäß der Definition des Arbeitsablauf ausgeführt. Die vom Benutzer erhaltenen Anmeldeinformationen werden zur Nutzung durch den Teildienst, zu welchem einzelne Elemente der Anmeldeinformationen gehören, vorzugsweise „gestapelt". Das Stapeln von Modulen ist in der Technik Fachleuten bekannt, die mit Identitätssystemen und Berechtigungsprüfsystemen mit der Funktion Einzelanmeldung vertraut sind. Das Stapeln betrifft die Verwendung eines „primären" Passworts als Chiffrierschlüssel, wobei die so verschlüsselte Informationen ein oder mehrere „sekundäre" Passwörter umfassen. Bei der Verwendung des Stapelprozesses im Rahmen der vorliegenden Erfindung dienen die sekundären Passwörter als Passwörter für die Teildienste, während das primäre Passwort für den Wirkungsbereich des gekoppelten Dienstes gilt und diese sekundären Passwörter schützt. Die Teildienste werden gemäß der WSFL-Definition in einer festgelegten Reihenfolge aufgerufen, wobei die gestapelten Passwörter dem Stapel entnommen und dem jeweiligen Teildienst für Identitätsprüfung und Berechtigungsprüfung vorgelegt werden.
Dieser Prozess beginnt in Schritt 600 von 6, wo die Benutzerkennung und das Passwort (oder eine ähnliche Eingabe zur Identitätsprüfung) empfangen werden. (Zu beachten ist, dass die Angabe des Begriffes „Passwörter" nicht als Einschränkung der Art der unterstützten Berechtigungsnachweise zu verstehen ist. Berechtigungsnachweise können auf vielerlei Weise bereitgestellt werden, darunter in Form von Normaltext, verschlüsselten Zeichenfolgen, Zugriffsberechtigungen und Sicherheitszertifikaten mit öffentlichem Schlüssel wie beispielsweise X.509-Zertifikate.) Diese Identitätsprüfungsinformation kann dann als Eingabe zu einem fernen Dienst weitergeleitet werden, der nach dem Aufrufen seiner Identitätsprüfungsoperation ein Identitätsprüfungs-Token erzeugt (Schritt 610).
Vorzugsweise wird das in Schritt 610 erzeugte Identitätsprüfungs-Token als XML-Fragment erzeugt, das dann in die Kopfdaten einer SOAP-Nachricht eingefügt werden kann. Auf diese Weise können Benutzeridentitäten beim Zugreifen auf Internetdienste übermittelt werden. Siehe auch die Erörterung der SOAP-Nachricht 700 der Probe in den 7A und 7B, die zeigt, wie eine digitale Signatur unter Verwendung der XML-Syntax in die SOAP-Kopfdaten eingefügt wird. (Dort wird auch gezeigt, dass die Token der digitalen Signatur einen qualifizierten Namensbereich verwenden und deshalb durch die Buchstaben „ds" eingeleitet werden.) Identitätsprüfungssysteme und Strategiesysteme können ebenso auch unter Verwendung von SOAP-Kopfdaten mit den Operationen eines Dienstes verknüpft werden. WSDL-Beschreibungen stellen Operationen vorzugsweise als Kombination von SOAP-Kopfdaten und -Textkörper dar. Das heißt, bei allen Operationen, die einen Nachweis der Identität verlangen, müssen vorzugsweise Benutzerberechtigungsnachweise ausgetauscht werden. Das in den vorliegenden Beispielen angewendete Verfahren der SOAP-Sicherheitserweiterungen stellt ein Beispiel dafür dar, wie dies realisiert werden kann. Auch die Markierungssprache der Sicherheitsvereinigung (Security Association Markup Language, SAML), die GSS-API (Generic Security Service, generischer Sicherheitsdienst) und die CSI-Architektur (Common Secure Interoperability, allgemeine sichere Interoperabilität) stellen ein Mittel zum sicheren Austauschen der Berechtigungsnachweise eines Auftraggebers bereit. (Eine Version von SAML ist in einem OASIS-Artikel definiert, der im Internet unter http://www.oasisopen.org/committees/security/docs/draft-sstc-saml-spec-00.PDF vom 11. April 2001 zu finden ist. Die GSS-API ist in RFC 2743, „Generic Security Service Application Program Interface, Version 2, Update 1" vom Januar 2000 zu finden. CSI ist in „Common Secure Interoperability V2 Specification" definiert, die im Internet unter http://www.omg.org/cgi-bin/doc?ptc/2001-03-02 zu finden ist.
Das in Schritt 610 unter Verwendung der in Schritt 600 erhaltenen Eingabeinformation erzeugte Token wird hier insofern als „allgemeines" Identitätsprüfungs-Token bezeichnet, als es anschließend vorzugsweise dazu dienen kann, verschiedenen Teildiensten des gekoppelten Dienstes die Identität dieses Benutzers nachzuweisen. (Mit anderen Worten, dieses Token ist vorzugsweise für keinen Teildienst oder keine Operation spezifisch.)
In Schritt 620 wird geprüft, ob die Identität dieses Benutzers (immer noch) global (das heißt, für den gekoppelten Dienst) gültig ist. Bei bevorzugten Ausführungsarten werden, sobald die Identität eines Benutzers einmal geprüft worden ist, dessen Berechtigungsnachweise den Anforderungen für den restlichen Arbeitsablauf (d.h, für die Aufrufe der gekoppelten Dienste) zugewiesen. Gemäß der Logik in 6 wird diese Prüfung in Schritt 620 jedoch nicht nur einmal durchgeführt, zum Beispiel, damit sich ein Benutzer während der im Arbeitsablauf aufeinander folgenden Operationen abmelden kann. Wenn das Ergebnis der Prüfung negativ ist, darf dieser Benutzer den gekoppelten Dienst nicht weiter nutzen, und vorzugsweise wird ein Fehlercode zurückgegeben (Schritt 640) und die Verarbeitung in 6 endet. Wenn das Ergebnis der Prüfung positiv ist, wird die Verarbeitung in Schritt 630 mit der Prüfung fortgesetzt, ob die Identität dieses Benutzers lokal gültig ist (das heißt, für den nächsten auszuführenden Dienst, wenn dieser gemäß dem WSDL-Arbeitsablauf vorgesehen ist). Wenn das Ergebnis dieser Prüfung negativ ist, geht das Verfahren weiter zu Schritt 640; ansonsten folgt Schritt 670.
In Schritt 625 werden die gestapelten Identitätsinformationen für die nächste auszuführende Operation abgerufen. Diese abgerufenen Informationen werden zur Identitätsprüfung dieser nächsten Operation weitergeleitet, die unter Verwendung dieser Identitätsinformationen ein für die operationsspezifisches Token erzeugt (oder abruft).
In Schritt 660 wird das operationsspezifische Token (wie unter Bezug auf die 7A und 7B beschrieben) unter Verwendung von SOAP-Kopfdaten an den Anrufer zurückgegeben. (Zu beachten ist, dass die Antwortnachrichten in den 5A bis 5C zwar keine Rückgabe von Identitätsprüfungs-Token zeigen, solche Token aber auf Wunsch hinzugefügt werden können.) In Schritt 670 wird dann unter Verwendung des empfangenen operationsspezifischen Token die operationsspezifische Berechtigung des Benutzers ermittelt. (Benutzer können unterschiedliche Rollen einnehmen, von denen ihre Berechtigungsnachweise für eine bestimmte Klasse von Operationen abhängen. Ein Manager kann beispielsweise in seiner Rolle als leitender Mitarbeiter berechtigt sein, die Personalakten seiner Angestellten einzusehen, während er in seiner Rolle als Angestellter dieselbe Operation möglicherweise nicht ausführen darf.) Die Anforderung der Berechtigung in Schritt 670 nutzt zur Weiterleitung des in Schritt 660 empfangenen operationsspezifischen Token vorzugsweise auch SOAP-Kopfdaten. Wenn das Ergebnis der Berechtigungsprüfung zeigt, dass der Benutzer zur Ausführung der nächsten Operation des gekoppelten Dienstes berechtigt ist, wird die Verarbeitung mit Schritt 680 fortgesetzt. (Ansonsten kann ein Fehler erzeugt und/oder oder der Arbeitsablauf mit einer anderen Operation fortgesetzt werden. Die jeweilige Verarbeitung kann jeweils zwischen den Ausführungsformen variieren und ist in 6 deshalb nicht dargestellt. Dem Fachmann ist klar, wie geeignete Schritte in die Logik von 6 eingefügt werden können.)
In Schritt 680 wird die nächstfolgende Operation aufgerufen. Für diesen Aufruf können auch SOAP-Kopfdaten verwendet werden, wenn ein Berechtigungsnachweis des Benutzer benötigt wird, um das in Schritt 660 empfangene operationsspezifische Token weiterzuleiten. (Wenn als Ergebnis der Verarbeitung in Schritt 670 ein Berechtigungs-Token empfangen wird, wird dieses Token zusätzlich oder anstelle des Token von Schritt 650 weitergeleitet.) Nach Beendigung der Operation wird in Schritt 690 geprüft, ob noch weitere Operationen anstehen. Wenn dies nicht der Fall ist, ist die Verarbeitung von 6 beendet. Ansonsten geht das Verfahren zurück zu Schritt 620, um zu ermitteln, ob die Identität des Benutzers für den gekoppelten Dienst immer noch gültig ist (worauf in Schritt 630 geprüft wird, ob die Identität des Benutzers wie oben beschrieben für diesen nächsten Dienst gültig ist).
Es wurde gezeigt, dass die vorliegende Erfindung vorteilhafte Verfahren zur Bereitstellung gekoppelter Internetdienste bereitstellt. Zur Übermittlung von Identitätsinformationen werden vorzugsweise SOAP-Kopfdaten verwendet. Mit Hilfe der beschriebenen Verfahren können heterogene Identitätssysteme zu einer dynamischen, integrierten Umgebung von Internetdiensten während der Laufzeit vereint werden. Der Einsatz von offenen Standards wird erleichtert. Zu beachten ist, dass bei der Beschreibung bevorzugten Ausführungsarten zwar bestimmte Standards (zum Beispiel WSDL und SOAP) genannt wurden, dass dies jedoch nur zur Veranschaulichung der erfindungsgemäßen Konzepte der vorliegenden Erfindung dient. Es können alternative Mittel zur Bereitstellung der analogen Funktionalität bereitgestellt werden, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen.
Der Fachmann kann sich vorstellen, dass Ausführungsarten der vorliegenden Erfindung in Form von Verfahren, Systemen oder Computerprogrammprodukten bereitgestellt werden können. Demzufolge kann die vorliegende Erfindung die Form einer Ausführungsart ausschließlich in Hardware, ausschließlich in Software oder als Kombination von Software- und Hardwareaspekten annehmen. Außerdem kann die vorliegende Erfindung die Form eines Computerprogrammprodukts mit einem darin enthaltenen computerlesbaren Programmcode annehmen, das auf einem oder mehreren computerlesbaren Speichermedien (darunter, aber nicht ausschließlich, Plattenspeicher, CD-ROM, optische Speicher usw.) realisiert ist.
Die vorliegende Erfindung ist unter Bezug auf Ablaufschaubilder und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsarten der Erfindung beschrieben worden. Es ist klar, dass jeder Arbeitsablauf und/oder jeder Arbeitsschritt der Ablaufschaubilder und/oder Blockschaubilder und Kombinationen von Arbeitsabläufen/Arbeitsschritten in den Ablaufschaubildern und/oder Blockschaubildern durch Computerprogrammanweisungen realisiert werden kann. Diese Computerprogrammanweisungen können einem Prozessor eines Universalcomputers oder eines Spezialcomputers, einem integrierten Prozessor oder einer anderen programmierbaren Datenverarbeitungseinrichtung bereitgestellt werden, um eine Maschine derart zu schaffen, dass die durch den Prozessor des Computers oder einer anderen programmierbaren Datenverarbeitungseinrichtung ausgeführten Anweisungen ein Mittel zur Realisierung der im Arbeitsablauf der Ablaufschaubilder und/oder in den Arbeitsschritten der Blockschaubilder dargestellten Funktionen bilden.
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Speicher gespeichert werden, der einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung in der Weise zum Ausführen einer Funktion veranlassen kann, dass die im computerlesbaren Speicher gespeicherten Anweisungen einen Herstellungsartikel bilden, der die im Arbeitsablauf des Ablaufschaubildes und/oder in den Arbeitsschritten des Blockschaubildes angegebene Funktion ausführt.
Die Computerprogrammanweisungen können auch in einen Computer oder eine andere programmierbare Datenverarbeitungseinheit geladen werden, um die Ausführung einer Reihe von Arbeitsschritten im Computer oder in der anderen programmierbaren Einrichtung zu veranlassen und somit einen durch den Computer durchgeführten Prozess zu schaffen, sodass die im Computer oder in der anderen programmierbaren Einrichtung ausgeführten Anweisungen Schritte zur Ausführung der im Arbeitsablauf der Ablaufschaubilder und/oder in den Arbeitsschritten der Blockschaubilder angegebenen Funktionen bewirken.
Obwohl die bevorzugten Ausführungsarten der vorliegenden Erfindung beschrieben worden sind, kann sich der Fachmann nach dem Erfassen der Grundideen der Erfindung weitere Varianten und Modifikationen dieser Ausführungsarten ausdenken. Deshalb sind die angehängten Ansprüche so zu verstehen, dass sie sowohl die bevorzugte Ausführungsart als auch alle derartigen Varianten und Modifikationen beinhalten und diese in den Geltungsbereich der Erfindung fallen.

Claims

Verfahren zur Bereitstellung eines gekoppelten Dienstes in einem Computernetz (100, 120, 150), wobei das Verfahren die folgenden Schritte umfasst: Empfangen (600) von Berechtigungsnachweisen eines Benutzers, der den Zugriff auf einen gekoppelten Dienst fordert; Suchen in einer über das Netz erreichbaren Registrierungsdatenbank nach einem Dienstbeschreibungsdokument, das eine Bereitstellungsschnittstelle für den gekoppelten Dienst beschreibt, wobei der gekoppelte Dienst eine Vielzahl miteinander gekoppelter Teildienste umfasst und die Bereitstellungsschnittstelle beschreibt, wie Identitätsfunktionen des gekoppelten Dienstes aufgerufen werden müssen; Analysieren (620, 630) der empfangenen Berechtigungsnachweise durch Aufrufen einer oder mehrerer der Identitätsfunktionen gemäß deren Beschreibung in der Bereitstellungsschnittstelle, um zu ermitteln, ob der Benutzer für den Zugriff auf den gekoppelten Dienst berechtigt ist; und Zulassen des Benutzers für den Zugriff auf den gekoppelten Dienst nur, wenn die Analyse ermittelt, dass der Benutzer für den Zugriff auf den gekoppelten Dienst zugelassen ist.
Verfahren nach Anspruch 1, bei dem eine Ausführungsform jeder der Identitätsfunktionen des gekoppelten Dienstes durch mindestens einen der Teildienste bereitgestellt wird.
Verfahren nach Anspruch 1, bei dem: mindestens einer der Teildienste eine lokale Bereitstellungsschnittstelle aufweist, wobei die lokale Bereitstellungsschnittstelle in einem entsprechenden Dienstbeschreibungsdokument beschrieben ist und eine Beschreibung umfasst, wie eine oder mehrere Identitätsfunktionen des Teildienstes aufgerufen werden müssen; und den Zugriff auf jeden der Teildienste mit der lokalen Bereitstellungsschnittstelle steuert, wobei die Steuerung ferner die folgenden Schritte umfasst: Ermitteln, ob der Benutzer für den Zugriff auf den Teildienst berechtigt ist, durch Aufrufen mindestens einer der einen oder mehreren Identitätsfunktionen des Teildienstes gemäß deren Beschreibung in der lokalen Bereitstellungsschnittstelle; und Zulassen des Benutzers für den Zugriff auf den Teildienst nur, wenn im Ermittlungsschritt ermittelt wird, dass der Benutzer für den Zugriff auf den Teildienst zugelassen ist.
Verfahren nach Anspruch 3, bei dem: im Schritt des Empfangens von Berechtigungsnachweisen vom Benutzer auch Teildienstberechtigungsnachweise für mindestens einen der Teildienste mit der lokalen Bereitstellungsschnittstelle empfangen werden; und die empfangenen Teildienstberechtigungsnachweise im Ermittlungsschritt verwendet werden.
Verfahren nach Anspruch 1, bei dem: eine oder mehrere Funktionen mindestens eines der Teildienste zugriffsgeschützt sind; der Empfangsschritt ferner das Empfangen funktionsspezifischer Berechtigungsnachweise des Benutzers für mindestens eine der zugriffsgeschützten Funktionen und ferner den folgenden Schritt umfasst: Steuern des Zugriffs auf jede der mindestens einen zugriffsgeschützten Funktionen, wobei die Steuerung ferner die folgenden Schritte umfasst: Analysieren der empfangenen funktionsspezifischen Berechtigungsnachweise durch Aufrufen einer oder mehrerer der Identitätsfunktionen gemäß deren Beschreibung in der Bereitstellungsschnittstelle, um zu ermitteln, ob der Benutzer auf die zugriffsgeschützte Funktion zugreifen kann; und Zulassen des Benutzers für den Zugriff auf zugriffsgeschützte Funktion nur, wenn im Schritt zur Analyse der empfangenen funktionsspezifischen Berechtigungsnachweise ermittelt wird, dass der Benutzer auf die zugriffgeschützte Funktion zugreifen kann.
Verfahren nach Anspruch 1, bei dem durch Aufrufen einer oder mehrerer Identitätsfunktionen gewonnene Identitätsinformationen programmgesteuert zwischen mindestens zwei der Teildienste des gekoppelten Dienstes ausgetauscht werden.
Verfahren nach Anspruch 6, bei dem der programmgesteuerte Austausch das Senden einer Nachricht umfasst, welche die Berechtigungsnachweise in den Kopfdaten der Nachricht und eine Dienstanforderung in einem Textkörper der Nachricht beschreibt.
Verfahren nach Anspruch 7, bei dem die Nachricht eine SOAP-Nachricht (Simple Objekt Access Protocol, einfaches Zugangsprotokoll für Objekte) ist.
Verfahren nach Anspruch 1, bei dem das Dienstbeschreibungsdokument in einer Auszeichnungssprache (Markup Language) beschrieben ist.
Verfahren nach Anspruch 9, bei dem die Markierungssprache eine Beschreibungssprache für Internetdienste (Web Services Description language, WSDL) ist.
Verfahren nach Anspruch 1, bei dem auf die über das Netz erreichbare Registrierungsdatenbank unter Verwendung von standardisierten Nachrichten zugegriffen wird.
Verfahren nach Anspruch 1, bei dem eine Ausführungsform mindestens eines der Teildienste dynamisch während der Laufzeit gesucht wird.
Verfahren nach Anspruch 6, bei dem die Identitätsinformation zu Anfang als Ergebnis des Analyseschrittes gewonnen wird.
Verfahren nach Anspruch 6, bei dem die Identitätsinformation ein Identitätsnachweis-Token umfasst, das durch eine der aufgerufenen Identitätsfunktionen erzeugt wurde.
Verfahren nach Anspruch 1, bei dem: mindestens zwei der Teildienste jeweils ein Identitätssystem für die Steuerung des Zugriffs auf die Teildienste zugehörig ist; mindestens zwei der zugehörigen Identitätssysteme heterogen sind; und mindestens eine der ausgewählten Identitätsfunktionen des gekoppelten Dienstes die dynamische Verknüpfung von mindestens zwei der heterogenen Identitätssysteme ermöglicht.
Verfahren nach Anspruch 15, bei dem die mindestens eine ausgewählte Identitätsfunktion nach dem Aufrufen das Identitätssystem erkennt, das Informationen speichert, die zu Benutzern desjenigen Teildienstes gehören, dem dieses Identitätssystem zugeordnet ist.
Verfahren zur Bereitstellung eines gekoppelten Dienstes in einem Rechnernetz, das Folgendes umfasst: ein Mittel zum Empfangen von Berechtigungsnachweisen eines Benutzers, der den Zugriff auf einen gekoppelten Dienst fordert; ein Mittel zum Suchen in einer über das Netz erreichbaren Registrierungsdatenbank nach einem Dienstbeschreibungsdokument, das eine Bereitstellungsschnittstelle für den gekoppelten Dienst beschreibt, wobei der gekoppelte Dienst eine Vielzahl miteinander gekoppelter Teildienste umfasst und die Bereitstellungsschnittstelle beschreibt, wie Identitätsfunktionen des gekoppelten Dienstes aufgerufen werden müssen; ein Mittel zum Analysieren der empfangenen Berechtigungsnachweise durch Aufrufen einer oder mehrerer der Identitätsfunktionen gemäß deren Beschreibung in der Bereitstellungsschnittstelle, um zu ermitteln, ob der Benutzer für den Zugriff auf den gekoppelten Dienst berechtigt ist; und Zulassen des Benutzers für den Zugriff auf den gekoppelten Dienst nur, wenn die Analyse ermittelt, dass der Benutzer für den Zugriff auf den gekoppelten Dienst zugelassen ist.
Computerprogrammprodukt zur Bereitstellung einer oder mehrerer Softwareressourcen eines gekoppelten Dienstes in einem Rechnernetz, wobei das Computerprogrammprodukt in einem oder mehreren computerlesbaren Medien realisiert ist und Folgendes umfasst: computerlesbare Programmcodemittel zur Ausführung aller Schritte des Verfahrens nach einem der Ansprüche 1 bis 16.