DE10224795A1 - Zweigsperren von Auftragsetiketten, um eine Zugriffskonkurrenz zu steuern - Google Patents

Abstract

Um Probleme eines gleichzeitigen Zugriffs zu steuern, kann der Auftragsetikettendienst Zweigsperrmerkmale verwenden, das heißt, die Fähigkeit, ein Auftragsetikett auf der Zweigebene zu sperren. Das Zweigsperren kann durch eines von mehreren Verfahren bewerkstelligt werden. Die Arbeitsflußsteuerung kann einen oder mehrere spezifische Prozessoren dafür vorsehen, die Aufgaben, die bei dem zu sperrenden Zweig identifiziert sind, durchzuführen. Dort, wo mehr als ein Prozessor zu einem Zugriff auf denselben Zweig autorisiert ist, kann der Auftragsetikettendienst den Zweig sperren, wenn einer der autorisierten Prozessoren den Zweig tatsächlich erlangt. Der Auftragsetikettendienst kann die Zweige sperren, indem er ein Sperren-/Entsperren-Flag für jeden Zweig setzt. Prozessoren, die auf das Auftragsetikett zugreifen, können daraufhin den Sperren-/Entsperren-Flag-Zustand prüfen, um zu bestimmen, ob auf den Zweig zugegriffen werden kann. Unter gewissen Umständen erlaubt der Auftragsetikettendienst eventuell einen Zugriff lediglich auf diejenigen Zweige, die entsperrt sind. Ein Prozessor, der eine durch den Zweig definierte Aufgabe abgeschlossen hat, benötigt es eventuell, daß der Zweig entsperrt wird, damit er den Zweig modifizieren kann.

Description

Das technische Gebiet ist die Integration und Steuerung von Dienstleistungen in einer vernetzten Umgebung.

Dienstleistungen können durch eine oder mehrere Betriebs­ einheiten in einem computerbasierten Netz bereitgestellt werden. Benutzer des Netzes können spezifische Aufgaben er­ zeugen und die Aufgaben in das Netz schicken, um einer der Betriebseinheiten zugeordnet zu werden. Beispielsweise kann ein Benutzer an einem Computer-Endgerät unter Verwendung eines an dem Endgerät installierten Treibers eine Druckan­ weisung erzeugen. Bei einem anderen Beispiel kann ein Be­ nutzer eine Druckanweisung erzeugen und die Druckanweisung in ein Computernetz schicken, damit die Druckanweisung durch einen Druckdienst ausgeführt wird. Die Druckanweisung kann sich auf eine Unternehmensbroschüre beziehen. Die Druckanweisung kann eindeutige Erfordernisse wie beispiels­ weise Papiertyp, Schriftgröße, Layout, Graphiken, Farbe und andere Erfordernisse enthalten. Der Benutzer kann festle­ gen, daß ein bestimmter Druckdienst, wie beispielsweise Kinkos, die Unternehmensbroschüre erstellt. Alternativ dazu kann das Computernetz Programme umfassen, die dem Benutzer Druckdienste vorschlagen.

Um den Druckauftrag zu steuern, kann das Computer-Endgerät des Benutzers ein Auftragsetikett erstellen. Das Auftrags­ etikett umfaßt die Erfordernisse, beispielsweise die oben angeführten Erfordernisse, und eine Identifizierung des be­ stimmten Auftrags, die es ermöglicht, daß der Auftragssta­ tus durch das Computernetz verfolgt werden kann.

Eine Verwendung des Auftragsetiketts ermöglicht es, daß das Drucken und ähnliche Dienste denjenigen Ressourcen (d. h. den Betriebseinheiten) zugewiesen werden, die sich am bes­ ten für das Ausführen der Dienste eignen. Ungünstigerweise ermöglichen derzeitige Computersysteme keinen Zugang zu der großen Vielfalt an Diensten, die in vernetzten Computersys­ temen, wie beispielsweise dem Internet, existieren. Über­ dies erfordern derzeitige Systeme, daß Benutzer über eine gewisse Kenntnis der vorhandenen Resscourcen verfügen, und erfordern eventuell, daß Benutzer eine relevante Program­ mierung einbeziehen, um mit den Dienstleistern zu kommuni­ zieren. Ferner ermöglichen derzeitige Systeme nicht, daß eine Auftragsanforderung unter mehreren Prozessoren aufge­ teilt wird. Folglich kann eine Fertigstellung der Auftrags­ anforderung länger dauern als nötig und wird eventuell nicht auf die effizienteste, kostengünstigste Weise er­ stellt.

Es ist die Aufgabe der vorliegenden Erfindung, eine Vor­ richtung, Verfahren und eine Programmspeichervorrichtung zu schaffen, die eine Steuerung von gleichzeitigen Zugriffen bzw. eine Zugriffskonkurrenzsteuerung auf eine effiziente, kostengünstige Weise ermöglichen.

Diese Aufgabe wird durch eine Vorrichtung gemäß Anspruch 1, Verfahren gemäß Anspruch 10 und 17 sowie eine Programmspei­ chervorrichtung gemäß Anspruch 21 gelöst.

Um diese und andere Probleme, die sich auf die Verwendung eines Auftragsetiketts beziehen, zu lösen, ermöglichen ein Verfahren und eine Vorrichtung es einem Client, Auftrags­ attribute und -prozesse unter Verwendung eines elektroni­ schen Dienstezentrums zu verwalten. Das Dienstezentrum um­ faßt einen Auftragsetikettdienst, der einen Zugriff und ei­ ne Modifizierung eines Auftragsetiketts durch mehrere Be­ nutzer in einem Netz ermöglicht. Das Verfahren und die Vor­ richtung verwenden ein Netzwerk-zugreifbares Auftragseti­ kett, um sich auf einen bestimmten Auftrag oder Inhalt zu beziehen. Das Auftragsetikett kann ein Objekt sein, wie beispielsweise ein XML-Objekt, das Routinen und Daten auf­ weist. Der Inhalt kann in dem Netz gespeichert sein, und auf ihn kann durch mehrere Auftragsetiketten zugegriffen werden. Speicherung und Handhabung des Auftragsetiketts sind für den Benutzer transparent. Das Auftragsetikett wird an einer öffentlich zugänglichen Position in dem Netz ge­ speichert. Das Auftragsetikett verbleibt in derselben Posi­ tion in dem Netz, und Benutzer greifen lediglich auf den Abschnitt des Auftragsetiketts zu, der erforderlich ist, um einen benannten Prozeß auszuführen. Es können zusätzlich Sicherheitsmaßnahmen ergriffen werden, um einen Zugriff auf diejenigen Benützer zu begrenzen, denen es ausdrücklich gestattet ist, auf das Auftragsetikett und die Auftragsda­ tei zuzugreifen. Das Auftragsetikett kann ein Dienstkenn­ zeichen umfassen, das das Auftragsetikett auf den ursprüng­ lichen Auftragsetikettdienst zurückbezieht. Auf diese Weise kann sich ein Benutzer, der das gesamte oder einen Teil des Auftragsetiketts erlangt, auf den ursprünglichen Auftrags­ etikettdienst (und das ursprüngliche oder modifizierte Auf­ tragsetikett) zurückbeziehen, um etwaige Änderungen zu ve­ rifizieren und um sicherzustellen, daß das Auftragsetikett, auf das gerade zugegriffen wird, auf dem neuesten Stand ist. Das Auftragsetikett umfaßt ferner ein Auftragskennzei­ chen, um das Auftragsetikett einem bestimmen Auftrag zuzu­ schreiben.

Das Dienstezentrum ist durch ein Kommunikationsnetz mit ei­ nem Vorfelddienst (Front-End-Dienst) gekoppelt. Der Vor­ felddienst ermöglicht es einem Benutzer, eine Dienst- oder Auftragsanforderung zu erstellen. Das Kommunikationsnetz kann beispielsweise das Internet oder ein lokales Netz sein.

Das Dienstezentrum umfaßt einen Dienstebus, mit dem ein Auftragsspeicher, der Auftragsetikettdienst und eine Ar­ beitsflußsteuerung gekoppelt sind. Ferner sind ein oder mehrere Prozessoren mit dem Dienstezentrum gekoppelt, die gesteuert werden können, um in den Auftragsetiketten defi­ nierte Prozesse und Aufgaben zu erfüllen.

Der Auftragsetikettdienst kann die Auftragsetiketten er­ stellen und speichern. Ein Auftragsinhalt (z. B. eine PDF- Datei) ist in dem Auftragsspeicher gespeichert. Bei dieser Struktur muß der Benutzer nicht die Speicherung des Auftragsinhalts verwalten oder wissen, welcher Auftrags­ speicher den Auftragsinhalt enthält. Der Auftragsetikett­ dienst steuert einen Zugriff auf die Auftragsetiketten, und durch die Verwendung der Auftragsetiketten steuert er fer­ ner einen Zugriff auf einen Auftragsinhalt in dem Auftrags­ speicher oder an anderer Stelle in dem Netz. Der Auftrags­ etikettdienst kann einen Verweis auf das Auftragsetikett erstellen und kann den Verweis verwenden, um einen Zugriff auf das Auftragsetikett zu steuern.

Durch Verwenden des Dienstezentrums kann ein Benutzer auf eine breite Palette von Diensten (Prozessoren) zugreifen, die mit dem Dienstezentrum gekoppelt sind. Das Dienste­ zentrum kann zwischen den Prozessoren entscheiden, um eine optimale Auswahl von Prozessoren zum Ausführen der Aufgaben zu bestimmen, die in der Auftragsanforderung des Benutzers spezifiziert sind. Das Dienstezentrum kümmert sich um die notwendigen Schnittstellen und Programmumwandlungen, die erforderlich sind, um eine Aufgabenerfüllung durch die aus­ gewählten Dienste zu ermöglichen. Auf diese Weise muß der Benutzer keine Kenntnis der Betriebserfordernisse der Pro­ zessoren aufweisen.

Um Probleme eines gleichzeitigen Zugriffs zu begrenzen, kann der Auftragsetikettdienst Zweigsperrmerkmale verwen­ den, das heißt die Fähigkeit, ein Auftragsetikett auf einer Zweigebene zu sperren. Die Zweigsperrung kann durch eines von mehreren Verfahren bewerkstelligt werden. Die Ar­ beitsflußsteuerung kann einen oder mehrere bestimmte Pro­ zessoren dazu bestimmen, die Aufgaben, die mit dem zu sper­ renden Zweig identifiziert sind, zu erfüllen. Wenn mehr als ein Prozessor autorisiert bzw. berechtigt ist, auf densel­ ben Zweig zuzugreifen, kann der Auftragsetikettdienst den Zweig sperren, wenn einer der autorisierten Prozessoren tatsächlich den Zweig erlangt. Ein Sperren eines Zweiges kann verhindern, daß andere Prozessoren den Zweig erlangen.

Wenn die Arbeitsflußsteuerung Zweigen keine Prozessoren zu­ gewiesen hat (d. h. ein beliebiger Prozessor kann zu jeder Zeit auf einen Zweig zugreifen), kann der Auftragsetikett­ dienst den Zweig sperren, wenn ein Prozessor den Zweig er­ langt.

Der Auftragsetikettdienst kann die Zweige sperren, indem er für jeden Zweig ein Sperren-/Entsperren-Flag setzt. Prozes­ soren, die auf das Auftragsetikett zugreifen, können dar­ aufhin den Sperren-/Entsperren-Flag-Status prüfen, um zu bestimmen, ob auf den Zweig zugegriffen werden kann. Unter manchen Umständen erlaubt der Auftragsetikettdienst eventu­ ell lediglich einen Zugriff auf diejenigen Zweige, die ent­ sperrt sind. Es kann sein, daß ein Prozessor, der eine durch den Zweig definierte Aufgabe erfüllt hat, benötigt, daß der Zweig entsperrt ist, um den Zweig zu modifizieren.

Ein elektronisches Dienstezentrum umfaßt Komponenten, die einen Zugriff auf ein Auftragsetikett steuern, wobei sich das Auftragsetikett auf eine Auftragsanforderung bezieht, die durch einen oder mehrere Prozessoren, die mit einem Kommunikationsnetz gekoppelt sind, auszuführen sind. Bei einem Ausführungsbeispiel umfassen die Komponentenfolgen­ des: eine mit dem Kommunikationsnetz gekoppelte Ar­ beitsflußsteuerung, wobei die Arbeitsflußsteuerung einen Arbeitsfluß, der der Auftragsanforderung entspricht, defi­ niert und das Auftragsetikett definiert, und wobei der Ar­ beitsfluß einen oder mehrere Zweige umfaßt; und einen Auf­ tragsetikettdienst, der das Auftragsetikett speichert, wo­ bei das Auftragsetikett einen Rahmen umfaßt, der die Zweige spezifiziert, und wobei der Auftragsetikettdienst einen Zweig sperrt, wenn auf den Zweig durch einen Prozessor zu­ gegriffen wird.

Bei einem Ausführungsbeispiel umfaßt ein Zweig ein Sperren- /Entsperren-Flag, wobei das Sperren-/Entsperren-Flag auf Sperren eingestellt ist, um den Zweig zu sperren, wobei das Sperren-/Entsperren-Flag den Zweig sperrt, um eine Zweigmo­ difizierung zu verhindern. Wenn der Zweig gesperrt ist, kann ein zweiter Prozessor in einem Nur-Lese-Modus auf den gesperrten Zweig zugreifen.

Bei einem anderen Ausführungsbeispiel wird dem Prozessor, der auf den Zweig zugreift, ein Schlüssel bereitgestellt. Um den Zweig zu entsperren, gibt der Prozessor den Schlüs­ sel an den Auftragsetikettdienst zurück.

Bei einem anderen Ausführungsbeispiel wird der Prozessor, der auf den Zweig zugreift, zu einem Zugriff auf den Zweig autorisiert, und diese Autorisierung wird mit dem Auftrags­ etikett gespeichert.

Bei einem weiteren Ausführungsbeispiel umfaßt das Dienste­ zentrum eine Auftragsspeicherung. Die Auftragsspeicherung speichert einen Inhalt, der dem Zweig entspricht. Wenn der Zweig entsperrt ist, kann der Prozessor auf den Inhalt zu­ greifen.

Bei einem weiteren Ausführungsbeispiel liefert das Sperren- /Entsperren-Flag einen Hinweis eines Sperrstatus für den Zweig.

Bei einem weiteren Ausführungsbeispiel speichert der Auf­ tragsetikettdienst eine Datentabelle, die Zweige des Ar­ beitsflusses auflistet. Wenn ein Prozessor auf einen Zweig zugreift, markiert der Auftragsetikettdienst die Datenta­ belle, um anzugeben, daß der Zweig für eine Modifizierung nicht zur Verfügung steht.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen, bei denen sich gleiche Bezugszeichen auf glei­ che Posten beziehen, näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm, das eine bekannte Verwendung eines Auftragsetiketts zeigt;

Fig. 2 ein Baumdiagramm, das die Prozesse bei einem bei­ spielhaften Auftragsetikett zeigt;

Fig. 3 ein Blockdiagramm eines Digitalbildarbeitsfluß­ netzes;

Fig. 4 ein Blockdiagramm eines Dienstezentrums, das bei dem Netz der Fig. 3 verwendet wird;

Fig. 5A bis 5D ein beispielhaftes Auftragsetikett;

Fig. 6 ein Diagramm von Funktionen, die durch einen Auf­ tragsetikettdienst gesteuert werden;

Fig. 7 ein Diagramm, das durch den Auftragsetikettdienst gesteuerte Zugriffsfunktionen. zeigt;

Fig. 8 ein Blockdiagramm, das zusätzliche Steuermerkmale des Auftragsetikettdienstes veranschaulicht;

Fig. 9 ein Flußdiagramm, das einen der durch den Auf­ tragsetikettdienst gesteuerten Prozesse veran­ schaulicht; und

Fig. 10 bis 15 Flußdiagramme, die Unterprozesse bei dem in Fig. 9 veranschaulichten Gesamtprozeß zeigen.

