DE10016531A1 - Verfahren zum Betrieb eines Datenverarbeitungssystems - Google Patents

Abstract

Verfahren zum Betrieb eines Datenverarbeitungssystems mit einer Mehrzahl von jeweils einem Benutzer zugeordneten Client-Benutzerschnittstellen und mindestens einem mit diesen verbundenen Server, insbesondere einer Mehrzahl von Servern, zur Ausführung von verteilten Anwendungen, die jeweils eine Mehrzahl von Methodenaufrufen umfassen, wobei auf dem Server oder den Servern eine Mehrzahl von Serverobjekten, zur Ausführung der Anwendung implementiert ist und wobei zur Ausführung der Anwendungen Serverobjekte an die Client-Benutzerschnittstellen gebunden werden, bei dem aus jedem Methodenaufruf ein Job erzeugt, mit dem Sitzungs-Identifikator versehen und als Botschaft an den Server oder die Server übermittelt und der jeweil übermittelte Job durch das zuerst arbeitsbereite Serverobjekt angenommen und unter Verwaltung des Sitzungs-Identifikators ausgeführt wird.

Description

Die Erfindung betrifft ein Verfahren zum Betrieb eines Daten­ verarbeitungssystems nach dem Oberbegriff des Anspruchs 1 sowie eine Anordnung zur Durchführung dieses Verfahrens.

Derartige Verfahren sind bekannt. Der Begriff "verteilte Anwen­ dung" wird hier in dem Sinne gebraucht, daß eine Anwendung ent­ fernte Methodenaufrufe durchführt und nicht "monolithisch" aus einem einzigen, geschlossen ausführbaren Programm besteht. Ent­ fernte Methodenaufrufe werden nach dem Stand der Technik durch­ objektorientierte Standards bzw. Implementationen, wie etwa CORBA (Common Object Request Broker Architecture), COM+ (Han­ delsname eines Produktes der Fa. Microsoft) oder RMI (Remote Method Invocation, eine Java-Implementierung der Fa. Sun Micro­ systems) definiert bzw. durchgeführt. Auch Anwendungen, die nicht objektorientierte Ansätze in Art des RPC (Remote Procedu­ re Call, Verfahren der Fa. Sun Microsystems) nutzen, werden voraussetzungsgemäß zu den gattungsgemäßen Verfahren gerechnet. Im hier festgelegten Kontext umfaßt der Begriff "Anwendung" oder "Applikation" auch eine Zusammensetzung von logisch ge­ trennten Einzelanwendungen, die über die erwähnten Mechanismen miteinander kommunizieren.

Bei bekannten Verfahren dieser Art ruft ein Benutzer (Client) zur Ausführung einer Anwendung Methoden eines entfernten Ser­ verobjektes (auch als "Remote Object" zu bezeichnen) auf. Hier­ für muß zunächst eine gültige Referenz auf das Serverobjekt ge­ funden werden. Dieser Vorgang wird nachfolgend als "Binden" be­ zeichnet. Ein Client kann bei bekannten Verfahren theoretisch beliebig viele Serverobjekte beliebig oft binden und die Metho­ den eines Serverobjektes beliebig oft aufrufen. Ein Serverob­ jekt seinerseits kann theoretisch von beliebig vielen Client gebunden bzw. referenziert sein.

Ein bekanntes System dieser Art ist in Fig. 1 skizziert, wo beispielhaft die Bindungen von vier Clients, Client 1 bis Cli­ ent 4 an vier verschiedene, auf zwei Servern A und B implemen­ tierte Serverobjekte dargestellt ist. Dieser Ablauf ist in Fig. 2 für einen Client, ein Proxyobjekt, einen Job und ein - hier als "original Objekt" bezeichnetes - Serverobjekt skizziert.

Bei den bekannten Verfahren ist es jedoch, speziell bei aus mehreren Modulen verschiedenen Ursprungs (verschiedener Her­ steller) zusammengesetzten Anwendungen, prinzipiell nicht mög­ lich, daß ein Serverobjekt den einen Methodenaufruf auslösenden Client identifiziert und daß eine ausgleichende Lastverteilung auf der Ebene der Methodenaufrufe stattfindet.

