DE10247529A1 - Anpassbare Zustandsmaschine und Zustandsaggregationstechnik zur Verarbeitung von Zusammenarbeits- und Transaktionsgeschäftsobjekten - Google Patents

Abstract

Es wird eine computerimplementierte Zustandsmaschine zum Verarbeiten von Geschäftsobjekten, die Zusamamenarbeiten zwischen Geschäftsentitäten darstellen, zur Verfügung gestellt. Wenigstens ein Geschäftsobjekt stellt eine Zusammenarbeit zwischen Geschäftsentitäten dar. Eine Anzahl von Grafen, die in computerlesbaren Medien dargestellt sind, entsprechen jeweils einer besonderen Zusammenarbeitsgeschäftsentität. Die Grafen werden unter Verwendung von Textdateien erzeugt, wobei wenigstens eine erste Textdatei Zustandsinformation für das Geschäftsobjekt aufweist, wenigstens eine zweite Textdatei Aktionsinformation für das Geschäftsobjekt aufweist und wenigstens eine dritte Textdatei Übergangsinformation für das Geschäftsobjekt aufweist. Es wird ein computerimplementiertes Verfahren zum Aggregieren von Zustandsinformation, die einem Verbundgeschäftsobjekt zugeordnet ist, das wenigstens eine Zusammenarbeit zwischen Geschäftsentitäten darstellt, zur Verfügung gestellt. Das Verfahren weist das Auslesen der Zustandsinformationen für das Verbundgeschäftsobjekt aus einem computerlesbaren Medium und das Bestimmen eines Zustands für das Verbundgeschäftsobjekt anhand einer zugewiesenen Prioritätsebene für einen Zustand in einer Hierarchievon Zuständen, die dem Verbundgeschäftsobjekt zugeordnet sind, wobei jeder Zustand in der Hierarchie von Zuständen eine entsprechende zugewiesene Prioritätsebene besitzt, auf.

Description

