DE69801420T2

DE69801420T2 - System und verfahren zum erstellen, ausführen und warten vond zwischenbetrieb-lichen vorgängen

Info

Publication number: DE69801420T2
Application number: DE69801420T
Authority: DE
Inventors: Robert Frost; W. Nibbelink; R. Olsen; Chelliah Thirunavukkarasu
Original assignee: Peregrine Extricity Inc
Current assignee: GXS Inc
Priority date: 1997-01-24
Filing date: 1998-01-23
Publication date: 2002-07-18
Anticipated expiration: 2018-01-24
Also published as: BR9809557A; AU6317198A; EP0954799A1; ID23434A; NZ336275A; CA2275190A1; DE69801420D1; DK0954799T3; CA2275190C; WO1998033125A1; JP2000511674A; CN1244267A; EP0954799B1; US6519642B1; AU714340B2; JP3090435U; IL130736A0

Description

Die Erfindung betrifft im allgemeinen Informationssysteme und insbesondere ein System und Verfahren zur Ermöglichung der Koordination von Aktivität zwischen verteilten Informationssystemen.
Die jüngste Veränderung in der Struktur von Unternehmensorganisationen, von unabhängigen monolitischen Einheiten zu mehreren voneinander abhängigen Geschäftsbereichen, spiegelt eine ähnliche Entwicklung in Computersystemen, von der einzelnen Zentraleinheit (Mainframe) zu verteilten Netzen mit Personal Computern und Arbeitsstationen, wieder. Da Computernetzwerke extrem effizient in der Übertragung von Information und Ausführung von Aktionen zwischen verteilten Orten sind, sollten moderne Netzwerke offensichtlich vorteilhaft für diese Revolution der Technologie sein. Solche standardmäßigen Aktivitäten, wie die Bestellung und Bestätigung eines Kaufs, könnten zwischen vorhandenen Systemen in einem geteilten Computernetzwerk automatisch ausgeführt werden. Zahlreiche Nachteile des Standes der Technik verhindern jedoch die vollständige Ausnutzung der herkömmlichen Netzwerktechnologie für zwischenbetriebliche Zwecke.
Die dringlichsten Probleme, welche sich bei der Benutzung geteilter Netze zwischen Geschäftspartnern stellen, sind (1) die Heterogenität der Computersysteme der Partner, (2) die Heterogenität der von den Partnersystemen benutzten Daten, (3) die Übertragungssicherheit und -zuverlässigkeit zwischen den Systemen und (4) gesetzliche, organisatorische und kulturelle Grenzen zwischen Partnern.
In bezug auf diese Systemheterogenität nutzen Organisationen häufig Kombinationen von Betriebssystemen, Middleware-Systeme und Softwareanwendung, die zueinander inkompatibel sind. Eine weit verbreitete Ausnutzung von Middleware ist nun auf dem Weg, die Interoparabilität zwischen den führenden Lagern wurde jedoch noch nicht vollständig definiert. Insbesondere problematische sind Unterschiede auf der Anwendungsebene, die grundsätzlich sind und die Realisationen noch einige Zeit herausfordern werden.
In bezug auf das zweite Problem, die Datenheterogenität, stellen verschiedene Anwendungen und Benutzer dieser Anwendungen Information häufig auf verschiedene Arten dar oder verwenden verschiedene Arten von Information zur Erfüllung derselben Aufgabe. Diese Unterschiede können besonders deutlich werden, wenn die Anwendungen und ihre Benutzer auf verschiedene Unternehmen verteilt sind. Die Überbrückung der damit einhergehenden syntaktischen und semantischen Unterschiede in der Information kann eine Mischung aus Transformationsfähigkeiten sowie neutralen Objekten erfordern.
In bezug auf das dritte Problem, die Übertragungssicherheit und -zuverlässigkeit, erfordert jede Interaktion zwischen den Systemen eines Unternehmensnetzwerks das Vorhandensein zuverlässiger und sicherer Übertragungswege zwischen den Teilnehmern. Die Sorge für die Sicherheit ist besonders wichtig, wenn das Internet als ein Glied in dem Übertragungsweg verwendet wird, weil dieses Medium anfällig gegen Abhören und andere Formen von Sicherheitsangriffen ist.
In bezug auf das vierte Problem, muß jeder Versuch, Geschäfisabläufe zwischen mehreren Partnern zu automatisieren, die zahlreichen nicht-technischen Grenzen überwinden, die mit der Verwaltung eines Projekts einhergehen, das über mehrere Organisationen verteilt ist. Diese Herausforderungen umfassen mangelnden Abgleich zwischen der Projektpriorität und der Zuweisung von Ressourcen, Sprachgrenzen, unterschiedliche Zeitzonen und sowohl Unternehmens- als auch Regierungsbestimmungen. Diese Herausforderungen begrenzen das Niveau der Koordination, das erreichbar ist. Jede technische Lösung muß daher darauf fokussiert sein, den Bereich und die Komplexität der gegenseitigen Festschreibung, die zum Realisieren der Lösung notwendig ist, zu minimieren.
Zur Zeit gibt es wenigstens fünf bekannte Verfahren zum Erweitern voneinander abhängiger Prozesse über ein Computersystem hinaus auf andere Systeme, welche über herkömmliche Computernetzwerkressourcen verbunden sind. Das erste ist ein manueller Ansatz, bei dem Nutzer mehrerer Computersysteme Information untereinander über Telefon, Fax oder andere Medien übertragen. Die übertragene Information wird dann von Hand in die jeweiligen Computersysteme eingegeben. Der manuelle Ansatz kann zur Überbrückung von Lücken in der Automatisierung verwendet werden, ist jedoch offensichtlich beschränkt in seiner Fähigkeit, Prozesse zwischen Partnern auf zuverlässig und effiziente Weise eng zu koppeln.
Der zweite Ansatz, der in der Ära der selbstgemachten Anwendungen für Zentraleinheiten entstand, ist bekannt als elektronischer Datenaustausch (EDI; Electronic Data Interchange). EDI ist ein breit definierter Begriff, bezeichnet jedoch am häufigsten einen bestimmten Satz von Normen, Technologien (Zusatznutzen-Netz, Selbstwählverkehr, Abbildungssoftware) und Gebräuche, die für den elektronischen Datenaustausch zwischen Unternehmen genutzt werden. Beim EDI können eine Sammlung von Geschäftsinformationen (z. B. ein Kaufauftrag) von einem Anwendungssystem exportiert werden, in ein neutrales Format abgebildet werden, zu einem Partner über ein VAN (Zusatznutzen-Netzwerk; Value-Added Network) übertragen werden, von dem Partner in ein Format abgebildet werden, das sich für seine Anwendung eignet und in die Anwendung, des Partners importiert werden. Alternativ kann das direkte Anwählen das VAN ersetzen. Der EDI ist jedoch im allgemeinen stapelorientiert, erfordert eine aufwendige Formatanpassung und unterstützt keine Prozesse.
Der dritte Ansatz, der zum Einsatz kommt, wenn die Unternehmensanforderungen nicht in das EDI-Modell passen, besteht darin, ein kundenspezifisches System zu nutzen, das gemäß den Spezifikationen der Benutzer gestaltet und realisiert ist. Dieser Ansatz ist kostenträchtig, erfordert eine Mischung aus Netzwerkprogrammierung und Systemintegrationsaufgaben und dient nur einem bestimmten Zweck bestimmter Nutzer. Es ist ferner nicht flexibel und schwierig zu modifizieren.
Jüngst haben zwei Trends in der Technologie die Arten, auf welche Anwendungssysteme vernetzt werden können, radikal verändert. Als Folge mußten zu den drei oben erörterten Ansätzen ein vierter und ein fünfter Ansatz sowie eine Anpassung des EDI hinzugefügt werden. Der erste Trend ist die rapide Erweiterung der Netzwerkinfrastruktur. Die am stärksten sichtbare Komponente dieser Infrastruktur ist die allgegenwäirtige Verbindbarkeit, die durch das Internet geschaffen wird. Beinah alle Organisationen sind mit dem Internet verbunden oder werden dies bald sein. Mit dieser Verbindbarkeit geht eine sich vergrößernde Menge von Middleware-Techniken und Diensten einher, wie verteilte Objekt-Rahmen und nachrichtenorientierter Middleware, welche besser lenkbare verteilte Anwendungen erleichtern und eine größere Interoparabilität der Softwarekomponenten versprechen.
Der zweite Trend betrifft Fortschritte in den Geschäftsanwendungssystemen, die von Unternehmen genutzt werden. Schlüsselmerkmale dieses Fortschritts in den Systemen umfassen die Entwicklung von Objektschnittstellen und die Entwicklung von Modellierungskapazitäten für Arbeitsablauf/Prozesse. Objektschnittstellen bieten ein flexibleres und weniger teures Verfahren zum Bewegen von Information zu und von Anwendungen als frühere Verfahren wie SQL (Structured Query Language; strukturierte Abfragesprache) oder dateibasierte Schnittstellen. Mehrere Verkäufer von Anwendungen bieten nun die Möglichkeit an, den Arbeitsablauf zwischen verschiedenen Anwendungsmodulen zu gestalten und zu realisieren. Diese Fähigkeit erlaubt es Unternehmen, sich besser auf ihre Geschäftsabläufe zu konzentrieren, und macht die Notwendigkeit, die Prozesse der Geschäftspartner zu verbinden, offensichtlicher.
Die am stärksten sichtbare Wirkung dieser Trends, und der vierte Ansatz zur Erweiterung der gegenseitigen Abhängigkeit von Geschäften, ist die Verwendung des World Wide Web für die Interaktion zwischen Unternehmen (b2b-Lnteraktion). In diesem Modell greift ein Angestellter eines Unternehmens auf Information zu, wie ein Katalog oder Frachtinformation, welche die Geschäftsanwendung eines anderen Unternehmens betrifft, indem er einen üblichen Web-Browser verwendet. Dieser Ansatz ist jedoch für viele umfangreiche Unternehmensprozesse, welche abhängige Interaktionen zwischen den Anwendungssystemen verschieden Organisationen erfordern, schlecht geeignet.
Der fünfte Ansatz nutzt jüngste Middleware-Technik, die es möglich macht, hochleistungsfähige verteilte Anwendungen zu erzeugen, die logisch integriert sind. Obwohl dieselbe Technik dazu genutzt werden kann, die Interoperation zwischen Anwendungsreihen verschiedener Verkäufer und zwischen Systemen in verschiedenen Unternehmen herzustellen, begrenzen erhebliche Herausforderungen die Machbarkeit. Zu aller erst ist die Verwendung der Middleware-Technik eine Programmieraufgabe, die erhebliche Programmierfähigkeiten und ein spezielles Verständnis der Sicherheit, Synchronisierung und anderer Netzwerkgegebenheiten erfordert. Die Kosten einer solchen Aufgabe könne für den Verkäufer einer verteilten Anwendung gerechtfertigt sein; Unternehmen, welche an einem bestimmten erweiterten Unternehmensprozess teilnehmen wollen, werden jedoch wahrscheinlich nicht das Kapital aufwenden, das zum Aufbauen verteilter Systeme von Grund auf notwendig ist.
Die Anpassung des EDI, die als Internet-EDI bezeichnet wird, umfaßt schließlich tatsächlich mehrere Verfahren, die versuchen, den traditionellen EDI-Ansatz, der oben erörtert wurde, auf ein Internet-Transportmedium zu übertragen. Diese Verfahren sind durch den Wunsch motiviert, hohe Transportkosten zu reduzieren, die mit den Zusatznutzen-Netzen (VAN) einhergehen. Diese Verfahren unterscheiden sich im Ergebnis sehr wenig von dem traditionellen EDI. Dieselben Nachrichtenformate, Abbildungssoftware und sogar Verpackungskonstrukte werden verwendet. Die Verwendung eines offenen Netzwerk erfordert jedoch zusätzliche Sicherheit, Zuverlässigkeit und Prüffähigkeiten, die früher Vorteil eines VAN-Dienstes waren. Zusätzlich müssen diese zusätzlichen Diente in einer offenen Netzwerkkonfiguration von Software an den Endpunkten eines Informationsaustauschs unterstützt werden. Der Internet- EDI leidet daher unter wesentlichen Beschränkungen, wie die fehlende Prozeßunterstützung, ein unangemessener Formalismus der Darstellung und ein Integrationsmodell, das mit den neuen Gebräuchen nicht zusammenpaßt.
Das U.S. Patent 5,390,247 offenbart ein Verfahren und eine Vorrichtung zum Erzeugen eines "reisenden" Programms umfassend Befehle und zugehörige Daten, das die Fähigkeit hat, wenigsten ein nächstes Ziel zu ermitteln und sich selbst zusammen mit den notwendigen zugehörigen Daten von einem Computernutzer zu einem anderen zu bewegen. D1 konzentriert sich insbesondere auf die digitale Authentisierung.
Das U.S. Patent 5,557,780 offenbart ein programmierbares Maschinensystem und ein Verfahren zum Ausführen von elektronischem Datenaustausch (EDI) zwischen zwei oder mehr Handelspartnern, einschließlich der Empfang, die Manipulation und die neue Übertragung von EDI-strukturierten Daten in jedem üblichen EDI-Fonnat ohne das Erfordernis eines Modells.
Die DE-A-196 29 192 beschreibt ein Kommunikationssystem, in dem Sender- und Empfängercomputer Verschlüsselung mit öffentlichem und privatem Schlüssel nutzen. Hashcodes werden für den elektronischen Datenaustausch berechnet und vor der Verschlüsselung mit dem privaten Schlüssel in Nachrichten eingebaut.
Die GB-A-2 271 002 befaßt sich mit dem Vergleich von EDI, nachrichtenbasiertem EDI, transaktionsbasiertem EDI und interaktivem EDI.
Die obigen Lösungen versagen darin, die zunehmenden Anforderungen an die Realisierung von komplexen automatisierten Prozessen, die sowohl sicher als auch handlebar sind, zwischen verteilten Systemen zu erfüllen. Es werden daher ein System und ein Verfahren zum Planen und Kontrollieren umfangreicher Geschäftsabhängigkeiten benötigt, die (1) sich insbesondere auf Interaktionen zwischen gleichrangigen Stationen (peer-to-peer) zwischen vorhandenen Geschäftsanwendungssystemen konzentrieren, (2) eine sichere und zuverlässige Kommunikation unterstützen, (3) die Entwicklung von Spezialsoftware minimieren, (4) eine Funktion zum Handhaben der Formalismen für die Darstellung heterogener Daten aufweisen und (5) die Fähigkeit haben, komplexe Prozesse zu unterstützen, die sich in und aus Unternehmensnanwendungen erstrecken.
Die Erfindung sieht ein Verfahren zu Koordinieren eines Prozesses zwischen einem ersten Standort und einem zweiten Standort mit den Merkmalen von Anspruch 1 und ein Verfahren zum Erzeugen einer Prozeßdefinition zur Kontrolle eines Prozesses zwischen einem ersten Standort und einem zweiten Standort mit den Merkmalen von Anspruch 9 vor.
Die Erfindung betrifft Verfahren zum Erzeugen, Ausführen und Aufrechterhalten von Prozessen zwischen Unternehmen. Prozesse zwischen Unternehmen sind geteilte automatisierte Geschäftsprozesse oder Arbeitsabläufe zwischen verteilten Informationssystemen, welche bestimmte Vorkehrungen für die Automatisierung dieser Prozesse über die Organisationsgrenzen hinaus und zwischen heterogenen Informationssystemen umfassen.
Das System besteht aus mehreren unabhängigen Kommunikationsuntersystemen mit gemeinsamen Fähigkeit, die Standort oder Stelle (site) genannt werden. Jeder dieser Standorte umfaßt eine Server mit gemeinsamen Mitteln zum Darstellen und Ausführen gemeinsam genutzter Prozeßdefinitionen. Diese Standorte handeln abgestimmt im Laufe der Ausführung geteilter Inter-Systemprozesse. Die Prozeßausführung umfaßt den koordinierten Nachrichtenaustausch zwischen den Standorten, dei gekoppelt ist mit einer kontrollierten Folge von Aktionen, die für jeden der Standorte lokal sind. Zusätzlich kann jeder der Standorte eines von mehreren Anwendungsprogrammen und Betriebssystemen zur Ausführung der Inter-Systemprozesse und der internen Prozesse auf dem Server aufweisen.
Automatisierte Inter-Systemprozesse werden in den Verfahren gemäß der Erfindung in einem zweistufigen Prozeßmodell dargestellt. Die obere Stufe oder öffentliche Prozeßdefinition/Modul erfaßt Interaktionen zwischen den unabhängigen Standorten (die jeweils üblicherweise eine Organisation oder eine Geschäfiseinheit darstellen). Interaktionen umfassen Datenaustauschereignisse, bei denen ein Standort, der in der öffentlichen Prozeßdefinition durch einen Knoten bezeichnet wird, eine Nachricht bekannter Art an einen anderen Standort schickt. Die öffentliche Prozeßdefinition ist dann eine logische Gruppierung oder ein gerichteter Graph voneinander abhängiger Datenaustauschereignisse zwischen einer Gruppe von Standorten. Jede Definition spezifiziert eine Gruppe gültiger Folgen von Datenaustauschereignissen zwischen den teilnehmenden Standorten.
Jeder öffentlichen Prozeßdefinition ist ein Gruppe von privaten Prozeßdefinitionen oder Modulen einer unteren Ebene zugeordnet. Eine getrennte private Prozeßdefinition ist in einem öffentlichen Prozeß jedem Knoten zugeordnet. Die private Prozeßdefinition spezifiziert eine Gruppe möglicher lokaler Aktionen, die an dem Standort ausgeführt werden können, wenn ein bestimmter öffentlicher Prozeßknoten ausgeführt wird. In der bevorzugten Ausführungsform ist die private Prozeßdefinition nach Art von Konstrukten definiert, wie Operationsparmeter und Softwareanwendungsinteraktionen, die für den Knoten oder Standort spezifisch sind.
Fig. 1 zeigt ein Blockdiagramm eines erweiterten Unternehmens mit mehreren Standorten, welche öffentliche Prozeßdefinitionen und private Prozeßdefinitionen gemäß der Erfindung aufweisen.
Fig. 2 zeigt eine graphische Darstellung einer öffentlichen Prozeßdefinition mit Knoten, Bögen und Verbindungen zwischen diesen gemäß der Erfindung.
Fig. 3 zeigt ein Flußdiagramm des Prozesses zum Ausführen einer privaten Prozeßdefinition gemäß der Erfindung.
Fig. 4 zeigt ein Blockdiagramm eines Systems gemäß der Erfindung.
Fig. 5 zeigt ein Flußdiagramm eines Verfahrens zum Verteilen einer öffentlichen Prozeßdefinition gemäß der Erfindung.
Fig. 6 zeigt ein Flußdiagramm eines Verfahrens für die Installation einer öffentlichen Prozeßdefinition gemäß der Erfindung.
Fig. 7 zeigt ein Flußdiagramm eines Verfahrens zum Ausführen einer Instanz für einen bestimmten Prozeßtyp gemäß der Erfindung.
Fig. 8 zeigt eine graphische Darstellung einer Anzeigevorrichtung, die eine graphische Benutzerschnittstelle zum Editieren der öffentlichen Prozeßdefinition darstellt.
Fig. 9 zeigt eine graphische Darstellung einer Anzeigevorrichtung, die eine graphische Benutzerschnittstelle zum Editieren einer privaten Prozeßdefinition darstellt.
Mit Bezug auf Fig. 1 wird eine bevorzugte Ausführungsform eines erweiterten Geschäftssystems 100 dargestellt. Das erweiterte Geschäftssystem 100 gemäß der bevorzugten Ausführungsform der Erfindung umfaßt vorzugweise mehrere Standorte 101, 102 und 103, die bei unterschiedlichen Organisationen installiert sind, welche über ein Kommunikationsnetzwerk 104 gekoppelt sind. Diese Standorte oder Stellen 141-103 bilden ein erweitertes Geschäft oder Unternehmen 100, in dem die internen Prozesse jedes Standortes 101-103 mit den internen Prozessen anderer Standorte 101-103 über koordinierte Folgen von Informationsaustausch gekoppelt sind. Die Standorte 101-103 können zum Beispiel Gescäftsunternehmen sein, welche drei Elemente einer Versorgungskette umfassen: Lieferant, Hersteller und Kunde. Der Fachmann wird jedoch verstehen, daß die Standorte 101-103 jede Art von Geschäftseinheit oder Funktion sein können, daß es beliebig viele Standorte geben kann und daß drei Standorte 101-103 nur als Beispiel gewählt sind.
Jeder dieser Standorte 101-103 stellt eine Kontrollzone dar und wird gebildet aus einer Gruppe von Anwendungssystemen, welche Information speichern und eine Logik zum Wiedergewinnen und Modifizieren dieser Information aufweisen. Beispielhafte Anwendungen umfassen ERP (Enterprise Resource Planning; Planung von Unternehmensressourcen)-Anwendungsfolgen, Produktdatenmanagement (PDM)-Systeme, logistische Anwendungen und fortschrittliche Planungssysteme (APS; Advanced Planning Sy stems).
Der Betrieb der Erfindung umfaßt koordinierte Folgen oder Sequenzen von Aktionen innerhalb jedes Standortes 101-103, welche mit koordinierten Folgen von Informationsaustausch zwischen verschiedenen Standorten 101-103 verknüpft sind. Diese Aktionen, welche innerhalb jedes Standortes 101-103 ausgeführt werden, umfassen hauptsächlich die Bewegung von Information zu und aus den Anwendungen, die zu den Standorten 101-103 gehören. Jedem Informationsaustausch zwischen Standorten 101-103 geht eine Folge von Aktionen innerhalb des sendenden Standortes voraus und folgt einer andere Folge von Aktionen innerhalb des empfangenen Standortes. Diese standortspezifischen Folgen von Aktionen dienen somit als die Verbindungen, welche eine Gruppe von Informationsaustausch-Vorgängen in eine einzige koordinierte Folge von Interaktionen einbinden.
Die möglichen Folgen von lokalen Aktionen und Informationsaustausch zwischen den Standorten sind für eine Prozeßdefinitionssprache spezifisch. Diese Sprache erlaubt komplexe Verzweigungen und Schleifenlogik und kann Beschränkungen enthalten, welche die Beziehungen zwischen Folgen lokaler Aktionen und den Austausch zwischen den Standorten beherrschen. Gemäß einem formaleren Aspekt umfaßt die Prozeßdefinitionssprache der bevorzugten Ausführungsform Knoten- und Bogenelemente, welche in einer bestimmten Ordnung und Logik kombiniert werden, um einen gerichteten Graphen zu erzeugen (wie in Fig. 2 gezeigt und beschrieben). Ein einzelner Ursprungsknoten 205-225 und eine einzelner Zielknoten 205-225 definieren jeweils ein Bogenelement. Jeder Knoten 205-225 umfaßt eine Gruppe von Eingangsbögen und eine zugehörige Logik, welche ihn mit vorhergehenden Knoten 205-225 verbindet, und eine Gruppe von Ausgangsknoten und eine zugehörige Logik, welche ihn mit nachfolgenden Knoten 205-225 verbindet. Die Beziehung zwischen den Eingangsbogen eines gegebenen Knotens 205-225 ist durch einen logischen Satz definiert, der möglicherweise verschachtelte konjunktive und disjunktive Vorschlagsverbindungen umfaßt, wobei jeder Bogen durch ein eigenes Vorschlagssymbol dargestellt wird. Die Ausgangsbogen eines gegebenen Knotens stehen durch einen getrennten Logiksatz äquivalenter Form in Beziehung. Der Knoten 201 hat keine Eingangsbogen und wird als Anfangsknoten bezeichnet. Die Knoten 299 haben keine Ausgangsbogen und werden als Endknoten bezeichnet.
In der bevorzugten Ausführungsform wird ein zweistufiges Prozeßmodell verwendet, um die Sammlung des Informationsaustausches zwischen den Standorten und standortspezifische Folgen von Aktionen darzustellen. Eine öffentliche Prozeßdefinition oder Modul 116a spezifiziert die Beziehung zwischen allen Vorgängen des Datenaustausch zwischen den Standorten. Die Folge möglicher Aktionen innerhalb eines einzelnen Standortes 101, 102, 103 für einen bestimmten Knoten in einer öffentlichen Prozeßdefinition 116a wird spezifiziert durch eine private Prozeßdefinition oder Modul 118a, 118b, 118c. Sowohl die öffentliche als auch die private Prozeßdefinition 116a, 118a, 118b, 118c bauen auf die Prozeßdefinitionssprache mit bestimmten Interpretationen für Knoten 205-225 und Bogenelemente auf. In einer öffentliche Prozeßdefinition 116a stellt jedes Knotenelement einen bestimmten Standort 101, 102, 103 dar und jedes Bogenelement stellt eine Nachricht mit einem bestimmten Informationsgehalt dar, der von dem Standort 101, 102, 103, der durch den Ursprungsknoten des Bogen dargestellt wird, zu dem Standort, der durch den Zielknoten dargestellt wird, gesendet wird. Der Graph für einen öffentlichen Prozeß kann nur einen einzelnen Anfangsknoten umfassen. Die öffentliche Prozeßdefinition 116a ist dann eine Spezifikation dessen, "wer" aus der Gruppe der Standorte 101-103 für eine bestimmten Zwecke "was wann tut". Jede öffentliche Prozeßdefinition 116a spezifizierte eine Gruppe gültiger Folgen von Datenaustauschereignissen zwischen den teilnehmenden Standorten 101, 102, 103. Genauer gesagt wird dieselbe öffentliche Prozeßdefinition 116a jedem Standort 101, 102, 103 zur Verfügung gestellt, der an der öffentlichen Prozeßdefinition 116a teilnimmt. Wie in Fig. 1 gezeigt kann jeder Standort 101, 102, 103 eine oder mehrere öffentliche Prozeßdefinitionen 116a aufweisen, eine für jeden Prozeß zwischen den Standorten. In einer privaten Prozeßdefinition 118a, 118b, 118c stellen Knotenelemente bestimmte Programmaktionen dar und spezifizieren Bogenelemente die Reihenfolge, in der diese Aktionen ausgeführt werden. Die private Prozeßdefinition 118a, 118b, 118c spezifiziert, wie Standorte 101-103 empfangene Nachrichten verarbeitet und ausgehende Nachrichten aufbauen. Ferner spezifizieren private Prozeßdefinitionen 118a, 118b, 118c, was innerhalb eines Knotens der öffentlichen Prozeßdefinition 116a passiert. Die privaten Prozeßdefinitionen 118a, 118b, 118c umfassen somit Routinen und Prozesse, die auf den jeweiligen Standort 101, 102, 103 zugeschnitten sind, zu dem die private Prozeßdefinition 118a, 118b, 118c gehört oder der mit dieser arbeitet. Noch spezieller sind die privaten Prozeßdefinitionen 118a, 118b, 118c für Interaktionen mit den Betriebssystemen, Anwendungen und Ressourcen des Standorts, zu dem sie gehören, konzipiert. Wie in Fig. 1 gezeigt unterscheidet sich somit jede private Prozeßdefinition 118a, 118b, 118c für jeden Standort 101, 102, 103. Wenn Standorte 101, 102, 103 ähnlich konfiguriert sind (zum Beispiel die gleichen Betriebssysteme, Anwendungen und Ressourcen haben), können gleichwohl die privaten Prozeßdefinitionen 118a, 118b, 118c gemeinsam genutzt werden. Der Fachmann wird verstehen, daß jeder Standort 101, 102, 103 auch mehrere private Prozeßdefinitionen 118a, 118b, 118c aufweisen kann, wie in Fig. 1 gezeigt. Die mehreren privaten Prozeßdefinitionen 118a, 118b, 118c können für eine öffentliche Prozeßdefinition 116a oder verschiedene öffentliche Prozeßdefinitionen 116a dienen.
Die bevorzugte Ausführungsform modelliert die Information, die in den Nachrichten enthalten ist, welche zwischen den Standorten 101, 102, 103 gesandt werden, als Objekte mit beschränkter Struktur und beschränktem Verhalten. Diese Objekte sind Datenbehälter, deren möglicher Inhalt durch Objektdefinitionen 120a, 120b, 120c definiert ist. In der bevorzugten Ausführungsform nimmt eine Objektdefinition 120a, 120b, 120c die Form einer XML (Extensible Markup Language) DTD (Dokument Type Definition) an. Diese Definition spezifiziert die lexikalische und grammatikalische Form aller Objekte dieses Typs. Objektdefinitionen 120a, 120b, 120c werden von öffentlicher und privater Prozeßdefinition in Bezug genommen.
Mit Bezug auf Fig. 2 ist nun eine beispielhafte öffentliche Prozeßdefinition 200 erläutert. Die öffentliche Prozeßdefinition 200 ist graphisch als ein Flußdiagramm dargestellt. Fig. 2 zeigt eine öffentliche Prozeßdefinition 200, die eine Gruppe möglicher Interaktionen zwischen den Standorten 101-103 spezifiziert. Der Prozeß 200 umfaßt eine Gruppe von Knoten 205-225 und eine Gruppe von Kommunikationsereignissen unter Datenaustauschereignissen 230-250. Jeder Knoten entspricht einem bestimmten Standort 101-103, und jedem Knoten 205-225 der öffentlichen Prozeßdefinition 200 ist eine private Prozeßdefinition 118a, 118b, 118c zugeordnet. Fig. 3 zeigt ein Beispiel einer privaten Prozeßdefinition 300, die einem Knoten 210 zugeordnet ist.
Jedes Kommunikationsereignis 230-250, welches einen Knoten mit einem anderen in einer öffentlichen Prozeßdefinition 200 verbindet, stellt den Austausch einer Nachricht eines bekannten Objekttyps dar. Der bekannt Objekttyp kann zum Beispiel ein beliebiger Typ der herkömmlichen Typen von Geschäftsobjekten sein, wie ein Kaufauftragsobjekt, ein Bestätigungsnachrichtenobjekt etc. Solche Objekte 120a, 120b, 120c sind in der Objektdefinition 120a, 120b, 120c definiert, so daß jeder Standort 101, 102, 103 die Objektdefinitionen 120a, 120b, 120c nach Bedarf verwenden kann, um Objekte auf entweder der öffentlichen Ebene oder der privaten Ebene zu verarbeiten. Mit anderen Worten ist die öffentliche Prozeßdefinition 200 eine logische Gruppierung oder ein gerichteter Graph voneinander abhängiger Kommunikationsereignisse 230-250 zwischen den Standorten 101-103, die in Fig. 1 gezeigt sind. Diese Gruppierung spezifiziert eine Gruppe gültiger Folgen von Kommunikationsereignissen zwischen den teilnehmenden Standorten 101, 102, 103. Insbesondere beschreibt die öffentliche Prozeßdefinition 200 ein Kommunikationsereignis 230 als einen Kaufauftrag, der vom Standort 101 an den Standort 102 geschickt wird. Dieser Kaufauftrag wir von dem privaten Prozeß des Standorts 101 erzeugt, der zu dem Knoten 205 gehört. Der Knoten 210 ist ein Verzweigungsknoten, und bei diesem Knoten werden zwei Kommunikationsereignisse 235 und 240 erzeugt. Abhängig von einer spezifischen Verzweigungsbedingung tritt entweder eines dieser Ereignisse oder beide Ereignisse auf. Die Bedingungen, unter denen die zwei Ereignisse ausgelöst werden, werden durch die öffentliche Definition 200 nicht angegeben, weil sie dem Standort 102 bekannt sind. Diese Bedingungen sind in der privaten Prozeßdefinition 118b enthalten, die zu dem Knoten 210 gehört und somit dem Standort 102. Der Fachmann wird auch erkennen, daß die private Prozeßdefinition 118b eine Gruppe privater Prozeßdefinitionen umfassen kann, die eine Instanz einer öffentlichen Prozeßdefinition 116a entsprechen.
Das Auftreten von Ereignissen 235 und/oder 240 bewirkt die Ausführung des (der) Knoten, welche unmittelbar folgen, und die Ausführung geht in der Figur nach unten weiter. Der Knoten 225 stellt eine Verzweigungsknoten dar, der auf eines oder alle Ereignisse einer Gruppe, die mit ihm verbunden sind, warten kann. Nach der Ausführung des Knotens 225 endet der öffentliche Prozeß beim Anschluß 299.
Jedem Knoten 205-225 der öffentlichen Prozeßdefinition 200 ist einer privaten Prozeßdefinition 118a, 118b, 118c zugeordnet. Fig. 3 zeigt zum Beispiel eine private Prozeßdefinition 300, die zu dem Knoten 210 gehört. Anders als die öffentliche Prozeßdefinition 200 wird der Inhalt der privaten Prozeßdefinition 300 durch den entsprechenden Standort bestimmt und ist nur diesem bekannt, in diesem Fall dem Standort 102. Die private Prozeßdefinition 300 umfaßt eine Anzahl von Aktionen 305-330, die abhängig von einer bestimmten Logik gesteuert werden. Mögliche Aktionen umfassen externe Geschäftsanwendungsinteraktionen, die Ausführung eines Skripts, die Benachrichtigung und Bestätigung eines Benutzers, Zeitverzögerungen, Ausgangsobjektspezifikationen und die Ausführung von Unterprozessen. Alle Instanzen der privaten Prozeßdefinition 300 haben Zugang zu dem Objekt des Typs "Kaufauftrag", der in dem Kommunikationsereignis 230 enthalten ist. Jede Aktion in der privaten Prozeßdefinition 300 kann auf dieses Objekt Bezug nehmen. Die private Prozeßdefinition 300 ist darauf beschränkt, ein Objekt entweder des Typs "Bestätigung" oder des Typs "Kaufauftrag" zu erzeugen, welche den Kommunikationsereignissen 235 bzw. 240 entsprechen.
Mit Bezug auf Fig. 3 wird nun eine beispielhafte Ausführungsform für eine private Prozeßdefinition 300 dargestellt. Die private Prozeßdefinition 300 beginnt bei einer Auslöseaktion 301, die nach der Beendigung des Kommunikationsereignisses 230 ausgeführt wird. Der Fachmann wird verstehen, daß der Prozeß für eine Vielzahl anderer privater Prozeßdefinitionen ähnlich wäre, so daß dann, wenn das Objekt einmal zu dem Standort 101, 102, 103 übertragen oder von diesem empfangen ist, die private Prozeßdefinition, welche dem dem Kommunikationsereignis folgenden Knoten entspricht, automatisch gestartet wird. Der private Prozeß 300 setzt sich bis zur Aktion 305 fort. Die Ausführung der Aktion 305 umfaßt das Absenden eines Informationsblocks, der dem empfangenen Kaufauftrag entspricht, an die Geschäftsanwendung 113. Nach der Beendigung der Aktion 305 fährt die Ausführung mit der Aktion 310 fort. Die Aktion 310 umfaßt das Abfragen einer Geschäftsanwendung 314, um zu bestimmen, ob der Gegenstand, der zu dem Kaufauftrag des Kommunikationsereignisses 230 gehört, vor Ort auf Lager ist oder ob er ausgelagert ist. Das Ergebnis dieser Abfrage wird in eine Variable gelegt, die mit "OUTSOURCED" (ausgelagert) bezeichnet ist und zu einer Gruppe von Variablen gehört, die zu dem privaten Prozeß 300 gehören. Die Aktion 315 wird nach der Aktion 310 ausgeführt. Die Aktion 315 umfaßt eine "WENN DANN SONST" Bedingung mit dem Wert von OUTSOURCED innerhalb einer Scriptaktion. Die Ergebnisse dieser Bedingung bestimmen, ob nach der Beendigung der Aktion 315 dem Weg A oder dem Weg B gefolgt wird. Die Ausführung des Wegs A führt zu einer Aktion 320, die den Aufbau eines Objekts des Typs "Bestätigung" sowie seine Bezeichnung als eine Ausgabe des privaten Prozesses umfaßt. Die Ausführung des Wegs B führte zur Aktion 325, die den Aufbau eines Objektstyps "Kaufauftrag" und seine Bezeichnung als eine Ausgabe des privaten Prozesses umfassen. Die Wege A und B enden bei der Aktion 330, die eine Benachrichtigung eines bestimmten Benutzers über E-Mail über bestimmte Statusinformation, die zu dem laufenden Prozeß gehört, umfaßt. Diese Information umfaßt die Identifikation von Eigenschaften des Kaufauftrags und Ergebnissen der Abfragen der Geschäftsanwendung. Nach der Ausführung der Aktion 330 endet der private Prozeß und die Steuerung geht zur öffentlichen Prozeßebene zurück. Die Verwendung solcher privaten Definitionen ist besonders vorteilhaft, weil sie eine einheitliche Kontrolle und Regelung der Prozesse zwischen den Standorten mit sich bringt und eine maximale Flexibilität bei der Verwendung privater Definitionen erlaubt, welche es der Steuerung eines bestimmten Standortes ermöglichen, die private Definition in bezug auf Parameter, Ressourcen und andere Beschränkungen für einen bestimmten Standort auf eine Vielzahl von Arten zu realisieren.
Jeder Standort der bevorzugten Ausführungsform umfaßt eine Kombination aus Komponenten, die die Gestaltung, Realisierung und Aufrechterhaltung öffentlicher und privater Prozesse und der Laufzeitkomponenten, welche die Ausführung dieser Prozesse unterstützen, unterstützen. Fig. 4 zeigt die bevorzugte Konfiguration eine beispielhaften Standortes 102.
Der Standardstandort 102 wird gebildet durch eine einzelnen Server 480 und einen oder mehrere Klienten 460, 470, die mit dem Server über ein Netzwerk 409 kommunizieren. Die Klienten 460 und 470 und der Server 480 laufen auf getrennten Hostrechnern. Die Klienten 460 und 470 enthalten graphische Benutzerschnittstellen (GUI) 465 bzw. 475. Zusätzlich hat der Server 480 Zugriff auf eine Datenbank 410 und Anwendungen 420 und 430. In der bevorzugten Ausführungsform liegt die Datenbank 410 auf einem Hauptrechner, der von dem Rechner, auf welchem der Server 430 liegt, getrennt ist. Die Klienten 460 und 470 und der Server 480 nutzen gemeinsame Darstellungen relevanter Information durch Interaktion über das Netzwerk 490 gemäß eines bestimmten und herkömmlichen Kommunikations- oder Datenaustauschprotokolls. Solche gemeinsam genutzten Informationsdarstellungen umfassen öffentliche und private Prozeßdefinitionen, Objektdefinitionen, Prozeßausführungsaufzeichnungen sowie Information über andere Standorte, mit denen der Standort interagiert. Menschliche Benutzer 440 und 450 interagieren mit dem Standort 102 über Klienten-GUI's 465 und 475, um die gemeinsam genutzten Informationsdarstellungen, die oben angegeben wurden, zu sehen, erzeugen, editieren und verwalten. Die Benutzer 440 und 450 können zum Beispiel graphische Darstellungen des öffentlichen Prozesses 200 und des privaten Prozesses 300 auf den GUI's 465 und 475 betrachten und editieren. Die Fig. 8 und 9 zeigen eine Bildschirmaufnahme der GUIs, welche den oben mit Bezug auf die Fig. 2 bzw. 3 beschriebenen öffentlichen und privaten Prozeßdefinitionen entsprechen.
Der Server 480 der bevorzugten Ausführungsform ist gebildet aus einer Verwaltungsgruppe mittleren Rangs 482, eine Ausführungsmaschine 484, eine Transportverwaltungseinheit 486 und Adaptern 488 und 489. Die Verwaltungsgruppe mittlerer Ordnung 482 steuert den Zugriff und den Ablauf von Information zwischen dem Netzwerk 409, der Maschine 484 und der Datenbank 410. Zusätzlich implementiert sie die zugehörige Anwendungslogik und stellt die Konsistenz der Information zwischen diesen Elementen sicher. In bezug auf das Netzwerk 409 vermittelt die Gruppe 482 den Zugriff auf Information von momentan arbeitenden Klienten und anderen Komponenten des Servers 480.
Wie unten im einzelnen erläutert, erfordert die Installation öffentlicher und privater Prozesse 200 und 300 die vorherige Zustimmung des Benutzers 440 oder 450. Wenn diese Zustimmung einmal empfangen ist, wird sie von dem entsprechenden Benutzer in den Klienten 410 oder 470 über die entsprechende GUI eingegeben. Ein lokales Installationsignal wird dann über das Netzwerk 409 an den Server 480 weitergeschaltet. Die Verwaltungsgruppe 482, die auf das empfangene Signal reagiert, löst die Installation der Prozeßdefinitionen in der Maschine 484 aus. Während der Installation transformiert die Ausführungsmaschine 484 die Prozeßdefinitionen, welche sie empfängt, in eine ausführbare Ablaufsteuerung, die in der Datenbank 410 gespeichert wird. Diese Transformation extrahiert aus der öffentlichen Prozeßdefinition alle Knoten, die mit Bögen verbunden sind, welche den Zielstandort betreffen. Die resultierende Ablaufsteuerung (Zustandsmaschine) enthält alle Information, die notwendig ist, damit ein einzelner Standort an der Ausführung des ursprünglichen öffentlichen Prozesses teilnehmen kann. Wenn die Installation beendet ist, liefert die Verwaltungsgruppe 482 der Maschine 484 alle zusätzliche Information, die in der Datenbank 410 gespeichert ist oder von den Klienten 460 und 470 empfangen wird und zum Durchführen der Prozeßausführung benötigt wird. Das Fortbestehen gemeinsam genutzter Daten wird durch die Kommunikation mit der Datenbank 410 erreicht.
Wenn die Installation der privaten und öffentlichen Prozeßdefinitionen 200 und 300 abgeschlossen ist, steuert die Maschine 484 ihre Ausführung. Während der Ausführung verwaltet die Ausführungsmaschine 484 zwei Schlüsselaktivitäten: eingehende und ausgehende Kommunikation mit anderen Standorten über die Transportverwaltungseinheit 486 und Interaktionen mit Anwendungen 420 und 430 über die Adapter 488 und 489. Die Maschine 484 verwaltet auch über die Verwaltungsgruppe 482 mehrere Hilfsaktivitäten, einschließlich dem Senden und Empfangen von Nachrichten zu und von den Benutzern 440 und 450 und die Speicherung von Log-Information in der Datenbank 410.
Während der Ausführung einer öffentlichen Prozeßdefinition, wie der Definition 200, verwaltet die Transportverwaltungseinheit 486 den Datenaustausch zu und von dem Internet 104. Die öffentliche Prozeßdefinition 200 nimmt zum Beispiel den Empfang des Kaufauftrags 230 und die Bestätigung 245 durch den Standort 102 vorweg sowie das Senden der Bestätigung 235 und des Kaufauftrags 240. In dieser Kapazität verwaltet die Verwaltungseinheit 486 vorzugsweise eine Logik für wiederholte Versuche und Bestätigung (gestützt auf die Eigenschaften des Dienstes, welchen sie verwendet). Nachrichten werden außerhalb bestimmter Transportdienste erzeugt, und die Übertragungssicherheit ist nachrichtengestützt. Ein Nicht- Verwerfungs-Empfang für Quelle und Transport wird unterstützt.
Während der Ausführung vermitteln die Adapter 488 und 489 den Datenstrom zwischen der Ausführungsmaschine 484 und den externen Anwendungen 420 und 430. Mit Bezug auf Schritt 315 der privaten Prozeßdefinition 300 kann die Maschine 484 zum Beispiel eine Anfrage über die Adapter 488 oder 489 übertragen, damit die Anwendung 420 oder 430 ermittelt, ob der fragliche Gegenstand nach außen gegeben wird. Die Anwendung reagiert ihrerseits über den entsprechenden Adapter. Optionen für die Konfiguration der Adapter 488 und 489 werden von den Autoren privater Prozesse für den zugehörigen Standort eingestellt. Diese Adapter 488 und 489 übertragen ihre annehmbaren Konfigurationsoptionen zur Zeit ihrer Installation an die Verwaltungsgruppe mittlerer Ordnung 482. Die Konfigurationsschnittstelle für die Adapter 488 und 489 erlaubt es einen privaten Prozeß, Daten in eine externe Anwendung einzufügen, Daten von einer externen Anwendung wiederzugewinnen oder auf ein von der externen Anwendung erzeugtes spezifisches Ereignis zu warten, wobei die eingefügten, wiedergewonnenen und erwarteten Daten durch eine Objektdefinition dargestellt werden. Die Adapter 488 und 489 sichern auch gleichmäßige Eigenschaften der Zustands/Konsistenzverwaltung und des Prüfverhaltens bei verschiedenen Anwendungen, welche in das System integriert werden. Während der Prozeßausführung bilden die Adapter 488 und 489 das Einfügen, Wiedergewinnen und Warten auf Aktionen, die in einem privaten Prozeß spezifiziert wurden, auf bestimmte Interaktionen mit den Zielanwendungen 420 und 430 ab.
Die Arbeit eines Standortes gemäß der bevorzugten Ausführungsform entwickelt sich um den Lebenszyklus einer öffentlichen Prozeßdefinition und den zugehörigen privaten Prozeß und die Objektdefinitionen. Wie in Fig. 5 gezeigt, beginnt dieser Zyklus mit der Erzeugung einer öffentlichen Prozeßdefinition und der in Bezug genommenen Objektdefinitionen, setzt sich dann mit der Verteilung der öffentlichen Prozeßdefinition und der Objektdefinitionen, der Erzeugung der notwendigen privaten Prozeßdefinitionen und der Installation des Prozesses fort und endet mit der Prozeßausführung.
In Schritt 502 erzeugt der Benutzer eine öffentliche Prozeßdefinition. Der Standort, bei dem die öffentliche Prozeßdefinition 200 erzeugt wird, wird als der Autorenstandort bezeichnet. Die Erzeugung der öffentlichen Prozeßdefinition 200 umfaßt die Erzeugung aller Prozeßdefinitionen, welche Nachrichten von Standort zu Standort in der öffentlichen Prozeßdefinition darstellen. Bei der bevorzugten Ausführungsform werden sowohl öffentliche Prozeß- als auch Objektdefinitionen von den Benutzern 440 und 450 erzeugt, die mit der Verwaltungsgruppe 482 über Klienten-GUIs 465 und 475 interagieren. Während der Erzeugung der öffentlichen Prozeßdefinition 200 spezifiziert der Benutzer 440 zum Beispiel die Folge der Interaktionen zwischen teilnehmenden Standorten 101, 102 und 103 und die Logik, welche diese Interaktionen verbindet. In diesem Beispiel würde die GUI 465 die Definition 200 als eine Gruppe von Piktogrammen darstellen, welche von Ablaufzeigern verbunden sind, die ähnlich wie das Diagramm in Fig. 2 in Erscheinung treten. Definitionen für den Kaufauftrag, Bestätigungs- und Zurückweisungsobjekte würden von dem Benutzer 440 ebenfalls über die GUI 465 erzeugt, wenn sie nicht bereits vorhanden sind.
Nachdem der öffentliche Prozeß und die notwendigen Objekte definiert sind, fährt der Benutzer mit der Verteilung des Prozesses fort. In Schritt 504 sendet der Autorenstandort über das Internet 104 die erzeugte öffentliche Prozeßdefinition und die in Bezug genommenen Objektdefinitionen an alle Standorte, die an dem öffentlichen Prozeß teilnehmen. Der Fachmann wird erkennen, daß das Internet 104 ein Intranet in einem lokalen Netz (LAN), ein Internet in einem Fernnetz (WAN) oder das Internet sein kann. In diesem Fall ist der Standort 102 der Autorenstandort, und die Standorte 101 und 103 sind die teilnehmenden Standorte. Damit der Standort 102 die öffentliche Prozeßdefinition 200 und die zugehörigen Objektdefinitionen über das Internet senden kann, werden die Definitionen von der Verwaltungsgruppe 482 an die Transportverwaltungseinheit 486 und von dort an die Transportverwaltungeinheiten der teilnehmenden Standorte gesendet. Bei Empfang der öffentlichen Prozeßdefinition 200 und er Objektdefinitionen durch die Transportverwaltungseinheiten der teilnehmenden Standorte, in diesem Fall die Standorte 101 und 103, werden die Definitionen von den Transportverwaltungseinheiten an die Verwaltungseinheiten mittlerer Ordnung weitergegeben, um diese in der Datenbank des Standorts dauerhaft zu speichern. Nach der Durchsicht der empfangenen öffentlichen Prozeßdefinition 200 und der Objektdefinitionen durch eine Klienten-GUI müssen die Benutzer an den teilnehmenden Standorten 101 und 103 die öffentliche Prozeßdefinition bestätigen oder ablehnen, wobei die Bestätigung oder Ablehnung über die Transportverwaltungseinheiten der Partnerstandorte an den Autorenstandort gesendet wird. Während die öffentliche Prozeßdefinition 200 an den teilnehmenden Standorten 101 und 103 durchgesehen wird, wartet der Autorenstandort 102 auf die Bestätigung oder Ablehnung, die von der Transportverwaltungseinheit 486 im Schritt 508 empfangen wird. Die Bestätigung oder Ablehnung durch die Standorte 101 und 103 bezieht sich wahrscheinlich mehr auf wirtschaftliche als technische Belange. Wenn ein Partnerstandort die wirtschaftlichen Vereinbarungen, die in der Definition 200 beschrieben sind, annehmbar findet, gibt er ein Bestätigungssignal an den Autorenstandort, in diesem Fall Standort 102. Im Schritt 508 überprüft das System die allgemeine Zustimmung, wenn einer der teilnehmenden Standorte 101 oder 103 den öffentlichen Prozeß 200 ablehnt, wird der Autorenstandort 102 eine Abbruchnachricht über die Transportverwaltungseinheit 486 an die Partnerstandorte 101 und 103 verteilen, wodurch Schritt 510 erreicht wird. In diesem Fall wird die öffentliche Prozeßdefinition 200 aufgegeben, und die Standorte 101, 102 und 103 können die Verhandlung einer neuen öffentlichen Prozeßdefinition beginnen. Wenn die öffentliche Prozeßdefinition im Schritt 508 allgemein angenommen wird, verteilt der Autorenstandort 102 eine Verpflichtungsnachricht an jeden der Partnerstandorte.
Nachdem die Verpflichtungsnachrichten durch den Autorenstandort übertragen und von den Teilnehmerstandorten empfangen wurden, schreiten der Autorenstandort und die teilnehmenden Standorten mit der Erzeugung der privaten Prozesse fort, die den öffentlichen Prozessen zugeordnet sind, welche zu jedem Standort gehören. Dies ist durch den Schritt 514 in Fig. 5 dargestellt. Jeder Standortbenutzer erzeugt eine private Prozeßdefinition für jeden Knoten der öffentlichen Prozeßdefinition, die dem Standort des Benutzers zugeordnet ist. Der Benutzer 440 erzeugt zum Beispiel eine private Prozeßdefinition 300 für den Knoten 210 und eine begleitende private Prozeßdefinition für den Knoten 220, da die Knoten 210 und 220 jeweils dem Standort 102 zugeordnet sind. Ähnlich würde ein Benutzer am Standort 101 eine private Prozeßdefinition für die Knoten 205 und 225 erzeugen, während ein Benutzer am Standort 103 eine Definition für den Knoten 215 erzeugen würde.
Nach der erfolgreichen Umsetzung der notwendigen privaten Prozeßdefinitionen sendet jeder teilnehmende Standort eine Nachricht an den Autorenstandort, die die Beendigung der privaten Prozeßumsetzung anzeigt. Im Schritt 516 sammelt der Autorenstandort die Signale bezüglich des Abschlusses der privaten Prozesse von allen Standorten. Wenn ein Standort nicht in der Lage ist, einen oder mehrere private Prozesse zu realisieren, sendet er eine Fehlernachricht an den Autorenstandort. In diesem Fall wird der Umsetzungsprozeß abgebrochen (Schritt 518), und die Prozeßdefinition 200 wird verworfen. Wenn der Autorenstandort von allen teilnehmenden Standorten Nachrichten empfangen hat, die erfolgreiche Umsetzung der privaten Prozesse anzeigen, und seine eigenen privaten Prozesse erfolgreich umgesetzt hat, kann der Autorenstandort mit dem Instalationsprozeß beginnen (Schritt 520).
Der Installationsprozeß (Schritt 520) beginnt damit, daß der Autorenstandort Installationsnachrichten an alle teilnehmenden Standorte sendet. Nach dem Empfang der Installationsnachricht installiert jeder teilnehmende Standort lokal den öffentlichen Prozeß. Fig. 6 zeigt ein Flußdiagramm eines Prozesses zum Installieren der privaten Prozeßdefinitionen, die zu einer öffentlichen Prozeßdefinition gehören, bei jedem einzelnen Standort. Im Schritt 602 werden die öffentliche Prozeßdefinition und die zugehörigen privaten Prozeßdefinitionen von der Verwaltungsgruppe 482 an die Ausführungsmaschine 484 weitergegeben. Im Schritt 604 wird die öffentliche Prozeßdefinition kompiliert, um eine Zustandsmaschine (Ablaufsteuerung) zu erzeugen, die Zustände nur von den in Rede stehenden Standorten enthält. Der Prozeß des Kompilierens der öffentlichen Prozeßdefinition 200 am Standort 102 führt zum Beispiel zu Zuständen in Zusammenhang mit den Knoten 210 und 220. In der Zustandsmaschine wird ein auslösendes Ereignis für jeden Zustand aufgezeichnet. In Fortführung des Beispiels der öffentlichen Prozeßdefinition 200 zeichnet der Standort 102 auf, daß das Ereignis 230, ein Kaufauftrag von dem Standort 101, den Zustand auslöst, der zu dem Knoten 210 gehört, und daß das Ereignis 245, eine Bestätigung von dem Standort 103, den Zustand auslöst, der zu dem Knoten 220 gehört. Im Schritt 606 wird jeder Zustand der Zustandsmaschine durch einen "Aufruf"-Befehl mit einer zugehörigen privaten Prozeßdefinition verbunden. Der Standort 102 verbindet zum Beispiel die private Prozeßdefinition 300 mit dem Zustand, der zu dem Knoten 210 gehört. Das Ergebnis dieser Verbindung ist, daß dann, wenn der zu dem Knoten 210 gehörende Zustand durch einen Kaufauftrag von dem Standort 101 ausgelöst wird, die private Prozeßdefinition 300 aufgehoben und ausgeführt wird. Im Schritt 608 wird ermittelt, ob der in Rede stehende Standort den öffentlichen Prozeß auslöst. Wenn nein, wie in Beispiel des Standorts 102, ermittelt die Ausführungsmaschine die auslösende Nachricht, die empfangen werden soll, und zeichnet sie in der Transportverwaltungseinheit auf. Bei dem Beispiel des Standorts 102 sind die zwei auslösenden Nachrichten der Kaufauftrag 230 von dem Standort 101 und die Bestätigung 245 von dem Standort 103. Wenn der Standort einen öffentlichen Prozeß auslöst, ist das auslösende Ereignis für den ersten privaten Prozeßstandort intern und wird im Schritt 612 als ein auslösendes Ereignis, ein geplanter Beginn oder ein auslösender Unterprozeß aufgezeichnet.
Nach der erfolgreichen Installation des öffentlichen Prozesses sendet jeder teilnehmende Standort eine Installationsbestätigungsnachricht an den Autorenstandort zurück. Im Schritt 522 erfaßt der Autorenstandort die Installationsbestätigungsnachrichten von allen teilnehmenden Standorten. Wenn irgendein Standort den öffentlichen Prozeß nicht installieren kann, wird der Prozeß abgebrochen 524, wie oben beschrieben. Die erfolgreiche Installation an dem Autorenstandort löste die Übertragung, von Nachrichten an alle Teilnehmer aus, wodurch angezeigt wird, daß der öffentliche Prozeß an allen betroffenen Standorten installiert wurde. An diesem Punkt ist der Prozeß bereit für die Ausführung (Schritt 526).
Wie oben erörtert wird die Ausführung eines öffentlichen Prozesses tatsächlich durch die interaktive Ausführung der zugehörigen privaten Prozesse bei den Partnerstandorten durchgeführt. Die Ausführung eines installierten öffentlichen Prozesses durch eine einzelnen Standort ist in Fig. 7 gezeigt. Die Ausführung beginnt im Schritt 702 mit einem auslösenden Ereignis, das folgendes umfassen kann: Empfang einer Nachricht von einem Partnerstandort, ein Ereignis, das zu einer Anwendung gehört, ein geplanter Beginn oder ein auslösender Unterprozeß. Der Knoten 210 der öffentlichen Prozeßdefinition 200 wird zum Beispiel durch den Empfang einer Kaufauftragsnachricht von dem Standort 101 aktiviert. Im Schritt 704 erzeugt die Ausführungsmaschine bei dem Standort eine Instanz in der geeigneten Zustandsmaschine und stellt die Maschine auf ihren Anfangszustand ein. Im Schritt 706 holt die Ausführungsmaschine den privaten Prozeß, der zu den zugeordneten Knoten des öffentlichen Prozesse gehört. Bei Aktivierung des Knotens 210 wird zum Beispiel auf die private Prozeßdefinition 300 zugegriffen. Im Schritt 708 gibt die Ausführungsmaschine geeignete Daten, einschließlich den Inhalt des Ereignisses 230, an den privaten Prozeß weiter und löst seine Ausführung aus. Im Schritt 710 wird der private Prozeß ausgeführt und gibt Daten an die Ausführungsmaschine zurück, und im Schritt 712 arbeitet die Ausführungsmaschine auf der Basis der zurückgegebenen Daten. Der private Prozeß 300 gibt zum Beispiel an die Ausführungsmaschine 484 entweder einen Befehl zum Senden einer Bestätigung an den Standort 101 oder einen Kaufauftrag an den Standort 103 zurück. Es sei bemerkt, daß während der Ausführung des privaten Prozesses im Schritt 710 die Maschine 484 die Anwendungen 420 und 430 verwendet. Die Ausführungsmaschine 484 reagiert entsprechend. Im Schritt 714 wird von der Ausführungsmaschine ermittelt, ob ein lokaler Endzustand der öffentlichen Prozeßdefinition erreicht ist. Diese Ermittlung ist lokal und auf die Teilnahme des Standorts in dem öffentlichen Prozeß begrenzt. Die Beendigung des Knotens 220 ist zum Beispiel ein lokaler Endzustand für den Standort 102, weil dies der Endknoten in dem Prozeß 200 ist, der dem Standort 102 entspricht. Abhängig vom Ergebnis des begleitenden privaten Prozesses kann ähnlich die Beendigung des Knotens 210 ein lokaler Endzustand für den Standort 102 sein. Wenn eine lokale Beendigung erfolgt, endet der öffentliche Prozeß für den Standort im Schritt 716. Der Schritt 716 ist nicht beendet, bis nicht ein zweiphasiges Verpflichtungsprotokoll zwischen den Standorten 101, 102 und 103 ausgeführt wurde, das eine gegenseitige Beendigung der Ausführung des Prozesses 200 sicherstellt.
Wenn in Schritt 714 kein lokaler Endzustand aufgefunden wird, wartet die Transportverwaltungseinheit auf eine auslösende Nachricht von den Partnerstandorten (Schritt 718). Wenn das Ergebnis des Knotens 210 zum Beispiel die Übertragung eines Kaufauftrags im Ereignis 240 ist, wartet die Transportverwaltungseinheit 486 auf die Bestätigung des Ereignisses 245, um eine privaten Prozeß im Zusammenhang mit dem Knoten 220 auszulösen. Wenn die auslösende Nachricht im Schritt 720 empfingen wurde, ssucht die Ausführungsmaschine den zugehörigen Prozeßzustand in Schritt 722. Der private Prozeß beginnt dann im Schritt 706 seine Ausführung und läuft wie oben beschrieben ab.