Bezüglich der Lastverteilung bzw. des Lastenausgleiches gehen die heutigen CORBA-, RMI- oder COM+-Implementationen wie folgt vor:

Existieren mehrere Serverobjekte der gleichen Art, wird im Au­ genblick des Bindens eine Entscheidung getroffen, welches Ser­ verobjekt mit dem Client verbunden wird. Danach jedoch geht jeder Methodenaufruf auf dasselbe Serverobjekt, ungeachtet der sich im allgemeinen ständig ändernden Lastverteilung der an der Anwendung beteiligten Rechner. Der Zeitpunkt des Bindens liegt in der Regel weit vor den Methodenaufrufen.

Die Alternative, daß die Clients nach jedem Methodenaufruf neu binden, ist nur sehr bedingt vertretbar, da der Vorgang sehr teuer ist.

Die Lastverteilung beim Binden wird entweder durch Abfrage der Last über das Betriebssystem der einzelnen Rechner oder durch (gegebenenfalls gewichtete) Zufallsverteilung oder durch Round- Robin-Verfahren (Verteilen des Bindens auf alle in Frage kom­ menden Serverobjekte der Reihe nach im Kreis) entschieden. Beim ersten Verfahren erfährt man nur, wie hoch die Auslastung eines Rechners im Moment ist. Je nach abgefragter System-Information ergibt sich, genau genommen, sogar nur eine Mittelung über ei­ nen vergangenen Zeitraum. Eigentlich möchte man aber denjenigen Rechner mit einer Aufgabe belasten, der am schnellsten damit fertig werden wird - es interessiert nicht, wie hoch seine au­ genblickliche Belastung ist. Die beiden anderen Verfahren hof­ fen aufgrund von statistischen Annahmen auf eine gleichmäßige Verteilung der Last. Dabei gehen sie davon aus, daß die mög­ lichen Anfragen an die Remoteobjekte eine nicht allzu große Varianz in ihrem Ressourcenbedarf haben.

Bei allen drei Verfahren kann es passieren, daß ein Rechner die Bewältigung einer Aufgabe übernehmen muß, obwohl er plötzlich sehr viel mehr ausgelastet ist als ein anderer. Weiterhin wird im Falle eines Rechnerverbundes die Netzwerkbelastung nicht berücksichtigt. Ein Serverobjekt, das zu einem Zeitpunkt auf­ grund der Lastverteilungsmethode mit der Bearbeitung einer Aufgabe beauftragt wird, könnte temporär in einem belasteten Netzwerksegment liegen. Dann wäre es günstiger, einen anderen Rechner zu finden, selbst wenn dessen Rechenkapazität mehr in Anspruch genommen wird.

Aufgabe der vorliegenden Erfindung ist es, ein verbessertes Verfahren der gattungsgemäßen Art bereitzustellen, welches ins­ besondere ohne Veränderung des fachlichen Quelltextes bestehen­ der Anwendungen und ohne Notwendigkeit der Bedienung einer Pro­ grammierschnittstelle durch die Entwickler neuer Anwendungen eine Optimierung der Lastverteilung erlaubt und die Möglichkeit einer Benutzerzuordnung und benutzerbezogenen Abrechnung der Ausführung von Transaktionen bzw. einer Anwendung schafft.

Hiermit soll letztlich eine leistungsbezogene und damit gegen­ über der bisherigen zeit- und benutzerzahlbezogenen Abrechnung wesentlich transparentere Abrechnung der Nutzung von Software realisiert werden. Weiterhin soll eine zur Durchführung des Verfahrens geeignete Anordnung angegeben werden.

Diese Aufgabe wird hinsichtlich ihres Verfahrensaspektes durch ein Verfahren mit den Merkmalen des Anspruchs 1 und hinsicht­ lich ihres Vorrichtungsaspektes durch eine Anordnung mit den Merkmalen des Anspruchs 17 gelöst.