• Die vorliegende Erfindung bezieht sich allgemein auf Zustandsmaschinen und auf den Entwurf von Zustandsmaschinen und insbesondere auf eine anpassbare Zustandsmaschine und auf eine Zustandsaggregationstechnik zur Verarbeitung von Zusammenarbeits- und Transaktionsgeschäftsobjekten.
• Die Verwendung objektorientierter Programmiersprachen wie etwa C++, Smalltalk, JAVA und Object-Pascal ermöglicht Systemkonstrukteuren und Programmierern, die Flexibilität des Entwurfs und die Leistung von Geschäftsanwendungen in elektronischen Handelsumgebungen wesentlich zu erhöhen. Objektorientierte Programmiersprachen ermöglichen, dass Programmierer den Datentyp einer Datenstruktur und die Typen von Operationen, die auf die Datenstruktur angewendet werden, definieren. Im Ergebnis wird die Datenstruktur zu einem "Objekt", d. h. zu einer selbständigen Entität, die sowohl Daten als auch die Prozeduren (z. B. Code) zum Manipulieren der Daten aufweist. Außerdem können Programmierer Beziehungen zwischen Objekten erzeugen. Beispielsweise kann ein Objekt erzeugt werden, das bestimmte Eigenschaften anderer Objekte erben kann. Somit besteht ein Hauptvorteil der objektorientierten Programmierung gegenüber vorausgehenden Programmiertechniken darin, dass Programmierer Software-Komponenten erzeugen können, die nicht geändert zu werden brauchen, wenn ein neuer Objekttyp eingeführt wird. Ein Programmierer kann ein neues Objekt erzeugen, das einige seiner Eigenschaften von den vorhandenen Objekten erbt. Da die objektorientierte Software verhältnismäßig leicht abzuändern ist, ist sie hinsichtlich des Entwurfs typischerweise wesentlich flexibler als Software, die gemäß vorausgehenden Programmiertechniken entwickelt worden ist. Außerdem können unter Verwendung objektorientierter Software Objektdatenbanken verwendet werden, die Objekte direkt speichern. Ein in einer Objektdatenbank gespeichertes Objekt kann ohne Verwendung von Verknüpfungsfeldern (wie etwa bei relationalen Datenbanken) auf ein anderes Objekt Bezug nehmen. Im Ergebnis sind Objektdatenbanken bei der Behandlung komplexer Objektbeziehungen mit komplexen Datentypen typischerweise wesentlich leistungsfähiger als relationale Datenbanken. Um objektorientierte Programmiertechniken zu nutzen, sind Hersteller relationaler Datenbanken im Begriff, relationale und Objekttechnologien zu kombinieren. Außerdem können unter Verwendung von Funktionsaufrufen, die durch objektorientierte Mechanismen angesteuert werden, Objekte in nicht objektorientierten Sprachen verwendet werden.
• Ein Geschäftsobjekt ist ein Objekt, das von einem Geschäftskonzept modelliert wird, wie etwa beispielsweise eine Geschäftsperson, ein Geschäftssitz, ein Geschäftsvorfall oder ein Geschäftsvorgang. Somit können Geschäftsobjekte, die tatsächliche Geschäftsentitäten darstellen, wie etwa Produkte, Aufträge, Rechnungen, Zahlungen, Kunden, Lieferanten, Angestellte usw., erzeugt werden. Geschäftsobjekte sind skalierbar und können in verschiedenen Konfigurationen und auf mehreren Ebenen eingesetzt werden. Durch Nutzung objektorientierter Technologien können Geschäftsobjekte zur Entwicklung und Anpassung von Geschäftsanwendungen verwendet werden.
• Auf einem elektronischen Marktplatz müssen Unternehmen (z. B. Geschäftsorganisationen) geregelt zusammenarbeiten, um ihre Operationen auszuführen. Beispielsweise können Unternehmen in Bezug auf die Beschaffung, den Entwurf, die Produktion und irgendwelche anderen geeigneten Aktivitäten zusammenarbeiten. Allerdings neigen bestimmte Geschäftsobjekte in einer Zusammenarbeitsanwendung dazu, sehr reaktionsfähig zu sein. Mit anderen Worten, ihre Semantik (die Bedeutung ihrer Anweisungen) kann sich anhand von Aktionen, die verschiedene Entitäten in dem Zusammenarbeitsanwendungsraum durchführen, von Grund auf ändern. Diesbezüglich ist es wesentlich, dass die Konstrukteure diese Geschäftsobjekte und ihr potenzielles Verhalten anhand von durchgeführten Aktionen genau modellieren. Die Entitäten (z. B. Geschäftsunternehmen) können an diesen Geschäftsobjekten in einem Zusammenarbeitsanwendungsraum eine Menge wohldefinierter Aktionen ausführen, die auf dem Verarbeitungsstadium des Objektes beruhen. Diese Geschäftsobjekte tragen eine Logik, die sich genau auf die besonderen betroffenen Geschäftsimplementierungen bezieht. Folglich muss eine solche Zusammenarbeitsanwendung, wenn sie eingesetzt wird, über ausreichende Flexibilität verfügen, um die Arbeitsabläufe und Semantiken für die betroffenen Geschäftsobjekte richtig zu definieren.
• Zustandsmaschinen können geeignete Mittel zur Verarbeitung von Geschäftsobjekten und der verschiedenen während der Lebensdauern der Objekte angetroffen Zustände sein. Allerdings können vorhandene Zugänge zum Entwurf von Zustandsmaschinen keine komplexen Arbeitsabläufe und Probleme, die in einer Zusammenarbeitsumgebung angetroffen werden, wirksam berücksichtigen. Im Ergebnis gibt es einen dringenden Bedarf an einem Entwurfszugang, der den Zustandsmaschinenentwurf für eine Zusammenarbeitsgeschäftsumgebung hinsichtlich Flexibilität, Anpassung und Einsatz vereinfachen und außerdem einen hohen Leistungspegel für die betroffenen Geschäftsanwendungen realisieren kann.
• Gemäß der vorliegenden Erfindung können die Probleme und Nachteile im Zusammenhang mit Zustandsmaschinen und Zustandsmaschinen-Entwurfstechniken des Standes der Technik verringert oder beseitigt werden.
• In Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung wird eine computerimplementierte Zustandsmaschine zur Verarbeitung von Geschäftsobjekten geschaffen, die Zusammenarbeiten zwischen Geschäftsentitäten darstellen. Wenigstens ein Geschäftsobjekt stellt eine Zusammenarbeit zwischen Geschäftsentitäten dar. Eine Anzahl von Grafen, die in computerlesbaren Medien dargestellt sind, entsprechen jeweils einer besonderen Zusammenarbeitsgeschäftsentität. Die Grafen werden unter Verwendung von Textdateien erzeugt, wobei wenigstens eine erste Textdatei Zustandsinformationen für das Geschäftsobjekt, wenigstens eine zweite Textdatei Aktionsinformationen für das Geschäftsobjekt und wenigstens eine dritte Textdatei Übergangsinformationen für das Geschäftsobjekt aufweist.
• In Übereinstimmung mit einer weiteren beispielhaften Ausführungsform der vorliegenden Erfindung wird ein computerimplementiertes Verfahren zur Aggregation von Zustandsinformationen im Zusammenhang mit einem Verbundgeschäftsobjekt geschaffen, das wenigstens eine Zusammenarbeit zwischen Geschäftsobjekten darstellt. Das Verfahren aufweist das Auslesen der Zustandsinformationen für das Verbundgeschäftsobjekt aus einem computerlesbaren Medium und das Bestimmen eines Zustands für das Verbundgeschäftsobjekt anhand einer zugewiesenen Prioritätsebene für einen Zustand in einer Hierarchie von mit dem Verbundgeschäftsobjekt verknüpften Zuständen, wobei jeder Zustand in der Hierarchie der Zustände eine entsprechende zugewiesene Prioritätsebene besitzt.
• In Zusammenarbeitsanwendungen müssen möglicherweise bestimmte hierarchische und Verbundgeschäftsobjekte Zustandsinformationen tragen. Außerdem müssen möglicherweise die Komponenten und Kinder dieser Geschäftsobjekte Zustandsinformationen tragen. In vielen Fällen kann ein Verbundgeschäftsobjekt einen abgeleiteten Zustand erfordern, der auf den Einzelzuständen der Komponenten des Verbundgeschäftsobjekts beruht. Somit wird in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung ein Zustandsaggregationsverfahren geschaffen, wobei ein Verbundgeschäftsobjekt einen abgeleiteten Zustand aufweist kann, der aus den Einzelzuständen der Komponenten des Geschäftsobjekts berechnet wird. Im Ergebnis kann das Zustandsaggregationsverfahren einen Mechanismus für die Ausbreitung von Zustandsinformationen in einem hierarchischen (z. B. mehrstufigen) Geschäftsobjekt schaffen.
• Bestimmte Ausführungsformen der vorliegenden Erfindung können einen oder mehrere technische Vorteile schaffen. Beispielsweise können besondere Ausführungsformen eine leistungsfähige anpassbare Zustandsmaschine zur Behandlung von Zusammenarbeits- und Transaktionsgeschäftsobjekten in einer elektronischen Marktplatzumgebung schaffen. Bestimmte Ausführungsformen können eine anpassbare Zustandsmaschine zur Verwendung bei der Behandlung von Zusammenarbeits- und Transaktionsgeschäftsobjekten schaffen, die für die betroffenen Geschäftsobjekte als Richtlinienmechanismus dienen kann. Eine Zulässigkeitssicherheitskomponente der Zusammenarbeitszustandsmaschine kann ermöglichen, dass verschiedene Entitäten in einem Unternehmen verschiedene Ansichten über die gleiche Zustandsmaschine haben. Außerdem schafft die Zusammenarbeitszustandsmaschine eine Fähigkeit, verschiedene Entitäten in verschiedenen Unternehmen in gewissem Umfang zu beschränken, so dass die verschiedenen Entitäten ähnliche oder verwandte Funktionen ausführen können. Besondere Ausführungsformen können eine ausreichende Flexibilität schaffen, damit Implementierer der Zusammenarbeitsanwendung die Arbeitsabläufe und Semantiken für die betroffenen Geschäftsobjekte richtig definieren können. Besondere Ausführungsformen können auch komplexe Arbeitsabläufe und Probleme, die in einer Zusammenarbeitsumgebung angetroffen werden, richtig berücksichtigen, und etwa beispielsweise Mitarbeitersysteme mit Drittunternehmens- Betriebsmittelplanungssystemen (Dritt-ERP-Systemen, engl. Enterprise Resource Planning) oder anderen Registriersystemen (SORs, engl. System of Records) richtig integrieren, die Gleichzeitigkeit optimieren, anwenderdefinierte Semantiken für Zustände und Übergänge schaffen, eine geeignete Sicherheit auf der Zustands- und auf der Aktionsebene schaffen, eine Fähigkeit zum leichten Ändern der Zustandsmaschine schaffen, so dass sie den Anforderungen spezifischer Entitäten genügt, und im Zusammenhang mit Zustandsänderungen Benachrichtigungsmeldungen senden. Besondere Ausführungsformen können einen hinsichtlich Flexibilität, Anpassung und Einsatz vereinfachten Zustandsmaschinenentwurf für eine Zusammenarbeitsgeschäftsumgebung erzeugen, der außerdem einen hohen Leistungspegel für die betroffenen Geschäftsanwendungen realisieren kann. Außerdem können besondere Ausführungsformen eine Zustandsaggregation als einen leistungsfähigen Mechanismus zur Ausbreitung von Zustandsinformationen in hierarchischen oder mehrstufigen Geschäftsobjekten schaffen.
• Systeme und Verfahren, die einen oder mehrere dieser oder anderer technischer Vorteile aufweist, können für moderne elektronische Handelsumgebungen gut geeignet sein. Einer oder mehrere weitere technische Vorteile der vorliegenden Erfindung können für einen Fachmann auf dem Gebiet aus den Figuren, der Beschreibung und den aufgeführten Ansprüchen leicht hervorgehen.
• Für ein vollständigeres Verständnis der vorliegenden Erfindung und ihrer Vorteile wird nun auf die folgende Beschreibung Bezug genommen, die in Verbindung mit der beigefügten Zeichnung zu nehmen ist, in der:
• Fig. 1 ein beispielhaftes System zeigt, das in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zur Implementierung einer anpassbaren Zustandsmaschine für die Verarbeitung von Zusammenarbeits- und Transaktionsgeschäftsobjekten in einer elektronischen Marktplatzumgebung verwendet werden kann;
• Fig. 2 ein Diagramm ist, das bestimmte Wechselwirkungen zeigt, die in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zwischen Entitäten in einer Zusammenarbeitsanwendung auftreten können, und das zeigt, wie die Zusammenarbeitszustandsmaschine eine verteilte Synchronisation von Zusammenarbeitsgeschäftsobjekten ermöglichen kann; und
• Fig. 3 ein Diagramm ist, das Programm-Pseudocode in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zur Verwendung eines beispielhaften Zustandsaggregierers zeigt.
• Bevorzugte Ausführungsformen der vorliegenden Erfindung und ihre Vorteile werden am besten verständlich anhand der Fig. 1-3 der Zeichnung, wobei für gleiche und einander entsprechende Teile der verschiedenen Figuren gleiche Bezugszeichen verwendet werden.
• Fig. 1 zeigt ein beispielhaftes System 10, das in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung zur Implementierung einer anpassbaren Zustandsmaschine für die Verarbeitung von Zusammenarbeits- und Transaktionsgeschäftsobjekten in einer elektronischen Marktplatzumgebung verwendet werden kann. Das System 10 kann Käufer 12, Lieferanten 14 und einen Geschäfts- Geschäfts- (B2B-, engl. Business-to-Business), einen Geschäfts-Verbraucher- (B2C-, engl. Business-to-Customer) oder einen anderen elektronischen Marktplatz 16 aufweist, der Käufer 12 mit Lieferanten n 14 verknüpfen kann. Dem elektronischen Marktplatz 16 können eine oder mehrere Websites zugeordnet sein, auf die die Käufer 12 und die Lieferanten 14 zugreifen können. Im Allgemeinen können die Lieferanten 14 Produkte oder andere Gegenstände herstellen, die für die Käufer 12 verfügbar sind, wobei sie mit den Käufern 12 auf die eine oder andere Art zusammenarbeiten können, um geeignete Käufer-Lieferanten-Beziehungen herzustellen und zu unterhalten. Je nach dem Wesen des elektronischen Marktplatzes 16 und dem Markt, den er unterstützt, können die Lieferanten 14 Hersteller, Vertriebshändler, Großhändler, Einzelhändler oder irgendwelche anderen Entitäten aufweisen, die unter Verwendung des elektronischen Marktplatzes 16 Gegenstände an die Käufer 12 liefern und mit ihnen zusammenarbeiten können. Vorzugsweise kann eine dem elektronischen Marktplatz 16 zugeordnete (nicht gezeigte) Datenbank Zusammenarbeitsdaten speichern, die durch die Käufer 12 und durch die Lieferanten 14 anhand ihrer Zusammenarbeiten, Ausführungen und irgendwelcher weiteren geeigneten Wechselwirkungen zwischen den Käufern 12 und den Lieferanten n 14 über den elektronischen Marktplatz 16 an den elektronischen Marktplatz 16 geliefert werden.
• Die Käufer 12, die Lieferanten 14 und der elektronische Marktplatz 16 können jeweils auf einem oder auf mehreren Computersystemen an einem oder an mehreren Orten arbeiten und die Datenspeicherung, die Kommunikation oder andere Betriebsmittel gemäß besonderen Anforderungen gemeinsam nutzen. Diese Computersysteme können geeignete Eingabevorrichtungen, Ausgabevorrichtungen, Massenspeichermedien, Prozessoren, Speicher oder andere Komponenten aufweist, um in Übereinstimmung mit dem Betrieb des Systems 10 Informationen zu empfangen, zu verarbeiten, zu speichern und zu übermitteln. Die hier erwähnten Computersysteme können jeweils einen oder mehrere Einzelcomputer an einem oder an mehreren geeigneten Orten aufweist. Die Käufer 12 und die Lieferanten 14 können selbstständig oder in Übereinstimmung mit einer Eingabe von einem oder von mehreren Anwendern mit dem elektronischen Marktplatz 16 in Wechselwirkung treten. Die Käufer 12 und die Lieferanten 14 können mit einem oder mit mehreren lokalen Netzen (LANs, engl. Local Area Networks), innerstädtischen Netzen (MANs, engl. Metropolitan Area Networks), Weitverkehrsnetzen (WANs, engl. Wide Area Networks), einem globalen Computernetz wie etwa dem Internet oder irgendeiner anderen geeigneten Draht-, optischen, drahtlosen oder anderen Verbindung mit dem elektronischen Marktplatz 16 verbunden sein. Die Käufer 12, die Lieferanten 14 und der elektronische Marktplatz 16 können gemäß einer Speichenarchitektur, einer Peer-to-Peer-Architektur oder einer anderen geeigneten Architektur miteinander kommunizieren. Beispielsweise kann das System 10 unter Verwendung einer Speichenarchitektur implementiert sein, in der die Speichen geeignet mit den Unternehmenssystemen der Käufer 12 und der Lieferanten 14 integriert sind, um zwischen diesen Unternehmenssystemen und dem elektronischen Marktplatz 16 eine plangestützte Datenübertragung zu ermöglichen. In einer besonderen Ausführungsform können die Käufer 12 und die Lieferanten 14 mit dem elektronischen Marktplatz 16wenigstens teilweise in Form der Hypertext Markup Language (HTML), der Extensible Markup Language (XML) oder anderer Dateien, die in Nachrichten gemäß dem Hypertext Transfer Protocol (HTTP) aufweist sind, kommunizieren.
• In Übereinstimmung mit der vorliegenden Erfindung wird im Wesentlichen eine (im Folgenden als "Zusammenarbeitszustandsmaschine" bezeichnete) anpassbare Zustandsmaschine zur Verwendung bei der Behandlung oder Verarbeitung von Zusammenarbeits- und Transaktionsgeschäftsobjekten geschaffen, die als Richtlinienmechanismus für die betroffenen Geschäftsobjekte dienen kann. Eine Zulässigkeits/Sicherheits-Komponente der Zusammenarbeitszustandsmaschine kann ermöglichen, dass verschiedene Entitäten in einem Unternehmen verschiedene Ansichten der gleichen Zustandsmaschine haben. Außerdem kann die Zusammenarbeitszustandsmaschine eine Fähigkeit schaffen, verschiedene Entitäten in verschiedenen Unternehmen in gewissem Umfang zu beschränken, so dass die verschiedenen Entitäten ähnliche oder verwandte Funktionen ausführen können. Falls eine Entität beispielsweise gerade eine Auftragsmanagementfunktion ausführt, können einige Anwender dieser Entität Änderungsbestellungen verarbeiten, während andere Anwender Bestellungsstornierungen verarbeiten können.
• Möglicherweise müssen bestimmte hierarchische und Verbundgeschäftsobjekte in Zusammenarbeitsanwendungen auch Zustandsinformationen tragen. Möglicherweise müssen auch die Komponenten und Kinder (unmittelbaren Nachkommen) solcher Geschäftsobjekte Zustandsinformationen tragen. In vielen Fällen kann ein Verbundgeschäftsobjekt einen abgeleiteten Zustand erfordern, der auf den Einzelzuständen der Komponenten des Verbundgeschäftsobjekts beruht. Somit wird in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung eine Zustandsaggregationstechnik geschaffen, durch die ein Verbundgeschäftsobjekt einen abgeleiteten Zustand aufweist kann, der aus den Einzelzuständen der Komponenten des Geschäftsobjekts berechnet wird. Im Ergebnis kann das Zustandsaggregationsverfahren einen Mechanismus schaffen, mit dem sich Zustandsinformationen in einem hierarchischen (z. B. mehrstufigen) Geschäftsobjekt ausbreiten können.
• In Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung wird eine Zusammenarbeitszustandsmaschine geschaffen, die erfolgreich reaktionsfähige Geschäftsobjekte verarbeiten und ihre Modellierungsanforderungen behandeln kann. Im Ergebnis können die Geschäftsobjekte in ihren jeweiligen Lebensdauern eine Menge von Zuständen durchlaufen, wobei jedes der Geschäftsobjekte eine besondere Semantik für die betroffenen Entitäten aufrechterhalten kann. Beispielsweise kann die Zusammenarbeitszustandsmaschine unter der Annahme, dass eine Menge von Zuständen und Richtlinien den Anforderungen jeder Kombination von Entitäten, die an einer Zusammenarbeitsanwendung beteiligt sind, nicht genügen kann, ermöglichen, dass jede Gruppe von Zusammenarbeitsentitäten ihre eigenen Richtlinien für die Zusammenarbeitslebensdauer der betroffenen Geschäftsobjekte festlegt. Somit ist die Zusammenarbeitszustandsmaschine hochgradig konfigurierbar und einsetzbar.
• In Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung kann die Zusammenarbeitszustandsmaschine durch eine Menge von Adjazenzgrafen dargestellt werden, wobei es für jede Entität in dem Zusammenarbeitsanwendungsraum einen solchen Grafen gibt. Wo dies geeignet ist, kann ein Adjazenzgraf als Zustandsübergangsgraf bezeichnet werden. Die Knoten in einem solchen Grafen können Zustände darstellen, während die Verknüpfungen in einem solchen Grafen Aktionen darstellen können. Vorzugsweise kann eine Menge von Zuständen für sämtliche betroffenen Grafen konstant sein. Wie unten ausführlich beschrieben wird, kann die Zusammenarbeitszustandsmaschine Probleme, die mit verschiedenen Techniken auftreten, richtig behandeln, wie etwa Mitarbeitersysteme richtig mit Dritt-ERP-Systemen oder anderen SORs integrieren, die Gleichzeitigkeit optimieren, eine anwenderdefinierte Semantik für Zustände und Übergänge schaffen, eine geeignete Sicherheit auf der Zustands- und auf der Aktionsebene schaffen, eine Fähigkeit schaffen, die Zustandsmaschine leicht zu ändern, so dass sie den Anforderungen spezifischer Entitäten genügt, und Benachrichtigungsmeldungen im Zusammenhang mit Zustandsübergängen senden. Benachrichtigungsmeldungen, die ausgesendet werden, wenn bestimmte Zustandsübergänge auftreten, können in verschiedenen Formen wie etwa unter Verwendung von E-Mails, Faxen oder Ereignisprotokollen transportiert werden. Außerdem kann die Zusammenarbeitszustandsmaschine als Richtlinienmechanismus dienen, der die Lebensdauer und Nebenwirkungen für das betroffene Geschäftsobjekt oder für die betroffenen Geschäftsobjekte vorschreibt.
• Genauer kann die Zusammenarbeitszustandsmaschine die Lebensdauern der betroffenen Geschäftsobjekte steuern und ausführen. Somit kann ein dem elektronischen Marktplatz 16 zugeordneter (nicht gezeigter) Prozessor die Zusammenarbeitszustandsmaschine für den Betrieb in den Speicher laden, wenn eine Geschäftsanwendung (z. B. eine Software- Anwendung) begonnen wird. Außerdem kann der Prozessor wie unten beschrieben dazu verwendet werden, die Zusammenarbeitszustandsmaschine zu implementieren, die prozessstrangsicher und hochgradig skalierbar ist. Somit kann die Zusammenarbeitszustandsmaschine Datenstrukturen aufweist, die Informationen über Zustände, Aktionen, Übergänge und Aktualisierungsrichtlinien aufweist. Außerdem kann die Zusammenarbeitszustandsmaschine leichte "Wrapper" aufweist, die über den Datenstrukturen liegen und Sicherheitsprüfungen und Hochleistungsschnittstellen für das Zugreifen auf Informationen in den Datenstrukturen schaffen. Außerdem kann die Zusammenarbeitszustandsmaschine Zustandsbehandler aufweist, die Aktualisierungsrichtlinien behandeln und Richtlinienmechanismen implementieren und außerdem geeignete Schnittstellen mit anderen Komponenten in irgendeinem betroffenen System schaffen.
• Wie zuvor erwähnt wurde, kann die Zusammenarbeitszustandsmaschine eine Menge von Grafen aufweist, die im Speicher gespeichert oder auf andere Weise dargestellt sein können, wobei jeder Graf einer besonderen Zusammenarbeitsgeschäftsentität entspricht. Beispielsweise kann ein Graf als Zusammenstellung von Punkten definiert sein, wobei einige Paare von Punkten durch Linien verbunden sind. Die Punkte können als Knoten bezeichnet werden, und die Linien können als Kanten bezeichnet werden. Somit ist eine Adjazenzmatrix eine geeignete Speicherstruktur, die zum Speichern solcher Grafen verwendet werden kann. Beispielsweise kann eine Adjazenzmatrix als eine quadratische Matrix von Nullen und Einsen definiert sein, deren Zeilen und Spalten durch die Knoten indiziert sind. Eine "1" an der Stelle ij der Matrix kann bedeuten, dass es eine Kante vom Knoten i zum Knoten j gibt. Eine "0" an der Stelle ij der Matrix kann angeben, dass es keine solche Kante gibt. Wo dies geeignet ist, kann eine Adjazenzmatrix als Zustandsübergangsmatrix bezeichnet werden.
• Für eine beispielhafte Ausführungsform der vorliegenden Erfindung kann eine Zusammenarbeitszustandsmaschine eine Anzahl von Grafen aufweist, die jeweils einer besonderen Zusammenarbeitsgeschäftsentität entsprechen. Die Grafen können in einer dreidimensionalen Adjazenzmatrix für die Zustandsmaschine gespeichert sein. Beispielsweise kann für eine Zusammenarbeitsanwendung eine Dimension der Matrix einen Zustandsidentifizierer (einen Zustands-ID), eine zweite Dimension der Matrix einen Aktions-ID und eine dritte Dimension der Matrix einen Entitäts-ID darstellen. Unter Verwendung geeigneter Adjazenzmatrix-Berechnungstechniken können in der dreidimensionalen Adjazenzmatrix für die Zustandsmaschine gespeicherte Informationen die resultierenden Zustandswerte darstellen.
• Beispielsweise können Zustandsinformationen in Tabellen oder anderen Textdateien gespeichert sein, die sich im Speicher an Plätzen befinden, welche durch die Anwendernamen und IDs der Zustände indiziert (z. B. adressiert) werden. Ähnlich können Aktionsinformationen in Tabellen oder anderen Textdateien gespeichert sein, die sich im Speicher an Plätzen befinden, die durch die Anwendernamen und IDs der Aktionen indiziert werden. Im Ergebnis können die Clients oder Anwender fordern, dass die Zusammenarbeitszustandsmaschine aktuelle Informationen in Bezug auf Zustände, Aktionen und irgendeinen aus einer Matrixberechnung (z. B. aus einer Adjazenzmatrixberechnung) abgeleiteten resultierenden Zustand liefert, die in einer oder in mehreren dieser Tabellen gespeichert sind. Außerdem kann die Zusammenarbeitszustandsmaschine eine Berechtigungs- oder Sicherheitsprüfung ausführen, wodurch die Zusammenarbeitszustandsmaschine den Berechtigungs- oder Sicherheitsebenenkontext für einen Anwender bestimmen und die Authentizitäts- und Berechtigungsmasken (z. B. Informationen, die ebenfalls in dem dem elektronischen Marktplatz 16 zugeordneten Speicher gespeichert sind) in Bezug auf die vom Anwender angeforderten Zustands- und Aktionsinformationen verifizieren kann. Außerdem können sämtliche Aktionsbeschreibungen (z. B. Richtlinien, die darauf beruhen, welche Aktualisierungen bei Übergängen stattfinden) als Teil eines Aktionsobjekts im Speicher gespeichert sein. Vorteilhaft unterstützt die obenbeschriebene verhältnismäßig "leichte" Speicherstruktur in Bezug auf die vorliegende Erfindung einen verhältnismäßig hohen Grad an Skalierbarkeit.
• Für eine beispielhafte Ausführungsform der vorliegenden Erfindung kann jeder Zustand einen oder mehrere Unterzustände (z. B. vorzugsweise mit einer Verschachtelungsebene) besitzen. Die Unterzustände können die Übergänge ihrer jeweiligen Überzustände erben. Ähnlich wie die Zustände können auch die Unterzustände aus der Perspektive einer Geschäftslogik modelliert werden. Beispielsweise kann eine Bestellung für ein Produkt "in der Warteschleife" angeordnet werden. Von einem Standpunkt der Geschäftslogik aus bedeutet, dass eine Bestellung "in der Warteschleife" angeordnet wird, nicht notwendig, dass sich der Bestellungszustand vollständig geändert hat. Die Bestellung kann vorübergehend "in einer Warteschleife" angeordnet werden, bis eine Aktion unternommen wird, in der die "Warteschleife" freigegeben wird. In diesem Fall kann die "Warteschleife" als Unterzustand modelliert werden.
• In Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung kann eine Zusammenarbeitszustandsmaschine als Richtlinienmechanismus für die Semantik des Geschäftsobjekts über ihre jeweiligen Lebensdauern modelliert werden. Beispielsweise kann die Zusammenarbeitszustandsmaschine (im Speicher) für jede für das betroffene System definierte Aktion eine Aktionsbeschreibung unterhalten.
• Diesbezüglich kann eine Aktionsbeschreibung als Objekt, d. h. als Richtlinien-Container, modelliert sein. Die Zusammenarbeitszustandsmaschine kann so konstruiert werden, dass sie eine feste Richtlinienmenge "versteht". Somit kann ein Systemkonstrukteur, Programmierer oder anderer Implementierer die Aktionsaktualisierungsrichtlinien als Untermenge der festen Richtlinienmenge konfigurieren. Beispielsweise kann eine Aktion "CUSTOMER_CANCEL", die von einem Entitätstyp "CUSTOMER" unternommen wird, mit den folgenden Aktionsaktualisierungsrichtlinien verknüpft sein: "UPDATE_STATE|SUPPLIER_SYNC_DOWN|DEBIT_CREDIT_CARD". Für dieses Kreditkartenbeispiel bedeuten die obenbeschriebenen Richtlinien, dass das System, wenn ein Kunde eine Aktion "CUSTOMER_CANCEL" ausführt, um eine Kreditkartenbelastung zu stornieren, den Ausgangszustand der Transaktion auf den neuen Zustand aktualisieren ("UPDATE_STATE") und einen zugeordneten Merker "SUPPLIER_SYNC" tief setzen kann. Daraufhin wird die Kreditkartenbelastung erstattet.
• Aktionsbeschreibungen können für die Zusammenarbeitszustandsmaschine als "Befehle" zum Ausführen einer besonderen Operation oder einer Menge von Operationen verwendet werden. Beispielsweise können solche Operationen die Aktualisierung von Datenbankinformationen für bestimmte Geschäftsobjekte, das Einsetzen oder Löschen bestimmter Geschäftsobjekte und/oder das Aufrufen anderer Modelle (z. B. eines Modells zum Ausführen einer Blankoauftrags-Netzanwendung) aufweisen.
• Zustandsbehandler sind Klassen (ein Objekt ist über seine Klassen definiert), die aus einem gegebenen Zustand die Logik für alle Übergänge liefern können. Zustandsbehandler können steuern, "was getan werden muss", wenn sich der Zustand eines Geschäftsobjekts ändert. Die Zusammenarbeitszustandsmaschine ermöglicht, dass Implementierer ihre eigenen Zustandsbehandler schreiben, die in die Zusammenarbeitszustandsmaschine eingeschoben werden können. Diesbezüglich kann ein Standardzustandsbehandler aufweist sein, der sämtliche Aktualisierungsrichtlinien (z. B. die zuvor beschriebenen) behandelt. Allerdings können einzelne Zustandsbehandler geschrieben werden, die den Anforderungen spezifischer Anwendungen genügen, falls das Standardverhalten solcher Anwendungen ungeeignet ist und der Standardzustandsbehandler überschrieben werden soll.
• In Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung kann die Zusammenarbeitszustandsmaschine den verschiedenen Zustandsübergängen, die in einer Geschäftsanwendung auftreten können, verschiedene Typen von Benachrichtigungen zuordnen. Diese Benachrichtigungsfunktion ermöglicht, dass sich Anwender für spezifische Zustandsübergänge, die in einem System auftreten können, anmelden. Der Inhalt einer Benachrichtigungsmeldung kann auf der Zustandsübergangsebene konfiguriert werden. Für jeden auftretenden Zustandsübergang kann der Inhalt einer zugeordneten auszusendenden Benachrichtigungsmeldung konfiguriert werden, wobei irgendwelche in einem Geschäftsobjekt aufweisenden Informationen in den Inhalt der Nachricht aufgenommen werden können.
• Benachrichtigungsmeldungen können außerdem für Zustandsänderungen ausgesendet werden, die wie etwa im Fall hierarchischer Objekte (z. B. in Verbindung mit den wie unten beschriebenen Zustandsaggregierern) auf höheren Ebenen auftreten. Dieses Benachrichtigungssystem schafft eine hohe Ebene der Anpassung, indem es die Anwender befähigt, sich wahlweise für verschiedene Ereignisse anzumelden, die in Bezug auf ein gegebenes Geschäftsobjekt auftreten können. Im Ergebnis können die Anwender bestimmte externe Entitäten aufrufen lassen, falls ein bestimmter Zustandsübergang auftritt.
• Im Betrieb kann ein (z. B. dem elektronischen Marktplatz 16 zugeordneter) Prozessor die Zusammenarbeitszustandsmaschinen-Informationen aus einem Dateisystem lesen und in den Arbeitsspeicher laden. Alternativ kann die Zusammenarbeitszustandsmaschine auf der Basis von Konstruktionsvorzügen in einer Datenbank gespeichert sein. Für eine beispielhafte Ausführungsform kann der Prozessor die Zusammenarbeitszustandsmaschine unter Verwendung von Tabellen oder anderen Textdateien konstruieren, die im Speicher oder in einer Datenbank gespeichert sind, so dass sie eine Anzahl von Grafen aufweist, die in einer dreidimensionalen oder anderen geeigneten Adjazenzmatrix für die Zustandsmaschine gespeichert sind, wobei jeder Graf einer besonderen Zusammenarbeitsentität entspricht. Ein Anwender kann diese Tabellen zur Implementierungszeit konfigurieren, so dass sie sich für das besondere Geschäftsszenarium eignen. Die Anpassung der Zusammenarbeitszustandsmaschine kann das Ändern der Anwendernamen der Zustände, das Ändern der Aktionsbeschreibungen und das Hinzufügen neuer Zustände und Aktionen und ihrer zugeordneten Übergänge aufweisen.
• Ein (z. B. dem elektronischen Marktplatz 16 zugeordneter) Anwendungs-Server kann für sämtliche Bezugnahmen auf Zustände und Aktionen intern Systemnamen als Primärschlüssel verwenden. Für eine beispielhafte Ausführungsform kann die Zusammenarbeitszustandsmaschine eine Abbildung zwischen Systemnamen und Anwendernamen ausführen, so dass die Anwendernamen zu irgendeinem Zeitpunkt geändert werden können, falls die betroffene Geschäftslogik dies fordert. Die Zustände und Aktionen können einen zugeordneten Anwendernamen besitzen, der angepasst werden kann, so dass er spezifischen Geschäftsanforderungen genügt.
• Wie oben erwähnt wurde, können zur Darstellung der Zusammenarbeitszustandsmaschine beispielsweise drei Tabellen (z. B. Textdateien) verwendet werden. Eine beispielhafte Struktur und ein beispielhafter Inhalt für eine solche Datei (z. B. "State.txt" oder die Zustandsdatei), die zur Darstellung der Zusammenarbeitszustandsmaschine verwendet werden kann, ist unten in Tabelle 1 gezeigt: Tabelle 1
  
  
• Beispielsweise kann die (obige) Datei "State.txt" Informationen für die vorhandenen Zustände in dem System, die Art, in der die Zustände zu behandeln oder zu verarbeitet sind, ihre SOR-Synchronisationsanforderungen und ihre Überzustandsbeziehungen aufweist. Jeder Zustand kann durch einen eindeutigen Anwendernamen sowie durch einen eindeutigen Systemnamen gekennzeichnet werden. Der Systemname kann im Speicher (oder in einer Datenbank) gespeichert werden, während der Anwendername für einen Anwender sichtbar ist. Im Ergebnis können den Zuständen kontextspezifische Namen zugewiesen werden. Für eine Zusammenarbeitsanwendung kann ein Zustandsobjekt zwei Felder aufweist: Customer Sync und Supplier Sync. Diese Felder können dazu verwendet werden, das spezifische Geschäftsobjekt zur SOR- Synchronisation (z. B. CSOR und SSOR für das Kunden-SOR bzw. für das Lieferanten- SOR) "zu verriegeln". Ein SOR-Freigabemerker an einem Zustand gibt an, dass der Zustand Synchronisierungsprüfungen erfordert. Falls die SOR-Merker beispielsweise tief sind (der Zustand die SOR-Synchronisation erfordert) und der Rollentyp (z. B. Kunde oder Lieferanten) angibt, dass das SOR freigegeben ist, wird dieser Datensatz für sämtliche nichtsynchronen Aktionen verriegelt. Sämtliche Übergänge werden von einem Überzustand zu einem Unterzustand (falls es solche Unterzustände gibt) gerichtet. Das Behandlerklassenfeld definiert die Behandlerklasse für die Übergänge. Beispielsweise kann die Behandlerklasse, wie in Tabelle 1 gezeigt ist, standardmäßig auf einen allgemeinen Behandler eingestellt sein.
• Eine beispielhafte Struktur und ein beispielhafter Inhalt für eine zweite solche Datei (z. B. "Action.txt" oder die Aktionsdatei), die zur Darstellung der Zusammenarbeitszustandsmaschine verwendet werden kann, ist unten in Tabelle 2 gezeigt: Tabelle 2
  
  
• Beispielsweise kann die Datei "Action.txt" Informationen für die zulässigen Aktionen in dem System zusammen mit ihren Aktualisierungsrichtlinien aufweist. Das Aktionsbeschreibungsfeld bildet eine Menge von Richtlinien, die anzuwenden sind, wenn die Aktion stattfindet. Dieses Feld (das z. B. wahlweise sein kann) schafft eine konfigurierbare Möglichkeit zur Beschreibung der Semantik der Aktionen. Falls in diesem Feld eine Aktionsbeschreibung vorhanden ist, beschreibt sie, was geschieht, wenn die Aktion auf einen Zustand angewendet wird. Die Einträge in dieser Spalte können vordefinierte Zeichenfolgen sein, die mit einem bitweisen "ODER"-Operator "|" begrenzt sind. Beispielsweise teilt die in Tabelle 2 gezeigte Aktionsbeschreibung von "UPDATE_STATE|UPDATE_DATA" dem Server mit, dass, wenn diese Aktion angetroffen wird, zunächst der Zustand aktualisiert wird und daraufhin die Daten aktualisiert werden.
• Eine beispielhafte Struktur und ein beispielhafter Inhalt für eine dritte solche Datei (z. B. "Trans.txt" oder Übergangsdatei), die zur Darstellung der Zusammenarbeitszustandsmaschine verwendet werden kann, ist unten in Tabelle 3 gezeigt: Tabelle 3
  
  
• Beispielsweise kann die Datei "Trans.txt" Übergänge aufweist, wie sie durch einen Zusammenarbeitsentitätstyp bezeichnet werden. Beispiele für solche Zusammenarbeitsentitätstypen können sein: KUNDE, LIEFERANTEN, TRANSPORTLIEFERANT usw. Somit können die Namen in der Datei "Trans.txt" die Anwendernamen der betroffenen Zustände und Aktionen sein. Diese Datei teilt dem Server den resultierenden Zustand bei einer Aktion für die Rolle (Zusammenarbeitsentitätstyp) mit.
• In Übereinstimmung mit der vorliegenden Erfindung ist die Zusammenarbeitszustandsmaschine vorteilhaft so konstruiert, dass sie ermöglicht, dass Aktionen für verschiedene Zustände wiederverwendet werden, was dazu dient, die Struktur und den Betrieb der Zusammenarbeitszustandsmaschine verhältnismäßig "schlank" zu halten. Typischerweise können bestimmte Arten von Aktionen für viele Zustände wiederholt werden. Beispielsweise kann für die meisten Zustände eine "Stornierungs"-Aktion unternommen werden. Folglich ermöglicht die Zusammenarbeitszustandsmaschine vorteilhaft, dass die gleiche Semantik für verschiedene Zustände wiederverwendet wird.
• Wenn die Zusammenarbeitszustandsmaschine erfolgreich in den Speicher (oder in eine Datenbank) geladen worden ist, können die Aktualisierungen und Zustandsänderungen im Zusammenhang mit den durch die Zusammenarbeitszustandsmaschine gebundenen Geschäftsobjekten durch die Zusammenarbeitszustandsmaschine gesteuert werden. Somit werden die Aktualisierungs- und Leseroutinen geschrieben, die mit der Zusammenarbeitszustandsmaschine in Wechselwirkung treten. Bei der Implementierung kann mehr als eine Zusammenarbeitszustandsmaschine verwendet werden.
• Beispielsweise kann für jeden Geschäftsobjekttyp, der Zustandsinformationen transportiert, eine andere Zusammenarbeitszustandsmaschine verwendet werden. Somit können zur Steuerung der Behandlung verschiedener Aufträge verschiedene Zusammenarbeitszustandsmaschinen verwendet werden. Ein Auftrag kann sich über in dem Auftrag vorhandene Gruppierungskriterien selbst der spezifischen Zustandsmaschine zuordnen. Als ein weiteres Beispiel können ähnlich verschiedene Zusammenarbeitszustandsmaschinen zur Steuerung der Behandlung verschiedener Benachrichtigungen über beschleunigten Versand verwendet werden, da ihre Richtlinien und Zustände verschieden sein können.
• Zur Kommunikation mit der Zusammenarbeitszustandsmaschine kann eine Anwenderschnittstelle (UI, engl. User Interface) verwendet werden, die alle möglichen Zustände abruft, die ein angemeldeter Anwender (beispielsweise auf einem Computermonitor) möglicherweise betrachten möchte, und die außerdem Aktionen abruft, die der Anwender für die gerade angezeigten Geschäftsobjekte durchführen möchte. Alternativ kann die Zusammenarbeitszustandsmaschine durch die UI auch das Rendern eines zu betrachtenden Objekts ansteuern.
• Für eine beispielhafte Ausführungsform können Stapelprozesse verwendet werden, die bestimmte Aktionen für die betroffenen Geschäftsobjekte einstellen und fördern, dass die Aktualisierungsaktionen stattfinden. Diesbezüglich können Aktualisierungs- und Einsetzungsprogrammierschnittstellen (APIs, engl. Application Process Interfaces) verwendet werden, die mit der Zusammenarbeitszustandsmaschine kommunizieren, um anhand des bestehenden Zustands des betroffenen Geschäftsobjekts Aktionen zu überprüfen und außerdem den resultierenden Zustand sowie die zu aktualisierenden oder einzusetzenden Daten zu bestimmen. Die meisten Stapelleseoperationen können auf Zustandsereignissen als den Hauptbeschränkungen (z. B. dem Abrufen aller Aufträge, die in einem "Neu"-Zustand sind) beruhen. Um sicherzustellen, dass ein besonderer Stapelprozess die Sicherheitsanforderungen für den angeforderten Zustand übergeben kann, kann in diesem Fall eine Lese-API mit der Zusammenarbeitszustandsmaschine kommunizieren.
• Wie oben erwähnt wurde, wird die Lebensdauer eines Geschäftsobjekts (z. B. eines Auftrags) vorzugsweise mit der Zusammenarbeitszustandsmaschine gesteuert. Im Ergebnis kann die Zusammenarbeitszustandsmaschine zulassen, dass verschiedene "Client"-Mechanismen (z. B. XML, flache Dateien, eine Web-gestützte Schnittstelle usw.) das gleiche Geschäftsobjekt bearbeiten und es unabhängig von dem Mechanismus, der den Zustand des Geschäftsobjekts ändert, während seiner Lebensdauer "führen".
• Fig. 2 ist ein Diagramm, das bestimmte Wechselwirkungen zeigt, die zwischen Entitäten in einer Zusammenarbeitsanwendung auftreten können, und das zeigt, wie die Zusammenarbeitszustandsmaschine in Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung eine verteilte Synchronisation der Zusammenarbeitsgeschäftsobjekte ermöglichen kann. Typischerweise (102) kann ein Geschäftsobjekt (z. B. ein Auftrag, engl. Purchase Order PO) in einem SOR erzeugt und (z. B. über das Internet) zu einem Zusammenarbeitsanwendungs-Server (z. B. zu einem von 12 Technologies US, INC., entwickelten Anwendungs-Server TRADEMATRIX) transportiert werden. Ein weiterer Beteiligter in dem Zusammenarbeitsraum kann das Objekt (z. B. den Auftrag) aus dem Anwendungs-Server auslesen, es zu seinem SOR zurücktransportieren und verarbeiten (104). Nachdem die Verarbeitung des Objekts abgeschlossen ist (106) kann dieser Beteiligte das Geschäftsobjekt (z. B. als Zusage in Reaktion auf den Auftrag) zu dem Zusammenarbeitsanwendungs-Server zurücktransportieren (108), so dass weitere Beteiligte das Objekt verarbeiten können. Beispielsweise kann der Beteiligte, der den Auftrag erzeugt hat, das Objekt (einschließlich der Zusage) von dem Anwendungs-Server auslesen (110), es erforderlichenfalls verarbeiten und das Objekt (das z. B. eine Annahme oder Ablehnung der Zusage darstellt) zu dem Anwendungs-Server transportieren (112).
• Wie zuvor erwähnt wurde, stellt die Zusammenarbeitszustandsmaschine in Übereinstimmung mit der vorliegenden Erfindung sicher, dass während der Verarbeitungsphase die Datenkonsistenz erhalten wird. Außerdem stellt die Zusammenarbeitszustandsmaschine sicher, dass die Datenkonsistenz leicht konfigurierbar ist. Somit kann die Zusammenarbeitszustandsmaschine eine Doppelbetriebsart (z. B. mit oder ohne SOR-Synchronisation) liefern. Beispielsweise kann ein Beteiligter in einigen Geschäftszusammenarbeitsszenarien ein SOR besitzen oder nicht. Beispielsweise kann eine verhältnismäßig große Geschäftsorganisation ein SOR besitzen, während sich einige ihrer kleineren Lieferanten möglicherweise kein SOR leisten können. In diesem Fall kann die Zusammenarbeitszustandsmaschine bestimmen, dass keine "Verriegelung" (z. B. synchrone Verriegelung beider miteinander) zwischen Entitäten erzwungen werden sollte. Die Entität ohne ein SOR kann über die UI (oder über eine andere solche Schnittstelle) des Anwendungs-Servers mit dem Anwendungs-Server der anderen Entität (z. B. einer, die ein SOR besitzt) in Wechselwirkung treten. Somit können z. B. jeder Entität in einem System ihrem im Profil dieser Entität gespeicherten Synchronisationsbedarf entsprechende Informationen zugeordnet sein. Beispielsweise kann eine Entität ohne SOR Profilinformationen besitzen, die angeben, dass keine Synchronisation erforderlich ist.
• Außerdem stellt die Zusammenarbeitszustandsmaschine dadurch, dass sie in Übereinstimmung mit dem besonderen betroffenen Zustand und/oder der besonderen betroffenen Entität eine Verriegelungsfunktion steuert, Synchronisationsoptionen auf Zustands- und Entitätsbasis bereit. Wie oben erwähnt wurde, ist die Synchronisationsverriegelung für eine bestimmte Entität möglicherweise nicht erforderlich, so dass sie für diese nicht erzwungen zu werden braucht. Beispielsweise braucht ein Kunde für eine Entitätssynchronisation für eine Bestellung in einem Zustand "versandt" nicht verriegelt zu werden, da die einzigen Aktualisierungen, die für diesen Zustand zulässig sind, die Lieferanten betreffen. Im Ergebnis dessen, dass die Zusammenarbeitszustandsmaschine Synchronisationsoptionen zulässt, schafft sie mehr Flexibilität für Anwendungsimplementierer als vorausgehende Techniken, was ermöglicht, das die Implementierer Kundenanwendungen leicht anpassen und dadurch ihre Leistung erhöhen.
• Als weiteres Beispiel könnte eine Verriegelung für das folgende Zusammenarbeitsgeschäftsszenarium erforderlich sein. Am 10. Juni 2001 fordert ein Kunde in Dallas, Texas, einhundert Computer von einem Lieferanten an. Als Reaktion kann der Lieferanten diese Informationen von der Zusammenarbeitsanwendung auslesen, über das Lieferanten spezifische SOR verarbeiten und am 10. Juni 2001 in Dallas, Texas, mit einer Zusage von neunzig Computern an den Kunden zurückgeben. Vorzugsweise ändert der Kunde die Bestellung nicht, bis der Lieferanten eine Antwort zurückgibt. Folglich kann ein Verriegelungsmechanismus verwendet werden, der sicherstellt, dass die Bestellung nicht geändert wird, bis eine Antwort zurückgegeben worden ist.
• Außerdem stellt die Zusammenarbeitszustandsmaschine vorteilhaft sicher, dass die Integration mit externen SORs leicht erreicht wird. Es ist wichtig, dass die Zusammenarbeitszustandsmaschine diese Integration auf der Zustandsebene konfigurierbar machen kann. Beispielsweise kann die Zusammenarbeitszustandsmaschine eine solche Integration erreichen, indem sie einem Zustand als Teil seiner (wie oben beschriebenen) Metainformationen zusammen mit ausführlichen Profilinformationen über die beteiligten Entitäten einen oder mehrere SOR- Merker anfügt. Jede Instanz eines Zustands kann mehrere Merker besitzen, die den Synchronisationsstatus der Zusammenarbeitsentitäten bestimmen. Falls eine Entität beispielsweise ein SOR besitzt und ein entsprechender SOR-Merker für ein Objekt tief ist kann die Zusammenarbeitszustandsmaschine sicherstellen, dass eine Aktualisierung für dieses Objekt nicht durchgeht, und außerdem einen Merker einstellen, dass ein Aktualisierungsfehler aufgetreten ist.
• Die Zusammenarbeitszustandsmaschine kann ermöglichen, dass eine UI anhand von Zustandsereignissen entscheidet, wie Objekte wiederzugeben (engl. render) sind. Die Aktionsaktualisierungsrichtlinien können an die UI Informationen über alle möglichen Aktualisierungen für ein besonderes Objekt (das z. B. einem Anwender angezeigt wird) liefern. Außerdem kann die Zusammenarbeitszustandsmaschine als Teil der allgemeinen Aktualisierungsrichtlinien für Objektrenderzwecke bestimmte UI-spezifische Aktualisierungsrichtlinien aufweist. Ferner kann die Zusammenarbeitszustandsmaschine in bestimmten Fällen den Arbeitsablauf für ein Objekt ansteuern. Beispielsweise kann eine UI mit der Zusammenarbeitszustandsmaschine Kontakt aufnehmen, um die Aktualisierungstypen zu bestimmen, die für eine gegebene Aktion möglich sind, und für Objekte, die diese Aktion durchführen, einen besonderen Arbeitsablauf verwenden.
• Wie zuvor beschrieben wurde, informiert die Aktionsbeschreibung für eine Aktion eine Anwendung darüber "was zu tun ist, wenn diese Aktion durchgeführt wird". Eine UI kann diesen Informationstyp auch verwenden, um zu bestimmen, "was ein Anwender tun können darf, falls eine Geschäftsentität in diesem Zustand ist". Im Ergebnis kann die UI entscheiden, was einem Anwender anzuzeigen ist, wenn ein Geschäftsobjekt (z. B. ein Auftrag) in einem besonderen Zustand gezeigt wird. Außerdem kann die UI entziffern, welche Tabellen-"Spalten" in einem besonderen Zustand editiert werden können. Auf diese Weise ermöglicht die Zusammenarbeitszustandsmaschine, dass UIs hochgradig konfigurierbar sind, was sich für eine hochgradig anpassbare Zusammenarbeitszustandsmaschine anbietet.
• Für hierarchische Objekte kann ein "Zustand" auf höheren Ebenen in einer Hierarchie eine Berechnung sein, die auf den Zuständen der vorangehenden unteren Ebenen beruhen. In Übereinstimmung mit einer beispielhaften Ausführungsform der vorliegenden Erfindung wird ein Zustandsaggregationssystem geschaffen, das eine Zusammenarbeitszustandsmaschine erweitert, um solche hierarchischen Objekte wirksam zu behandeln. Somit können Zustandsaggregierer einen anderen Typ einer Zusammenarbeitszustandsmaschine auf den höheren Ebenen der hierarchischen Geschäftsobjekte ermöglichen. Dieser etwas andere Zusammenarbeitszustandsmaschinentyp kann als "berechnete Zustandsmaschine" bezeichnet werden. Die Zustandsaggregierer, die konfigurierbar sind, können eine konfigurierbare Geschäftslogik bilden, die die berechnete Zustandsmaschine auf der aggregierten Ebene ansteuert. In einigen Implementierungen kann das Objekt der untersten Ebene einen gesamten Zustandsübergang durchlaufen, wobei die Objekte der höheren Ebene lediglich Informations-Container (d. h. keine Übergänge) zu sein brauchen. Somit bearbeiten die Entitäten in der Zusammenarbeit das Objekt auf der höheren Ebene nicht direkt. Folglich kann der Zustand des Objekts auf der höheren Ebene in Übereinstimmung mit der vorliegenden Erfindung als Aggregation berechnet werden.
• Beispielsweise kann ein Zustandsaggregierer eine Matrix von Zuständen für zusammengesetzte Objekte nehmen und entscheiden, was der Zustand auf der höheren Ebene sein soll. Beispielsweise kann ein Zustandsaggregierer auf der Auftragsebene die Zustände der Gegenstände einer zusammengesetzten Zeile des Auftrags durchsehen und entscheiden, welchen Zustand der Auftrag haben soll. Somit können in Übereinstimmung mit der vorliegenden Erfindung für sämtliche zusammengesetzten Gegenstände, die aus Objekten mit Zustandseigenschaften zusammengesetzt sind, Aggregierer definiert werden. Ein solcher Zustandsverdichter kann die folgenden Anforderungen besitzen. Zunächst ist die Zustandsaggregiererdatei zur Implementierungszeit in den Speicher zu laden. Somit kann ein Implementierer auf Wunsch seinen eigenen Zustandsaggregierer schreiben. Ein Zeiger auf eine Speicheradresse für diesen Zustandsaggregierer kann in einer Eigenschaftsdatei angeordnet werden. Zweitens ist anhand der Zustandsprioritäten eine Standardimplementierung für die Zustandsaggregierer bereitzustellen. Ein Implementierer kann die Standardimplementierung auswählen und eine oder mehrere der Zustandsprioritäten für das spezifische betroffene Geschäftsmodell anpassen. Drittens hat ein Zustandsaggregierer Transaktionssemantik- und Konkurrenzfragen geeignet zu behandeln.
• Fig. 3 ist ein Diagramm, das Programm-Pseudocode zur Verwendung eines beispielhaften Zustandsaggregierers in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt. Anhand von Fig. 3 kann eine Zustandsaggregation in den meisten Fällen im Wesentlichen dadurch ausgeführt werden, dass den Zuständen Prioritäten zugewiesen werden, wobei der Zustand mit der höchsten Priorität als der resultierende Zustand ausgewählt wird. Ein Prioritätsaggregierer kann diese Funktion dadurch ausführen, dass er die Prioritäten von Zuständen liest und die Prioritätsinformationen in den Prioritätsaggregierertabellen unterhält. Beispielsweise kann eine Datei für einen Prioritätsaggregierer als Datei "Aggregator_priorities.txt" bezeichnet werden, wobei sie aus einem Dateisystem gelesen werden kann, wenn der Anwendungs-Server für den Betrieb geladen wird. Eine beispielhafte Struktur für die Informationen, die in einer Datei Aggregator_priorities.txt unterhalten werden können, ist unten in Tabelle 4 gezeigt: Tabelle 4
  
  
• Beim Implementieren einer Datei Aggregator_priorities.txt kann eine Voraussetzung gemacht werden, dass die kleineren "Prioritäts"-Nummern in der Datei höhere Prioritäten als die größeren Nummern darstellen. Vorzugsweise werden keine negativen Prioritätsnummern verwendet, während keine zwei Zustände in der Datei die gleiche Priorität besitzen dürfen.
• Obgleich bevorzugte Ausführungsformen der vorliegenden Erfindung in der beigefügten Zeichnung gezeigt und in der vorstehenden Beschreibung erläutert wurden, ist die Erfindung selbstverständlich nicht auf die offenbarten Ausführungsformen beschränkt, wobei zahlreiche Änderungen, Abwandlungen und Ersetzungen vorgenommen werden können, ohne von dem durch die folgenden Ansprüche dargestellten und definierten Erfindungsgedanken abzuweichen.