Claims

1. Verfahren zum Koordinieren des Prozesses zwischen einer ersten Stelle und einer zweiten Stelle in einem verteilten Informationssystem unter Verwendung einer öffentlichen Prozeßdefinition (116a), welche einen der ersten Stelle (101) zugeordneten ersten Knoten (205), einen der zweiten Stelle (102) zugeordneten zweiten Knoten (210) - und einen mit dem ersten und dem zweiten Knoten (205, 210) verbundenen Bogen umfaßt, mit folgenden Verfahrensschritten:

Ausführen des ersten Knotens (205) der öffentlichen Prozeßdefinition (116a) bei der ersten Stelle (101) durch Ausführen einer ersten privaten Prozeßdefinition (118a), die dem ersten Knoten (205) durch gemeinsam genutzte Information zugeordnet wird; und bei Empfang der durch den Bogen definierten Nachricht, Ausführen des zweiten Knotens (210) der öffentlichen Prozeßdefinition (116a) bei der zweiten Stelle (102) durch Ausführen einer zweiten privaten Prozeßdefinition (118b), die dem zweiten Knoten (210) durch gemeinsam genutzte Information zugeordnet wird.

2. Verfahren nach Anspruch 1, wobei der Bogen ein Geschäftsobjekt (120) ist.

3. Verfahren nach Anspruch 1 oder 2, mit den weiteren Verfahrensschritten:

Erzeugen (502) der öffentlichen Prozeßdefinition (116a) bei der ersten Stelle (101); Weitergeben (504) der öffentlichen Prozeßdefinition (116a) zu der zweiten Stelle (102);

wobei bei der ersten Stelle (101) dem ersten Knoten (205) durch gemeinsam genutzte Information eine erste private Prozeßdefinition (118a) zugeordnet wird, die eine Aktion umfaßt, welche der Übertragung der Nachricht von der ersten Stelle (105) vorhergeht; und

wobei bei der zweiten Stelle (102) dem zweiten Knoten (210) durch gemeinsam genutzte Information eine zweite private Prozeßdefinition (118b) zugeordnet wird, die eine Aktion umfaßt, die dem Empfang der Nachricht an der zweiten Stelle (102) folgt.

4. Verfahren nach Anspruch 3, wobei der Schritt des Verteilens (504) die folgenden weiteren Schritte umfaßt:

Durchsehen der öffentlichen Prozeßdefinition (116a) bei der zweiten Stelle (102); und wenn die öffentliche Prozeßdefinition (116a) bei der zweiten Stelle (102) bestätigt wird, Übertragen eines Bestätigungssignals von der zweiten Stelle (102) an die erste Stelle (101); und

wenn die öffentliche Prozeßdefinition (116a) bei der zweiten Stelle (102) nicht bestätigt wird, Übertragen eines Nicht-Bestätigungssignals von der zweiten Stelle (102) an die erste Stelle (101).