Die Erfindung schließt den grundlegenden Gedanken einer dynami­ schen, request-orientierten Organisation verteilter Anwendungen in Einheiten der einzelnen Methodenaufrufe ein. Sie schließt weiter den Gedanken ein, mittels einer geeigneten Systemstruk­ tur aus den Methodenaufrufen sog. "Jobs" zu erzeugen, die den vorhandenen Serverobjekten in Art einer Vermakelung (Brokerage) angeboten werden. Weiterhin schließt sie den Gedanken ein, die Abarbeitung der einzelnen Jobs demjenigen (zur Ausarbeitung ge­ eignet ausgebildeten, d. h. "fachlich zuständigen") Serverob­ jekt zu übertragen, welches auf das Jobangebot zuerst reagiert.

Die Jobs werden einzeln verwaltet - sowohl in Bezug auf den Be­ nutzer (Client) als auch in Bezug auf die Lastverteilung. Den Jobs entsprechen - gemäß dem MOM (Message Oriented Middleware)- Konzept - Botschaften, die zwischen Clients und Serverobjekten übertragen werden. Jeder durch einen Client initiierte Metho­ denaufruf erzeugt - nach der Umwandlung in einen Job und der Übermittlung als Botschaft - eine Jobanforderung (Request). Die Rückgabewerte von Methodenaufrufen werden als Antwortjobs wie­ der zurück an den aufrufenden Client transportiert. (Einem Client kann eine Benutzerschnittstelle entsprechen, er kann aber in einer Methodenaufruf-Kette seinerseits Serverobjekt eines anderen Client sein.)

Damit die erforderliche Transparenz des Verfahrens aus Sicht der fachlichen Anwendung erreicht wird, muß zur umfassenden Lö­ sung der genannten Aufgabe für den Client (Benutzer) das Beste­ hen einer "starren" Verbindung zu einem bestimmten "fachlich zuständigen" Serverobjekt vorgespiegelt werden, obgleich gerade das Aufbrechen dieser Verbindung nach dem initialen Bindungs­ vorgang ein Kernpunkt der Erfindung ist.

Die Basis des Verfahrens, auf der die anderen Elemente aufbau­ en, ist die Erzeugung der Jobs. Aus der Sicht des Client wird eine Referenz auf ein Serverobjekt gebunden, anschließend wer­ den Methoden dieses Servers aufgerufen und die Rückgabewerte in Empfang genommen. Transparent für den Client wird aus dem Auf­ ruf ein Job erzeugt, der zu einem der möglichen Serverobjekte vermittelt wird. Dieses bearbeitet den Job und generiert im allgemeinen Fall eine Antwort. Die Antwort wird als Job zurück übermittelt und in den Rückgabewert umgewandelt, den der Client erwartet und in Empfang nimmt.

Jeder Benutzer bedient seine Anwendung über eine Client-Benut­ zerschnittstelle, bei der es sich insbesondere um native aus­ führbare Programme, HTML (HyperText Markup Language)- oder WML (Wireless Markup Language)-Clients oder auch Java-Applika­ tionen oder -Applets mit vorbestimmtem Programmablauf handelt. Dieser meist als GUI (Graphical User Interface) ausgeprägte Teil einer Anwendung ist als sogenannte Instanz während einer Sitzung genau einem Benutzer zugeordnet, d. h. es gibt genauso viele Instanzen der Schnittstellen, wie es zu einem Zeitpunkt tätige Benutzer gibt. Innerhalb des Programmablaufs der Benut­ zerschnittstellen rufen diese als Client die Methoden entfern­ ter Serverobjekte auf. Das Verfahren gewährleistet, daß jeder von einem Benutzer ausgelöste Methodenaufruf einer bestimmten Sitzung und damit dem Benutzer zugeordnet werden kann. Dabei wird die Identifikation einer Sitzung gehalten, so daß damit jeder Job markiert werden kann.

Falls es für einen Job mehrere mögliche Serverobjekte gibt, so erhält dasjenige den Auftrag zur Bearbeitung, das aufgrund seiner aktuellen Ressourcen in der Lage ist, mit der Bearbeitung zu beginnen und sich am schnellsten darum beworben hat. Damit wird ein Lastenausgleich auf Methodenebene erreicht, der zudem die Nachteile der im Stand der Technik bekannten Lastvertei­ lungs-Verfahren behebt.