Fig. 1 ist ein Blockdiagramm, das eine bekannte Anwendung eines Auftragsetikettdienstes zeigt. Auftragsetiketten sind oft einem Druckstandard, dem Auftragsdefinitionsformat (JDF - job definition format), zugeordnet. Das JDF ist ausführ­ lich in der bei www.hp_opensource.com erhältlichen JDF Spe­ cification Draft Spiral 4.0, die durch Bezugnahme in dieses Dokument aufgenommen ist, ausführlich beschrieben. In Fig. 1 erstellt ein Benutzer 1 eine Auftragsanforderung und sen­ det die Auftragsanforderung durch ein Portal 4 an einen Prozessor 5. Die Auftragsanforderung kann eine Auftragseti­ kett-Datendatei 2 und eine Inhaltsdatei 3 umfassen. Der Be­ nutzer 1 kann ein Computer-Endgerät in einem vernetzten Computersystem sein, und der Prozessor 5 kann ein vernetz­ ter Drucker sein. Die Auftragsanforderung kann ein Drucken eines Dokuments beinhalten. Das Dokument kann durch den In­ halt 3, der eine digitale Darstellung von zu druckendem Text und zu druckenden Bildern ist, dargestellt sein. Das beabsichtigte Format des gedruckten Dokuments kann in der Auftragsetikettdatei 2 beschrieben sein, die einfach eine digitale Datei ist, die spezifiziert, wie der Drucker das Dokument drucken soll. Beispielsweise kann die Auftragseti­ kettdatei 2 erfordern, daß das Dokument auf Rücken an Rü­ cken liegenden Seiten druckt.

Bei einer spezifischen Anwendung können die Funktionen der Auftragsetikettdatei 2 durch einen Druckertreiber ausge­ führt werden. Der Druckertreiber codiert Steuerdaten, die mit einem Drucken des Dokuments in Zusammenhang stehen, und sendet die Steuerdaten und den Inhalt 3 an den Drucker (d. h. den Prozessor 5). Der Drucker greift auf die Steuerdaten und den Inhalt 3 zu, um das Dokument zu drucken.

Während die in Fig. 1 gezeigte Anwendung gut funktioniert, um ein Dokument zu drucken, weist die Anwendung viele Nachteile auf. Insbesondere wenn mehrere Prozessoren an ei­ nem Erstellen des Dokuments beteiligt sind, erfordert jeder derartige Prozessor einen Zugriff auf die Auftragsetikett­ datei 2. Dieser Zugriff bringt Probleme bezüglich Sicher­ heit, Modifikationssteuerung und Arbeitsflußsteuerung mit sich. Es kann beispielsweise sein, daß jeder Prozessor, der einen Zugriff auf die Auftragsetikettdatei 2 erfordert, mit dem Verarbeiten warten muß, bis ein vorheriger Prozessor eine Verwendung der Auftragsetikettdatei 2 abgeschlossen hat. Somit kann die Anwendung des Standes der Technik zu unerwünschten Verzögerungen beim Ausführen der Auftragsan­ forderung führen.

Bekannte Anwendungen von Auftragsetikettdiensten sind auch insofern nachteilig, als der Benutzer eventuell nichts über die Prozessoren weiß, einschließlich der Fähigkeiten und der Verfügbarkeit der Prozessoren, noch, ob die Prozessoren existieren. Somit weiß der Benutzer eventuell nicht, wel­ ches Portal er verwenden soll, um mit einem bestimmten Pro­ zessor verbunden zu werden.

Dieses und weitere Probleme werden durch ein Verfahren und eine Vorrichtung gelöst, das bzw. die einen Zugriff auf ein Auftragsetikett und einen zugeordneten Inhalt durch Verwen­ dung eines Auftragsetikettdienstes steuert. Der Auftrags­ etikettdienst umfaßt Mechanismen, die unter mehreren Benut­ zern des Auftragsetiketts einen Zugriff auf das Auftrags­ etikett entscheiden, einen Zugriff auf das Auftragsetikett durch ein Einfließenlassen von Sicherheitsmerkmalen begren­ zen und sicherstellen, daß Modifikationen, die durch einen Prozessor oder Benutzer vorgenommen werden, in dem Auf­ tragsetikett und dem Inhalt reflektiert werden. Tatsächlich umfaßt die Vorrichtung eine generische Datenbank, die Ein­ gangsdaten von Clients als Auftragsanforderungen mit Aus­ gangsdiensten wie beispielsweise Prozessoren koppelt, die Aufgaben oder Prozesse durchführen, um die Auftragsanforde­ rungen zu erfüllen. Die Datenbank kann insofern die Merkma­ le einer generischen XML-Datenbank aufweisen, als sie er­ weiterbar ist und insofern als die Clients keine Kenntnisse über die einzelnen durchzuführenden Prozesse oder die in­ ternen Programmierungserfordernisse der Prozessoren aufwei­ sen müssen. Somit können die Clients Auftragsanforderungen einem Dienstezentrum unterbreiten, das sicherstellt, daß ein geeigneter Prozessor oder geeignete Prozessoren zuge­ wiesen werden, um die Auftragsanforderung zu erfüllen.

Bevor die Vorrichtung und das Verfahren ausführlich be­ schrieben werden, wird eine Besprechung eines Auftragseti­ ketts bereitgestellt. Fig. 2 ist ein Knoten-Baum-Diagramm (oder einfach ein Knotenbaum) 10, der in einem Auftragseti­ kett zum Drucken einer Broschüre definierte Prozesse veran­ schaulicht. Die Broschüre kann in einer handelsüblichen Presse gedruckt werden und kann einen digitalen Inhalt ver­ wenden, um Platten zum Drucken der Broschüre herzustellen. In dem Knotenbaum 10 spezifizieren die Knoten ein Produkt, einen Prozeß oder eine Gruppe von Prozessen. Jeder Knoten kann Ressourcen modifizieren, verbrauchen oder erzeugen. Jeder Knoten kann weitere verschachtelte Knoten oder Unter­ knoten enthalten. Die Anordnung von Knoten und Unterknoten kann mit einem Baum verglichen werden, und jeder Knoten und Unterknoten kann als Zweig bezeichnet werden. Ein Broschü­ renknoten 11 definiert die Merkmale und Parameter der Bro­ schüre. Ein Einbandknoten 12 definiert die Parameter zum Erstellen des Einbands der Broschüre. Ein Innenseitenknoten 13 umfaßt die Parameter zum Herstellen der Innenseiten. Der Innenseitenknoten 13 ist mit mehreren Unterknoten gezeigt, einschließlich eines Unterknotens 14 zum Herstellen einer digitalen Platte. Der Digitalplattenherstellungs- Unterknoten 14 selbst umfaßt zwei weitere Unterknoten, ei­ nen Auftrenn-Unterknoten 16 und einen Plattenherstellungs- Unterknoten 18.

Jedem der in Fig. 2 gezeigten Knoten und Unterknoten sind Eingangsressourcen und mindestens eine Ausgangsressource zugeordnet. Eine Ressource kann durch Parameter oder logi­ sche Entitäten beschrieben werden. Die Ressource kann eine physische Entität wie beispielsweise eine Komponente, eine Handhabungsressource oder ein Verbrauchsartikel sein. Eine Komponentenressource kann die Ausgabe eines Knotens oder Unterknotens sein, wie beispielsweise bedruckte Blätter. Eine Handhabungsressource wird während eines Prozesses ver­ wendet, wird jedoch nicht durch den Prozeß verbraucht. Eine Verbrauchsartikelressource kann durch den Prozeß teilweise oder gänzlich verbraucht werden. Beispiele von Verbrauchs­ artikelressourcen umfassen Tinten, Platten und Kleber. An­ dere Ressourcen können eine digitale Datei oder eine Dar­ stellung eines physischen Objekts sein. Beispielsweise kann der Auftrenn-Unterknoten 16 als Eingaberessourcen eine Laufliste, Medien, RIP-Parameter und Layout umfassen. Die Lauflistenressource beschreibt die Seiten, einschließlich der Dateien, in denen die Seiten auftreten, und welche Sei­ ten zu verwenden sind. Die Medienressource beschreibt die Medien, die zum Herstellen von Platten verwendet werden, und wird benötigt, um die Abmessungen der Medien zu be­ schreiben. Die RIP-Parameter-Ressource beschreibt alle ge­ rätespezifischen Parameter des Auftrennvorgangs. Die Lay­ outressource beschreibt eine Plazierung von Quellenseiten auf den Platten und schließlich auf Preßschichten. Als Aus­ gangsressource kann der Auftrenn-Unterknoten 16 aufgetrenn­ te Flachstücke bereitstellen. Andere Ressourcen umfassen Parameterressourcen, die die Einzelheiten von Prozessen de­ finieren, sowie andere nicht-physische Computerdateien, die von einem Prozeß verwendet werden.

Der in Fig. 2 gezeigte Knotenbaum 10 soll für ein Drucken eines Dokuments gelten. Es können jedoch Knoten-Baum- Diagramme verwendet werden, um Auftragsetiketten für andere Dienste als Drucken darzustellen. Beispielsweise kann ein Auftragsetikett für eine Datenverarbeitung, eine Bildverar­ beitung, zum Erstellen und Pflegen einer Datenbank, für Electronic Publishing (Erstellen von Druckerzeugnissen auf Rechnern), E-Mail und diverse E-Commerce-Dienste verwendet werden. Überdies kann das Auftragsetikett verwendet werden, um es verschiedenen E-Commerce-Diensten zu ermöglichen, miteinander in Kontakt zu treten.

Fig. 3 ist ein Blockdiagramm eines DIW-Netzes 20 (DIW = di­ gital imaging work flow, Digitale-Bilderzeugung- Arbeitsfluß), das ein Dienstezentrum und einen Auftragseti­ kettdienst beinhaltet, um durch Clients unterbreitete Auf­ gaben zu steuern. Das Dienstezentrum kann als einzelnes Portal arbeiten, durch das die Clients mit einem oder meh­ reren E-Diensten, einschließlich E-Mail, E-Commerce und On­ line-Einkaufen, E-Drucken und Datendiensten, einschließlich Datenbanksuchen und Datenbankerstellung, -besetzung und -pflege, verbunden sind. Bei einem alternativen Ausfüh­ rungsbeispiel kann das Dienstezentrum mehrere Portale auf­ weisen. Bei diesem alternativen Ausführungsbeispiel kann jedes der mehreren Portale einem spezifischen E-Dienst ge­ widmet sein. Alternativ dazu können die mehreren Portale bereitgestellt sein, um eine Bandbreite zu erhöhen. Eine Verwendung eines einzelnen Portals, wie beispielsweise des Dienstezentrums, ermöglicht es den Clients, aus einer brei­ ten Palette von E-Diensten, wie beispielsweise den oben an­ gegebenen, auszuwählen, ohne daß dabei erforderlich wäre, daß die Clients eine vorherige Kenntnis der E-Dienste be­ sitzen.

Das Dienstezentrum kann Komponenten umfassen, die Informa­ tionen in Form von Auftragsanforderungen empfangen, und kann unter Verwendung der Informationen ein Auftragsetikett erstellen, das Aufgaben und Ressourcen spezifiziert. Das Auftragsetikett kann in einem Auftragsetikettdienst gespei­ chert sein, und es können Meldungen gesandt werden, um an­ zugeben, wann ein Auftragsetikett zur Verfügung steht. Mit dem Dienstezentrum gekoppelte Prozessoren können eine Er­ füllung des Auftragsetiketts anbieten, und das Dienste­ zentrum kann einen Angebotsdienst umfassen, der Angebote auswertet. Das Dienstezentrum kann einen oder mehrere Prozessoren auswählen, um ihn bzw. sie dem Auftragsetikett auf der Basis von durch den Client bereitgestellten Kriterien oder auf der Basis eines Satzes von Standardkriterien, einschließlich Standardkriterien der Industrie, zuzuweisen. Das Dienstezentrum kann Mechanismen bereitstellen, um einen Zugriff auf das Auftragsetikett oder auf Abschnitte (Zweige) des Auftragsetiketts zu steuern. Die Mechanismen umfassen ein Zweigsperren und Autorisierungs- und Authentifizierungsserver, die eine Verschlüsselung von öffentlichen Schlüsseln oder ähnliche Prozesse verwenden.

Das Dienstezentrum kann Hardware-Komponenten, wie bei­ spielsweise Server, Computer, Zentralverarbeitungseinhei­ ten, Kommunikationsschnittstellen und Speichergeräte umfas­ sen, um die Verarbeitungsfähigkeit und Datenspeicherung be­ reitzustellen, die erforderlich ist, um die oben beschrie­ benen Funktionen zu erfüllen.

Das DIW-Netz 20 umfaßt einen Vorfelddienst 30, der es einem Client 31 ermöglicht, eine Dienst- oder Auftragsanforderung zu erzeugen und zu unterbreiten. Bei einem Ausführungsbei­ spiel kann der Vorfelddienst 30 ein Internet-Webbrowser sein. Alternativ dazu kann der Vorfelddienst 30 eine Web- Anwendung oder eine Port-Überwachungseinrichtung sein. Die Auftragsanforderung kann detaillierte Informationen darüber enthalten, wie der Auftrag auszuführen ist, und kann gemäß dem Auftragsdefinitionsformatstandard formatiert sein. Al­ ternativ dazu umfaßt die Auftragsanforderung eventuell le­ diglich grundlegende Informationen, die durch eine andere Komponente verwendet werden, um die Auftragsdefinition oder den Arbeitsfluß abzuschließen. Schließlich kann die Auf­ tragsanforderung den zu verarbeitenden Inhalt oder Auftrag umfassen. Der Inhalt könnte eine oder mehrere digitale Da­ teien, Textdateien und andere Dateien sein. Der Vorfeld­ dienst 30 ist mit einem Kommunikationsnetz 35 gekoppelt, das beispielsweise das Internet oder ein lokales Netz sein kann. Mit dem Kommunikationsnetz 35 ist ein Dienstezentrum 40 gekoppelt, das einen oder mehrere Prozessoren 80 _i mit dem Kommunikationsnetz 35 verknüpft. Jeder der Prozessoren 80 _i kann einen Cache 81 _i umfassen, der verwendet werden kann, um Informationen zu speichern, die sich auf eine Auf­ tragsanforderung beziehen, einschließlich Informationen, die sich auf Auftragsetiketten beziehen. Bei einem Ausfüh­ rungsbeispiel kann das Dienstezentrum 40 eine Internet- Website sein, die Datenspeicher- und -steuerfunktionen um­ faßt. Bei einem anderen Ausführungsbeispiel ist das Dienstezentrum 40 ein Knoten in einem lokalen Netz.

Das Dienstezentrum 40 ermöglicht ein breites Spektrum von Kommunikationen zwischen Entitäten, die mit dem Dienste­ zentrum 40 gekoppelt sind. Insbesondere ermöglicht das Dienstezentrum 40 verschiedenen E-Diensten, unter Verwen­ dung von spezifischen Protokollen und generischen Protokol­ len (z. B. TCP/IP) programmatisch miteinander zu interagie­ ren. Diese programmatische Interaktion ermöglicht es ver­ schiedenen Diensten und Prozessen, die mit dem Netz gekop­ pelt sind, Daten und Dateien auszutauschen und die Daten und Dateien zu modifizieren. Die programmatische Interakti­ on kann durch eine Verwendung eines Fernprozedurrufs (RPC - remote procedure call) zwischen Entitäten, die mit dem Dienstezentrum 40 gekoppelt sind, abgeschlossen werden. An­ dere Verfahren zum Bereitstellen der programmatischen In­ teraktion umfassen CORBA, UDDI und E-speak.

Fig. 4 ist ein Diagramm des Dienstezentrums 40. Das Dien­ stezentrum 40 umfaßt einen Dienstebus 41, der sich in Kommunikation mit dem Kommunikationsnetz 35 und den Prozessoren 80 _i der Fig. 3 befindet. Mit dem Dienstebus 41 ist ein Auftragsspeicher 50, ein Auftragsetikettdienst 60, eine Arbeitsflußsteuerung 70, ein optionaler Angebotsdienst 90, ein Autorisierungsserver 92 und ein Authentifizierungsserver 94 gekoppelt. Der Auftragsspeicher 50 kann eine oder mehrere Auftragsinhaltsdateien 51 _i speichern. Der Auftragsetikettdienst 60 kann ein oder mehrere Auftragsetiketten 61 _i steuern. Die Arbeitsflußsteuerung 70 kann einen oder mehrere Agenten 71 _i verwenden, um Prozesse an dem Dienstebus 41 zu steuern.