5. Verfahren nach Anspruch 3 oder 4, wobei der Schritt des Verteilens (504) die weiteren Schritte umfaßt:

wenn bei der ersten Stelle (101) ein Bestätigungssignal von der zweiten Stelle (102) empfangen wird, Übertragen einer Ausführungsnachricht an die zweite Stelle (102); Installieren der öffentlichen Prozeßdefinition (116a) und der ersten privaten Prozeßde-

finition (118a) bei der ersten Stelle (101); und

falls die Ausführungsnachricht von der ersten Stelle (101) bei der zweiten Stelle (102) empfangen wird, Installieren der öffentlichen Prozeßdefinition (116a) und der zweiten privaten Prozeßdefinition (118b) bei der zweiten Stelle (102).

6. Verfahren nach Anspruch 3, 4 oder 5, wobei der Schritt des Verteilens (504) die weiteren Schritte umfaßt:

falls bei der ersten Stelle (101) ein Nicht-Bestätigungssignal der zweiten Stelle (102) empfangen wird, Übertragen einer Abbruchnachricht an die zweite Stelle (102).

7. Verfahren nach einem der vorangehenden Ansprüche, bei dem

bei der ersten Stelle (101) die öffentliche Prozeßdefinition (116a) in eine erste Ablaufsteuerung transformiert wird und