Die oben erwähnte "Vorspiegelung" einer permanenten Bindung zwischen Client und Serverobjekt wird auf Seiten des Client da­ durch realisiert, daß zu Beginn jeder Sitzung ein Proxyobjekt an die Client-Benutzerschnittstelle gebunden wird, welches die­ ser gegenüber die Kommunikationseigenschaften eines Serverob­ jektes zeigt, aus den Methodenaufrufen die Jobs erzeugt und mit dem Sitzungs-Identifikator versieht und mit diesem zusammen weiterleitet.

Dies ist in Fig. 3 skizziert.

Die Benutzerschnittstelle nimmt die gewünschten Aktionen des Benutzers entgegen und agiert als Client der Proxyobjekte. Eine Instanz der Benutzerschnittstelle ist während einer Sitzung ge­ nau einem Benutzer zugeordnet. Innerhalb dieser Instanz wird eine eindeutige Sitzungs-Identifikator gehalten, die jedem Proxyobjekt beim Binden mitgeteilt wird. Daraus folgt, daß eine Benutzerschnittstelle zwar beliebig viele Proxyobjekte binden kann, ein Proxyobjekt aber nur von einer Benutzerschnittstelle als Client gebunden sein kann. Jeder Job, der als Folge eines Methodenaufrufs erzeugt wird, wird vom Proxyobjekt mit dem Sit­ zungs-Identifikator versehen, den es im Moment des Bindens er­ halten hat.

Die oben angesprochene Vortäuschung einer permanenten Bindung zwischen Client und Serverobjekt wird auf seiten der Serverob­ jekte durch Gegenstellen zum Proxyserver realisiert, die im folgenden als "Jobverwaltungsstellen" bezeichnet werden. Die Jobverwaltungsstellen zeigen den Serverobjekten gegenüber im wesentlichen die Kommunikationseigenschaften einer Client- Benutzerschnittstelle.

Ihre sinnvolle Funktion im Gesamtsystem setzt insbesondere vor­ aus, daß das Proxyobjekt eine Klassifizierung des Jobs nach Jobarten in Zuordnung zu Methoden entsprechend einer Konkor­ danztabelle ausführt und jedem Job einen Jobart-Identifikator zuordnet. Die Annahme eines Jobs erfolgt in Abhängigkeit vom Jobart-Identifikator durch eine dem Serverobjekt zugeordnete Jobverwaltungsstelle. Auf die Formulierung und Übermittlung ei­ nes Jobs durch das Proxyobjekt hin referenziert also die Gegen­ stelle das Serverobjekt, das zur Ausführung des Jobs geeignet ist, und ruft die entsprechende Methode auf. Nach Bearbeitung nimmt sie den Rückgabewert in Empfang, formuliert daraus einen Antwortjob und sendet diesen zurück an das Proxyobjekt. Dieses interpretiert wiederum aus dem Antwortjob den Rückgabewert und leitet ihn weiter zur Client-Benutzerschnittstelle.

Zur Realisierung einer vorteilhaften Lastverteilung werden bei den Jobverwaltungsstellen Warteschlangen eingerichtet, in die die dem betreffenden Serverobjekt angebotenen Jobs in der Rei­ henfolge ihrer Erzeugung eingegliedert werden, wobei die Job­ verwaltungsstellen nach Abarbeitung jeweils eines Jobs ein An­ forderungssignal für den nächsten Job in der Warteschlange ge­ nerieren.

Wenn mehrere Serverobjekte der gleichen Art vorhanden sind, das heißt für die Bearbeitung eines Jobs aus Sicht des Proxyobjek­ tes mehrere Gegenstellen (Jobverwaltungsstellen) in Frage kom­ men, so wird jeder dieser Gegenstellen der Job zur Bearbeitung angeboten. Die Gegenstellen haben eine Warteschlange mit zu be­ arbeitenden Jobs. Wenn sie einen Job verarbeitet haben, so for­ dern sie den nächsten in ihrer Warteschlange vom Anbieter an. Die erste Gegenstelle, die den Job anfordert, erhält den Zu­ schlag und beginnt mit der Verarbeitung des Jobs. Beim Proxy­ objekt als "Joberzeuger" später eintreffende Anforderungen werden abgelehnt, und die Gegenstellen können zum nächsten Job in ihrer Warteschlange übergehen.