Claims (40)

1. Computerimplementierte Zustandsmaschine zum Verarbeiten von Geschäftsobjekten, die Zusammenarbeiten zwischen Geschäftsentitäten darstellen, aufweisend:
wenigstens einem Geschäftsobjekt, das eine Zusammenarbeit zwischen mehreren Geschäfisentitäten darstellt; und
mehreren Grafen, die in computerlesbaren Medien dargestellt sind, wobei jeder Graf einer bestimmten Zusammenarbeitsgeschäftsentität entspricht, wobei die mehreren Grafen unter Verwendung mehrerer Textdateien erzeugt werden, wobei wenigstens eine erste der Textdateien Zustandsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind, wenigstens eine zweite der Textdateien Aktionsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind, und wenigstens eine dritte der Textdateien Übergangsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind.

2. Zustandsmaschine nach Anspruch 1, bei der die Grafen in einer Zustandsübergangsmatrix für die Zustandsmaschine gespeichert sind.

3. Zustandsmaschine nach Anspruch 2, bei der die Grafen Adjazenzgrafen sind und die Zustandsübergangsmatrix eine mehrdimensionale Adjazenzmatrix ist.

4. Zustandsmaschine nach Anspruch 2, bei der die Zustandsübergangsmatrix drei Dimensionen aufweist.