beider zweiten Stelle (102) die öffentliche Prozeßdefinition (116a) in eine zweite Ablaufsteuerung transformiert wird.

8. Verfahren nach einem der vorangehenden Ansprüche, bei dem die Ausführung des ersten Knotens (205) der öffentlichen Prozeßdefinition (116a) in einer ersten Prozeßausführungsaufzeichnung aufgezeichnet wird;

die Ausführung des zweiten Knotens (210) der öffentlichen Prozeßdefinition (116a) in einer zweiten Prozeßausführungsaufzeichnung aufgezeichnet wird, die erste und die zweite Prozeßausführungsaufzeichnung geübt werden.

9. Verfahren zum Erzeugen einer Prozeßdefinition zur Kontrolle eines Prozesses zwischen einer ersten Stelle (101) und einer zweiten Stelle (102) in einem verteilten Informationssystem, mit folgenden Verfahrensschritten:

Erzeugen (502) einer öffentlichen Prozeßdefinition (116a) bei der ersten Stelle (101), mit einem der ersten Stelle (101) zugeordneten ersten Knoten (205), einem der zweiten Stelle (102) zugeordneten zweiten Knoten (201) und einem Bogen (120), der zwischen dem ersten Knoten und dem zweiten Knoten liegt;

Weitergeben (504) der öffentlichen Prozeßdefinition (116a) an die zweite Stelle (102); Erzeugen (514) einer ersten privaten Prozeßdefinition (118a) bei der ersten Stelle, die mittels gemeinsam genutzter Information dein ersten Knoten (205) zugeordnet wird, wobei eine der Übertragung dei Nachricht von der ersten Stelle (102) vorangehende Aktion definiert wird;

Erzeugen (514) einer zweiten privaten Prozeßdefinition (118) bei der zweiten Stelle, welche mittels gemeinsam genutzter Information dem zweiten Knoten (210) zugeordnet wird, wobei eine dem Empfang der Nachricht bei der zweiten Stelle (102) folgende Aktion definiert wird.

10. Verfahren nach Anspruch 9, bei dem

der erste Knoten (205) der öffentlichen Prozeßdefinition (116a) ausgeführt wird, indem die erste private Prozeßdefinition (118a) bei der ersten Stelle (102) ausgeführt wird; und

beim Empfang der Nachricht der zweite Knoten (210) der öffentlichen Prozeßdefinition (116a) ausgeführt wird, indem die zweite private Prozeßdefinition (118b) bei der zweiten Stelle (102) ausgeführt wird.