Dieses Verfahren gewährleistet, daß immer dasjenige Serverob­ jekt mit einem Job beauftragt wird, das seine vorherigen bear­ beitet hat und Zeit für den nächsten hat. Der Effekt dieser Vorgehensweise wird nicht negativ beeinflußt durch Jobarten (Transaktionen), die eine große Varianz in ihrem Ressourcen­ bedarf haben, und es kann nicht passieren, daß aufgrund einer eigentlich veralteten Information über die Auslastung eines Rechners eine falsche Verteilungsentscheidung getroffen wird. Die Netzwerkbelastung geht automatisch mit in die Lastvertei­ lungsentscheidungen ein. Ein in einem weniger belasteten Netz­ werksegment befindlicher Server wird gegebenenfalls die Bewer­ bung um einen Job gegen einen weniger belasteten Server in einem höher belasteten Segment "gewinnen". Die Tatsache, daß ein Server sich schneller als andere um den Job bewirbt, belegt seine optimale Eignung zu ihrer Abarbeitung.

Ein wesentlicher Vorteil des vorgeschlagenen Verfahrens besteht in der Möglichkeit einer transaktions- bzw. jobbasierten Ab­ rechnung ("Transaction Billing"). Hierzu wird insbesondere für jeden Job ein Abrechnungsticket ("Billing Ticket") erzeugt. Dieses wird erfaßt und über den Sitzungs-Identifikator, mit dem das Sitzungsmanagement den Job markiert hat, eindeutig einer bestimmten Benutzersitzung zugeordnet. Das Verfahren hält In­ formationen über die Bewertung (Kosten) der verschiedenen Arten von Jobs. Die Arten der Jobs geben die Methoden der verschiede­ nen Serverobjekte wieder.

Das Abrechnungsticket ist eine Botschaft, die keinen fachlichen Hintergrund hat, sondern den Jobart-Identifikator und den Sit­ zungs-Identifikator enthält. Das Abrechnungsticket wird zu ei­ ner Abrechnungseinheit gesendet, die den Sitzungs-Identifikator einem Benutzer zuordnen kann. Die Abrechnungseinheit hält kon­ figurierbare Informationen über die Kosten der einzelnen Trans­ aktionen, und ist somit jederzeit in der Lage, die Gesamtko­ sten, die ein Benutzer in einem Zeitraum verursacht hat, zu er­ mitteln.

In einer in Fig. 4 skizzierten Variante wird das Abrechnungs­ ticket durch das jeweilige Proxyobjekt erzeugt. Alternativ hierzu kann es auch von der Jobverwaltungsstelle erstellt wer­ den, die den Job für das zugeordnete Serverobjekt angenommen und die entsprechende Methode aufgerufen hat. In diesem Fall können variierende Kosten in das Abrechnungsticket mit einflie­ ßen, indem ein dynamischer Faktor mit dem in der Abrechnungs­ einheit konfigurierten Grundpreis einer Transaktion verrechnet wird.

Damit die Abrechnungseinheit über die Abrechnungstickets den Sitzungen Benutzer zuordnen kann, muß ein Benutzer einmal pro Sitzung authentifiziert und danach bei jedem Abrechnungsticket identifiziert werden.

Das Verfahren nutzt bevorzugt den Authentisierungsmechanismus der fachlichen Anwendung. Das System wird so konfiguriert, daß es den entfernten Methodenaufruf zur Authentisierung eines Benutzers (Einloggen) erkennen und auch das Ergebnis inter­ pretieren kann. Es wird eine Authentisierungsinformation für die Abrechnungseinheit erzeugt, in der neben dem Sitzungs- Identifikator auch ein Benutzer-Identifikator enthalten ist. Die Abrechnungseinheit bildet ab diesem Zeitpunkt die Sitzungs- Identifikator der nachfolgend im Laufe der Anwendung erhaltenen Abrechnungstickets auf diesen Benutzer ab. Analog dazu wird der Vorgang des Ausloggens eines Benutzers behandelt, um die Zuord­ nung des Sitzungs-Identifikator zum Benutzer wieder zu lösen.