5. Zustandsmaschine nach Anspruch 2, bei der eine erste Dimension der Zustandsübergangsmatrix einen Zustandsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine zweite Dimension der Zustandsübergangsmatrix einen Aktionsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine dritte Dimension der Zustandsübergangsmatrix einen Entitätsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, und die in der Zustandsübergangsmatrix gespeicherten Informationen Zustandswerte aufweisen, die sich aus einer Berechnung ergeben, die von der Zustandsmaschine ausgeführten wird.

6. Zustandsmaschine nach Anspruch 1, bei der die Zusammenarbeitsgeschäftsentitäten wenigstens einen Kunden und einen Lieferanten aufweisen.

7. Zustandsmaschine nach Anspruch 1, bei der die Zustandsinformation wenigstens eine aus Zustandsidentifizierer-Information, Zustandsbehandlerklassen-Information, Synchronisationsanforderungs- Information und Überzustandsbeziehungs-Information aufweist.

8. Zustandsmaschine nach Anspruch 1, bei der die Aktionsinformation zumindest eine aus zulässigen Aktionsinformation und Aktualisierungsrichtlinien-Information aufweist.

9. Zustandsmaschine nach Anspruch 1, bei der die Übergangsinformation zumindest eine aus Entitätstypinformation, Startzustandsinformation, Information über eine durchgeführte Aktion und Information über den resultierenden Zustand aufweist.