Der Auftragsspeicher 50, der Auftragsetikettdienst 60 und die Arbeitsflußsteuerung 70 funktionieren so, daß sie In­ formationen von den Clients 31 entgegennehmen und die In­ formationen verwenden, um die Aktionen der Prozessoren 80 _i zu steuern. Die Prozessoren 80 _i erfüllen spezifische Aufga­ ben oder Prozesse, wie sie durch das Dienstezentrum 40 be­ stimmt sind.

Der Auftragsspeicher 50 kann ein Knoten an dem Dienstebus 41 sein und kann eine Programmierung umfassen, um es dem Auftragsspeicher 50 zu ermöglichen, seine Funktionen auszu­ führen. Der Auftragsspeicher 50 kann verwendet werden, um den Inhalt 51 zu speichern, der in Form einer oder mehrerer großer Dateien vorliegen kann. Im Zusammenhang eines Dru­ ckens eines Dokuments unter Verwendung eines Dienstes oder Prozesses, der mit dem Dienstebus 41 gekoppelt ist, kann der Auftragsspeicher 50 den Dokumenteninhalt beispielsweise in einer oder mehreren PDF-Dateien speichern. Der Inhalt 51 kann Graphiken und Text umfassen. Der Inhalt 51 für ein spezifisches Dokument kann mehrere Dateien umfassen. Bei­ spielsweise kann eine Broschüre eine separate Datei für den Einband und eine andere Datei für die Innenseiten aufwei­ sen. Text für die Innenseiten kann in einer Datei vorlie­ gen, und Bilder können in einer weiteren Datei vorliegen. Der Inhalt 51 kann ferner Verknüpfungen zu anderen Ressour­ cen oder Entitäten auf dem Dienstebus 41 umfassen. Der Auf­ tragsspeicher 50 sorgt für eine Massenspeicherung des In­ halts 51, so daß ein Benutzer (Client 31 oder Prozessor 80) nicht die für den Auftragsinhalt 51 erforderliche Massen­ speicherung bereitstellen muß. Durch Verwenden der Massen­ speicherfähigkeiten des Auftragsspeichers 50 kann dafür ge­ sorgt werden, daß der Inhalt 51 in dem Netz 20 fortbesteht und daß er jederzeit für Benutzer zugreifbar gemacht wird. Ferner verwaltet und steuert der Auftragsspeicher 50 den Inhalt, so daß der Benutzer (Client 31 oder Prozessor 80) den Inhalt 51 nicht verwalten muß. Verwaltungsfunktionen umfassen ein Aufrechterhalten einer Konfiguration oder Ver­ sionssteuerung des Inhalts 51, ein Steuern des Zugriffs auf den Inhalt 51 und ein Beibehalten des Inhalts 51 in einer Speicherung.

Der Auftragsetikettdienst 60 hält Auftragsetiketten 61. Der Auftragsetikettdienst 60 steuert einen Zugriff auf die Auf­ tragsetiketten 61 und verwaltet eventuell eine Konfigurati­ on derselben. Beispielsweise kann es der Auftragsetikett­ dienst 60 Benutzern (Clients 31 und Prozessoren 80) ermög­ lichen, auf einen Abschnitt oder Zweig eines Auftragseti­ ketts 61 zuzugreifen, statt das Auftragsetikett 61 unter mehreren Benutzern herumzureichen. Ein Zugriff auf den Auf­ tragsetikettabschnitt kann durch Verwendung einer Anwen­ dungsprogrammierschnittstelle, einer skriptfähigen Schnitt­ stelle oder eines ähnlichen Merkmals bewirkt werden. Wie oben angemerkt wurde, umfaßt das Auftragsetikett 61 nicht den Inhalt 51 (z. B. die graphischen und Textdateien eines Dokuments), sondern das Auftragsetikett 61 bezieht sich auf den in dem Auftragsspeicher 50 gespeicherten Inhalt 51 (z. B. eine PDF-Datei). Der Benutzer muß nicht die Speicherung des Auftragsinhalts verwalten oder wissen, welcher Auf­ tragsspeicher 50 den Auftragsinhalt enthält. Statt dessen vergibt der Auftragsetikettdienst 60 einen Verweis in dem Auftragsetikett 61. Dies ermöglicht es mehreren Clients 31 und Prozessoren 801, auf den Inhalt 51 zuzugreifen. Über­ dies kann sich der Inhalt 51 auf mehr als ein Auftragseti­ kett 61 beziehen. Der Auftragsetikettdienst 60 und seine Beziehungen zu anderen Entitäten, die mit dem Dienstebus 41 gekoppelt sind, werden später ausführlich beschrieben.

Auf manche Auftragsetiketten 61 kann durch mehrere Prozes­ soren 80 _i entweder auf serielle, überlappende oder gleich­ zeitige Weise zugegriffen werden. Das Mehrfachzugriff- Verarbeiten könnte zu Problemen bei Verwendung des Auf­ tragsetiketts 61 führen. Beispielsweise kann es sein, daß ein erster Prozessor das Auftragsetikett 61 (oder einen Ab­ schnitt oder Zweig desselben) erlangt und einen in dem Ar­ beitsfluß spezifizierten Prozeß durchführt, der den Zweig modifizieren kann. Eine solche Modifizierung kann stattfin­ den, um beispielsweise einen Zweig als vollständig an­ zugeben, Eingangsressourcen aufzubrauchen oder neue Ausgangsressourcen zu schaffen. Ein zweiter Prozessor könnte versuchen, den Zweig zu erlangen, "weiß" jedoch möglicherweise nicht, daß der erste Prozessor den Zweig modifiziert hat. Alternativ dazu könnte eine Blockierungssituation entstehen, wenn zwei Prozessoren um den selben Zweig konkurrieren.

Eine Lösung der obigen Probleme könnte darin bestehen, das Auftragsetikett 61 immer dann zu sperren, wenn ein Prozes­ sor 80 das Auftragsetikett 61 erlangt. Ungünstigerweise kann ein Sperren des Auftragsetiketts 61 ein gleichzeitiges oder paralleles Verarbeiten verhindern und eine Fertigstel­ lung der Auftragsanforderung verlangsamen.

Der in Fig. 4 gezeigte Auftragsetikettdienst 60 überwindet diese und andere Probleme, indem er die Fähigkeit aufweist, das Auftragsetikett 61 auf der Zweigebene zu sperren. Die Zweigsperrung kann durch eines von mehreren Verfahren be­ werkstelligt werden. Die Arbeitsflußsteuerung 70 kann einen oder mehrere spezifische Prozessoren 80 _i einteilen, die Aufgaben, die bei dem zu sperrenden Zweig identifiziert sind, zu erfüllen. Wenn lediglich ein Prozessor 80 _i autori­ siert ist, auf den Zweig zuzugreifen, ist ein Zweigsperren eventuell nicht erforderlich. Wenn mehr als ein Prozessor 80 autorisiert ist, auf denselben Zweig zuzugreifen, kann der Auftragsetikettdienst 60 den Zweig sperren, wenn einer der autorisierten Prozessoren 80 _i den Zweig tatsächlich er­ langt.

Wenn die Arbeitsflußsteuerung 70 Zweigen keine Prozessoren 80 _i zugewiesen hat (d. h. ein beliebiger Prozessor 80 kann zu jeder Zeit auf einen Zweig zugreifen), kann der Auf­ tragsetikettdienst 60 den Zweig sperren, wenn ein Prozessor 80 den Zweig erlangt.

Der Auftragsetikettdienst 60 kann die Zweige sperren, indem er für jeden Zweig ein Sperren-/Entsperren-Flag setzt. Pro­ zessoren 80 _i, die auf das Auftragsetikett 61 zugreifen, können daraufhin den Sperren-/Entsperren-Flag-Status prü­ fen, um zu bestimmen, ob auf den Zweig zugegriffen werden kann. Unter manchen Umständen erlaubt der Auftragsetikett­ dienst 60 eventuell lediglich einen Zugriff auf diejenigen Zweige, die entsperrt sind. Es kann sein, daß ein Prozessor 80, der eine durch den Zweig definierte Aufgabe erfüllt hat, benötigt, daß der Zweig entsperrt ist, um den Zweig zu modifizieren.

Bei einem Ausführungsbeispiel kann der Prozessor 80, der auf einen Zweig zugreift und dadurch bewirkt, daß der Zweig gesperrt wird, mit einem Schlüssel versehen sein. Um den Zweig später zu ent sperren (z. B. um den Zweig zu modifi­ zieren), muß der Prozessor 80 den Schlüssel an den Auf­ tragsetikettdienst 60 zurückgeben.

Ein Prozessor 80, der zu einem Zugriff auf einen spezifi­ schen Zweig 66 autorisiert ist, kann den Schlüssel an einen weiteren autorisierten Prozessor 80 weitergeben. Um eine nicht autorisierte Verwendung des Schlüssels zu verhindern, kann der Schlüssel verschlüsselt werden. Ein Schlüsselver­ schlüsselungssystem wird später beschrieben. Indem der Schlüssel unter autorisierten Prozessoren 80 _i weitergelei­ tet wird, werden die Kommunikationen mit dem Dienstezentrum minimiert, wodurch die Betriebseffizienz erhöht wird.

Bei einem anderen Ausführungsbeispiel ist der gesperrte Zweig gesperrt, um lediglich eine Zweigmodifizierung zu verhindern, und nur der Prozessor 80, der den oben be­ schriebenen Schlüssel oder einen auf andere Weise autori­ sierten Zugriff zu Modifizierungszwecken aufweist, kann den Zweig auch tatsächlich modifizieren. Jedoch können andere Prozessoren 80 in einem Nur-Lese-Modus auf den Zweig zugreifen. Um einen Zugriff auf das Auftragsetikett 61 wei­ ter zu begrenzen, können die anderen Prozessoren 80, die in einem Nur-Lese-Modus auf den Zweig zugreifen können, in dem Aufgabenabschnitt 68 des Auftragsetiketts 61 aufgeführt sein.

Bei einem anderen Ausführungsbeispiel wird ein Zweigsperren durch den Auftragsetikettdienst 60 gesteuert. Der Auftrags­ etikettdienst kann eine Datentabelle umfassen, die zeigt, welche der Prozessoren 80 _i dazu autorisiert sind, auf spe­ zifische Auftragsetiketten 61 oder Zweige 66 zuzugreifen.

Wenn ein Prozessor 80 beispielsweise einen Zweig 66 erlangt hat, kann der Auftragsetikettdienst 60 die Datentabelle markieren, um den Zugriff anzugeben. Nachfolgenden Prozes­ soren 80 _i, die versuchen, auf denselben Zweig 66 zuzugrei­ fen, kann ein Zugriff verwehrt werden, bis die Datentabelle geändert ist, um anzugeben, daß der erste Prozessor 80 nicht länger über einen Zugriff auf den Zweig 66 verfügt. Alternativ dazu können die nachfolgenden Prozessoren 80 eventuell auf eine Nur-Lese-Weise auf den Zweig 66 zugrei­ fen.

Die Arbeitsflußsteuerung 70 kann verwendet werden, um die Auftragsetiketten 61 _i zu erstellen, die in dem Auftragseti­ kettdienst 60 gespeichert sind. Die Arbeitsflußsteuerung 70 kann die durch die Clients 31 unterbreiteten Auftragsanfor­ derungen 32 überprüfen und kann daraufhin eine Auftragseti­ kettschablone verwenden, um das Auftragsetikett 61 zu er­ stellen. Die Arbeitsflußsteuerung 70 kann daraufhin das Auftragsetikett 61 zur Speicherung und Verarbeitung an den Auftragsetikettdienst 60 senden.

Die Arbeitsflußsteuerung 70 steuert ferner einen Abschluß von Aufgaben unter den Prozessoren 80. Bei einem Ausfüh­ rungsbeispiel bestimmt die Arbeitsflußsteuerung 70, welche der Prozessoren 80 die notwendigen und verfügbaren Ressour­ cen aufweisen, um die in einem spezifischen Auftragsetikett 61 aufgeführten Prozesse zu beginnen. Daraufhin benennt die Arbeitsflußsteuerung 70 die geeigneten Prozessoren 80 _i, um die durch das Auftragsetikett 61 ausgewiesenen Aufgaben zu erfüllen. Wenn ein Auftragsetikett 61 ₁ beispielsweise ein Farbdrucken erfordert, kann die Arbeitsflußsteuerung 70 be­ stimmen, daß lediglich der Prozessor 80 ₃ ein Farbdrucker mit der Kapazität ist, den in dem Auftragsetikett 61 ₁ spe­ zifizierten Auftrag zu beginnen. Dieses Ausführungsbei­ spiel, bei dem die Arbeitsflußsteuerung 70 bestimmt, wel­ chen Prozessoren 80 ein spezifisches Auftragsetikett 61 zu­ gewiesen werden soll, kann besonders geeignet sein, wenn das Netz 35 ein lokales Netz ist und alle Prozessoren 80 direkt mit dem lokalen Netz 35 gekoppelt sind.

Alternativ dazu kann die Arbeitsflußsteuerung 70 Angebots­ informationen von mit dem Internet verbundenen Prozessoren 80 _i empfangen und kann die Angebotsinformationen verwenden, um die Prozessoren 80 _i, die die Auftragsanforderung 32 er­ füllen sollen, auszuwählen.

Die Arbeitsflußsteuerung 70 kann ferner verwendet werden, um diverse Knoten, Eingangs- und Ausgangsressourcen und an­ dere Merkmale des Knotenbaumes, die verwendet werden, um die Auftragsanforderung zu erfüllen, zu benennen. Das heißt, daß die Arbeitsflußsteuerung 70 verwendet werden kann, um ein Konstrukt, oder einen Arbeitsfluß, wie bei­ spielsweise den in Fig. 2 gezeigten Knotenbaum 10, zu erstellen. Um diese Aufgaben zu bewerkstelligen, kann die Arbeitsflußsteuerung 70 einen oder mehrere Agenten 71 _i umfassen, die eine Auftragsdefinitionsdatei schreiben, auf der Basis von Steuerdaten, die in der Auftragsanforderung 32 enthalten sind. Alternativ dazu kann ein separates Ver­ waltungsinformationssystem (nicht gezeigt) verwendet wer­ den, um die Knoten zu erstellen und um einen Fluß von Auf­ gaben zu den Prozessoren 80 _i und anderen Entitäten zu steu­ ern. Bei einem anderen Ausführungsbeispiel können die Auf­ tragsdefinitionen durch den Client 31, der die Auftragsan­ forderung 32 hervorbrachte, geschrieben sein.

Unter erneuter Bezugnahme auf den Knotenbaum 10 der Fig. 2 dienen viele Ausgangsressourcen der einzelnen Knoten als Eingangsressourcen für andere Knoten. Diese anderen Knoten sind eventuell nicht in der Lage, mit dem Ausführen zu be­ ginnen, bevor alle Eingangsressourcen vollständig und ver­ fügbar sind, was bedeutet, daß die Knoten eventuell in ei­ ner hinreichend definierten Abfolge ausführen müssen. Bei­ spielsweise erzeugt ein Prozeß zum Herstellen von Platten Preßplatten als eine Ausgangsressource, die von einem Druckprozeß benötigt wird. Bei der hierarchischen Organisa­ tion des Knotenbaums 10 stellen Knoten, die höher in dem Knotenbaum 10 erscheinen, abstraktere Operationen einer hö­ heren Ebene dar, während Knoten niedrigerer Ordnung detail­ liertere, spezifische Prozesse darstellen. Überdies ist es möglich, daß Knoten, die sich in der Nähe des oberen Endes des Knotenbaums 10 befinden, lediglich eine Absicht bezüg­ lich der Komponenten oder Anordnungen, die das Produkt auf­ weisen, darstellen, und Knoten einer niedrigeren Ebene lie­ fern die ausführlichen Anweisungen an einen Prozessor 80, um einen spezifischen Prozeß durchzuführen.