Ein einfaches Ablaufdiagramm für den Vorgang der Benutzerau­ thentisierung zeigt Fig. 5.

Das Verfahren bietet die Möglichkeit, aus Sicherheitsgründen die Verarbeitung von Jobs zu sperren, deren Sitzungs-Identifi­ kator keinem Benutzer zugeordnet ist. Eine "Benutzerenlose" Sitzung kann zum Beispiel durch eine fehlgeschlagene Authentisierung und fehlerhaft programmierte oder vorsätzlich mani­ pulierte Benutzerschnittstellen verursacht worden sein.

Mit Blick auf besondere Vorteile des vorgeschlagenen Verfahrens und Systems ist noch auf folgendes hinzuweisen: Aus der Sicht der Anwendung können sich fachliche Transaktionen aus mehreren Einzeltransaktionen zusammensetzen. Schlägt eine oder schlagen mehrere Einzeltransaktionen fehl, so müssen alle zu einer fach­ lichen Transaktion gehörenden Einzelvorgänge rückgängig gemacht werden. Ein das hier beschriebene Verfahren implementierendes System wird bezüglich fachlicher, zusammengesetzter Transaktio­ nen konfiguriert und gewährleistet die Konsistenz der Vorgänge in einer Anwendung, indem es die Einzeltransaktionen überwacht und gegebenenfalls deren Stornierung einleitet. Das Verfahren entkoppelt die Anwendung von nicht-fachlichen Fehlern wie zum Beispiel Netzwerk- oder Hardwarefehlern. Das System kann Trans­ aktionen wiederholen, ohne daß die Anwendung davon betroffen ist.

Grundsätzlich ist eine Zusammenfassung der oben angesprochenen Identifikatoren zu einer (nicht-fachlichen) Gesamtkennzeichnung des jeweiligen Jobs möglich. Speziell repräsentiert auch ein Sitzungs-Identifikator natürlich zugleich einen Client bzw. ei­ ne Client-Benutzerschnittstelle. Der Einsatz eines Benutzer- Identifikators erlaubt aber - neben der oben erwähnten Sperrung "mandantenloser" Sitzungen - zudem die Mitführung von Informa­ tionen bezüglich eines klassifizierbaren Systemverhaltens des jeweiligen Benutzers bzw. der Client-Benutzerschnittstelle und auf dieser Grundlage die Initiierung spezifischer Reaktionen bei der Abarbeitung.

Die Ausführung der Erfindung ist nicht auf die vorstehend be­ schriebene bevorzugte Verfahrensführung beschränkt, sondern auch in Abwandlungen möglich, die im Rahmen fachgemäßen Han­ delns liegen.

Claims (23)

1. Verfahren zum Betrieb eines Datenverarbeitungssystems mit einer Mehrzahl von jeweils einem Benutzer zugeordneten Client-Benutzerschnittstellen und mindestens einem mit diesen verbundenen Server, insbesondere einer Mehrzahl von Servern, zur Ausführung von verteilten Anwendungen, die jeweils eine Mehrzahl von Methodenaufrufen umfassen, wobei auf dem Server oder den Servern eine Mehrzahl von Server­ objekten, zur Ausführung der Anwendung implementiert ist und wobei zur Ausführung der Anwendungen Serverobjekte an die Client-Benutzerschnittstellen gebunden werden, dadurch gekennzeichnet, daß