10. Zustandsmaschine nach Anspruch 1, bei der die Zustandsmaschine eine von mehreren Zustandsmaschinen in einem computerimplementierten System zur Zusammenarbeit zwischen Geschäfisentitäten ist, wobei jede Zustandsmaschine eine Zustandsübergangsmatrix aufweist, die Informationen enthält, die mehrere Grafen für die Zustandsmaschine darstellen, und die unter Verwendung mehrerer Textdateien für die Zustandsmaschine erzeugt worden ist, wobei jeder Graf einem bestimmten Zusammenarbeitsgeschäftsentität entspricht.

11. Computerimplementiertes Verfahren, das die Verarbeitung von Geschäftsobjekten, die Zusammenarbeiten zwischen Geschäftsentitäten darstellen, durch eine Zustandsmaschine erleichtert, aufweisend:
Zugreifen auf wenigstens ein Geschäftsobjekt, das eine Zusammenarbeit zwischen mehreren Geschäftsentitäten darstellt; und
Erzeugen mehrerer Grafen, die in computerlesbaren Medien dargestellt sind, wobei jeder Graf einer besonderen Zusammenarbeitsgeschäftsentität entspricht, wobei die mehreren Grafen unter Verwendung mehrerer Textdateien erzeugt werden, wobei wenigstens eine erste der Textdateien Zustandsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind, wenigstens eine zweite der Textdateien Aktionsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind, und wenigstens eine dritte der Textdateien Übergangsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind.