Da zwei Knotenbäume eventuell nicht ähnlich sind, kann die Arbeitsflußsteuerung 70 folgendes bestimmen: auszuführende Prozesse, die Reihenfolge, in der die Prozesse ausgeführt werden, und die Prozessoren 80 _i, die die Prozesse ausführen sollen. Die Arbeitsflußsteuerung 70 kann die Agenten 71 _i verwenden, um einen tatsächlichen Arbeitsfluß unter Anbet­ racht von Faktoren wie zum Beispiel Steuerfähigkeiten der Prozessoren, die die Prozesse ausführen, Transportentfer­ nungen zwischen Prozessoren, Belastungsvermögen der Prozes­ soren und Zeitbeschränkungen bei der Auftragsanforderung zu bestimmen. Die Agenten 71 können den Gesamtprozeß unter Verwendung einer seriellen Verarbeitung, die eine(n) nach­ einander erfolgende(n) Herstellung und Verbrauch von Res­ sourcen durch die Prozessoren 80 _i beinhaltet, einer über­ lappenden Verarbeitung, die eine(n) gleichzeitige(n) Verbrauch und Herstellung von Ressourcen durch mehr als ei­ nen Prozessor 80 _i beinhaltet, einer parallelen Verarbei­ tung, die ein gemeinsames Verwenden von Ressourcen durch Prozessoren 80 beinhaltet, und einer iterativen Verarbei­ tung, die ein Vorwärts- und Rückwärts-Verarbeitungsschema beinhaltet, um Ressourcen zu entwickeln, definieren.

Beim Bestimmen, welchem der Prozessoren 80 _i die Erfüllung einer bestimmten Auftragsanforderung zuzuweisen ist, kann die Arbeitsflußsteuerung 70 Prozessoren 80 _i, abfragen, die mit dem Dienstezentrum 40 gekoppelt sind. Wie oben ange­ merkt wurde, können die Prozessoren 80 _i direkt mit dem Dienstebus 41 gekoppelt sein oder können durch einen ande­ ren Kommunikationsbus, wie beispielsweise das Internet, in­ direkt gekoppelt sein. Das Abfragen kann immer dann statt­ finden, wenn ein Auftragsetikett 61 durch den Auftragseti­ kettdienst 60 erstellt wird. Alternativ dazu kann das Ab­ fragen und eine entsprechende Informationssammlung auf pe­ riodischer Basis stattfinden, und die Arbeitsflußsteuerung 70 kann Informationen, die sich auf die Prozessoren 80 _i be­ ziehen, speichern.

Als Alternative zum Abfragen können Prozessoren 80 _i, die mit dem Dienstezentrum 40 gekoppelt sind, den Auftragseti­ kettdienst 60 überwachen. Der Auftragsetikettdienst 60 kann beispielsweise nach Art eines schwarzen Brettes Nachrichten bezüglich Auftragsetiketten, die zum Verarbeiten zur Verfü­ gung stehen, periodisch plazieren. Die Prozessoren 80 _i kön­ nen daraufhin ein Angebot für die in der Auftragsetikett­ meldung definierten Aufgaben und Prozesse unterbreiten. Bei einem Ausführungsbeispiel können die Angebote digital sig­ niert sein. Die Arbeitsflußsteuerung 70 oder der separate, optionale Angebotsdienst 90, kann die Angebote prüfen und bestimmen, welcher einzelne Prozessor 80 oder welche Kombi­ nation von Prozessoren 80 _i am besten geeignet wäre, um die in der Auftragsetikettmeldung definierten Aufgaben und Pro­ zesse zu erfüllen. Die Arbeitsflußsteuerung 70 kann einen Zugriff auf die Angebote steuern, so daß lediglich der Pro­ zessor 80, der ein Angebot unterbreitet, die in demselben enthaltenen Angebotsinformationen einsehen kann.

Das Dienstezentrum 40 kann mehrere Merkmale umfassen, um eine Sicherheit bereitzustellen und um einen Zugriff auf das Auftragsetikett 61 zu steuern. Wie oben erörtert wurde, kann der Auftragsetikettdienst 60 eine Vorkehrung für eine Zweigsperrung umfassen. Überdies können Server verwendet werden, um einen Prozessor 80 zu autorisieren und authenti­ fizieren und um die Autorisierung und Authentifizierung während einer Fertigstellung einer Auftragsanforderung 32 aufrechtzuerhalten. Der Authentifizierungsserver 92 emp­ fängt Authentifizierungsinformationen von einem Prozessor 80, und der Autorisierungsserver 94 verwendet die Informa­ tionen, um eine Autorisierungsfunktionalität zu prüfen. Die Autorisierung oder Zugriffsrechte des Prozessors 80 können als Teil des Auftragsetiketts 61 getragen werden. Die Ser­ ver 92 und 94 können Hardwaregeräte sein, müssen jedoch nicht in derselben Hardwareplattform existieren, und die Server 92 und 94 müssen nicht eng gekoppelt sein. Alterna­ tiv dazu können die Funktionen der Server 92 und 94 bei ei­ ner Programmierung durchgeführt werden, die in einer der Komponenten des Dienstezentrums 40 gespeichert ist, wie beispielsweise die Arbeitsflußsteuerung 70. Unter Verwen­ dung der oben beschriebenen Merkmale kann das Dienste­ zentrum 40 dem Autorisierungsserver 94 vertrauenswürdige Authentifizierungsinformationen über den Prozessor 80 lie­ fern, und daraufhin führt der Autorisierungsserver 94 seine Autorisierungsprüfungsfunktionen durch.

Das Auftragsetikett 61 kann mit einer Industriestandard- Öffentlicher-Schlüssel-Verschlüsselung-Nachrichtenauszug- (MD-)Signatur (MO = message digest) signiert sein und kann durch ein Öffentlicher-Schlüssel-Verschlüsselungssystem ge­ schützt sein. Daher kann jeder beliebige Benutzer, der den öffentlichen Schlüssel aufweist, das Auftragsetikett 61 be­ stätigen, ohne daß er mit dem Authentifizierungsserver 92 kommunizieren muß. Diese Merkmale verringern eine Kommuni­ kation zwischen verteilten Serveranwendungen. Die Merkmale ermöglichen ferner, daß das Auftragsetikett 61 von einem Prozessor 80 zu einem anderen Prozessor 80 geleitet wird, wobei eine Sicherheit aufrechterhalten wird und wobei nicht mit dem Dienstezentrum 40 kommuniziert wird.

Bei einem alternativen Ausführungsbeispiel hält das Auf­ tragsetikett 61 Authentifizierungs-/Zugriffsdaten, was ei­ nen begrenzten Zugriff in der Infrastruktur des Dienste­ zentrums 40 ermöglicht. Ressourcen können durch Paßwörter und andere Mechanismen geschützt sein. Ein Zugriff auf das Auftragsetikett 61 kann auf ähnliche Weise geschützt sein.

Überdies können Prozessoren 80 _i mit einer Zugriffsautori­ sierung eine solche Zugriffsautorisierung aufweisen, die durch ein Auflisten der Prozessoren in dem Auftragsetikett hervorgerufen ist. Die Auflistung kann beispielsweise durch ein Aufnehmen einer Netzadresse für die Prozessoren 80 _i be­ wirkt werden. Die Netzadresse kann in den in dem Auftrags­ etikett 61 aufgenommenen Angebotsinformationen enthalten sein.

Obwohl sich die obige Beschreibung auf eine Entwicklung durch die Arbeitsflußsteuerung 70 bezieht, können andere Komponenten in dem Netz 20 verwendet werden, um einen Ge­ samtarbeitsfluß zu entwickeln, um die Auftragsanforderung 32 zu erfüllen (siehe Fig. 7). Beispielsweise kann der Auf­ tragsetikettdienst 60 verwendet werden, um den Gesamtar­ beitsfluß zu entwickeln.

Wie oben erörtert wurde, kann der Angebotsdienst 90 verwen­ det werden, um Angebotsinformationen von Prozessoren 80 _i, die mit dem Dienstezentrum 40 gekoppelt sind, zu empfangen. Die Prozessoren 80 _i unterbreiten Angebote als Reaktion auf ein Plazieren von Auftragsetikettmeldungen an dem Dienste­ zentrum 40. Bei einem Ausführungsbeispiel ist die Auftrags­ etikettnachricht ein in dem Dienstezentrum 40 gespeichertes separates Objekt. Bei einem anderen Ausführungsbeispiel dient das Auftragsetikett 61 selbst der Meldungsfunktion. Die Arbeitsflußsteuerung 70 kann die Auftragsetikettmeldun­ gen nach Empfang der Auftragsanforderung 32 plazieren. Der Angebotsauswertungs- und -auswahlprozeß können derselbe sein, ob nun der Angebotsdienst 90 oder die Ar­ beitsflußsteuerung 70 die Angebote empfängt.

Die durch die Arbeitsflußsteuerung 70 plazierte Auftrags­ etikettmeldung kann spezifische Aufgaben oder Prozesse (Zweige) umfassen, die erfüllt werden müssen, um die Auf­ tragsanforderung 32 zu erfüllen. Es kann sein, daß eine einfache Auftragsanforderung 32 lediglich einen Zweig auf­ weist. Komplexere Auftragsanforderungen 32, wie beispiels­ weise die in Fig. 2 veranschaulichte Auftragsanforderung (d. h. Drucken einer Broschüre), können viele Zweige auf­ weisen. Ferner können manche Zweige so zueinander in Bezie­ hung stehen, daß sie nur in einer spezifischen Abfolge er­ füllt werden können, während andere Zweige auf parallele oder überlappende Weise erfüllt werden können. Diese Abhän­ gigkeitsbeziehung kann oft das Ergebnis dessen sein, daß ein Zweig eine Ausgangsressource erzeugt, die eine Ein­ gangsressource für einen oder mehrere andere Zweige ist. Die Auftragsetikettnachricht kann Beschreibungen spezifi­ scher Zweige und ihrer Abhängigkeitsbeziehungen ausreichend detailliert umfassen, um es den Prozessoren 80 _i zu ermögli­ chen, eine Fertigstellung der Zweige anzubieten. Die Auf­ tragsetikettmeldung kann über einen festgelegten Zeitraum in dem Dienstezentrum 40 fortbestehen, um es den Prozesso­ ren 801 zu ermöglichen, Angebote zu senden. Die Zeit kann ein eingestellter Wert (z. B. eine Stunde) sein oder kann auf einer in der Auftragsanforderung 32 festgelegten Fer­ tigstellungsfrist basieren.

Der Angebotsdienst 90 kann auf der Basis von festgelegten Kriterien Angebote 91 von den Prozessoren 80 auswählen. Beispielsweise kann die Auftragsanforderung 32 minimale Leistungserfordernisse (z. B. maximale Kosten und eine Fer­ tigstellungsfrist) festlegen. Der Angebotsdienst 90 kann alle Angebote, die die minimalen Leistungserfordernisse nicht erfüllen, zurückweisen. Wenn die Arbeitsflußsteuerung 70 mehrere Zweige erstellt hat, kann jeder solche Zweig mi­ nimale Leistungserfordernisse umfassen. Die zweigspezifi­ schen Leistungserfordernisse können durch die Ar­ beitsflußsteuerung 70 auf der Basis von Gesamtleistungser­ fordernissen für das Auftragsetikett 61 festgelegt werden. Ein Prozessor 80, der bezüglich eines bestimmten Zweiges anbietet, kann durch den Angebotsdienst 90 zurückgewiesen werden, wenn der Prozessor 80 die minimalen Leistungserfor­ dernisse nicht erfüllt.

Wenn der Client 31 keine minimalen Leistungserfordernisse festlegt, kann der Angebotsdienst 90 einen standardmäßigen Satz von Kriterien (z. B. einen Industriestandard) anwen­ den. Ferner muß das Angebot jegliche Erfordernisse bezüg­ lich eines Erzeugens von Ausgangsressourcen erfüllen. Dies­ bezüglich können Angebote, die versehentlich gemacht werden oder die ansonsten wahrscheinlich zurückgewiesen würden, aussortiert werden. Beispielsweise kann ein Angebot zum Drucken von Innenseiten der Broschüre ein Fertigstellungs­ datum von einem Jahr angeben. Ein solches Angebot wird eventuell zurückgewiesen, auch bei Abwesenheit jeglicher festgelegter Leistungserfordernisse von dem Client 31.

Zusätzlich zu einem Unterbreiten von Leistungserfordernis­ sen kann der Client 31 einen Auswertungsalgorithmus zum Auswerten von Angeboten spezifizieren. Beispielsweise kann der Client 31 festlegen, daß Kosten zweimal so stark zu ge­ wichten sind wie jegliche andere Leistungserfordernisse.

In der Abwesenheit eines durch einen Client festgelegten Auswertungsalgorithmus kann der Angebotsdienst 90 einen standardmäßigen Auswertungsalgorithmus anwenden, um Angebo­ te für jeden Zweig in dem Arbeitsfluß in eine Rangordnung zu bringen. Der Auswertungsalgorithmus kann Gewichtungskri­ terien anwenden oder kann eine vorgegebene Regel anwenden. Beispielsweise können Angebote auf der Basis einer maxima­ len Punktzahl in eine Rangordnung gebracht werden, wobei Punkte für Kostenschätzungen unter einem Maximum und für Fertigstellungszeiten unter einem Maximum vergeben werden. Nachdem der Auswertungsalgorithmus angewendet wurde, bringt der Angebotsdienst 90 die Angebote für jeden Zweig in eine Rangordnung. Wenn lediglich ein Prozessor 80 den Prozeß überlebt, kann dieser Prozessor 80 automatisch ausgewählt und dem Zweig zugewiesen werden. Wenn mehrere Prozessoren 80 überleben, kann der Angebotsdienst 90 eine Liste dieser Prozessoren 80 _i der Arbeitsflußsteuerung 70 bereitstellen, die daraufhin die Prozessoren 80 _i auswählt, die den Zweigen zuzuweisen sind. Alternativ dazu kann die Liste dem Client 31 bereitgestellt werden, und der Client 31 kann den bzw. die Prozessor(en) 80 _i auswählen, der bzw. die die in dem Arbeitsfluß definierten Aufgaben erfüllen soll bzw. sollen.

Die Arbeitsflußsteuerung 70 kann als Gewinner hervorgehende Angebote entsprechenden Zweigen zuordnen und kann die Ange­ botsinformationen mit dem Auftragsetikett 61 speichern. Die gespeicherten Angebotsinformationen können Identifizie­ rungsinformationen umfassen, die es dem Autorisierungsser­ ver 94 und dem Authentifizierungsserver 92 ermöglichen, ei­ nen Zugriff auf Auftragsetikettzweige oder auf das gesamte Auftragsetikett 61 zu erlauben. Da die Angebotsinformatio­ nen mit dem Auftragsetikett 61 gespeichert sind, kann ein Prozessor 80 auf diejenigen Zweige, für die der Prozessor 80 autorisiert ist, zugreifen, ohne direkt mit dem Auf­ tragsetikettdienst 61 kommunizieren zu müssen. Dieses Merk­ mal ermöglicht es, daß das Auftragsetikett 60 von einem Prozessor 80 zu einem anderen Prozessor 80 weitergereicht wird, was die Verarbeitungszeit und -effizienz verbessert.

Bei einem Ausführungsbeispiel greift die Arbeitsflußsteue­ rung 70 auf Steuerdaten des Auftragsetiketts 61 zu, um zu bestimmen, welche(r) Prozessor(en) 80 _i, der in dem Auftrags­ etikett identifizierten spezifischen Aufgabe zugewiesen werden sollte bzw. sollten. Die Arbeitsflußsteuerung 70 kann ferner identifizieren, welche(r) der Prozessoren 80 in der Lage wäre(n), die in den Steuerdaten festgelegten Kri­ terien zu erfüllen, und kann dem Client durch den Vorfeld­ dienst 30 eine Liste solcher Prozessoren 80 bereitstellen. Der Client 31 kann dann (einen) Prozessor(en) 80 aus der Liste auswählen.

Bei einem Ausführungsbeispiel kann der Auftragsetikett­ dienst als eine Abfolge von Programmierungsanweisungen imp­ lementiert sein, die auf einer maschinenlesbaren Vorrich­ tung, beispielsweise einem CD-ROM, aufgenommen sind. Die maschinenlesbare Vorrichtung wird daraufhin von einem Com­ puterprozessor gelesen, der die Abfolge von Programmie­ rungsschritten ausführt, um die Funktionen des Auftragseti­ kettdienstes zu erfüllen.

Fig. 5A veranschaulicht ein beispielhaftes Auftragsetikett 61. Das Auftragsetikett 61 kann zwei Teile umfassen. Ein erster Teil umfaßt einen Rahmen 62 und eine optionale Cli­ ent-Erweiterung 64. Der Rahmen 62 umfaßt Informationen, Dateien und eine Programmierung, die notwendig sind, um Aufgaben, die in dem Auftragsetikett 61 definiert sind, zu steuern. Die Client-Erweiterung 64 kann Informationen um­ fassen, die sich auf einen bestimmten Client (Maschine) und auf einen Benutzer der Maschine beziehen. Ein zweiter Teil umfaßt ein Sicherheitsmodul 67, das das Auftragsetikett 61 vor einem nicht autorisierten Zugriff schützt.