• - jeder aktiven Client-Benutzerschnittstelle zur Ausfüh­ rung einer Anwendung eindeutig eine Sitzung mit einem Sitzungs-Identifikator zugeordnet wird,
• - aus jedem Methodenaufruf ein Job erzeugt, mit dem Sit­ zungs-Identifikator versehen und als Botschaft an den Server oder die Server übermittelt,
• - der jeweils übermittelte Job durch das zuerst arbeits­ bereite Serverobjekt angenommen und unter Verwaltung des Sitzungs-Identifikators ausgeführt und
• - aus dem Ausführungsergebnis ein Antwortjob erzeugt und als Rückgabewert an die Client-Benutzerschnittstelle übermittelt wird, von der der Methodenaufruf ausging.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Client-Benutzerschnittstellen als native ausführbare Programme, HTML- oder WML-Clients oder Java-Applikationen oder -Applets mit vorbestimmtem Programmablauf ausgebildet sind.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß zu Beginn jeder Sitzung ein Proxyobjekt an die Client-Be­ nutzerschnittstelle gebunden wird, welches dieser gegen­ über die Kommunikationseigenschaften eines Serverobjektes zeigt und aus den Methodenaufrufen die Jobs erzeugt und mit dem Sitzungs-Identifikator versieht.

4. Verfahren nach Anspruch 3, gekennzeichnet durch die Implementierung einer Mehrzahl von Proxyobjekten, wo­ bei jedes Proxyobjekt nur von einer Client-Benutzer­ schnittstelle gebunden sein, eine Client-Benutzerschnitt­ stelle aber mehrere Proxyobjekte binden kann.

5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, daß das Proxyobjekt eine Klassifizierung des Jobs nach Jobar­ ten in Zuordnung zu Methoden entsprechend einer Konkor­ danztabelle ausführt und jedem Job einen Jobart-Identi­ fikator zuordnet.

6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß die Annahme eines Jobs in Abhängigkeit vom Jobart-Identi­ fikator durch eine dem Serverobjekt zugeordnete Jobverwal­ tungsstelle erfolgt.

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daß die Jobverwaltungsstellen den Serverobjekten gegenüber im wesentlichen die Kommunikationseigenschaften einer Client- Benutzerschnittstelle zeigen.

8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, daß bei den Jobverwaltungsstellen Warteschlangen eingerichtet werden, in die die dem betreffenden Serverobjekt angebote­ nen Jobs in der Reihenfolge ihrer Erzeugung oder gemäß ei­ ner vorgegebenen Priorisierung eingegliedert werden, wobei die Jobverwaltungsstellen nach Abarbeitung jeweils eines Jobs ein Anforderungssignal für den nächsten Job in der Warteschlange generieren.

9. Verfahren nach einem der Ansprüche 5 bis 8, dadurch gekennzeichnet, daß die Jobart-Identifikatoren durch dem Proxyobjekt bzw. den Proxyobjekten nachgeordnete Jobvermittlungsstellen zur Zu­ weisung der Jobs an zu ihrer Ausführung geeignet ausgebil­ dete Serverobjekte ausgewertet werden.

10. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß zu Beginn einer Sitzung über die Client-Benutzerschnitt­ stelle eine Identifizierung und Authentisierung des Benut­ zers ausgeführt und die Zuweisung eines Sitzungs-Identi­ fikators erst nach erfolgter Authentisierung und in Ver­ bindung mit der Zuweisung eines Benutzer-Identifikators vorgenommen wird.

11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß die Erzeugung und/oder Übermittlung eines Jobs nur bei Vorhandensein eines Benutzer-Identifikators ausgeführt wird.

12. Verfahren nach Anspruch 10 oder 11, dadurch gekennzeichnet, daß beim Ausloggen eines Benutzers die Verbindung zwischen Sitzungs-Identifikator und Benutzer-Identifikator aufgeho­ ben wird.

13. Verfahren nach einem der Ansprüche 9 bis 12, dadurch gekennzeichnet, daß spezifische Benutzer-Identifikatoren in Abhängigkeit von einem klassifizierbaren Systemverhalten des jeweiligen Be­ nutzers bzw. der Client-Benutzerschnittstelle vergeben und durch das jeweilige Proxyobjekt zur Ableitung spezifischer Reaktionen ausgewertet werden.

14. Verfahren nach einem der Ansprüche 10 bis 13, dadurch gekennzeichnet, daß in Verbindung mit der Ausführung eines Jobs der Jobart- Identifikator und Benutzer-Identifikator und/oder Sit­ zungs-Identifikator zur Abrechnung der Ausführung eines Methodenaufrufes unter Nutzung einer Jobart-Kostenbetrag- Zuordnungstabelle ausgewertet werden.