12. Verfahren nach Anspruch 11, ferner aufweisend Speichern der Grafen in einer Zustandsübergangsmatrix für die Zustandsmaschine.

13. Verfahren nach Anspruch 12, bei dem die Grafen Adjazenzgrafen sind und die Zustandsübergangsmatrix eine mehrdimensionale Adjazenzmatrix ist.

14. Verfahren nach Anspruch 12, bei dem die Zustandsübergangsmatrix drei Dimensionen aufweist.

15. Verfahren nach Anspruch 12, bei dem eine erste Dimension der Zustandsübergangsmatrix einen Zustandsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine zweite Dimension der Zustandsübergangsmatrix einen Aktionsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine dritte Dimension der Zustandsübergangsmatrix einen Entitätsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, wobei die in der Zustandsübergangsmatrix gespeicherten Informationen Zustandswerte aufweisen, die sich aus einer Berechnung ergeben, die von der Zustandsmaschine ausgeführt wird.

16. Verfahren nach Anspruch 11, bei dem die Zusammenarbeitsgeschäftsentitäten wenigstens einen Kunden und einen Lieferanten aufweisen.

17. Verfahren nach Anspruch 11, bei dem die Zustandsinformation zumindest eine aus einer Zustandsidentifizierer-Information, einer Zustandsbehandlerklassen-Information, einer Synchronisationsanforderungsinformation und einer Überzustandsbeziehungs- Informationen aufweist.