Der Rahmen 62 kann ein Auftragskennzeichen (ID) 63, ein Dienst-ID 65, einen Aufgabenabschnitt 68 und einen Steuer­ datenabschnitt 69 umfassen. Das Auftrags-ID 63 umfaßt einen Verweis auf einen spezifischen Auftrag oder Inhalt 51, der in dem Auftragsspeicher 50 gespeichert ist. Das Auftrags-ID 63 umfaßt ferner einen Verweis auf einen bestimmten Auf­ tragsspeicher 50, der verwendet wird, um den Inhalt 51 zu speichern. Eine Entität, die einen Verweis auf das Auf­ tragsetikett 61 erlangt, kann das Auftrags-ID 63 verwenden, um auf den entsprechenden Inhalt 51 zuzugreifen. Somit kann das in Fig. 3 gezeigte Netz 20 mehrere Auftragsspeicher 50 umfassen, und das Auftrags-ID 63 kann verwendet werden, um das Auftragsetikett 61 mit einem spezifischen Auftragsspei­ cher 50 in Beziehung zu setzen. Das Dienst-ID 65 identifi­ ziert einen spezifischen Auftragsetikettdienst 60, der das Auftragsetikett 61 speichert. Beispielsweise kann das Netz 20 mehrere Auftragsetikettdienste 60 (in Fig. 3 nicht ge­ zeigt) umfassen. Das Dienst-ID 65 wird verwendet, um das Auftragsetikett 61 mit dem entsprechenden Auftragsetikett­ dienst 60 in Beziehung zu setzen.

Der Aufgabenabschnitt 68 (Fig. 5B) kann Zweigdefinitionen und andere Informationen, die benötigt werden, um eine Fer­ tigstellung der Zweige zu steuern, umfassen. Der Aufgaben­ abschnitt 68 kann derart strukturiert sein, daß jeder Zweig oder Knoten in einem Knotenbaum durch einen oder mehrere Zweige 66i in dem Aufgabenabschnitt dargestellt wird. Bei diesem Ausführungsbeispiel kann jeder Knoten in dem Knoten­ baum (z. B. dem Knotenbaum 10 der Fig. 2) dem Knoten, der Beschreibung 95, Ressourcen 96, Sperren-/Entsperren-Flag 97 und Sicherheitsmerkmalen 99 zugeordnet sein. Auf diese Wei­ se reflektiert das Auftragsetikett 61 eine hierarchische Datenbankstruktur.

Der Steuerdatenabschnitt 69 umfaßt die spezifischen Anwei­ sungen, Parameter und Kriterien zum Erfüllen der durch das Auftragsetikett 61 identifizierten Aufgabe. Steuerdaten in dem Steuerdatenabschnitt 69 können ferner jedem Knoten in einem Knotenbaum zugeordnet sein.

Das Sicherheitsmodul 67 steuert einen Zugriff auf ein spe­ zifisches Auftragsetikett. Das Sicherheitsmodul 67 kann un­ ter Verwendung von standardmäßigen Verschlüsselungs- und Zugriffstechniken, einschließlich z. B. Öffentlicher- /Privater-Schlüssel-Infrastrukturen, implementiert werden.

Die Client-Erweiterung 64 kann "Kunden"-Informationen wie beispielsweise das Alter, die Kreditkartennummer und die Postleitzahl des Benutzers enthalten. In der Client- Erweiterung 64 bereitgestellte Informationen können durch Verwendung einer Öffentlicher-Schlüssel-Signatur oder ein ähnliches Merkmal geschützt sein. Daher sind alle Client- Erweiterung-Informationen automatisch in einem Nachrichten­ auswahlprotokoll (MDP - message digest protocol) enthalten und wirken sich auf die Signatur des Auftragsetiketts 61 aus. Bei der oben beschriebenen Auftragsetikettarchitektur nimmt man sich vieler Internet-bezogener Sicherheitsfragen an, einschließlich IP-Schwindel, zeitgesteuerter Sitzungen, Auftragsetikettänderungen, variierender Autorisierungsebe­ nen und einer clientabhängigen Dauerdatenspeicherung.

Das in Fig. 5A gezeigte Auftragsetikett 61 kann verwendet werden, um auf einen spezifischen Inhalt 51 in dem Auf­ tragsspeicher 50 zu verweisen. Alternativ dazu können meh­ rere Auftragsetiketten 61 verwendet werden, um auf einen spezifischen Inhalt 51 zu verweisen, oder es kann ein Auf­ tragsetikett 61 verwendet werden, um auf mehrere Inhalte 51 zu verweisen. Somit kann beispielsweise ein Auftragsetikett 61 eine sich wiederholende Druckaufgabe spezifizieren, die an ähnlichen Dokumenten zu erfüllen ist, von denen jedes einen unterschiedlichen Inhalt 51 aufweist.

Unter Verwendung des in Fig. 3 gezeigten Netzes 20 und des in Fig. 5A gezeigten entsprechenden Auftragsetiketts kann ein Client 31 viele verschiedene elektronische Dienste an­ fordern und ausführen lassen. Beispielsweise kann der Cli­ ent 31 das Netz 20 als E-Mail-Anwendung verwenden.

Fig. 5B zeigt den Aufgabenabschnitt 68 im Detail. Der Auf­ gabenabschnitt 68 kann einen oder mehrere Zweigdeskriptoren 66 umfassen, die Informationen umfassen, welche sich auf eine Verarbeitung für diesen Zweig beziehen. Ein Beschrei­ bungssegment 95 kann die für jeden Zweig zu erfüllenden Aufgaben definieren. Alternativ dazu kann das Beschrei­ bungssegment 95 eine Verknüpfung mit oder eine Kennung zu einer Datei bereitstellen, die die Zweigbeschreibung ent­ hält. Das Ressourcensegment 96 listet Eingangs- und Aus­ gangsressourcen, die den für den Zweig definierten Aufgaben zugeordnet sind, auf. Das Sperren-/Entsperren-Flag-Segment 97 ermöglicht es einem Flag, auf ein Sperren und Entsperren eines Zweiges gesetzt zu sein. Ein Angebotsinformationsseg­ ment 98 umfaßt Angebotsinformationen, die beispielsweise durch den Angebotsdienst 90 gesammelt wurden. Die Angebots­ informationen 98 können detaillierte Informationen wie bei­ spielsweise die IP-Adresse der Prozessoren, die zu einem Zugriff auf den Zweig autorisiert sind, geschätzte Leis­ tungsinformationen (z. B. geschätzte Kosten, Lieferzeit) und andere Informationen umfassen. Alternativ dazu können die Angebotsinformationen 98 eine Verknüpfung mit einer an­ deren Datei enthalten, die die ausführlichen Angebotsinfor­ mationen enthält. Das Sicherheitssegment 99 kann autori­ sierte Sicherheitsebenen angeben und kann als Teil einer Öffentlicher-Schlüssel/Privater-Schlüssel-Infrastruktur verwendet werden. Die Sicherheitsfunktionen verhindern un­ ter Umständen, daß ein Prozessor 80 auf ein Angebot bezüg­ lich Informationen von anderen Prozessoren 80 _i zugreift.

Fig. 5C veranschaulicht ein Ausführungsbeispiel des Steuer­ datenabschnitts 69. Der Steuerdatenabschnitt 69 umfaßt eine Client-Adresse, die eine Maschinenadresse sein kann, wie beispielsweise eine IP-Adresse (IP = Internet protocol, In­ ternet-Protokoll). Ein Ablaufdatum-/-Zeitsegment kann ver­ wendet werden, um einen aktiven Status des Etiketts 61 zu beenden. Nachdem dieser beendet wurde, kann das Etikett aus dem Auftragsetikettdienst 60 gelöscht werden, und der ent­ sprechende Inhalt 51 kann einer Verweisaufhebung unterzogen werden. Dieses Merkmal kann dazu beitragen, veraltete Daten zu beseitigen und Ressourcen für andere Auftragsanforderun­ gen 32 freizumachen (siehe Fig. 7). Insbesondere ermöglicht dieses Merkmal, daß der spezifische Auftragsinhalt 51 mit mehr als einem Auftragsetikett 61 _i verwendet wird. Schließ­ lich können die Steuerdaten 69 spezifische Leistungserfor­ dernisse umfassen, wie beispielsweise Kosten und Lieferung, Gewährleistung, benötigte Materialien, Mengenrabatte und andere Erfordernisse.

Die Verwendung von Auftragsetiketten als XML-Objekte ermög­ licht es Clients, Datenbanken zu definieren und Daten durch den Auftragsetikettdienst 60 und den Auftragsspeicher 50 zu speichern. Die Datenbanken können verwendet werden, um Kon­ taktlisten, Adressen und andere persönliche Daten aufzube­ wahren. Die Datenbanken können ferner dazu verwendet wer­ den, beliebige andere generische Daten zu speichern. Die Datenbanken könnten daraufhin in Verbindung mit einer Viel­ zahl von E-Diensten, die durch die Prozessoren 80 _i bereit­ gestellt werden, verwendet werden. Beispielsweise kann ein E-Mail-Prozessor 80, der E-Mail-Dienste bereitstellt, in Verbindung mit einer persönlichen Kontaktliste verwendet werden, um E-Mail-Nachrichten zu senden, elektronische Da­ teien zu transferieren oder einen Chatroom einzurichten. Der E-Mail-Prozessor 80 kann in vordefinierten Abständen auf die Kontaktliste zugreifen, um E-Mail-Nachrichten an eine ausgewählte Gruppe von E-Mail-Adressen zu senden. Da das Dienstezentrum 40 ferner Prozessoren 80, die mit dem Kommunikationsnetz 35 gekoppelt sind, ein einzelnes Portal bereitstellt, muß der Client 31 keinerlei Kenntnis der Da­ tenbankstruktur oder der Verarbeitungserfordernisse der Prozessoren 80 haben.

Bei der spezifischen Anwendung der generischen XML- Datenbank auf einen E-Mail-Dienst hat der Client 31 viel­ leicht eine Liste von E-Mail-Kontakten als eine generische Datenbank eingerichtet. Die Kontakte-Datenbank kann dann in dem Auftragsspeicher 50 als Inhaltsdatei 51 gespeichert werden. Bei dem Auftragsetikettdienst 60 kann ein entspre­ chendes Auftragsetikett 61 gespeichert werden. Das Auf­ tragsetikett 61 umfaßt Steuerdaten, die benötigt werden, um E-Mail durch das Dienstezentrum 40 zu senden und zu empfan­ gen. Ferner dient das Auftragsetikett 61 als ein Zeiger auf Daten in der Inhaltsdatei 51. Insbesondere kann das Auf­ tragsetikett 61 XML-Daten speichern, die mit anderen Daten, die in der Inhaltsdatei 51 gespeichert sind, in Zusammen­ hang stehen.

Alternativ dazu kann das Auftragsetikett 61 die Kontakte- Daten speichern. Diese Alternative nützt die Tatsache aus, daß das Auftragsetikett 61 ein Vokabular umfaßt, das erwei­ tert werden kann, um die Kontaktdaten zu umfassen, und daß das Vokabular ferner erweitert werden kann, um Eigenschaf­ ten für jede Kontaktperson in den Kontaktdaten zu umfassen. Beispielsweise kann das Auftragsetikett 61 festlegen, daß eine Kontaktperson eine Geschäftskontaktperson oder eine Privatkontaktperson ist. Es können auch andere Eigenschaf­ ten enthalten sein, beispielsweise, ob die Kontaktpersonen in der Kontakt-Datenbank Mobiltelephone, ortsfeste Telepho­ ne, Faxgeräte und E-Mail-Adressen verwenden.

Die Verwendung des Auftragsetiketts 61 ermöglicht ferner ein syntaktisches Analysieren, Durchsuchen und Aktualisie­ ren der Kontakte-Datenbank. Beispielsweise kann der Client 31 die Kontakte-Datenbank nach Telephonnummern für alle Personen, deren Vorname Joe ist, durchsuchen wollen. Diese Suchfunktionalität ist in dem Auftragsetikett 61 enthalten und ermöglicht es dem Auftragsetikettdienst 60, dem Client eine Liste von Telephonnummern für alle Einträge in der Kontakte-Datenbank, bei denen der Vorname der Person Joe ist, bereitzustellen. Das heißt, daß die Kontakte-Datenbank Einträge umfaßt, die die Eigenschaft Joe aufweisen, und daß der Auftragsetikettdienst in der Lage ist, die Kontakte- Datenbank auf diese Eigenschaft hin zu durchsuchen und eine Liste dieser Einträge an den Client 31 zurückzugeben.

Die Eigenschaftenfunktion des Auftragsetiketts 61 ermög­ licht ferner, daß der Auftragsetikettdienst 60 spezifische Aufgaben, die von dem Client gewünscht werden, steuert, o­ der dem Client anzeigt, daß eine gewünschte Aufgabe nicht erfüllt werden kann. Um bei dem Beispiel der Kontakte- Datenbank zu bleiben, möchte der Client 31 vielleicht eine Faksimileübertragung an alle Einträge in der Kontaktliste senden, die eine bestimmte Postleitzahl aufweisen. Der Auf­ tragsetikettdienst 60 kann die Kontakte-Datenbank nach Ei­ genschaften hin durchsuchen, wobei er nach der Postleitzahl sucht. Ferner kann der Auftragsetikettdienst 60 die Kontak­ te-Datenbank durchsuchen, um zu bestimmen, ob es einen Ein­ trag gibt, der kein Faksimilegerät hat. Für diejenigen Ein­ träge, die kein Faksimilegerät haben, kann der Auftragseti­ kettdienst 60 eine Nachricht erzeugen, die an den Client 31 zurückzusenden ist und den Client 31 informiert, daß die Faksimileübertragung nicht zugestellt werden konnte. Unter Verwendung dieser Funktionalität muß der Client 31 nichts über die beabsichtigten Empfänger der Faksimileübertragung wissen.

Um zu dem Beispiel eines E-Mail-Dienstes zurückzukehren, kann bei dem Client 31 eine E-Mail-Anwendung gestartet wer­ den, um unter Verwendung des Internet eine E-Mail-Nachricht an eine oder mehrere Kontaktpersonen in der Kontakte- Datenbank zu senden. Der Client 31 muß jedoch kein Abonne­ ment bei einem Internet-Dienstleister haben. Statt dessen bestimmt das Dienstezentrum 40, welcher Prozessor 80 am be­ sten dem Erfordernis des Client, die E-Mail-Nachricht zu senden, entspricht. Das heißt, daß das Dienstezentrum 40 einen E-Mail-Dienstleister (einen Prozessor 80) auswählen kann, um die E-Mail-Nachricht an eine ausgewählte Zielad­ resse zu senden. Ferner kann das Dienstezentrum 40 auf der Basis von Informationen, die in der Kontakte-Datenbank ge­ führt werden (d. h. dem Inhalt 51 in dem Auftragsspeicher 50), bestimmen, welche Zustelloptionen durch einen Benutzer an der Zieladresse gewünscht sind. Beispielsweise kann der Benutzer der Zieladresse wünschen, daß alle E-Mail- Nachrichten an einen E-Mail-Briefkasten gesendet werden oder daß immer dann, wenn eine E-Mail-Nachricht gesendet wird, eine Mitteilung bereitgestellt wird. Diese Liefer­ merkmale können in der Kontakte-Datenbank gespeichert sein. Alternativ dazu können die Zustellmerkmale in einer separa­ ten Datenbank (Inhaltsdatei 51) in dem. Auftragsspeicher 50 gespeichert sein, und das Dienstezentrum kann beim Bestim­ men, wie die E-Mail-Nachricht zuzustellen ist, aus dieser separaten Datenbank Informationen wiedergewinnen. Im ein­ zelnen kann die separate Datenbank eine Vielzahl von Benut­ zern zusammen mit der Internet-Adresse des Benutzers umfas­ sen. Durch Vergleichen der bereitgestellten Internet- Adresse mit dem ausgehenden E-Mail an die Internet-Adressen in der separaten Datenbank kann das Dienstezentrum 40 ge­ wünschte Zustelloptionen des Adressaten bestimmen. Dieser Prozeß zum Bestimmen von Zustelloptionen ist für den Client 31, von dem die E-Mail-Nachricht ausging, transparent. Al­ les, was der Client 31 wissen muß, sind die Kontaktinforma­ tionen (z. B. die Internet-Adresse).