15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß die Auswertung eine sitzungs- und/oder benutzerbezogene Aufsummierung von Job-Kostenbeträgen umfaßt.

16. Verfahren nach Anspruch 14 oder 15, dadurch gekennzeichnet, daß bei jeder Ausführung eines Jobs, insbesondere durch das Proxyobjekt oder die Jobverwaltungsstellen, ein Abrech­ nungsticket erzeugt und an eine Abrechnungseinheit über­ mittelt wird.

17. Anordnung zur Durchführung des Verfahrens nach einem der vorangehenden Ansprüche, mit

• - einer Mehrzahl von jeweils einem Benutzer zugeordneten Client-Benutzerschnittstellen, die zu Methodenaufrufen bei der Ausführung von Anwendungen ausgebildet sind,
• - mindestens einem Server, insbesondere einer Mehrzahl von Servern, auf dem bzw. denen eine Mehrzahl von Serverobjekten zur Abarbeitung der Methodenaufrufe imple­ mentiert ist,
• - mindestens einem zwischen die Client-Benutzerschnitt­ stellen und die Serverobjekte geschalteten Proxyobjekt, insbesondere einer Mehrzahl von Proxyobjekten, zur Ge­ nerierung von Jobs aus Methodenaufrufen und zur Zuwei­ sung jeweils eines Sitzungs-Identifikators zu jedem Job und zur Weiterleitung der Jobs als Botschaften, wobei das oder jedes Proxyobjekt gegenüber den Client-Benut­ zerschnittstellen die Kommunikationseigenschaften eines Serverobjektes zeigt, und
• - den Serverobjekten zugeordnete Jobverwaltungsstellen zur Organisation der Annahme und Abarbeitung von Jobs durch das jeweilige Serverobjekt, wobei die Jobverwal­ tungsstellen den Serverobjekten gegenüber im wesentli­ chen die Kommunikationseigenschaften einer Client-Be­ nutzerschnittstelle zeigen.

18. Anordnung nach Anspruch 17, dadurch gekennzeichnet, daß das oder jedes Proxyobjekt zur Klassifizierung der Jobs nach Jobarten und zur Zuweisung eines Jobart-Identifika­ tors ausgebildet ist, wobei dem Proxyobjekt oder den Proxyobjekten insbesondere ein erster Konkordanzspeicher zur Speicherung einer Methoden-Jobart-Konkordanztabelle zugeordnet ist.

19. Anordnung nach Anspruch 17 oder 18, dadurch gekennzeichnet, daß die Client-Benutzerschnittstellen zur Identifizierung und Authentisierung des Benutzers ausgebildet sind.

20. Anordnung nach einem der Ansprüche 17 bis 19, dadurch gekennzeichnet, daß das oder jedes Proxyobjekt zur Auswertung eines spezifi­ schen Benutzer-Identifikators zur Ableitung spezifischer Reaktionen ausgebildet ist.

21. Anordnung nach einem der Ansprüche 17 bis 20, gekennzeichnet durch eine Abrechnungseinheit zur sitzungs- und/oder benutzerbe­ zogenen Abrechnung der Ausführung einer Anwendung unter Auswertung des Jobart-Identifikators und Benutzer-Identi­ fikators und/oder Sitzungs-Identifikators.

22. Anordnung nach Anspruch 21, dadurch gekennzeichnet, daß die Abrechnungseinheit zur Auswertung von durch das Proxy­ objekt bzw. die Proxyobjekte oder die Jobverwaltungsstel­ len erzeugten und übermittelten Abrechnungstickets ausge­ bildet ist.

23. Anordnung nach Anspruch 21 oder 22, dadurch gekennzeichnet, daß dem Proxyobjekt bzw. den Proxyobjekten oder den Jobverwal­ tungsstellen ein zweiter Konkordanzspeicher zur Speiche­ rung einer Jobart-Kostenbetrag-Konkordanztabelle zugeord­ net ist.