18. Verfahren nach Anspruch 11, bei dem die Aktionsinformation zumindest eine aus einer zulässige Aktionsinformation und einer Aktualisierungsrichtlinien- Information aufweist.

19. Verfahren nach Anspruch 11, bei dem die Übergangsinformation zumindest eine aus einer Entitätstypinformation, einer Startzustandsinformation, einer Information über eine durchgeführte Aktion und Information über den resultierenden Zustand aufweist.

20. Verfahren nach Anspruch 11, bei dem das Geschäftsobjekt in einem computerimplementierten System zur Zusammenarbeit zwischen Geschäftsentitäten unter Verwendung einer von mehreren Zustandsmaschinen verarbeitet wird, wobei jede Zustandsmaschine eine Zustandsübergangsmatrix aufweist, die Informationen enthält, die mehrere Grafen für die Zustandsmaschine darstellen, und die unter Verwendung mehrerer Textdateien für die Zustandsmaschine erzeugt worden ist, wobei jeder Graf einer bestimmten Zusammenarbeitsgeschäftsentität entspricht.

21. Software für die Erleichterung der Verarbeitung durch eine Zustandsmaschine von Geschäftsobjekten, die Zusammenarbeiten zwischen Geschäftsentitäten darstellen, wobei die Software auf computerlesbaren Medien verkörpert ist und, wenn sie ausgeführt wird, in der Lage ist, um:
auf wenigstens ein Geschäftsobjekt zuzugreifen, das eine Zusammenarbeit zwischen mehreren Geschäftsentitäten darstellt; und
mehrerer Grafen zu erzeugen, die in computerlesbaren Medien dargestellt sind, wobei jeder Graf einer besonderen Zusammenarbeitsgeschäftsentität entspricht, wobei die mehreren Grafen unter Verwendung mehrerer Textdateien erzeugt werden, wobei wenigstens eine erste der Textdateien Zustandsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind, wenigstens eine zweite der Textdateien Aktionsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind, und wenigstens eine dritte der Textdateien Übergangsinformationen aufweist, die dem Geschäftsobjekt zugeordnet sind.