Der Client 31 kann den Auftragsetikettdienst 60 verwenden, um eine Anzahl von Leistungsmerkmalen, die sich auf den E- Mail-Dienst beziehen, festzulegen. Beispielsweise möchte der Client 31 vielleicht, daß das Dienstezentrum eine fest­ gelegte Anzahl von Zustellversuchen unternimmt und, falls keine Zustellung stattfindet, dem Client 31 eine Rücknach­ richt sendet, die die Nichtzustellung der E-Mail-Nachricht angibt.

Wie oben angemerkt wurde, kann das Auftragsetikett 61 in Verbindung mit anderen Komponenten des Dienstezentrums 40 auch verwendet werden, um eine dauerhafte, generische ob­ jektbasierte Datenstruktur, beispielsweise eine XML- Datenbank, zu erstellen. Ein Beispiel der Verwendung eines Auftragsetiketts 61 für diesen Zweck ist in Fig. 5D veran­ schaulicht. Das Auftragsetikett 61 umfaßt eine Kontakte- Liste 84, die in Form einer XML-Datenbank oder einer ande­ ren generischen Datenbank vorliegen kann. Die Kontakte- Liste 84 kann eine Struktur mit Einträgen für eine ge­ schäftliche 85 und private 86 Verwendung umfassen. Die Strukturen der geschäftlichen 85 und privaten 86 Kontakte können Einträge von Einzelpersonen 87 umfassen, wie gezeigt ist. Jeder der Einträge 87 kann spezifische Eigenschaften umfassen, wie oben definiert ist. Zusätzlich oder alterna­ tiv dazu kann jeder der Einträge 87 Verknüpfungen mit ande­ ren Datenbanken umfassen, die weitere Informationen und Ei­ genschaften über die Einzelperson bereitstellen.

Während die Verwendung des Auftragsetiketts 61 als eine XML-Datenbank unter Bezugnahme auf einen E-Mail- und Nach­ richtendienst beschrieben wurde, ist das Auftragsetikett 61 nicht so begrenzt. Jegliche Daten, die in einer Datenbank gespeichert werden können, sind unter Verwendung des Auf­ tragsetiketts 61 zugänglich und steuerbar.

Die oben beschriebenen und in den Fig. 5A bis 5D gezeigten Merkmale können in einem anderen Ausführungsbeispiel eines Auftragsetiketts 61 reproduziert werden, bei dem sich alle Daten, die sich auf einen bestimmten Knoten oder Zweig be­ ziehen, in diesem Knoten oder Zweig befinden. Unter Verwen­ dung des in Fig. 2 gezeigten beispielhaften Knotenbaums 10 kann jeder Knoten (Zweig) detaillierte Informationen und Merkmale wie beispielsweise Ressourcen, autorisierte Pro­ zessoren 80 _i, Sperren-/Entsperren-Flag, Angebotsinformatio­ nen, Zweigbeschreibung und andere Informationen umfassen.

Fig. 6 ist ein Diagramm von Funktionen des Auftragsetikett­ dienstes 60. Die Hauptfunktionen des Auftragsetikettdiens­ tes 60 bestehen darin, die Auftragsetiketten 61 _i zu spei­ chern 73 und Benutzern, beispielsweise dem Client 31 und den Prozessoren 80 _i, Zugriff auf die Auftragsetiketten 61 _i zu gewähren 75. Um diese Speicher- und Zugriffsfunktionen zu bewerkstelligen, kann der Auftragsetikettdienst 60 einen Auftragsetikettverweis 72 und einen Auftragsressourcenver­ weis 74 erstellen. Der Auftragsetikettdienst 60 steuert überdies einen Auftragsinhaltzugriff 76, aktualisiert 77 die Auftragsetiketten 61 _i, während Prozesse: durch die Prozesso­ ren 80 _i abgeschlossen und berichtet werden, ergänzt das Auftragsetikett 61 _i und berichtet 78, wenn alle Prozesse für ein bestimmtes Auftragsetikett 61 abgeschlossen sind, und stellt einen Klassifizierungsprozeß 79 bereit, um es einem Client 31 zu ermöglichen, eine Erfüllung der in dem Auftragsetikett 61 benannten Aufgaben zu ratifizieren.

Der Auftragsetikettverweis 72 umfaßt einen spezifischen Verweis auf ein entsprechendes Auftragsetikett 61 _i. Der Auftragsetikettverweis 72 kann durch den Auftragsetikett­ dienst 60 verwendet werden, um es einem oder mehreren Pro­ zessoren und Clients zu ermöglichen, auf das Auftragseti­ kett 61 zuzugreifen. Das heißt, statt das Auftragsetikett 61 an einen Prozessor 80 weiterzugeben, gibt der Auftrags­ etikettdienst 60 den Auftragsetikettverweis 72 weiter. Mit dem Auftragsetikettverweis 72 kann der Prozessor 80 auf das gesamte oder einen Teil eines Auftragsetiketts 61 zugrei­ fen, so daß der Prozessor 80 einen oder mehrere Prozesse abschließen kann. Im Gegensatz zu herkömmlichen Auftrags­ etikettdiensten behält der Auftragsetikettdienst 60 das Auftragsetikett in einem Speicher 73 und erlaubt es ledig­ lich Benutzern (Clients 31 _i und Prozessoren 80 _i), auf das Auftragsetikett 61 zuzugreifen. Dieses Merkmal ermöglicht es mehreren Prozessoren 80, gleichzeitig Prozesse für die spezifische Auftragsanforderung 32, die sich auf das Auf­ tragsetikett 61 bezieht, abzuschließen.

Der Auftragsetikettdienst 60 kann ferner einen Ressourcen­ verweis 74 erstellen und kann den Ressourcenverweis 74 den Prozessoren 80 _i und den Clients 31 _i auf eine ähnliche Weise wie bei dem Auftragsetikettverweis 72 bereitstellen. Wie oben bei der Beschreibung, die die Fig. 2 begleitet, ange­ merkt wurde, können die Ressourcen physische Geräte und Ma­ terialien umfassen und können digitale Dateien umfassen. Eine Verwendung des Ressourcenverweises 74 kann Daten, die in dem Auftragsetikett 61 enthalten sind, vereinfachen.

Alternativ dazu können Informationen, die in dem Ressour­ cenverweis 74 enthalten sind, in dem Auftragsetikett 61 enthalten sein oder können in anderen Dateien enthalten sein, auf die durch die Clients 31 _i und die Prozessoren 80 _i zugegriffen wird.

Fig. 7 ist ein Diagramm, das einen Betrieb von ausgewählten Funktionen des Auftragsetikettdienstes 60 zeigt. Wie in Fig. 7 gezeigt ist, umfaßt der Auftragsetikettdienst 60 ein Auftragsetikett 61 ₁, das ein Programmierungsobjekt wie das­ jenige, das in Fig. 2 dargestellt wurde und oben beschrie­ ben wurde, sein kann. Das Auftragsetikett 61 ₁ ist als dem Auftragsetikettdienst 60 durch den Client 31 ₁ bereitge­ stellt gezeigt. Der Client 31 ₁ kann ein vernetzter Computer oder ein ähnliches Gerät sein, das in der Lage ist, die di­ gitalen Informationen, die das Auftragsetikett 61 ₁ darstel­ len, an den Auftragsetikettdienst 60 zu übermitteln. Um si­ cherzustellen, daß das Auftragsetikett 61 _i, bei dem Auf­ tragsetikettdienst 60 ankommt, kann das Auftragsetikett 61 ₁ eine Bezugnahme auf den Auftragsetikettdienst 60 enthalten, wie beispielsweise das in Fig. 5A veranschaulichte Dienste- ID 65. Das Dienste-ID 65 kann eine Netzadresse des Auf­ tragsetikettdienstes 60 umfassen. Beispielsweise kann das Dienste-ID 65 einen Einheitsressourcenlokator (URL - uni­ versal resource locator) umfassen, falls der Auftragseti­ kettdienst 60 eine Internet-Website ist.

Ebenfalls in Fig. 7 sind ein Client 312 und Prozessoren 80 ₁-80 _N gezeigt. Die Prozessoren 80 ₁-80 _N können vernetzte Ressourcen wie beispielsweise vernetzte Drucker, Electro­ nic-Commerce-Entitäten, die beispielsweise Internet- Websites, und Entitäten "aus Ziegelsteinen und Mörtel", wie beispielsweise lokale Druckershops, die unter Verwendung des Dienstebusses 41 mit dem Auftragsetikettdienst 60 ver­ bunden sind, umfassen.

Der Client 31 erzeugt eine Auftragsanforderung 32 (Inhalt 51 und Auftragsetikettdaten). Unter Verwendung des Vorfeld­ dienstes 30 (nicht in Fig. 7 gezeigt) und des Dienstebusses 41 sendet der Client 31 ₁ die Auftragsetikettdaten an den Auftragsetikettdienst 60 und den Inhalt 51 (nicht in Fig. 7 gezeigt) an den Auftragsspeicher 50. Der Auftragsetikett­ dienst 60 kann die Auftragsetikettdaten an die Ar­ beitsflußsteuerung 70 weiterleiten, die dann ein Auftrags­ etikett 61 erstellt. Der Inhalt 51 ₁ und das Auftragsetikett 611 stehen durch das Auftragskennzeichen 63 miteinander in Zusammenhang. Das Auftragskennzeichen 63 umfaßt ferner eine Identifizierung des Auftragsspeichers 50 und einer Position in dem Auftragsspeicher 50, an der der Inhalt 51 ₁ gespei­ chert ist. Bei einem alternativen Ausführungsbeispiel kann der Inhalt 51 ₁ bei dem Client 31 ₁ gespeichert sein, und durch den Dienstebus 41 und den Vorfelddienst 30 kann dar­ aufhin durch andere Benutzer auf ihn zugegriffen werden.

Das Auftragsetikett 61 ₁ spezifiziert Prozesse, die abge­ schlossen werden müssen, um die Auftragsanforderung 32 zu beenden. Wie oben bemerkt wurde, veranschaulicht Fig. 2 Prozesse, die erforderlich sind, um eine Broschüre zu dru­ cken, einschließlich der Innenseiten und des Einbands. Es kann mehr als ein Prozessor 80 _i erforderlich sein, um eine solche Auftragsanforderung abzuschließen oder um die Auf­ tragsanforderung auf die kosteneffizienteste und/oder zeit­ sparendste Weise abzuschließen. Die Arbeitsflußsteuerung 70 (nicht in Fig. 7 gezeigt) kann bestimmen, welche(r) der Prozessoren 80 ₁-80 _N einen spezifischen Prozeß abschließen sollte, und, falls notwendig, die Reihenfolge, in der sol­ che Prozesse abgeschlossen werden sollten. Die Ar­ beitsflußsteuerung 70 kann die diversen Prozessoren 80 _i ab­ fragen, um zu bestimmen, welche verwendet werden können, um die Auftragsanforderung abzuschließen. Die Arbeitsflußsteu­ erung 70 kann daraufhin ausgewählte Prozessoren 80 _i davon benachrichtigen, daß bei dem Auftragsetikettdienst 60 eine Auftragsanforderung registriert wurde.

Für jedes empfangene Auftragsetikett 61 _i erstellt der Auf­ tragsetikettdienst 60 einen Verweis 72 _i zu dem Auftragseti­ kett 61 _i. Der Prozessor 80 ₁ kann einen Zugriff auf das Auf­ tragsetikett 61 anfordern, um einen oder mehrere Prozesse abzuschließen. Als Reaktion stellt der Auftragsetikett­ dienst 60 dem Prozessor 80 ₁ den Auftragsetikettverweis 72 ₁ bereit. Der Auftragsetikettverweis 72 ₁ wird daraufhin als Index zu dem Auftragsetikett 61 ₁ verwendet. Der Auftrags­ etikettverweis 72 ₁ kann auch anderen Prozessoren, bei­ spielsweise dem Prozessor 80 ₂, und anderen Clients, bei­ spielsweise dem Client 31 ₂, bereitgestellt werden. Der Pro­ zessor 80 ₂ und der Client 31 ₂ können daraufhin zur selben Zeit, wie der Prozessor 80 ₁ auf das Auftragsetikett 61 ₁ zu­ greift, auf das Auftragsetikett 61 ₁ zugreifen. Dieser gleichzeitige Zugriff ermöglicht, daß verschiedene Prozesse parallel abgeschlossen werden können. Bei dem in Fig. 2 veranschaulichten Beispiel kann der Prozessor 80 ₁ manche oder alle Prozesse für die Innenseiten abschließen, und der Prozessor 80 ₂ kann die Prozesse für den Einband abschlie­ ßen.

Fig. 8 ist ein Blockdiagramm, das eine beispielhafte Anwen­ dung der Steuermerkmale des Auftragsetikettdienstes 60 ver­ anschaulicht. Das Auftragsetikett 61 ₁ wird durch das Auf­ tragsetikettkennzeichen 63 auf den Auftragsinhalt 51 ₁ ver­ wiesen, und Informationen, die sich auf das Auftragsetikett 61 ₁ und den Auftragsinhalt 51 ₁ beziehen, werden über den Dienstebus 41 geleitet. Die Prozessoren 80 _i können unter Verwendung des Dienstebusses 41 auf den Auftragsinhalt 51 ₁ und das Auftragsetikett 61 ₁ zugreifen. Bei dem veranschau­ lichten Beispiel bezieht sich das Auftragsetikett 61 ₁ auf eine Auftragsanforderung 32, um unter Verwendung der in Fig. 2 dargelegten Prozesse eine Broschüre zu drucken. Der Prozessor 80 ₁ wird durch den Arbeitsflußprozessor 70 dazu benannt, die Innenseiten der Broschüre zu erzeugen, und der Prozessor 80 ₂ ist dazu benannt, den Broschüreneinband zu erzeugen. Der Prozessor 80 ₁ leitet eine Auftragsetikett- Zugriffsanforderung an den Auftragsetikettdienst 60. Die Zugriffsanforderung kann Sicherheitsinformationen umfassen, die es dem Prozessor 80 ₁ ermöglichen, auf das Auftragseti­ kett 61 ₁ und den entsprechenden Inhalt 51 ₁ oder Auftrag zu­ zugreifen. Als Reaktion stellt der Auftragsetikettdienst 60 einen Auftragsetikettverweis 62 ₁ bereit, der durch den Pro­ zessor 80 ₁ verwendet wird, um auf das Auftragsetikett 61 ₁ zuzugreifen. Der Prozessor 80 ₁ kann Informationen in dem Auftragsetikett 61 ₁ verwenden, um auf den in dem Auftrags­ speicher 50 gespeicherten Inhalt 51 ₁ zuzugreifen. Da der Prozessor 80 ₁ lediglich die Innenseiten erzeugt, benötigt der 23707 00070 552 001000280000000200012000285912359600040 0002010224795 00004 23588 Prozessor 80 ₁ keinen Zugriff auf alle in dem Auftrags­ etikett 61 ₁ enthaltenen Informationen. Da das Auftragseti­ kett 61 ₁ ferner in dem Auftragsetikettdienst 60 bleibt, können ferner andere Entitäten, beispielsweise der Prozes­ sor 80 ₂, weiterhin auf das Auftragsetikett zugreifen.

Während der Prozessor 80 ₁ diverse Prozesse abschließt, kann der Prozessor 80 ₁ den Inhalt 51 ₁ und das Auftragsetikett 61 ₁ aktualisieren. Somit kann das Auftragsetikett 61 ₁ den neu­ esten Status der Auftragsanforderung 32 widerspiegeln. Die Statusberichte können angeben, wenn ein Knoten in dem Kno­ tenbaum 10 abgeschlossen ist, wenn eine vorläufige Frist abgeschlossen ist, wenn ein weiterer Prozessor verwendet werden kann, um einen Prozeß abzuschließen, und wenn das gesamte Verarbeiten abgeschlossen ist. Der Statusbericht kann in einer digitalen Datei enthalten sein, die bei­ spielsweise durch die Arbeitsflußsteuerung 70 verwendet wird. Der Statusbericht kann auch in einem für Menschen lesbaren Format enthalten sein, beispielsweise in einem Di­ alogfenster auf einem Anzeigebildschirm eines Computers. Der Prozessor 80 ₁ kann den Auftragsetikettverweis 72 ₁ emp­ fangen und kann alle geplanten Prozesse abschließen, wobei der Auftragsetikettverweis 72 ₁ zu dem Auftragsetikettdienst 60 zurückgegeben wird. Der Prozessor 80 ₁ kann ferner eine Kopie des Auftragsetikettverweises 72 ₁ an den Prozessor 80 ₂ senden, so daß der Prozessor 80 ₂ auf das Auftragsetikett 61 ₁ und den Inhalt 51 ₁ zugreifen und den Broschüreneinband erzeugen kann.

Fig. 9 ist ein Flußdiagramm, das eine Operation 100 des Auftragsetikettdienstes 60 veranschaulicht. Die Operation 100 basiert auf einem Abschließen der Innenseitenknoten, die in Fig. 2 gezeigt sind. Die Operation 100 kann sich zu­ mindest teilweise unter der Steuerung der Arbeitsflußsteue­ rung 70 oder eines äquivalenten Geräts befinden. Die Opera­ tion 100 geht davon aus, daß eine Auftragsanforderung 32 (Auftragsetikettdaten und -inhalt) an das Dienstezentrum 40 geleitet wurde und daß ein Auftragsetikettdienst 60 er­ stellt wurde. Die Operation 100 beginnt bei einem Start­ block 101. Bei einem Block Prüfe Prozessoren und Weise Pro­ zessoren zu 105 bestimmt die Arbeitsflußsteuerung 70, wel­ che Prozessoren 80 _i in der Lage und verfügbar sind, den Auftrag abzuschließen. Die Arbeitsflußsteuerung 70 oder der optionale Angebotsdienst 90 können Abfrage- oder Angebots­ merkmale verwenden, um die Bestimmung durchzuführen. Wenn mehr als ein Prozessor 80 zur Verfügung steht und die An­ forderungen des Auftragsetiketts 61 erfüllen kann, kann die Arbeitsflußsteuerung 70 dem Auftrag einem bestimmten Pro­ zessor 80 zuweisen. Alternativ dazu kann die Ar­ beitsflußsteuerung 70 dem Client 31 eine Liste von Prozes­ soren 80 _i bereitstellen und es dem Client 31 ermöglichen, einen oder mehrere Prozessoren 80 _i auszuwählen.

Bei einem Block Anforderung Auftragsetikett 110 sendet ein Prozessor 80, nachdem ihm ein Zugriff auf ein Auftragseti­ kett 61 gewährt wurde, unter Verwendung des Dienstebusses 41 eine Zugriffsanforderung an den Auftragsetikettdienst 60. Bei Block 115 verifiziert der Auftragsetikettdienst, ob der Prozessor 80 auf das Auftragsetikett 61 zugreifen kann. Der Zugriff kann beispielsweise durch ein Paßwort, ein Kennzeichen und ein Öffentlicher-Schlüssel/Privater- Schlüssel-Sicherheitssystem gesteuert werden. Beim Block 115 kann, falls dem Prozessor 80 der Zugriff verweigert wird, ein Fehlersignal an den Prozessor und/oder den Client 31 gesandt werden, Block 120.

Falls der Zugriff gewährt wird, liefert der Auftragseti­ kettdienst 60 beim Block 115 dem Prozessor 80 eine Kopie des Auftragsetikettverweises 72, der dem Auftragsetikett 61 entspricht, Block 125. Der Auftragsetikettverweis 72 ermög­ licht es dem Prozessor 80, zu jeder Zeit auf das Auftrags­ etikett zuzugreifen. Dadurch, daß er zu jeder beliebigen Zeit auf das Auftragsetikett 61 zugreift, ist der Prozessor 80 in der Lage, eine aktualisierte Version des Auftragseti­ ketts 61 einzusehen, während durch andere Entitäten, ein­ schließlich anderer Prozessoren 80, Änderungen an dem Auf­ tragsetikett 61 vorgenommen werden.

Bei Block 130 stellt der Auftragsspeicher 50 einen Zugriff auf den Auftragsinhalt 51 bereit, auf den durch das Auf­ tragsetikett 61 verwiesen wird. Es kann sein, daß lediglich derjenige Teil des Inhalts 51, der durch den Prozessor 80 eventuell benötigt wird, durch den Auftragsspeicher 50 be­ reitgestellt wird. Wenn der Prozessor 80 beispielsweise le­ diglich die Innenseiten der Broschüre erstellen soll, kann es sein, daß der Auftragsspeicher 50 keinen Zugriff auf den Inhalt gewährt, der benötigt wird, um den Broschüreneinband zu erzeugen. Nachdem er den Auftragsetikettverweis 72 und den Inhalt 51 empfangen hat, kann der Prozessor 80 eine oder mehrere Aufgaben erfüllen, indem er Eingangsressourcen verwendet, um eine vorläufige oder endgültige Ausgangsres­ source zu erzeugen. Mit dem Abschluß jedes Knotens in dem Knotenbaum 10 kann der Prozessor 80 dem Auftragsetikett­ dienst 60 eine Eingabe bereitstellen, um eine Modifizierung des Auftragsetiketts 61 zu ermöglichen, Block 135. Wenn der Prozessor 80 alle benötigten Prozesse abschließt, kann der Prozessor 80 dem Auftragsetikettdienst 60 zusammen mit et­ waigen endgültigen Modifizierungen des Auftragsetiketts 61 einen endgültigen Statusbericht liefern, Block 140.

Bei Block 145 bestimmen der Auftragsetikettdienst 60 und die Arbeitsflußsteuerung 70, ob eine weitere Aufgabenzuwei­ sung erforderlich sein kann. Wenn weitere Aufgaben erfor­ derlich sind, stellt die Arbeitsflußsteuerung 70 sicher, daß die geeigneten Prozessoren 80 _i zugewiesen werden, und die Operation kehrt zum Block 110 zurück. Wenn keine zu­ sätzlichen Prozesse benötigt werden, geht die Operation zum Block 150 und endet.

Fig. 10 ist ein Flußdiagramm, das die Routine 105 zum Ent­ wickeln eines Arbeitsflusses und Zuweisen von Prozessoren zu dem Arbeitsfluß veranschaulicht. Der Prozeß beginnt bei Block 200. Bei Block 205 empfängt das Dienstezentrum 40 ei­ ne Auftragsanforderung 32. Die Auftragsanforderung 32 kann Leistungserfordernisse, Ressourcen und andere Parameter spezifizieren und kann den Inhalt 51 oder eine Verknüpfung zu dem Inhalt 51 umfassen. Bei Block 210 definiert die Ar­ beitsflußsteuerung 70 einen Arbeitsfluß, um die in der Auf­ tragsanforderung 32 festgelegten Aufgaben zu erfüllen. Der Arbeitsfluß kann durch einen Knotenbaum, beispielsweise den in Fig. 2 gezeigten Knotenbaum 10, dargestellt sein.

Bei Block 230 erstellt die Arbeitsflußsteuerung 70 unter Verwendung der durch die Auftragsanforderung 32 bereitge­ stellten Informationen, den bei Block 210 erzeugten Ar­ beitsfluß und einer geeigneten Auftragsetikettschablone ein Auftragsetikett 61. Das Auftragsetikett 61 wird daraufhin in dem Auftragsetikettdienst 60 gespeichert. In dem Auf­ tragsspeicher 50 kann ein jeglicher Inhalt 51 gespeichert werden.

Die Arbeitsflußsteuerung 70 oder der Auftragsetikettdienst 60 können eine Auftragsetikettnachricht oder ein anderes Objekt erstellen und die Nachricht, Block 250, an dem Dien­ stezentrum 40 plazieren, so daß äußere Entitäten (z. B. die Prozessoren 80 _i) ausreichende Informationen erlangen können, um einen Abschluß des Auftragsetiketts 61 oder ei­ nes Zweiges 66 des Auftragsetiketts 61 anzubieten. Bei ei­ nem alternativen Ausführungsbeispiel kann das Auftragseti­ kett 61 an dem Dienstezentrum 40 plaziert werden. Falls das Auftragsetikett 61 plaziert wird, kann das Auftragsetikett 61 einen Mechanismus zum Begrenzen des Zugriffs auf das Auftragsetikett oder zum Begrenzen des Zugriffs auf be­ stimmte Abschnitte des Auftragsetiketts 61 umfassen, Bei­ spielsweise ist die Client-Erweiterung 64 eventuell für die Prozessoren 80 _i nicht zugreifbar.

Bei Block 270 empfängt das Dienstezentrum 40 Angebote von spezifischen Prozessoren 80 _i, und bei Block 290 wertet das Dienstezentrum 40 die Angebote aus. Bei Block 295 bestimmt das Dienstezentrum 40, ob der Client 31, der die Auftrags­ anforderung 32 unterbreitet, das bzw. die als Gewinner her­ vorgehende(n) Angebote auszuwählen beabsichtigt, oder ob das Dienstezentrum 40 die Auswahl trifft. Wenn der Client die Auswahlen trifft, stellt das Dienstezentrum 40 bei Block 300 dem Client 31 die Angebotsinformationen bereit. Daraufhin empfängt das Dienstezentrum 40 bei Block 305 die Auswahlen von dem Client 31. Wenn das Dienstezentrum 40 die Auswahlen trifft, wählt das Dienstezentrum 40 bei Block 310 das bzw. die als Gewinner hervorgehende(n) Angebot(e) aus. Bei Block 315 benachrichtigt das Dienstezentrum die als Ge­ winner hervorgehenden Prozessoren. Das Dienstezentrum kann ferner die Angebotsinformationen mit dem entsprechenden Auftragsetikett 61 speichern. Bei Block 320 endet die Rou­ tine 105.

Fig. 11 ist ein Flußdiagramm, das die Unterroutine 210 zum Definieren eines Arbeitsflusses veranschaulicht. Die Unter­ routine 210 startet bei Block 350. Bei Block 355 bestimmt die Arbeitsflußsteuerung 70, ob der Arbeitsfluß mehrere Zweige enthalten wird. Wenn der Arbeitsfluß mehrere Zweige enthalten wird, definiert die Arbeitsflußsteuerung 70 die Zweige, Block 360. Bei Block 365 wählt die Arbeitsflußsteu­ erung 70 einen Zweig aus, für den Ressourcen und Prozesse zu definieren sind. Bei Block 370 definiert die Ar­ beitsflußsteuerung 70 Eingangsressourcen für einen ersten Prozeß oder Knoten. Bei Block 375 definiert die Ar­ beitsflußsteuerung 70 die Aufgaben, die für den ersten Pro­ zeß abzuschließen sind. Bei Block 380 bestimmt die Ar­ beitsflußsteuerung 70 die Ausgangsressourcen des ersten Prozesses. Bei Block 385 bestimmt die Arbeitsflußsteuerung 70, ob ein weiterer Prozeß für den Arbeitsfluß oder Zweig erforderlich ist. Wenn keine weiteren Prozesse erforderlich sind, bestimmt die Arbeitsflußsteuerung 70, ob ein weiterer Zweig definiert werden soll, Block 390. Falls ein weiterer Block definiert werden soll, wählt die Arbeitsflußsteuerung 70 einen weiteren Zweig aus, Block 365, und die Unterrouti­ ne 210 wird fortgesetzt. Wenn kein weiterer Zweig definiert werden soll, endet die Unterroutine, Block 395. Die Ergeb­ nisse der Arbeitsflußdefinition können in das Auftragseti­ kett 61 aufgenommen werden (siehe Fig. 10, Block 230).

Fig. 12 ist ein Flußdiagramm, das die Unterroutine 250 des Plazierens einer Auftragsetikettmeldung oder eines Auf­ tragsetiketts veranschaulicht. Die Unterroutine 250 startet bei Block 400. Bei Block 405 bestimmt die Arbeitsflußsteue­ rung 70, ob der dem Auftragsetikett 61 zugeordnete Ar­ beitsfluß mehrere Zweige umfaßt. Wenn der Arbeitsfluß nicht mehrere Zweige umfaßt, plaziert die Arbeitsflußsteuerung die Auftragsetikettmeldung, die den einzelnen Zweig auflis­ tet, Block 410. Wenn der Arbeitsfluß mehrere Zweige umfaßt, plaziert die Arbeitsflußsteuerung 70 die Auftragsetikett­ meldung bei mehreren Zweigen, Block 420. Dann endet die Un­ terroutine 250.

Fig. 13 ist ein Flußdiagramm, das die Unterroutine 290 zum Auswerten von Angeboten veranschaulicht. Die Unterroutine startet bei Block 440. Bei Block 445 wählt der Angebots­ dienst 90 ein erstes Angebot zur Analyse aus. Bei Block 450 bestimmt der Angebotsdienst 90, ob der Client 31 etwaige Auswertungskriterien oder -erfordernisse bereitgestellt hat. Wenn der Client keine Auswertungserfordernisse bereit­ gestellt hat, vergleicht der Angebotsdienst 90 das ausge­ wählte Angebot mit einem Satz von standardmäßigen Mindest­ leistungserfordernissen, die Erfordernisse des Industrie­ standards sein können, Block 455. Bei Block 460 bestimmt der Angebotsdienst 90, ob das Angebot die Mindestleistungs­ erfordernisse erfüllt. Wenn das Angebot die Mindestleis­ tungserfordernisse nicht erfüllt, wird das Angebot zurück­ gewiesen, Block 475. Wenn das Angebot zurückgewiesen wird, bestimmt der Angebotsdienst 90, ob weitere Angebote unter­ breitet wurden, Block 495. Wenn weitere Angebote unterbrei­ tet wurden, kehrt der Angebotsprozessor 90 zu Block 445 zu­ rück und wählt das nächste Angebot zur Auswertung aus.

Bei Block 450, falls der Client 31 Leistungserfordernisse bereitgestellt hat, vergleicht der Angebotsdienst 90 das ausgewählte Angebot mit den durch den Client bereitgestell­ ten Leistungserfordernissen, Block 465. Bei Block 470 be­ stimmt der Angebotsdienst 90, ob das ausgewählte Angebot den Mindestkriterien der durch den Client bereitgestellten Leistungserfordernissen entspricht. Wenn die Mindestkrite­ rien nicht erfüllt werden, weist der Angebotsdienst 90 das Angebot zurück, Block 475.

Bei Blöcken 470 und 460, falls die Mindestkriterien erfüllt werden, bestimmt der Angebotsdienst 90, ob der Client 31 einen Auswertungsalgorithmus bereitgestellt hat. Wenn der Client 31 keinen Auswertungsalgorithmus bereitgestellt hat, wendet der Angebotsdienst einen standardmäßigen Auswer­ tungsalgorithmus an, der ein Algorithmus eines Industrie­ standards sein kann, Block 485. Wenn der Client einen Aus­ wertungsalgorithmus bereitgestellt hat, wendet der Ange­ botsdienst 90 den durch den Client bereitgestellten Auswer­ tungsalgorithmus an, Block 490. Der Angebotsdienst 90 kann daraufhin die Ergebnisse des Algorithmus bis zur Auswertung aller Angebote speichern.

Bei Block 495 bestimmt der Angebotsdienst 90, ob noch et­ waige Angebote ausgewertet werden müssen. Wenn weitere An­ gebote verbleiben, kehrt die Unterroutine 290 zu Block 445 zurück, und der Angebotsdienst wählt das nächste Angebot zur Auswertung aus. Bei Block 495, falls keine weiteren An­ gebote zur Auswertung verbleiben, bringt der Angebotsdienst 90 die Angebote in eine Rangordnung, Block 500. Dann endet die Unterroutine 290, Block 505.

Fig. 14 ist ein Flußdiagramm, das die Routine 130 zum Be­ reitstellen eines Zugriffs auf ein Auftragsetikett 61 ver­ anschaulicht. Die Routine 130 beginnt bei Block 510. Bei Block 515 empfängt der Auftragsetikettdienst 60 einen Auf­ tragsetikettverweis 72 von einem Prozessor 80 und erlangt das entsprechende Auftragsetikett 61 wieder, Block 520.