22. Software nach Anspruch 21, die ferner in der Lage ist um die Grafen in einer Zustandsübergangsmatrix für die Zustandsmaschine zu speichern.

23. Software nach Anspruch 22, bei der die Grafen Adjazenzgrafen sind und die Zustandsübergangsmatrix eine mehrdimensionale Adjazenzmatrix ist.

24. Software nach Anspruch 22, bei der die Zustandsübergangsmatrix drei Dimensionen aufweist.

25. Software nach Anspruch 22, bei der eine erste Dimension der Zustandsübergangsmatrix einen Zustandsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine zweite Dimension der Zustandsübergangsmatrix einen Aktionsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine dritte Dimension der Zustandsübergangsmatrix einen Entitätsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, wobei die in der Zustandsübergangsmatrix gespeicherten Informationen Zustandswerte aufweisen, die sich aus einer Berechnung ergeben, die von der Zustandsmaschine ausgeführt wird.

26. Software nach Anspruch 21, bei der die Zusammenarbeitsgeschäftsentitäten wenigstens einen Kunden und einen Lieferanten aufweisen.

27. Software nach Anspruch 21, bei der die Zustandsinformation zumindest eine aus einer Zustandsidentifizierer-Information, einer Zustandsbehandlerklassen- Information, einer Synchronisationsanforderungsinformation und einer Überzustandsbeziehungs-Information aufweist.

28. Software nach Anspruch 21, bei der die Aktionsinformation zumindest eine aus einer zulässige Aktionsinformation und einer Aktualisierungsrichtlinieninformation aufweist.

29. Software nach Anspruch 21, bei der die Übergangsinformation zumindest eine aus einer Entitätstypinformation, einer Startzustandsinformation, einer Informationen über eine durchgeführte Aktion und einer Information über den resultierenden Zustand aufweist.

30. Software nach Anspruch 21, bei der der Software eine von mehreren Zustandsmaschinen in einem computerimplementierten System zur Zusammenarbeit zwischen Geschäftsentitäten zugeordnet ist, wobei jede Zustandsmaschine eine Zustandsübergangsmatrix aufweist, die Informationen enthält, die mehrere Grafen für die Zustandsmaschine darstellen, und die unter Verwendung mehrerer Textdateien für die Zustandsmaschine erzeugt worden ist, wobei jeder Graf einer besonderen Zusammenarbeitsgeschäftsentität entspricht.

31. Computerimplementierte Zustandsmaschine zur Verarbeitung von Geschäftsobjekten, die Zusammenarbeiten zwischen Geschäftsentitäten darstellen, aufweisend:
wenigstens einem Geschäftsobjekt, das eine Zusammenarbeit zwischen mehreren Geschäftsentitäten darstellt; und
mehreren Grafen, die in einem computerlesbaren Medium dargestellt sind, wobei jeder Graf einer bestimmten Zusammenarbeitsgeschäftsentität entspricht, wobei die mehreren Grafen unter Verwendung mehrerer Textdateien erzeugt werden:
wenigstens eine erste der Textdateien Zustandsinformation aufweist, die dem Geschäftsobjekt zugeordnet sind, wobei die Zustandsinformation zumindest eine aus einer Zustandsidentifizierer- Informationen, einer Zustandsbehandlerklassen-Informationen, einer Synchronisationsanforderungsinformation und einer Überzustandsbeziehungs-Information aufweist;
wenigstens eine zweite der Textdateien Aktionsinformation aufweist, die dem Geschäftsobjekt zugeordnet sind, wobei die Aktionsinformation zumindest eine aus einer Information über zulässige Aktionen und einer Aktualisierungsrichtlinieninformation aufweist; und
wenigstens eine dritte der Textdateien dem Geschäftsobjekt zugeordnete Übergangsinformation aufweist, wobei die Übergangsinformation zumindest eine aus einer Entitätstypinformation, einer Startzustandsinformationen, einer Informationen über eine durchgeführte Aktion und einer Information über den resultierenden Zustand aufweist;
die Grafen in einer dreidimensionalen Zustandsübergangsmatrix für die Zustandsmaschine gespeichert sind, wobei eine erste Dimension der Zustandsübergangsmatrix einen Zustandsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine zweite Dimension der Zustandsübergangsmatrix einen Aktionsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, eine dritte Dimension der Zustandsübergangsmatrix einen Entitätsidentifizierer darstellt, der dem Geschäftsobjekt zugeordnet ist, wobei die in der Zustandsübergangsmatrix gespeicherten Informationen Zustandswerte aufweisen, die sich aus einer Berechnung ergeben, die von der Zustandsmaschine ausgeführt wird.

32. Computerimplementiertes Verfahren zum Aggregieren von Zustandsinformationen, die einem Verbundgeschäftsobjekt zugeordnet sind, das wenigstens eine Zusammenarbeit zwischen mehreren Geschäftsentitäten darstellt, wobei das Verfahren aufweist:
Auslesen der Zustandsinformationen für das Verbundgeschäftsobjekt aus einem computerlesbaren Medium; und
Bestimmen eines Zustands für das Verbundgeschäftsobjekt anhand einer zugewiesenen Prioritätsebene für einen Zustand in einer Hierarchie von Zuständen, die dem Verbundgeschäftsobjekt zugeordnet sind, wobei jedem Zustand in der Hierarchie von Zuständen eine entsprechende Prioritätsebene zugewiesen ist.

33. Verfahren nach Anspruch 32, bei dem die zugewiesene Prioritätsebene eine höchste Prioritätsebene für die Hierarchie von Zuständen aufweist.

34. Verfahren nach Anspruch 32, bei dem die Zustandsinformationen als Werte in einer mehrdimensionalen Zustandsübergangsmatrix für eine Zustandsmaschine gespeichert sind.

35. Software zum Aggregieren von Zustandsinformationen, die einem Verbundgeschäftsobjekt zugeordnet sind, das wenigstens eine Zusammenarbeit zwischen mehreren Geschäftsentitäten darstellt, wobei die Software in computerlesbaren Medien gespeichert ist und, wenn sie ausgeführt wird, in der Lage ist, um:
die Zustandsinformationen für das Verbundgeschäftsobjekt aus einem computerlesbaren Medium auszulesen; und
einen Zustand für das Verbundgeschäftsobjekt anhand einer zugewiesenen Prioritätsebene für einen Zustand in einer Hierarchie von Zuständen, die dem Verbundgeschäftsobjekt zugeordnet sind, wobei jedem Zustand in der Hierarchie von Zuständen eine entsprechende Prioritätsebene zugewiesen ist, zu bestimmen.

36. Software nach Anspruch 35, bei der die zugewiesene Prioritätsebene eine höchste Prioritätsebene für die Hierarchie von Zuständen aufweist.

37. Software nach Anspruch 35, bei der die Zustandsinformationen als Werte in einer mehrdimensionalen Zustandsübergangsmatrix für eine Zustandsmaschine gespeichert sind.

38. Computerimplementierter Zustandsaggregierer zum Aggregieren von Zustandsinformationen, die einem Verbundgeschäftsobjekt zugeordnet sind, das wenigstens eine Zusammenarbeit zwischen mehreren Geschäftsentitäten darstellt, wobei der Zustandsaggregierer aufweist:
Mittel zum Auslesen der Zustandsinformation für das Verbundgeschäftsobjekt aus einem computerlesbaren Medium; und
Mittel zum Bestimmen eines Zustandes für das Verbundgeschäftsobjekt anhand einer zugewiesenen Prioritätsebene für einen Zustand in einer Hierarchie von Zuständen, die dem Verbundgeschäftsobjekt zugeordnet sind, wobei jedem Zustand in der Hierarchie von Zuständen eine entsprechende Prioritätsebene zugewiesen ist.

39. Zustandsaggregierer nach Anspruch 38, bei dem die zugewiesene Prioritätsebene eine höchste Prioritätsebene für die Hierarchie von Zuständen aufweist.

40. Zustandsaggregierer nach Anspruch 38, bei dem die Zustandsinformationen als Werte in einer mehrdimensionalen Zustandsübergangsmatrix für eine Zustandsmaschine gespeichert sind.