Bei Block 525 vergleicht der Auftragsetikettdienst 60 das Prozessorkennzeichen mit Prozessoren, die in dem Auftrags­ etikett 61 oder Zweigen 66 des Auftragsetiketts 61 aufge­ listet sind. Der Auftragsetikettdienst 60 bestimmt, ob die ausgewählten Zweige 66 gesperrt sind, Block 530. Wenn die ausgewählten Zweige 66 nicht gesperrt sind, kopiert der Auftragsetikettdienst 60 die ausgewählten Zweige 66 zu dem Prozessor 80, Block 535. Bei Block 550 bestimmt der Auf­ tragsetikettdienst 60 daraufhin, ob die ausgewählten Zweige 66 gesperrt werden müssen. Wenn die ausgewählten Zweige nicht gesperrt werden müssen, endet die Routine 130, Block 560. Wenn die ausgewählten Zweige 66 gesperrt werden müs­ sen, sperrt der Auftragsetikettdienst 60 die ausgewählten Zweige 66, Block 555. Dann endet die Routine 130, Block 560.

Bei Block 530, falls die ausgewählten Zweige 66 gesperrt sind, bestimmt der Auftragsetikettdienst 60, ob der Prozes­ sor 80 beabsichtigt, Informationen in den ausgewählten Zweigen 66 zu modifizieren, Block 540. Falls der Prozessor 80 die ausgewählten Zweige 66 nicht modifiziert, kann der Auftragsetikettdienst 60 eine Fehlernachricht bereitstel­ len, Block 545. Falls die ausgewählten Zweige 66 modifi­ ziert werden, kann der Auftragsetikettdienst 60 die ausge­ wählten Zweige 66 entsperren.

Fig. 15 ist ein Flußdiagramm eines Verfahrens zum Ermögli­ chen eines Zugriffs auf ein Auftragsetikett 61. Das Verfah­ ren kann als Teil der in Fig. 9 gezeigten Routine 115 aus­ geführt werden. Das Verfahren startet bei Block 600. Bei Block 605 empfängt der Authentifizierungsserver 94 Authen­ tifizierungsinformationen von einem Prozessor 80 und er­ langt ein Auftragsetikett 61 wieder, dass einem Auftragseti­ kettverweis 72, den der Prozessor 80 besitzt, entspricht. In diesem Stadium des Prozesses enthält das Auftragsetikett 61 (ausschließlich des Öffentlicher-Schlüssel- Signaturfeldes 67) zwei Informationsfelder, den Rahmen 62 und die Client-Erweiterung 64. Der Rahmen 62 enthält Infor­ mationen wie beispielsweise das Dienst-Kennzeichen, die Client-IP-Adresse, Ablaufdatum und -Zeit sowie Prozessorau­ torisierung, wie zuvor beschrieben wurde. Die Client- Erweiterung 64 enthält Informationen wie beispielsweise Kreditkartennummer und Postleitzahl, ebenfalls zuvor be­ schrieben. Die Informationen in dem Auftragsetikett 61 (ausschließlich des Öffentlicher-Schlüssel-Signaturfeldes 67) werden daraufhin beispielsweise unter Verwendung eines MD5-Protokolls optional Hash-codiert und mit einem Öffent­ licher-Schlüssel-Verschlüsselungssystem verschlüsselt, Block 610, wobei eine Hash-Nummer erzeugt wird, Block 615. Es können auch andere Hash-Codierungs- oder Verschlüsse­ lungsmethoden verwendet werden. Die Hash-Nummer ist reprä­ sentativ für die in dem Auftragsetikett 61 enthaltenen spe­ zifischen Informationen. Die bei Block 615 erzeugte Hash- Nummer wird daraufhin unter Verwendung eines standardmäßi­ gen Öffentlicher-Schlüssel-Verschlüsselungssystems ver­ schlüsselt, Block 620. Ein Verschlüsseln der Hash-Nummer mit einem privaten Schlüssel verhindert, daß ein Benutzer ohne Kenntnis des öffentlichen Schlüssels die Auftragsin­ formationen modifiziert. Bei Block 625 werden das Auftrags­ etikett 61 und die verschlüsselte Hash-Nummer verkettet, um das abgeschlossene Auftragsetikett 61 zu erzeugen. Daher die Informationsfelder des abgeschlossenen Auftragsetiketts 61: 1) der Rahmen 62, 2) die Client-Erweiterung 64 und 3) die Öffentlicher-Schlüssel-Signatur (verschlüsselte Hash- Nummer) 67. Daraufhin endet das Verfahren, Block 630.

Bei den veranschaulichten Ausführungsbeispielen können das Dienstezentrum 40 und seine Unterkomponenten, einschließ­ lich der Arbeitsflußsteuerung 70 und des Auftragsetikett­ dienstes 60, beispielsweise als eine einzelne, einem be­ stimmten Zweck gewidmete integrierte Schaltung (z. B. eine ASIC), die einen Haupt- oder Zentralprozessorabschnitt für eine Gesamtsteuerung auf Systemebene aufweist, und als se­ parate Schaltungen implementiert sein, die dafür reserviert sind, diverse unterschiedliche Berechnungen, Funktionen und andere Prozesse unter der Steuerung des Zentralprozessorab­ schnitts durchzuführen. Fachleuten wird einleuchten, daß das Dienstezentrum 40 ferner unter Verwendung einer Mehr­ zahl von separaten, zweckgebundenen oder programmierbaren integrierten oder anderen elektrischen Schaltungen oder Vorrichtungen implementiert sein kann (z. B. festverdrahte­ ten elektronischen oder logischen Schaltungen wie bei­ spielsweise Schaltungen mit Einzelbauelementen, oder pro­ grammierbaren logischen Vorrichtungen wie beispielsweise PLDs, PLAs oder PALs). Das Dienstezentrum 40 kann ferner unter Verwendung eines auf geeignete Weise programmierten Mehrzweckcomputers, z. B. eines Mikroprozessors, einer Mik­ rosteuerung oder einer anderen Prozessorvorrichtung (CPU oder MPU), entweder allein oder in Verbindung mit einem oder mehreren Daten- und Signalverarbeitungs- Peripheriegeräten (z. B. integrierte Schaltung) implemen­ tiert sein. Allgemein kann jegliche Vorrichtung oder Anord­ nung von Vorrichtungen, bei der eine Finit-Zustand- Maschine, die in der Lage ist, die in den Fig. 9 bis 15 ge­ zeigten Flußdiagramme zu implementieren, verwendet werden kann, als das Dienstezentrum 40 oder seine Unterkomponenten verwendet werden.

Claims (22)

1. Vorrichtung, die einen Zugriff auf ein Auftragsetikett (61) steuert, wobei sich das Auftragsetikett (61) auf eine Auftragsanforderung (32) bezieht, die durch einen oder mehrere Prozessoren (80), die mit einem Kommuni­ kationsnetz (35) gekoppelt sind, ausgeführt werden soll, wobei die Vorrichtung folgende Merkmale auf­ weist:
eine Arbeitsflußsteuerung (70), die mit dem Kommunika­ tionsnetz (35) gekoppelt ist, wobei die Ar­ beitsflußsteuerung (70) in der Lage ist, einen Ar­ beitsfluß, der der Auftragsanforderung (32) ent­ spricht, zu definieren, und in der Lage ist, das Auf­ tragsetikett (61) zu definieren, und wobei der Ar­ beitsfluß einen oder mehrere Zweige (66) aufweist; und
einen Auftragsetikettdienst (60), der in der Lage ist, das Auftragsetikett (61) zu speichern, wobei das Auf­ tragsetikett (61) einen Rahmen (62) aufweist, der den einen oder die mehreren Zweige (66) spezifiziert, und wobei der Auftragsetikettdienst (60) einen Zweig (66) sperrt, wenn auf den Zweig (66) durch einen Prozessor (80) zugegriffen wird.

2. Vorrichtung gemäß Anspruch 1, bei der ein Zweig (66) ein Sperren-/Entsperren-Flag (97) aufweist, wobei das Sperren-/Entsperren-Flag (97) auf Sperren eingestellt wird, um den Zweig (66) zu sperren.

3. Vorrichtung gemäß Anspruch 2, bei der das Sperren- /Entsperren-Flag (97) den Zweig (66) sperrt, um eine Zweigmodifizierung zu verhindern, und bei der ein zweiter Prozessor (80) in einem Nur-Lesen-Modus auf den gesperrten Zweig (66) zugreifen kann.

4. Vorrichtung gemäß einem der Ansprüche 1 bis 3, die ferner einen Zugriffsschlüssel aufweist, wobei der Zu­ griffsschlüssel dem Prozessor (80), der auf den Zweig (66) zugreift, bereitgestellt wird, und bei der der Prozessor (80) den Zugriffsschlüssel dem Auftragseti­ kettdienst (60) bereitstellt, um den gesperrten Zweig (66) zu entsperren.

5. Vorrichtung gemäß Anspruch 4, bei der der Auftragseti­ kettdienst (60) ein Schlüsselverschlüsselungssystem aufweist und bei der der Zugriffsschlüssel unter Ver­ wendung des Schlüsselverschlüsselungsdienstes ver­ schlüsselt ist.

6. Vorrichtung gemäß einem der Ansprüche 1 bis 5, bei der der Prozessor (80), der auf den Zweig (66) zugreift, zu einem Zugriff auf dem Zweig (66) autorisiert ist, und bei der eine solche Autorisierung mit dem Auf­ tragsetikett (61) gespeichert ist.

7. Vorrichtung gemäß einem der Ansprüche 1 bis 6, die ferner einen Auftragsspeicher (50) umfaßt, wobei der Auftragsspeicher (50) einen Inhalt (51) speichert, der dem Zweig (66) entspricht, und wobei der Prozessor (80) auf den Inhalt (51) zugreift, wenn der Zweig (66) entsperrt ist.

8. Vorrichtung gemäß einem der Ansprüche 1 bis 7, bei der das Sperren-/Entsperren-Flag (97) einen Hinweis auf einen Sperrzustand für den Zweig (66) liefert.

9. Vorrichtung gemäß einem der Ansprüche 1 bis 8, bei der der Auftragsetikettdienst (60) eine Datentabelle auf­ weist, die Zweige (66) des Arbeitsflusses auflistet, und bei der, wenn der Prozessor (80) auf einen Zweig zugreift, der Auftragsetikettdienst (60) die Datenta­ belle markiert, um anzugeben, daß der Zweig für eine Modifizierung nicht zur Verfügung steht.

10. Verfahren zum Steuern eines Zugriffs auf ein Auftrags­ etikett (61) durch Sperren von Zweigen (66) des Auf­ tragsetiketts (61), bei dem sich das Auftragsetikett (61) auf einen Auftrag bezieht, der durch einen oder mehrere Prozessoren (80) in einem elektronischen Netz ausgeführt werden soll, wobei das Verfahren folgende Schritte aufweist:
Identifizieren (360) eines Zweiges (66) des Auftrags­ etiketts (61);
Empfangen (515) einer Zweigzugriffsanforderung von ei­ nem Prozessor (80);
Versorgen (525) des Prozessors (80) mit einem Zugriff auf den Zweig (66); und
Sperren (555) des Zweiges (66).

11. Verfahren gemäß Anspruch 10, bei dem der Schritt des Sperrens des Zweiges (66) den Schritt des Setzens ei­ nes Sperren-Flags (97) umfaßt.

12. Verfahren gemäß Anspruch 10 oder 11, bei dem der Schritt des Sperrens des Zweiges (66) den Schritt des Vornehmens eines Sperren-Eintrags in einer Datenta­ belle umfaßt.

13. Verfahren gemäß einem der Ansprüche 10 bis 12, bei dem der Schritt des Sperrens des Zweiges (66) eine Zweig­ modifizierung verhindert und einen Nur-Lese-Zugriff auf den Zweig (66) ermöglicht.

14. Verfahren gemäß einem der Ansprüche 10 bis 13, das ferner den Schritt eines Versorgens des Prozessors (80) mit einem Schlüssel umfaßt, wobei der Schlüssel einen Modifikationszugriff auf den Zweig (66) steuert.

15. Verfahren gemäß Anspruch 14, das ferner den Schritt eines Verschlüsselns des Schlüssels umfaßt.

16. Verfahren gemäß Ansprüch 14 oder 15, das ferner den Schritt eines Zurückgebens des Schlüssels, um einen Zugriff auf den Zweig (66) zur Modifizierung zu erlan­ gen, umfaßt.

17. Verfahren zum Steuern eines Zugriffs auf ein Auftrags­ etikett (61), bei dem eine Mehrzahl von Prozessoren (80) um eine Auswahl konkurrieren, um auf das Auf­ tragsetikett (61) bezogene Aufgaben durchzuführen, wo­ bei das Verfahren folgende Schritte aufweist:
Definieren einer oder mehrerer Aufgaben zum Abschlie­ ßen des Auftragsetiketts (61), wobei das Auftragseti­ kett (61) einen Knotenbaum (10) mit einer Mehrzahl von Zweigen (66) aufweist und wobei jeder Zweig (66) der Mehrzahl von Zweigen (66) eine oder mehrere definierte Aufgaben umfaßt;
Empfangen einer Anforderung von einem oder mehreren der Mehrzahl von Prozessoren (80), auf einen oder meh­ rere der Mehrzahl von Zweigen (66) zuzugreifen;
Bestimmen, ob ein Prozessor (80) derzeit auf einen o­ der mehrere der Mehrzahl von Zweigen (66) zugreift;
für Zweige (66), auf die derzeit nicht zugegriffen wird, Bestimmen, ob der eine beziehungsweise die meh­ reren anfordernden Prozessoren (80) zu einem Zugriff auf die Zweige (66) autorisiert ist beziehungsweise sind;
für Zweige (66), für die ein Zugriff autorisiert ist, Kopieren von Informationen von den Zweigen (66) zu den autorisierten Prozessoren (80); und
Sperren der Zweige (66), auf die zugegriffen wird.

18. Verfahren gemäß Anspruch 17, bei dem ein Prozessor (80), der auf einen Zweig (66) zugreift, die Zweigin­ formationen modifiziert, wobei das Verfahren ferner folgende Schritte aufweist:
Entsperren des Zweiges (66); und
Kopieren der modifizierten Zweiginformationen auf das Auftragsetikett (61).

19. Verfahren gemäß Anspruch 17 oder 18, bei dem der Schritt des Sperrens des Zweiges (66) den Schritt ei­ nes Setzens eines Sperren-Flags an dem Zweig (66) um­ faßt.

20. Verfahren gemäß einem der Ansprüche 17 bis 19, bei dem der Schritt des Sperrens des Zweiges (66) eine Zweig­ informationsmodifizierung verhindert und einen Nur- Lese-Zugriff auf den gesperrten Zweig (66) ermöglicht.

21. Programmspeichervorrichtung, die durch eine Maschine lesbar ist und auf greifbare Weise ein Programm von Anweisungen verkörpert, die durch die Maschine aus­ führbar sind, um Verfahrensschritte zum Steuern eines Zugriffs auf ein Auftragsetikett (61) durchzuführen, wobei eine Mehrzahl von Prozessoren (80) um ein Aus­ wählen konkurriert, um auf das Auftragsetikett (61) bezogene Aufgaben durchzuführen, wobei die Verfahrens­ schritte folgende Schritte aufweisen:
Definieren einer oder mehrerer Aufgaben zum Abschlie­ ßen des Auftragsetiketts (61), wobei das Auftragseti­ kett (61) einen Knotenbaum (10) mit einer Mehrzahl von Zweigen (66) aufweist und wobei jeder Zweig (66) der Mehrzahl von Zweigen (66) eine oder mehrere definierte Aufgaben umfaßt;
Empfangen einer Anforderung von einem oder mehreren der Mehrzahl von Prozessoren (80), auf einen oder meh­ rere der Mehrzahl von Zweigen (66) zuzugreifen;
Bestimmen, ob ein Prozessor (80) derzeit auf einen oder mehrere der Mehrzahl von Zweigen (66) zugreift;
für Zweige (66), auf die derzeit nicht zugegriffen wird, Bestimmen, ob der eine beziehungsweise die meh­ reren anfordernden Prozessoren (80) zu einem Zugriff auf die Zweige (66) autorisiert ist beziehungsweise sind;
für Zweige (66), für die ein Zugriff autorisiert ist, Kopieren von Informationen von den Zweigen (66) zu den autorisierten Prozessoren (80); und
Sperren der Zweige (66), auf die zugegriffen wird.

22. Programmspeichervorrichtung gemäß Anspruch 21, bei der ein Prozessor (80), der auf einen Zweig (66) zugreift, die Zweiginformationen modifiziert, wobei die Verfah­ rensschritte ferner folgende Schritte aufweisen:
Entsperren des Zweiges (66); und
Kopieren der modifizierten Zweiginformationen auf das Auftragsetikett (61)