DE69936627T2 - In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen - Google Patents

In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen Download PDF

Info

Publication number
DE69936627T2
DE69936627T2 DE69936627T DE69936627T DE69936627T2 DE 69936627 T2 DE69936627 T2 DE 69936627T2 DE 69936627 T DE69936627 T DE 69936627T DE 69936627 T DE69936627 T DE 69936627T DE 69936627 T2 DE69936627 T2 DE 69936627T2
Authority
DE
Germany
Prior art keywords
message
procedures
calls
client
queue
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69936627T
Other languages
English (en)
Other versions
DE69936627D1 (de
Inventor
Richard Bellevue DIEVENDORFF
Patrick J. Bellevue HELLAND
Gagan Redmond CHOPRA
Mohsen Redmond AL-GHOSEIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Application granted granted Critical
Publication of DE69936627D1 publication Critical patent/DE69936627D1/de
Publication of DE69936627T2 publication Critical patent/DE69936627T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G06F9/548—Object oriented; Remote method invocation [RMI]

Description

  • Technisches Gebiet
  • Die vorliegende Erfindung betrifft verteilte komponentenbasierte Computersoftware-Anwendungen, insbesondere in einer Warteschlange angeordnete Aufrufe von Prozeduren für solche Anwendungen.
  • Stand der Technik
  • In zahlreichen Informationsverarbeitungsanwendungen stellt eine auf einem Host- oder Server-Computer in einem verteilten Netzwerk laufende Server-Anwendung Verarbeitungsdienste für von einer Vielzahl von Benutzern betriebene, auf Terminal- oder Arbeitsstationscomputern des Netzwerks laufende Client-Anwendungen bereit. Bekannte Beispiele für entsprechende Serveranwendungen umfassen Software zum Verarbeiten von Kursanmeldungen an einer Universität, Reisereservierungen, Geldtransfers und anderen Bankdienstleistungen sowie Verkäufen in Unternehmen. In diesen Beispielen können die von der Serveranwendung bereitgestellten Verarbeitungsdienste Datenbanken von Stundenplänen, Hotelreservierungen, Kontoständen, Lieferaufträgen, Zahlungen oder Bestandsaufnahmen für von den Einzelbenutzern an den jeweiligen Standorten initiierte Aktionen aktualisieren. Dies wird gelegentlich als Client/Server-Datenverarbeitung bezeichnet.
  • In einer Art der Client/Server-Datenverarbeitung, die mitunter als "Verteilte Objekte" bekannt ist, wird die Serveranwendung als eine Zusammenstellung von Komponenten entwickelt, die einem Objektorientierten Programmierungsmodell (OOP-Modell), wie beispielsweise dem Komponenten-Objekt-Modell (Microsoft Component Objekt Model (COM)) und dem Verteilte Komponenten-Objekt-Modell (Distributed Component Object Model (DCOM)) von Microsoft, dem System-Objekt-Modell (IBM System Object Model (SOM)) von IBM, der Architektur für Vermittler der Abrufe von gemeinsamen Objekten (Object Management Group's Common Object Request Broker Architecture (CORBA)) der Object Management Group und anderen, entsprechen. Die Vorteile der objektorientierten Programmierung liegen im Allgemeinen in der Einfachheit der Programmierung, der Erweiterbarkeit, der Wiederverwendbarkeit von Code sowie der Möglichkeit der Integration von Software verschiedener Hersteller und (bei einigen objektorientierten Programmierungsmodellen) in verschiedenen Programmiersprachen.
  • In der objektorientierten Programmierung werden Programme als eine Zusammenstellung von Objektklassen geschrieben, welche jeweils reale oder abstrakte Elemente durch Kombinieren von Daten zur Abbildung von Eigenschaften des Gegenstands mit Prozeduren (z.B. Programmfunktionen oder -prozeduren) zur Abbildung der Funktionalität des Elements modellieren. Genauer gesagt ist ein Objekt eine als Klasse bezeichnete Instanz eines programmiererdefinierten Typs, welche die Eigenschaften Datenkapselung, Polymorphie und Vererbung darstellt.
  • Datenkapselung bezieht sich auf das Kombinieren von Daten (auch als Objekteigenschaften bezeichnet) und Prozeduren, die auf den Daten operieren (auch als Memberfunktionen eines Objekts bezeichnet), zu einer einheitlichen Softwarekomponente (d.h. dem Objekt), so daß das Objekt seine interne Zusammensetzung, Struktur und Operation verbirgt und seine Funktion den das Objekt nutzenden Client-Programmen gegenüber ausschließlich über eine oder mehrere Schnittstellen offenbart. Eine Schnittstelle des Objekts ist eine Gruppe semantisch verwandter Prozeduren des Objekts. Anders formuliert, greifen die Client-Programme nicht direkt auf die Objektdaten zu, sondern sie müssen vielmehr Prozeduren an den Objektschnittstellen abrufen, um auf den Daten operieren zu können.
  • Polymorphie bezieht sich auf die Fähigkeit, zwei gleichartige Objekte über eine gemeinsame Schnittstelle zu betrachten (d.h. damit zu interagieren), wodurch sich die Notwendigkeit, zwischen zwei Objekten zu differenzieren, erübrigt. Vererbung bezieht sich auf das Ableiten verschiedener Objektklassen von einer Basisklasse, wobei die abgeleiteten Klassen die Eigenschaften und Besonderheiten der Basisklasse erben.
  • Bei Client/Server-Datenverarbeitung mit "verteilten Objekten" nutzt das Client-Programm auf dem Benutzercomputer in der Regel "Echtzeit"- oder synchrone Verarbeitungsmechanismen zum Fernaufrufen von Prozeduren auf den Server-Anwendungs-Objekten, die sich auf dem Server-Computer befinden, wie beispielsweise der Prozedur-Fernaufruf ("RPC"). Bei einem typischen Prozedur-Fernaufruf erstellen Objektdienste des Betriebssystems eine Schnittstellendefinitionssprachbeschreibung eines Serveranwendungsobjekts, um einen lokalen "Proxy" für das Serveranwendungsobjekt auf dem Client-Computer zu generieren. Die Client-Software ruft Prozeduren des entfernten Serveranwendungsobjekts auf, indem sie gewöhnliche lokale Aufrufe von Prozeduren direkt an den Proxy ausgibt. Der Proxy nutzt seinerseits RPC-Dienste, um den Prozedur-Aufruf an das aktuelle Serveranwendungsobjekt auf dem entfernten Server-Computer weiterzuleiten. Die RPC-Dienste arrangieren Werte für Aufruf-Parameter zu einer Netzwerk-Nachricht und senden die Nachricht über Netzwerkprotokolle an den Server-Computer. Auf dem Server-Computer machen die RPC-Dienste das Arrangieren der Aufruf-Parameter rückgängig und geben den Aufruf an die richtige Serveranwendungsobjekt-Prozedur aus. Außerdem übernehmen die RPC-Dienste das Arrangieren und Rückgängigmachen des Arrangierens von Rückgabewerten von der Serveranwendungsobjekt-Prozedur zurück zum Client-Programm über eine Netzwerk-Nachricht.
  • Dementsprechend verarbeiten die RPC-Dienste alle Feinheiten der Netzwerkkommunikation gewissermaßen "hinter den Kulissen", so daß das Client-Programm die entfernte Prozedur auf die gleiche Weise wie einen lokalen Prozedur-Aufruf aufruft. Wie bei einem lokalen Prozedur-Aufruf wird die Ausführung des Client-Programms während des RPC-Prozedur-Aufrufs bis zum Abschluß und zur Rückkehr der Prozedur unterbrochen (auch bekannt als "Blockieren"). Dies bewirkt einen synchronen Ausführungsfluß zwischen dem Client-Programm und den Serveranwendungsobjekten.
  • Obzwar sich Echtzeit-Prozedur-Aufruf-Modelle, wie beispielsweise RPC, für viele Anwendungen eignen, können sie den Anforderungen anderer Anwendungen aufgrund einer Anzahl von Einschränkungen in Bezug auf Verfügbarkeit, Netzübertragungskosten, fehlende Möglichkeit der Priorisierung, Lebensdauer des Objekts und Referenzlokalität nicht adäquat entsprechen.
  • Bezüglich der Verfügbarkeit fordern Echtzeit-Prozedur-Aufruf-Modelle, daß das Serveranwendungsobjekt zum Zeitpunkt verfügbar ist, zu welchem das Client-Programm einen Aufruf an eine der Prozeduren des Objekts ausgibt. Ist dies nicht der Fall, kann der Echtzeit-Prozedur-Aufruf nicht erfolgen. In der Praxis können Serveranwendungsobjekte jedoch aufgrund von Netzwerkfehlern oder durch eine Arbeitsüberlastung des Server-Computers nicht verfügbar sein. In einigen Fällen kann der Server-Computer über einen bestimmten Zeitraum offline (beispielsweise aufgrund von Aktualisierungs- oder Wartungsmaßnahmen) oder nur zu bestimmten Tageszeiten online sein. Außerdem kann, wenn ein beliebiges Serveranwendungsobjekt nicht in "Echtzeit" verfügbar ist, kein Teil der Arbeit abgeschlossen werden (einschließlich der von verfügbaren Serveranwendungsobjekten). Dieses Problem verstärkt sich bei komplexen Operationen mit multiplen Knoten (z.B. Computer in einem Netzwerk). So ist beispielsweise ein Prozeß, der Zugang zu vier unabhängigen Objekten an separaten Knoten erfordert, wovon jeder ca. 90% der Zeit verfügbar ist, tatsächlich nur etwa 66% der Zeit verfügbar (da 90%4 = 65,61%).
  • Außerdem sind einige Client-Computer nur gelegentlich mit einem Netzwerk verbunden und somit einen Großteil der Zeit über nicht in der Lage, Echtzeit-Aufrufe von Prozeduren auszugeben. Ein treffendes Beispiels für solche gelegentlich verbundenen Client-Computer sind Laptops, Notebooks und Handheld-Computer mobiler Benutzer, deren Anteil bei Computerneuanschaffungen heute auf über 50% geschätzt wird.
  • Zur Verfügbarkeitsanforderung des Echtzeit-Prozedur-Aufruf-Modells gehört auch, daß der/die Server-Computer mit ausreichender Kapazität konfiguriert sein muß/müssen, um die Anfragen interaktiver Benutzer der Server-Anwendung zu Spitzenzeiten bewältigen zu können. Demzufolge ist das typische System mit Server-Computern konfiguriert, welche die meiste Zeit über nicht ausgelastet, zu bestimmten Zeiten allerdings überlastet sind (wenn z.B. die tatsächliche Belastung die Erwartungen überschreitet).
  • Aus den genannten Gründen ist das Echtzeit-Prozedur-Aufruf-Modell für Datenverarbeitungsumgebungen mit eingeschränkter Verfügbarkeit, mobilen Benutzern, hohen Knotenzahlen oder stark variierenden Lasten durch interaktive Benutzer ungeeignet.
  • Was die Netzübertragungskosten betrifft, so erfordert jeder Echtzeit-Prozedur-Aufruf über einen RPC eine Hin-und-Rück-Netzwerkkommunikation, die zu beachtlichen Netzübertragungskosten führt, beispielsweise durch die Bearbeitungszeit für das Arrangieren der Aufruf-Parameter und das Rückgängigmachen des Arrangierens, das Verarbeiten im Netzwerkprotokoll-Stack sowie Übertragungszeit. Überdies kann es sein, daß der Client mehrere Prozeduren einer Serveranwendungskomponente aufrufen muß, um verwendbare Arbeit zu leisten, wodurch sich die Netzübertragungskosten wiederum erhöhen. Insbesondere moderne objektorientierte Designtechniken neigen zu einer Vielzahl von Aufrufen von Prozeduren mit relativ wenigen Parametern pro Aufruf. Ein typisches derartiges Objekt ist beispielsweise so gestaltet, daß ein Client zunächst zur Vorbereitung einer Operation verschiedene Eigenschaftsprozeduren ("Property-Set"-Prozeduren) und anschließend eine Prozedur zum Verarbeiten der Operation aufruft. Folglich kann viel Zeit durch Netzwerk-Overhead verwendet werden. Aufgrund dieser Netzübertragungskosten können Echtzeit-Prozedur-Aufruf-Modelle für einige Anwendungen weniger geeignet sein.
  • In Bezug auf Priorität werden Aufrufe bei typischen Echtzeit-Prozedur-Aufruf-Modellen nach dem "First-come, first-served"-Prinzip dann bearbeitet, wenn sie eintreffen, ohne jegliche Berücksichtigung von Priorität.
  • In Bezug auf die Lebensdauer des Objekts besitzen Serveranwendungsobjekte in Echtzeit-Prozedur-Aufruf-Modellen eine tendenziell lange Lebensdauer. Bei der typischen Client/Server-Datenverarbeitung durch ein verteiltes Objekt existiert das Serveranwendungsobjekt auf dem Server-Computer ab dem Zeitpunkt der Erzeugung durch den Client solange, bis das Objekt freigegeben wird. Vor einem nächsten Prozedur-Aufruf durch den Client verwendet das Objekt einen Großteil dieser Zeit einfach auf das Warten auf den Aufruf der Prozeduren des Objekts durch den Client und auf die Netzübertragungskosten für das Zurückliefern von Prozedurergebnissen. Währenddessen verbraucht das Objekt Ressourcen des Server-Computers, einschließlich Speicher- und Verarbeitungs-Overhead der Ausführungsumgebung. Das Serveranwendungsobjekt "erwacht" und „schläft" gewissermaßen mindestens ein Mal pro Prozedur-Aufruf. Diese "Belegungszeit" des Serveranwendungsobjekts stellt ein Hemmnis für schnelles Durchlaufen von Serverobjekten dar und führt zur Beschränkung von Serveranwendungsskalierbarkeit.
  • In Bezug auf Referenzlokalität greifen viele Teile von Computersystemen (z.B. der Prozessor-Cache und der Arbeitsbereich des virtuellen Speichers) auf Referenzlokalität zurück, um Leistungszuwächse zu erreichen. Stark lokale Anwendungen, z.B. Objekte oder Anwendungscode, die/der direkt unter Nutzung lokal verfügbarer Daten ausführen/ausführt, verfügen hierfür über Referenzmuster, die besser Leistungen erzielen. Im Gegensatz dazu besitzen Anwendungen mit über mehrere Server-Computer verteilten Objekten, die Echtzeit-Prozedur-Aufrufe wie das RPC nutzen, nur geringe Referenzlokalität. Beispielsweise wird ein Serverobjekt durch den ersten Echtzeit-Prozedur-Aufruf erzeugt und verbringt häufig einen Großteil seiner Lebensdauer damit, auf nachfolgende Echtzeit-Aufrufe von Prozeduren zu warten. Nach der Verarbeitung jedes Prozedur-Aufrufs wird das Serverobjekt in der Regel aus dem Prozessor-Cache entfernt und fällt manchmal zwischen Aufrufen aus dem Arbeitsbereich des virtuellen Speichers heraus. Auf diese Weise verringern die Echtzeit-Aufrufe von Prozeduren den Transaktions-Verarbeitungsumfang der Anwendung.
  • Eine Alternative zu „verteilten Objekten", die das Problem der eingeschränkten Verfügbarkeit eines RPC-Echtzeit-Prozedur-Aufrufs zum Teil bewältigt, ist eine mitunter als "nachrichtenorientierte Middleware" (Message Oriented Middleware) (MOM)) bezeichnete Art der Client/Server-Datenverarbeitung. Bei MOM kommuniziert eine Client-Anwendung mit einer entfernten Server-Anwendung durch Senden von Nachrichten an eine Nachrichtenwarteschlange. Die Server-Anwendung, die zu einem späteren Zeitpunkt als die Client-Anwendung laufen kann, ruft die Nachrichten von ihrer Nachrichtenwarteschlange ab und verarbeitet diese. Die Serveranwendung kann Ergebnisse dieser Verarbeitung an die Client-Anwendung zurücksenden, indem sie Nachrichten an eine gleiche oder separate Nachrichtenwarteschlange zur Verarbeitung durch die Client-Anwendung sendet. Solcher Datentransfer unter Verwendung von Nachrichtenwarteschlangen hat den Vorteil, daß die Client- und die Server-Anwendungen nicht gleichzeitig verfügbar sein und keine übereinstimmenden Lebensdauern haben müssen.
  • Herkömmliche MOM-Produkte weisen allerdings auch Anzahl von Einschränkungen auf. Eine Einschränkung besteht darin, daß die Client- und die Serveranwendung die Nachricht selbst als einen linearen Stream formatieren. Genauer gesagt, müssen die Client- und die Serveranwendungen die Daten dieses Streams selbst arrangieren und das Arrangieren selbst rückgängig machen. Die Nachrichtenwarteschlangen-Infrastruktur umfaßt keinen Support für das Arrangieren.
  • Eine weitere Einschränkung von MOM besteht darin, daß die Client- und die Server-Anwendung für die Kommunikation mit der Nachrichtenwarteschlangen-Infrastruktur eine herstellerspezifische Programmierschnittstelle (Application Programming Interface (API)) für Nachrichtenwarten-schlangenbildungsanwendungen nutzen. Anders formuliert, senden die Client- und die Serveranwendung Nachrichten an eine Nachrichtenwarteschlange über explizite Aufrufe an die Nachrichtenwarteschlangen bildende API. Für die Entwickler von Client/Serveranwendungen gilt es, noch ein weiteres API-Set zu lernen. So ist beispielsweise die Nachrichtenwarteschlangen bildende Schnittstelle (MQI) (für MQSeries API) die API des nachrichtenorientierten Middlewareprodukts der MQSeries von IBM. Andere Hersteller von MOM-Produkten, wie beispielsweise Microsoft (Microsoft Message Queue (MSMQ), Covia (Communications Integrator), Peerlogic (PIPES), Horizon Strategies (Message Express) oder System Strategies (ezBridge) haben unterschiedliche Nachrichtenwarteschlangen bildende APIs.
  • Außerdem erstellen Abnehmer eines MOM-Produkts (wie beispielsweise eine Informationstechnologie-Organisation (IT-Organisation)) aus unterschiedlichen Beweggründen eine separate API-Schicht über die vom Hersteller bereitgestellte Nachrichtenwarteschlangen bildende API. Ein Beweggrund ist, daß die IT-Organisation verhindert möchte, daß ihre Anwendungsentwickler entscheiden können, welche Teile der Nachrichtenwarteschlangen bildenden API sie nutzen und auf welche Weise sie die API nutzen. Ein zweiter Beweggrund kann sein, daß die Nachrichtenwarteschlangen bildende API zu umfangreich, zu komplex ist oder den Anwendungsentwicklern zu viele Optionen bietet. Die IT-Organisationen erstellen somit ihre eigene API-Schicht in der Absicht, die API für ihre Anwendungsentwickler zu vereinfachen. Folglich müssen die meisten Entwickler sowohl die Nachrichtenwarteschlangen bildende API des Herstellers als auch die von der IT-Organisation bereitgestellte API lernen. Ein dritter Beweggrund kann sein, daß die IT-Organisation vermeiden möchte, daß ihre Anwendungen von einer jeglichen Nachrichtenwarteschlangen bildenden API eines Herstellers oder einem jeglichen MOM-Produkt anhängig sind, und sich die Möglichkeit offenhalten möchte, die Hersteller zu einem späteren Zeitpunkt zu wechseln. Dies hindert häufig die IT-Organisation daran, die Funktionen des MOM-Produkts voll auszuschöpfen. Dieses Phänomen verzögert die Implementierung von Anwendungen mit einem MOM-Produkt und erschwert der IT-Organisation bisweilen die Nutzung neueingeführter Funktionen des MOM-Produkts.
  • Eine weitere Einschränkung herkömmlicher MOM-Produkte besteht in der suboptimalen Leistungsfähigkeit in einigen Konfigurationen. Insbesondere können Anwendungen und Anwendungsobjekte lokal über Aufrufe von Prozeduren zu extrem niedrigen Verarbeitungszeitkosten kommunizieren, insbesondere wenn sie in einem gleichen Prozeß sind. Anwendungen und Anwendungsobjekte, die über eine Nachrichtenwarteschlangen bildende API kommunizieren, erfordern die Verarbeitung über einen Warteschlangenmanager, selbst wenn sich die Anwendungen oder Objekte in derselben oder einer ähnlichen Umgebung, wie beispielsweise einem gleichen Prozeß, befinden.
  • In ihrem Aufsatz "Design of a Remote Procedure Call System for Object-Oriented Distributed Programming" beschreiben die Autoren Anand R. Tripathi und Terence Noonan das Design eines RPC-Systems zur Bildung objektorientierter verteilter Softwaresysteme. Bei Nutzung dieses Systems kann eine eine Prozedur darstellende Anfragenachricht an einen Server übermittelt werden, auf dem ein Objekt unter Verwendung einer Kernel-Funktion verwaltet wird. Der Kernel sendet den einzigen Identifikator für den Aufruf an die RPC-Laufzeit zurück. Um die Antwort des Aufrufs zu empfangen, führt der Client-Prozeß RPC-Laufzeit-Funktion aus und überprüft anschließend den Status des Aufrufs in einer Aufruftabelle. Wurde der Aufruf aufgrund eines Zeitüberschreitungs- oder eines jeglichen anderen Fehlerzustands abgebrochen, sendet er diesen Status an den Client-Prozeß zurück und entfernt den Eintrag für diesen Auftrag aus der Aufruftabelle. Ist der Aufruf noch zu erledigen, führt er eine Funktion zum Empfangen einer Antwortnachricht vom Kernel aus. Er wartet während der in einer Sync-Funktion vorgegebenen Zeitüberschreitungsperiode auf den Eingang der Antwortnachricht, und wenn während dieser Zeitüberschreitungsperiode keine Nachricht eingeht und der Aufruf im Kernel immer noch anhängig ist, wird ein Zeitüberschreitungsstatus an den Client-Prozeß zurückgesandt. Der Client-Prozeß muß dann die Synchronisierung zu einem späteren Zeitpunkt nochmals versuchen.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung befähigt einen Client eines Objekts zur Ausgabe und das Objekt zum Empfang von Aufrufen von Prozeduren auf der Grundlage einer Warteschlange unter Nutzung normaler Aufrufsemantik eines Objektmodells ohne Verwendung einer Nachrichtenwarteschlangen bildenden API. Genauer gesagt nutzt der Client die normale Semantik des Objektmodells, um das Objekts zu erstellen, die Prozeduren des Objekts aufzurufen und das Objekt freizugeben. Der Rahmen oder die Ausführungsumgebung des Objekts stellt Dienste zum automatischen Anordnen der Aufrufe von Prozeduren in einer Warteschlange und zum möglicherweise späteren Ausgeben der in einer Warteschlange angeordneten Aufrufe von Prozeduren an das Objekt bereit. Unterdessen kann der Client asynchron zu der aufgerufenen Prozedur die Ausführung fortsetzen. Das Objekt wiederum hat die an seine Schnittstelle(n) über normale Aufrufsemantik ausgegebenen, in einer Warteschlange angeordneten Aufrufe von Prozeduren, verarbeitet diese und sendet anschließend einen Wert der Prozedur unter erneuter Nutzung normaler Aufrufsemantik zurück. Auf diese Weise müssen die Anwendungsentwickler den Client und das Objekt nicht für die Nutzung einer Nachrichtenwarteschlangen bildenden API zur Warteschlangenverarbeitung programmieren, wie es bei herkömmlicher nachrichtenorientierter Middleware der Fall ist, und das Erlernen solcher APIs ist nicht erforderlich.
  • Gemäß einem Aspekt der Erfindung kann ein Objekt sowohl Echtzeit- als auch in einer Wartschlange angeordnete Aufrufe von Prozeduren über eine gemeinsame Schnittstelle empfangen. Echtzeit-Aufrufe von Prozeduren werden an das Objekt über einen lokalen Prozedur-Aufruf oder einen entfernten Prozedur-Aufruf an die Schnittstelle ausgegeben. In einer Warteschlange angeordnete Aufrufe von Prozeduren werden in einer Vorrichtung für in einer Warteschlange angeordnete Aufrufe von Prozeduren in einer Warteschlange angeordnet und anschließend über einen lokalen Prozedur-Aufruf von der Vorrichtung an die Objektschnittstelle ausgegeben. Das Objekt unterscheidet nicht zwischen den Echtzeit- und den in einer Warteschlange angeordneten Aufrufen von Prozeduren. Daher kann das Objekt ohne Veränderung sowohl in einer synchronen Echtzeit-Umgebung als auch in einer asynchronen Warteschlangen-Umgebung laufen gelassen werden. In gewisser Weise weiß das Objekt weder, ob es sich in einer Echtzeit- oder in einer Warteschlangen-Umgebung befindet, noch, in welcher Weise die Prozeduren auf seiner Schnittstelle aufgerufen werden.
  • Gemäß einem weiteren Aspekt der Erfindung stellt der Rahmen oder die Umgebung des Objekts außerdem Support zum automatischen Arrangieren für in einer Warteschlange angeordnete Aufrufe von Prozeduren bereit. Ein Client gibt in einer Warteschlange angeordnete Aufrufe von Prozeduren an ein Objekt über einen vom System bereitgestellten Proxy und Stub oder Adapter (Wrapper) aus, der aus der Beschreibung einer Schnittstellendefinitionssprache der Schnittstelle des Objekts übersetzt ist, um das geeignete Arrangieren von Aufrufparametern und zugehörigen Daten zu und von in einer Warteschlange angeordneten Nachrichten zu implementieren.
  • Gemäß einem weiteren Aspekt der Erfindung umfaßt die Vorrichtung zum Anordnen von Aufrufen von Prozeduren in einer Warteschlange eine Aufzeichnungseinrichtung für Aufrufe von Prozeduren auf einer Client-Seite und eine Abspieleinrichtung für Aufrufe von Prozeduren auf der Objekt-Seite der Client-Objekt-Interaktion. Die Aufzeichnungseinrichtung für Prozedur-Aufrufe empfängt eine Anzahl von möglicherweise mehr als einem Prozedur-Aufruf eines Clients, die als ein Stapel an die Abspieleinrichtung für Prozedur-Aufrufe weitergeleitet werden soll. Beispielsweise kann die Aufzeichnungseinrichtung eine Menge von in einer Warteschlange angeordneten, vom Client an das Objekt als Teil einer Transaktion ausgegebenen Prozedur-Aufrufen sammeln und die Prozedur-Aufrufe erst nach Abschluß der Transaktion weitergeben. Die Abspieleinrichtung für Prozedur-Aufrufe ruft die in einer Warteschlange angeordneten Prozedur-Aufrufe nacheinander von einer Warteschlange für Prozedur-Aufrufe ab und gibt die Aufrufe von Prozeduren – möglicherweise als Teil einer anderen, das Objekt umfassenden Transaktion – an das Objekt aus.
  • Gemäß einem weiteren Aspekt der Erfindung entspricht ein Objekt, das in einer Warteschlange angeordnete Aufrufe von Prozeduren unterstützt, der Einschränkung, daß dessen Prozeduren ausschließlich Eingabeparameter aufweisen können und keine anwendungsspezifischen Informationen zurücksenden können. Die in einer Warteschlange angeordneten Aufrufe von Prozeduren können dann als unidirektionale Kommunikationen vom Client zum Objekt ausgegeben werden, bei denen der Client nicht in Echtzeit- oder synchroner Ausführung auf Ergebnisse des Prozedur-Aufrufs warten muß. Das Objekt kann Ergebnisse der Verarbeitung der in einer Warteschlange angeordneten Prozedur-Aufrufe durch Ausgabe von Echtzeit-Prozedur-Aufrufen oder von in einer Warteschlange angeordneten Prozedur-Aufrufen an ein durch einen Eingabeparameter vom Client beschriebenes Ergebnisobjekt liefern.
  • Weitere Eigenschaften und Vorteile der Erfindung werden anhand der nachfolgenden detaillierten Beschreibung einer Ausführungsform unter Bezugnahme auf die beigefügten Zeichnungen ersichtlich.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm eines Computersystems, das zur Implementierung eines Verfahrens und einer Vorrichtung genutzt werden kann, welche die Erfindung für in einer Warteschlange angeordnete Aufrufe von Prozeduren verkörpern.
  • 2 ist ein Blockdiagramm einer Ausführungsumgebung und einer Laufzeitarchitektur für in einer Warteschlange angeordnete Aufrufe von Prozeduren gemäß der dargestellten Ausführungsform der Erfindung.
  • 3 ist ein Blockdiagramm einer Struktur einer in einer Warteschlange angeordneten Komponente in der Ausführungsumgebung von 2.
  • 4 ist ein Blockdiagramm einer Aufzeichnungseinrichtung und eines Proxy in der Laufzeitarchitektur von 2.
  • 5 ist ein Blockdiagramm einer Abspieleinrichtung und eines Stub in der Laufzeitarchitektur von 2.
  • 6 ist ein Blockdiagramm einer Vorrichtung zur Überwachung von Warteschlangen für unzustellbare Nachrichten (Dead-Letter-Queue) und eines Ausnahmezustandsbehandlers in der Laufzeitarchitektur von 2.
  • 7 ist eine Programmliste von beispielhaften Objekt-Instanziierungs-Aufrufen zur Aktivierung der in einer Warteschlange angeordneten Komponente in der Laufzeitarchitektur von 2.
  • 8 ist eine Programmliste einer „IPlaybackControl"-Schnittstelle eines Ausnahmezustandsbehandlers in 5 und 6.
  • 9 ist eine Programmliste eines Formats einer Nachricht von in einer Warteschlange angeordneten Aufrufen von Prozeduren in der Laufzeitarchitektur von 2.
  • 10 ist ein Blockdiagramm des Formats einer in einer Warteschlange angeordnete Prozedur-Aufrufe enthaltenden Nachricht in der Laufzeitarchitektur von 2.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Die vorliegende Erfindung betrifft ein Verfahren und ein System für in einer Warteschlange angeordnete Aufrufe von Komponentenprozeduren. In einer hier erläuterten Ausführungsform wird die Erfindung in eine als „COM+" bezeichnete Objektdienste-Komponente eines als „Microsoft Windows NT Server 5.0" bezeichneten, durch die Microsoft Corporation in Redmond, Washington vertriebenen Betriebssystems integriert. Kurz beschrieben ist diese Software ein skalierbares Hochleistungsnetzwerk- und Computerbetriebssystem, das verteilte Client/Server-Datenverarbeitung unterstützt und eine Objekt-Ausführungsumgebung für dem Komponentenobjektmodell (COM) von Microsoft entsprechende Komponentenanwendungen bereitstellt. Die COM+-Komponente umfaßt Objektdienste von vorbekannten Objektsystemen, einschließlich des Microsoft-Komponentenobjektmodells (COM), der Microsoft-Objektverlinkung und -einbettung (Microsoft Object Linking and Embedding (OLE)), des Verteilten Komponentenmodells (DCOM) von Microsoft und des Microsoft-Transaktionsservers (Microsoft Transaction Server (MTS)).
  • Beispielhafte Betriebsumgebung
  • 1 und die folgende Darstellung dienen einer kurzen, allgemeinen Beschreibung einer geeigneten Datenverarbeitungsumgebung, in welcher die Erfindung implementiert werden kann. Obwohl die Erfindung im allgemeinen Kontext computerausführbarer Anweisungen eines auf einem Computer laufenden Computerprogramms beschrieben wird, wird der Fachmann feststellen, daß die Erfindung gleichfalls in Kombination mit anderen Programmmodulen implementiert werden kann. Programmmodule umfassen im Allgemeinen Routinen, Programme, Komponenten, Datenstrukturen usw., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Außerdem wird der Fachmann erkennen, daß die Erfindung mit anderen Computersystemkonfigurationen, wie beispielsweise Handheld-Vorrichtungen, Multiprozessorsystemen, Mikroprozessor-basierter oder programmierbarer Unterhaltungselektronik, Minicomputer, Großrechenanlagen u. a., betrieben werden kann. Die dargestellte Ausführungsform der Erfindung wird ebenfalls in verteilten Datenverarbeitungsumgebungen betrieben, wo Aufgaben über entfernte, durch ein Kommunikationsnetzwerk verbundene Verarbeitungsvorrichtungen ausgeführt werden. Einige Ausführungsformen der Erfindung können allerdings auch auf Einzelrechnern betrieben werden. In einer verteilten Datenverarbeitungsumgebung können sich Programmmodule sowohl in lokalen als auch in entfernten Speichervorrichtungen befinden.
  • Bezugnehmend auf 1 umfaßt ein beispielhaftes System zur Implementierung der Erfindung einen konventionellen Computer 20 (wie beispielsweise Personalcomputer, Laptops, Palmtops, Set-Tops, Server, Großrechenanlagen und andere Computerarten) mit einer Verarbeitungseinheit 21, einem Systemspeicher 22 und einem Systembus 23, der verschiedene Systemkomponenten einschließlich des Systemspeichers mit der Verarbeitungseinheit 21 verbindet. Die Verarbeitungseinheit kann ein jeglicher von verschiedenen im Handel erhältlichen Prozessoren sein, wie beispielsweise Intel x86-, Pentium- und kompatible Mikroprozessoren von Intel und anderen Herstellern, wie beispielsweise Cyrix, AMD und Nexgen; Alpha von Digital, MIPS von MIPS Technology, NEC, IDT, Siemens u. a. sowie der PowerPC von IBM und Motorola. Duale Mikroprozessoren und andere Multiprozessor-Architekturen können ebenfalls als Verarbeitungseinheit 21 genutzt werden.
  • Der Systembus kann ein jeglicher von verschiedenen, einen Speicherbus oder eine Speicher-Steuereinheit, einen Peripheriebus und einen lokalen Bus umfassenden Busstruktur-Typen sein, die eine von unterschiedlichen konventionellen Bus-Architekturen nutzen, wie beispielsweise PCI, VESA, AGP, Microchannel, ISA und EISA, um nur einige zu nennen. Der Systemspeicher umfaßt Nur-Lese-Speicher (ROM) 24 und Speicher mit wahlfreiem Zugriff (RAM) 25. In ROM 24 befindet sich ein einfaches Eingabe/Ausgabe-System (BIOS), welches die Basisprogramme zur Übertragung von Informationen zwischen Elementen innerhalb des Computers 20, wie beispielsweise während des Hochfahrens, umfaßt.
  • Der Computer 20 umfaßt weiterhin ein Festplattenlaufwerk 27, ein Magnetplattenlaufwerk 28 beispielsweise zum Lesen einer oder zum Schreiben auf eine Wechselplatte 29 und ein Optische-Medien-Laufwerk 30 beispielsweise zum Lesen einer CD-ROM-Platte 31 oder zum Lesen eines oder zum Schreiben auf ein anderes optisches Medium. Das Festplattenlaufwerk 27, das Magnetplattenlaufwerk 28 und das Optische-Medien-Laufwerk 30 sind jeweils über eine Festplattenlaufwerk-Schnittstelle 32, eine Magnetplattenlaufwerk-Schnittstelle 33 bzw. eine Schnittstelle für ein Optische-Medien-Laufwerk 24 mit dem Systembus 23 verbunden. Die Laufwerke und ihre dazugehörigen computerlesbaren Medien stellen nichtflüchtigen Speicher von Daten, Datenstrukturen, Computer-ausführbaren Anweisungen usw. für den Computer 20 bereit. Obwohl sich die obige Beschreibung computerlesbarer Medien auf eine Festplatte, eine magnetische Wechselplatte und eine CD bezieht, sollte der Fachmann feststellen, daß auch andere computerlesbaren Medientypen, wie beispielsweise Magnetbandkassetten, Flash-Speicherkarten, digitale Videodisks, Bernoulli-Laufwerke u. a., in der beispielhaften Betriebsumgebung eingesetzt werden können.
  • In den Laufwerken und dem RAM 25 kann eine Anzahl von Programmmodulen, einschließlich des Betriebssystems 35, eines oder mehrerer Anwendungsprogramme 36, weiterer Programmmodule 37 und Programmdaten 38, gespeichert werden.
  • Ein Benutzer kann über eine Tastatur 40, und eine Steuervorrichtung, wie beispielsweise eine Maus 42, Befehle und Informationen in den Computer 20 eingeben. Weitere (nicht abgebildete) Eingabevorrichtungen können ein Mikrophon, ein Joystick, ein Gamepad, eine Parabolantenne, ein Scanner oder ähnliches sein. Diese und andere Eingabevorrichtungen sind an die Verarbeitungseinheit 21 häufig über einen seriellen Schnittstellenport 46 angeschlossen, der mit dem Systembus verbunden ist, aber auch an andere Schnittstellen, wie beispielsweise einen Parallel-Port, einen Game-Port oder einen universellen seriellen Bus (USB) angeschlossen sein kann. Außerdem ist ein Bildschirm 47 oder eine andere Anzeigevorrichtung über eine Schnittstelle, wie beispielsweise einen Video-Adapter 48, an den Systembus 23 angeschlossen. Zusätzlich zum Bildschirm umfassen Computer in der Regel andere periphere (nicht abgebildete) Ausgabevorrichtungen, wie beispielsweise Lautsprecher und Drucker.
  • Der Computer 20 kann in einer vernetzten, logische Verbindungen zu einem oder mehreren entfernten Computer, wie beispielsweise einem entfernten Computer 49, nutzenden Umgebung operieren. Der entfernte Computer 49 kann ein Server, ein Router, eine Peer-Vorrichtung oder ein anderer gemeinsamer Netzknoten sein und umfaßt in der Regel viele oder alle der in Bezug auf den Computer 20 beschriebenen Elemente, auch wenn in 1 nur eine Speichervorrichtung 50 dargestellt ist. Die in 1 dargestellten logischen Verbindungen umfassen ein lokales Netz (LAN) 51 und ein Weitbereichsnetz (WAN) 52. Entsprechende vernetzende Umgebungen sind gewöhnlich in Büros, Computer-Netzwerken in Unternehmen, internen Netzwerken und im Internet anzutreffen.
  • Bei Einsatz in einer LAN-vernetzenden Umgebung wird der Computer 20 über eine Netzwerkschnittstelle oder einen -adapter 53 mit dem lokalen Netz 51 verbunden. Bei Einsatz in einer WAN-vernetzenden Umgebung umfaßt der Computer 20 in der Regel ein Modem 54 oder andere Mittel zum Aufbau von Kommunikation (z. B. mittels LAN, eines Gateway- oder eines Proxy-Servers 55) über das Weitbereichsnetz 52, wie beispielsweise das Internet. Das Modem 54, das ein internes oder externes sein kann, wird über den seriellen Schnittstellenport 46 an den Systembus 23 angeschlossen. In einer vernetzten Umgebung können in Bezug auf den Computer 20 dargestellte Programmodule oder Teile davon in einer entfernten Speichervorrichtung gespeichert werden. Man erkennt, daß die dargestellten Netzwerkverbindungen Beispiele sind und andere Mittel zum Aufbau einer Kommunikationsverbindung zwischen Computern verwendet werden können.
  • In Übereinstimmung mit den Gepflogenheiten von Fachleuten aus dem Bereich der Computerprogrammierung erfolgt die nachstehende Beschreibung der vorliegenden Erfindung, falls nicht anders angegeben, unter Bezugnahme auf durch den Computer 20 ausgeführte Handlungen und symbolische Darstellungen von Operationen. Entsprechende Handlungen und Operationen werden gelegentlich als „durch einen Computer ausgeführt" bezeichnet. Man erkennt, daß die Handlungen und symbolisch dargestellten Operationen die durch die Verarbeitungseinheit 21 erfolgende, Datentbits darstellende Bearbeitung von elektrischen Signalen, welche eine resultierende Transformation oder Reduktion der Darstellung elektrischer Signale hervorruft, sowie die Verwaltung der Datenbits an im Speichersystem (mit Systemspeicher 22, Festplattenlaufwerk 27, Magnetplatten-Speicher 29 und CD-ROM 31) befindlichen Speicherorten umfassen, um so die Operation des Computersystems sowie andere Signalverarbeitung zu rekonfigurieren oder anderweitig zu ändern. Bei den Speicherorten, an denen Datenbits verwaltet werden, handelt es sich um physische Speicherplätze, die bestimmte elektrische, magnetische oder optische, den Datenbits entsprechende Eigenschaften aufweisen.
  • Ausführungsumgebung der Komponentenanwendung
  • Wie aus 2 ersichtlich, liefert die oben erwähnte COM+-Komponente des Microsoft Windows NT 5.0 Betriebssystems Laufzeit- oder Systemdienste zur Erstellung einer Ausführungsumgebung für Laufzeitobjekte 80 auf einem Server-Computer 84, welche in einer Warteschlange angeordnete Aufrufe von Prozeduren an ein Objekt 86 (nachstehend als „Warteschlangenkomponente" bezeichnet) automatisch bereitstellt. Die COM+-Komponente ist als dynamische Linkbibliothek (Dynamic Link Library (DLL)) implementiert. (Eine DLL ist ein bekanntes ausführbares Dateiformat, welches dynamische Verlinkung oder Laufzeitverlinkung von ausführbarem Code in den Prozeß eines Anwendungsprogramms ermöglicht). Die COM+-DLL wird direkt in Anwendungsserverprozesse (z. B. „ASP" 90) geladen, die Komponentenanwendungsobjekte hosten, und läuft transparent im Hintergrund dieser Prozesse.
  • Der dargestellte ASP 90 ist ein Systemprozeß, der die Ausführung von Komponentenanwendungsobjekten einschließlich der Warteschlangenkomponente 86 hostet. Jeder ASP 90 kann mehrere Komponentenanwendungsobjekte hosten, die zu einer als „COM+-Anwendung" bezeichneten Sammlung (in der Objektausführungsumgebung des vorbekannten Microsoft-Transaktionsservers auch als „Package" bezeichnet) gruppiert werden. Ferner können mehrere ASP 90 auf dem Server-Computer 84 unter einem Multithreaded-, Multitasking-Betriebssystem (z. B. Microsoft Windows NT in der dargestellten Ausführungsform) ablaufen. Jeder ASP 90 stellt eine separate Vertrauensgrenze (separate trust boundary) und einen separaten Fehlereingrenzungsbereich (fault isolation domain) für die Serveranwendungsobjekte bereit. Anders formuliert, kann sich bei getrennten ASPs ein durch ein Serveranwendungsobjekt hervorgerufener Fehler, der eine Beendigung seines ASP bewirkt, in der Regel nicht auf die Serveranwendungsobjekte in einem anderen ASP auswirken. In der dargestellten Ausführungsform sind die Komponentenanwendungsobjekte als eine COM+-Anwendung gruppiert, um mit Hilfe eines als „COM+-Explorer" bezeichneten Verwaltungsprogramms gemeinsam in einem ASP zu laufen. Dieses Programm stellt eine grafische Benutzerschnittstelle zur Steuerung von mit den Komponentenanwendungsobjekten verbundenen Attributen einschließlich der Gruppierung von Objekten in COM+-Anwendungen bereit.
  • In einer typischen, in 2 dargestellten Installation befindet sich die Ausführungsumgebung 80 auf dem Server-Computer 84 (der ein Beispiel des oben beschriebenen Computers 20 sein kann), der in einem verteilten Computernetzwerk angeschlossen ist, welches eine große Menge an auf die Komponentenanwendungsobjekte in der Ausführungsumgebung 80 zugreifenden Client-Computern 92 umfaßt. Alternativ kann sich die Ausführungsumgebung 80 auf einem Einzelcomputer befinden und Komponentenanwendungsobjekte hosten, auf die ebenfalls auf diesem Computer befindliche Client-Prozesse zugreifen.
  • Überblick über Komponentenanwendungsobjekte
  • Unter Bezugnahme auf 2 führt der Computer 84 als eine COM+-Anwendung entwickelte, eine Gruppe von Komponentenanwendungsobjekte umfassende Komponentenanwendungen aus. Beispielsweise können die in der Ausführungsumgebung 80 des ASP 90 gehosteten Komponentenanwendungsobjekte (wie z. B. die Warteschlangenkomponente 86) die Geschäftslogik einer Client/Server-Anwendung, wie z. B. den Code zur Steuerung von Einschreibungen in einer Registrierungsanwendung einer Universität oder von Aufträgen in einer Online-Verkaufsanwendung, implementieren. In der Regel umfaßt jede Komponentenanwendung eine Mehrzahl von Komponenten, wovon jede Programmcode für einen Teil der Anwendungsarbeit enthält.
  • Bezugnehmend auf 3 entsprechen die Komponentenanwendungsobjekte in der dargestellten Ausführungsumgebung 80 (2) der Anforderung des Microsoft-Komponentenobjektmodells ("COM") (d.h., daß sie als ein "COM-Objekt" 100 implementiert sind) und werden, wie oben beschrieben, unter Nutzung der COM+-Dienste des Microsoft Windows NT Server 5.0 Betriebssystems ausgeführt; alternativ können sie allerdings auch nach anderen Objektstandards implementiert werden (wie beispielsweise den Anforderungen der CORBA (Common Objekt Request Broker Architecture (Architektur für Vermittler der Abrufe von gemeinsamen Objekten)) der Object Management Group oder Java Beans von der Sun Microsystems Inc.) und unter Objektdiensten eines anderen Betriebssystems ausgeführt werden. Die COM-Anforderung definiert binäre Standards für Objekte und deren Interfaces, welche die Integration von Softwarekomponenten in Anwendungen erleichtern. (Für eine detaillierte Erörterung von COM und OLE siehe Kraig Brockschmidt: "Inside OLE", 2. Auflage, Microsoft Press, Redmond, Washington 1995).
  • Gemäß COM wird das COM-Objekt 100 im Computer 84 (2) durch eine Instanzdatenstruktur 102, eine Tabelle 104 der virtuellen Funktionen und Prozeduren oder Memberfunktionen 106–108 dargestellt. Die Instanzdatenstruktur 102 umfaßt einen Zeiger 110 auf die Tabelle 104 der virtuellen Funktionen und Daten 112 (auch als Datenmember oder Eigenschaften des Objekts bezeichnet). Ein Zeiger ist ein Datenwert, der die Adresse eines Gegenstands im Speicher hält. Die Tabelle 104 der virtuellen Funktionen umfaßt Einträge 116–118 für die Prozeduren 106–108. Jeder dieser Einträge 116–118 umfaßt einen Verweis auf den die entsprechende Prozedur implementierenden Code 106–108.
  • Der Zeiger 110, die Tabelle 104 der virtuellen Funktionen und die Prozeduren 106–108 implementieren eine Schnittstelle des COM-Objekts 100. Üblicherweise werden die Schnittstellen eines COM-Objekts grafisch als eine Steckbuchse dargestellt, wie für die Warteschlangenkomponente 86 in 2 gezeigt. Außerdem erhalten Schnittstellen üblicherweise Bezeichnungen, die mit dem Großbuchstaben "I" beginnen. Gemäß COM kann das COM-Objekt 100 mehrere Schnittstellen umfassen, die mit einer oder mehreren Tabellen der virtuellen Funktionen implementiert werden. Die Prozedur einer Schnittstelle wird mit „IInterfaceName::FunctionName" bezeichnet.
  • Die Tabelle 104 der virtuellen Funktionen und die Prozeduren 106–108 des COM-Objekts 100 werden von einem Objektserverprogramm 120 (nachstehend als „Objektserver-DLL" bezeichnet) bereitgestellt, welches in dem Computer 20 (1) als eine Datei einer dynamischen Linkbibliothek (mit der Dateinamenerweiterung ".dll" versehen) gespeichert ist. Gemäß COM umfaßt die Objektserver-DLL 120 Code für die Tabelle 104 der virtuellen Funktionen und die Prozeduren 106–108 der Klassen, die sie unterstützt, sowie weiterhin eine Klassenfabrik 122, welche die Instanzdatenstruktur 102 für ein Objekt der Klasse generiert.
  • Andere Objekte und Programme (als „Client" des COM-Objekts 100 bezeichnet) greifen auf die Funktionalität des COM-Objekts durch Aufrufen der Prozeduren über die Schnittstellen des COM-Objekts zu. Zunächst muß das COM-Objekt jedoch instanziiert werden (z. B. indem die Klassenfabrik zur Erstellung der Instanzdatenstruktur 102 des Objekts veranlaßt wird), und der Client muß einen Schnittstellenzeiger auf das COM-Objekt erhalten.
  • Bevor das COM-Objekt 100 instanziiert werden kann, wird das Objekt zunächst auf dem Computer 20 installiert. In der Regel umfaßt die Installation das Installieren einer Gruppe verwandter, in einer COM+-Anwendung enthaltener Objekte. Die Installation des COM-Objekts 100 erfolgt durch das Speichern der Objektserver-DLL-Datei(en), welche das Objekt in dem Computer 20 zugänglichem Datenspeicher (in der Regel die in 1 dargestellte Festplatte) bereitstellt/bereitstellen, und das Registrieren von COM-Attributen (z. B. Klassenidentifikatoren, Pfad und Bezeichnung der Objektserver-DLL-Datei 120 usw.) des COM-Objekts in einem Systemregister, einem Katalog oder einer ähnlichen Konfigurationsdatenbank.
  • Ein Client fordert die Instanziierung des COM-Objekts unter Einsatz vom System bereitgestellter Dienste und einer Menge systemdefinierter Standard-Komponentenschnittstellen, die auf den Klassen und Schnittstellen des COM-Objekts zugewiesenen Klassen- und Schnittstellenidentifikatoren basieren, an. Genauer gesagt sind die Dienste für die Client-Programme als Funktionen von Schnittstellen zur Anwendungsprogrammierung (API) verfügbar, die in der COM+-Bibliothek bereitgestellt werden, welche eine Komponente des Microsoft Windows NT Server 5.0 Betriebssystems in einer Datei mit dem Namen „OLE32.DLL." ist. Außerdem werden in COM+ Klassen von COM-Objekten ausschließlich mit Klassenidentifikatoren („CLSIDs") assoziiert und von ihrem CLSID in einer als „Registry" bezeichneten Systemkonfigurationsdatenbank registriert.
  • Der Registrierungseintrag für eine Klasse von COM-Objekten assoziiert den CLSID der Klasse mit Informationen, die eine ausführbare, die Klasse bereitstellende Datei (z.B. eine DLL-Datei, die eine Klassenfabrik zur Erstellung einer Instanz der Klasse aufweist) identifizieren. Klassenidentifikatoren sind 128-Bit global eindeutige Identifikatoren (Globally Unique Identifiers ("GUIDs")), die der Programmierer mittels eines als "CoCreateGUID" bezeichneten COM+-Dienstes (oder einer/einem von verschiedenen anderen APIs und Programmen zur Erstellung universeller eindeutiger Identifikatoren) programmiert und den entsprechenden Klassen zuweist. Zusätzlich werden die Schnittstellen einer Komponente mit Schnittstellenidentifikatoren ("IIDs") verbunden.
  • Insbesondere stellt die COM+-Bibliothek API-Funktionen, z.B. "CoCreateInstance()" und "CoGetObject()" bereit, die das Client-Programm aufrufen kann, um die Erstellung einer seine zugewiesene CLSID und einen IID einer gewünschten Schnittstelle nutzenden Komponente anzufordern. Als Reaktion auf eine Instanziierungsanforderung des Clients sucht die "CoCreatelnstance()"-API den Registrierungseintrag der angeforderten CLSID im Register, um die ausführbare Datei für die Klasse zu identifizieren. Die "CoCreatelnstance()"-API-Funktion lädt anschließend die ausführbare Datei der Klasse und nutzt die Klassenfabrik in der ausführbaren Datei, um eine Instanz des COM-Objekts 100 zu erstellen. Abschließend sendet die "CoCreatelnstance()"-API-Funktion einen Zeiger der angeforderten Schnittstelle an das Client-Programm zurück. Die "CoCreatelnstance()"-API-Funktion kann die ausführbare Datei entweder in den Prozeß des Client-Programms oder in einen Serverprozeß laden, der, je nach den für das COM-Objekt 100 in der System-Registrierdatenbank registrierten Attributen, lokal oder entfernt sein kann (z.B. auf dem selben Computer oder auf einem entfernten Computer in einem verteilten Computernetzwerk). Die "CoGetObject()"-API andererseits nutzt die COM-Moniker-Architektur, um eine die Serverobjektklasse identifizierende Zeichenkette zu analysieren und ein Moniker-Objekt zu erstellen, welches anschließend zur Erstellung einer Instanz der Serverobjektklasse genutzt wird.
  • Sobald der Client des COM-Objekts 100 diesen ersten Schnittstellen-Zeiger des COM-Objekts erhalten hat, kann der Client Zeiger anderer gewünschter Schnittstellen der Komponente durch Nutzung des mit der gewünschten Schnittstelle verbundenen Schnittstellenidentifikators erhalten. COM+ definiert verschiedene, üblicherweise von COM-Objekten unterstützte Standardschnittstellen einschließlich der "IUnknown"-Schnittstelle. Diese Schnittstelle umfaßt eine Prozedur namens "Querylnterface()". Die "Querylnterface()"-Funktion kann mit einem Schnittstellenidentifikator als ein Argument aufgerufen werden und sendet einen Zeiger an die mit diesem Schnittstellenidentifikator verbundene Schnittstelle zurück. Die "IUnknown"-Schnittstelle jedes COM-Objekts umfaßt außerdem Prozeduren, "AddRef()" und "Release()", zum Verwalten einer Zahl von Clientprogrammen, die einen Verweis (z.B. einen Schnittstellenzeiger) auf das COM-Objekt halten. Üblicherweise sind die Prozeduren der "IUnknown"-Schnittstelle als Teil jeder Schnittstelle auf einem COM-Objekt enthalten. Dementsprechend kann jeder Schnittstellenzeiger, den der Client auf eine Schnittstelle des COM-Objekts 100 erhält, zum Aufruf der "Querylnterface"-Funktion genutzt werden.
  • Überblick über Transaktionsverarbeitung
  • Nochmals bezugnehmend auf 2, implementiert die COM+-Komponente außerdem eine automatische Transaktionsverarbeitung für die Komponentenanwendungsobjekte in der dargestellten Ausführungsumgebung 80. Eine ausführlichere Offenbarung der automatischen Transaktionsverarbeitung von komponentenbasierten Serveranwendungen findet sich in dem US-Patent Nr. 5,890,161 von Helland et al. über "Automatic Transaction Processing Of Component-Based Server Applications", eingereicht am 28.10.1997 und veröffentlicht am 30.03.1999 (nachfolgend als "Patentanmeldung für Automatische Transaktionen" bezeichnet). Kurz beschrieben, koordiniert die automatische Transaktionsverarbeitung die Verarbeitungsaktivitäten von Komponentenanwendungs-Objekten in der Ausführungsumgebung 80, die Teile einer Operation bilden, um als eine einzelne, unteilbare Arbeitseinheit, die im Allgemeinen als Transaktion bezeichnet wird, wirksam zu werden.
  • Transaktionen in der Ausführungsumgebung 80 werden über einen Transaktionsmanager 128 gesteuert. Der Transaktionsmanager 128 ist ein Systemdienst, der mehrere gesteuerte Transaktionsressourcen, wie beispielsweise Datenbanken, Dateisysteme usw., umfassende Transaktionen koordiniert. Der Transaktionsmanager 128 gewährleistet, daß die gesamte in eine Transaktion eingebundene Verarbeitungsarbeit (z.B. Updates von Datenbanken) in Übereinstimmung mit den ACID-Eigenschaften (Atomarität (Atomicity), Konsistenz (Consistency), Isolation (Isolation), Dauerhaftigkeit (Durability)) unter Nutzung des vorbekannten Two-Phase-Commit-Protokolls und ungeachtet von Fehlern (z.B. Computer-, Netzwerk-, Hardware- oder Softwarefehler oder Fehler durch Fehlverhalten von Ressourcenmanager oder -anwendung), Wettlaufsituationen (z.B. eine Transaktion beginnt mit der Übergabe, während ein Ressourcenmanager einen Abbruch initiiert) oder Verfügbarkeit (ein Ressourcenmanager bereitet eine Transaktion vor, kehrt aber nicht zurück) erfolgt. Der dargestellte Transaktionsmanager 148 ist der als Teil des Microsoft SQL Servers 6.5 veröffentlichte Microsoft-Koordinator von verteilten Transaktionen (Microsoft Distributed Transaction Coordinator) (MSDTC)). Für zusätzliche Hintergrundinformationen über Transaktionsverarbeitung siehe u.a. Jim Gray und Andreas Reuter: "Transaction Processing Concepts and Techniques", Morgan Kaufmann, 1993.
  • Laufzeitarchitektur von in einer Warteschlange angeordneten Komponenten
  • Weiterhin bezugnehmend auf 2 stellt eine Laufzeitarchitektur 130 von in einer Warteschlange angeordneten Komponenten (nachfolgend als "QC-Architektur" bezeichnet) Support für in einer Warteschlange angeordnete Aufrufe von Prozeduren unter Nutzung normaler COM-Aufrufsemantik bereit. Genauer gesagt, ruft ein Client 132 in einem Prozeß 134 auf dem Client-Computer 92 Prozeduren auf Schnittstellen 87 der Warteschlangenkomponente 86 unter Nutzung der üblichen COM-Konventionen für synchrone Echtzeitinteraktion auf, einschließlich folgender Schritte: Erstellen des Objekts, beispielsweise über einen "CoGetObject()"-Aufruf oder einen "CoCreateInstance()"-Aufruf; Empfang eines Schnittstellenzeigers, beispielsweise durch Spezifizieren eines Schnittstellenidentifikators (IID) in einem "CoCreatelnstance()"-API-Aufruf oder einem "Querylnterface()"-Aufruf; die Ausgabe von Aufrufen an das Objekt über dessen Tabelle der virtuellen Funktionen oder eine Dispatch-Schnittstelle (für dynamische Bindung) und schließlich die Freigabe des Objekts beispielsweise durch Aufrufen der "Release"-Prozedur des Objekts. (In einigen Implementierungen der Erfindung, wie beispielsweise in der hier dargestellten QC-Architektur 130, kann der Client einen anderen Objekterstellungsmechanismus für in einer Warteschlange angeordnete Prozedur-Aufrufe (z. B. die oben beschriebene "CoGetObject()"-API und einen Warteschlangen-Moniker (unten beschrieben)) als für Aufrufe von Echtzeit-Prozeduren nutzen, wobei er allerdings Prozeduren des Objekts nach wie vor mittels normaler Aufrufsemantik aufruft.) Die Warteschlangenkomponente 86 andererseits ruft ihre Prozeduren über ihre Tabelle der virtuellen Funktionen oder eine Dispatch-Schnittstelle wie bei einem lokalen Prozedur-Aufruf auf. Anders formuliert, müssen der Client 132 und die Warteschlangenkomponente 86 nicht so geschrieben werden, daß sie jegliche Nachrichten einreihende API nutzen, um in einer Warteschlange angeordnete Aufrufe von Prozeduren der Warteschlangenkomponente auszugeben oder zu empfangen.
  • Die Aufrufe von Prozeduren des Clients auf die Warteschlangenkomponente 86 werden auf einer Client-Seite 140 der Client-zu-Objekt-Interaktion aufgezeichnet und zu einem späteren Zeitpunkt wieder abgespielt und an die Warteschlangenkomponente 86 auf einer Server-Seite 142 der Interaktion ausgegeben. Die dargestellte QC-Architektur 130 zeichnet alle Prozedur-Aufrufe des Clients auf der Warteschlangenkomponente 86 auf und spielt die Prozedur-Aufrufe erst dann wieder ab, wenn der Client 132 seine Nutzung der Warteschlangenkomponente 86 abgeschlossen hat (d. h. nach Freigabe der Warteschlangenkomponente durch den Client). Falls der Client 132 an einer Transaktion beteiligt ist, gilt des Weiteren, daß die Prozedur-Aufrufe erst nach regulärem Abschluß der Transaktion wieder abgespielt werden.
  • Die dargestellte QC-Architektur 130 wird in der COM+-Komponente des Microsoft Windows NT 5.0 Betriebssystems implementiert. Die COM+-Komponente stellt verschiedene Laufzeitobjekt-Dienste für auf dem Computersystem 20 laufende COM-Objekte bereit. Die Laufzeitdienste stellen eine Aufzeichnungseinrichtung 150, eine Empfangseinrichtung 152 und eine Abspieleinrichtung 154 bereit, die in einer Warteschlange angeordnete Aufrufe von Prozeduren über normale Aufrufsemantik durch den Client 132 auf die Warteschlangenkomponente 86 ausführen. Die Aufzeichnungseinrichtung 150 fungiert als ein Proxy für die Warteschlangenkomponente, um das Arrangieren der Prozedur-Aufrufe des Clients mit deren Aufrufparametern und zugehörigen Daten in Nachrichten auszuführen, und nutzt außerdem eine Nachrichtenwarteschlangen bildende API (wie beispielsweise die "Microsoft Message Queue" oder "MSMQ"), um die Nachrichten in eine der Warteschlangenkomponente 86 zugehörige Nachrichtenwarteschlange für Prozedur-Aufrufe 158 einzureihen. (Für weitere Details zu MSMQ siehe Microsoft Developer Network (MSDN) Library Edition – Juli 1998, SDK Documentation, Platform SDK, Networking and Distributed Services, Microsoft Message Queue Server (MSMQ).) Die Empfangseinrichtung 152 wartet darauf, daß Nachrichten an der Warteschlange 158 eintreffen, und sendet die Nachrichten, sobald sie eingetroffen sind, an die Abspieleinrichtung 154. Die Abspieleinrichtung 154 macht das Arrangieren der Prozedur-Aufrufe rückgängig und gibt die Prozedur-Aufrufe an die Warteschlangenkomponente 86 aus.
  • Diese verschiedenen, zur QC-Architektur 130 gehörigen Teile werden nachfolgend genauer beschrieben.
  • Warteschlangenkomponenten
  • Die Warteschlangenkomponente 86 in der dargestellten QC-Architektur 130 ist ein COM-Objekt, welches die oben beschriebe Struktur aufweist und in 3 dargestellt ist. Die Warteschlangenkomponente 86 ist dadurch gekennzeichnet, daß sie in einer Warteschlange angeordnete Aufrufe von Prozeduren unterstützt, indem sie den Schnittstellen der Komponente ein Attribut (das "QUEUEABLE"-Attribut) zuordnet. Der Entwickler einer Komponente weist den Schnittstellen der Komponente das "QUEUEABLE"-Attribut durch Hinzufügen eines Schnittstellenattribut-Makros (d.h. des Wortes "QUEUEABLE") zur Schnittstellensektion der Schnittstellendefinitionssprachbeschreibung der Komponentenklasse zu. Alternativ kann der Entwickler das "QUEUEABLE"-Attribut mittels des oben beschriebenen "COM+-Explorer" setzen, welcher graphische Bedienelemente in Objekteigenschaftfenstern ("sheet dialogs") zum Setzen der den Objekten in der dargestellten Ausführungsumgebung 80 zugewiesenen Attribute bereitstellt. In einigen erfindungsgemäßen Ausführungsformen kann das "QUEUEABLE"-Attribut in einem Katalog 165, einer Registrierdatenbank des Betriebssystems oder einer anderen, mit dem Betriebssystem oder der spezifischen Anwendungssoftware assoziierten Konfigurationsdatenbank gespeichert sein.
  • Einige Attribute werden außerdem mit der COM+-Anwendung assoziiert, in welche die Warteschlangenkomponente 86 gepackt ist. Ein "Queued App"-Attribut zeigt an, ob die Objekte der COM+-Anwendung über in einer Warteschlange angeordnete Aufrufe von Prozeduren aufgerufen werden können. Ein "Queue Listener"-Attribut zeigt an, ob die COM+-Anwendung eine Warteschlangen-Empfangseinrichtung, wie beispielsweise die Empfangseinrichtung 152 (2), starten sollte. Ebenso umfaßt ein "Queue BLOB"-Attribut MSMQ-Namen (als GUID-Formatnamen (GUID = global eindeutiger Identifikator) einer Menge von der COM+-Anwendung zugeordneten Warteschlangen. ("BLOB" ist ein Akronym für "Binary Large Object" (binäres großes Objekt)). In der dargestellten Architektur 130 sind die "Queued App"- und die "Queue Listener"-Attribute als Boolesche Marken gespeichert, die "on" oder "off" gesetzt werden können. Das "Queue BLOB"-Marken speichert MSMQ-Namen von fünf verschiedenen Warteschlangen. Das "Queued App"-Attribut und das "Queue Listener"-Attribut können von einem Anwendungsintegrator mittels eines COM+-Explorer-Werkzeugs, welches Kontrollkästchen-Elemente zum Setzen der "Queued App"- und "Queued Listener"-Attribute in einem COM+-Anwendungs-Eigenschaftsfenster bereitstellt, betrachtet und gekennzeichnet werden. Wenn die "Queued App"- und "Queue Listener"-Attribute auf "on" gesetzt wurden, generiert das Programm als Reaktion darauf das "Queue BLOB"-Attribut.
  • Wenn die COM+-Anwendung erstmalig erstellt wird, werden die "Queued App"- und "Queue Listener"-Attribute auf "off" gesetzt und das "Queue BLOB"-Attribut ist nicht vorhanden.
  • Wenn das "Queued App"-Attribut auf "on" gesetzt wird (z.B. durch Auswählen eines Kontrollkästchens im COM+-Explorer), initiiert der COM+-Explorer eine API-Funktion in den COM+-Laufzeitdiensten, die eine Menge von MSMQ-Warteschlangen für die COM+-Anwendung erstellt und deren MSMQ-Namen im "Queue BLOB"-Attribut speichert. Zusätzlich werden sowohl das "Queued App"- als auch das "Queue Listener"-Attribut auf "on" gesetzt. Der Anwendungsintegrator hat dann die Möglichkeit, die Kontrollkästchen eines dieser Attribute im COM+-Explorer zu deaktivieren, um die Attribute auf "off" zu setzen. Das bedeutet, daß die COM+-Anwendung nur Echtzeit-Prozedur-Aufrufe nutzen soll, obwohl sie ein Objekt enthält, das eine Warteschlangenkomponente sein kann.
  • In der dargestellten QC-Architektur 130 werden die Schnittstellen der Warteschlangenkomponente vom Entwickler direkt mit dem "QUEUEABLE"-Attribut gekennzeichnet. Ein COM-Objekt gilt als eine in einer Warteschlange anordbare Komponente, wenn es mindestens eine als "QUEUEABLE" gekennzeichnete Schnittstelle besitzt. Befindet sich das Objekt in einer als eine "Queued App" gekennzeichneten COM+ Anwendung, gilt es als Warteschlangenkomponente. Allerdings kann die Komponente in alternativen Ausführungsformen der Erfindung auch selbst mit dem "QUEUEABLE"-Attribut gekennzeichnet werden. Alle Schnittstellen der gekennzeichneten Komponente, deren Prozeduren nur [in]-Parameter besitzen, würden dann als "QUEUEABLE" gelten.
  • Aktivierung einer Warteschlangenkomponente
  • Wie oben beschrieben, erstellt der Client 132 die Warteschlangenkomponente 86 unter Nutzung normaler COM-Aufrufsemantik, die auch für Echtzeit-Prozedur-Aufrufe genutzt wird. Genauer gesagt, erstellt der Client in der dargestellten QC-Architektur 130 die Warteschlangenkomponente 86 in einem Aufruf an die "CoGetObject()"-API (oder an die äquivalente "GetObject-"-API entsprechend der Programmiersprachensemantik von Visual Basic oder Visual Java), die eine gewöhnliche Objektinstanziierungs-API von COM ist. Der Client legt fest, daß die zu erstellende Warteschlangenkomponente mit in einer Warteschlange angeordneten Prozedur-Aufrufen genutzt wird, indem er "queue:/new" und anschließend die Programm-ID oder den Zeichenketten-GUID (Global eindeutiger Identifikator) der Warteschlangenkomponente als "displayname"-Parameter des "CoGetObject()"-API-Aufrufs festlegt. Als Reaktion darauf parst die "CoGetObject()"-API diese Zeichenkette in einen neuen Moniker ("new"-Moniker) und einen Warteschlangen-Moniker ("queue"-Moniker), welche die "CoGetObject()"-API anschließend veranlaßt, sich an die Warteschlangenkomponente zu binden. Der neue Moniker führt, wie auch die "CoCreatelnstance()"-API, die Verarbeitung zur Erstellung einer Instanz des Serverobjekts durch. Der Warteschlangen-Moniker führt die Verarbeitung zum Vorbereiten der in 4 dargestellten Aufzeichnungseinrichtung aus, damit der Client die in einer Warteschlange angeordneten Aufrufe von Prozeduren für die Warteschlangenkomponente nutzen kann.
  • In alternativen Ausführungsformen kann der Client die Warteschlangenkomponente 86 erstellen, ohne in einer Warteschlange angeordnete Aufrufe von Prozeduren in der Instanziierungsanforderung explizit festzulegen, wenn die Warteschlangenkomponente die geeigneten Attribute aufweist (d.h. das mit seinen Schnittstellen oder Klasse verbundene QUEUEABLE-Attribut). Der Client fordert einfach die Erstellung der Warteschlangenkomponenten-Instanz über die "CoGetObject()"- oder die "CoCreatelnstance()"-API an, und diese erstellen anschließend das Objekt als eine auf diesem Attribut basierende Warteschlangenkomponente.
  • Beispielhafte Objekt-Instanziierungsaufrufe sind in einer Programmliste 159 in 7 dargestellt.
  • Aufzeichnungseinrichtung
  • Unter genauerer Bezugnahme auf 4 ist die Aufzeichnungseinrichtung 130 in der dargestellten QC-Architektur 150 ein in einer COM+-DLL bereitgestelltes COM-Objekt. Die DLL der Aufzeichnungseinrichtung wird mit Hilfe eines Setup-Programms in ein COM+- bezogenes Verzeichnis auf dem Computer 20, wie beispielsweise "d:.\Program Files\Microsoft\COM+", installiert. Die Installation veranlaßt außerdem die DLL der Aufzeichnungseinrichtung, sich selbst zu registrieren, was das Speichern von die Aufzeichnungseinrichtung 150 identifizierenden Konfigurationsinformationen (wie beispielsweise des Klassenidentifikators, des DLL-Pfadnamens, von Attributen usw.) im Katalog oder einer anderen Konfigurationsdatenbank umfaßt.
  • In der dargestellten QC-Architektur umfaßt das Proxy-Objekt 160 eine als Proxy-Manager handelnde Aufzeichnungseinrichtung 150. Die Aufzeichnungseinrichtung steuert einen oder mehrere Schnittstellenproxies 166 und 167, die eine Implementierung der Schnittstellen 87 der Warteschlangenkomponente 86 bereitstellen, um stellvertretend für die Warteschlangenkomponente 86 im Client-Prozeß 134 zu handeln und Aufrufe von Prozeduren des Clients 132 auf die Warteschlangenkomponente als direkte Aufrufe an die Proxy-Schnittstellen zu empfangen. Die Generierung der Schnittstellenproxies 166–167 erfolgt gemäß der Standard-Marshaling-Architektur des Microsoft COM RPC (d.h. sie werden aus Microsoft Schnittstellendefinitionssprachbeschreibungen(Microsoft Interface Definition Language)(MIDL))-Beschreibungen) der Warteschlangenkomponente 86 generiert) oder gemäß dem Marshaler der Microsoft Automation Type Bibliothek. (Für eine umfangreichere und detailliertere Erörterung des Microsoft COM RPC siehe Brockschmidt: "Inside OLE", 2. Auflage, 277–338 (Microsoft Press 1995)).
  • Genauer gesagt implementiert die als Proxy-Manager fungierende Aufzeichnungseinrichtung 150 eine "IUnknown"-Schnittstelle 162. Wie im vorstehenden Abschnitt über Komponentenanwendungsobjekte beschrieben, fordert der Client 132 einen Schnittstellenzeiger an, indem er in einem Aufruf an die "Querylnterface()"-Prozedur der "IUnknown"-Schnittstelle 162 einen Schnittstellenidentifikator (IID) der Schnittstelle festlegt. Unter der Voraussetzung, daß die festgelegte IID Teil einer in einem Katalog 165 (2) aufgeführten unveränderlichen IID-Gruppe ist, lädt und aggregiert die Aufzeichnungseinrichtung 150 einen Schnittstellen-Proxy 166–167 (mitunter auch als „Facelet" bezeichnet), der von einem MIDL-Übersetzer der Standard-Marshaling-Architektur generiert ist, um eine Proxy-Schnittstelle 168–169 für die entsprechende Schnittstelle der Warteschlangenkomponente, deren IID im Aufruf des Clients festgelegt ist, zu implementieren. Die Proxy-Schnittstellen 168–169 stimmen mit den Schnittstellen der Warteschlangenkomponente überein, welche abschließend instanziiert wird, um die in einer Warteschlange angeordneten Aufrufe von Prozeduren zu empfangen.
  • Die Aufzeichnungseinrichtung 150 implementiert außerdem eine "IRpcChannelBuffer"-Schnittstelle 170 und eine "IObjectControl"-Schnittstelle 172. Die "IObjectControl"-Schnittstelle 172 ist eine Schnittstelle, die über den Microsoft Transaktionsserver (MTS) definiert und von der Aufzeichnungseinrichtung 150 genutzt wird, um Benachrichtigungen über die Deaktivierung eines Objekts gemäß der "Just-In-Time"-Aktivierungsfunktion von MTS (die in COM+ integriert ist) zu empfangen. Die "IRpcChannelBuffer"-Schnittstelle ist eine in der COM RPC Standard Marshaling-Architektur definierte Schnittstelle.
  • Die Schnittstellenproxies 166–167 werden vom MIDL-Übersetzer generiert, um die Prozeduraufrufe des Clients mit geeigneten Aufruf-Parametern und entsprechenden Daten aus dem Speicher des Client-Prozesses 134 in einen Puffer zu arrangieren. Entsprechend der Standard Marshaling-Architektur des Microsoft COM RPC nutzen die Schnittstellenproxies 166–167 die "IRpcChannelBuffer"-Schnittstelle 170 (die eine in der Standard-Marshaling Architektur definierte Standard-COM-Schnittstelle ist), um den Puffer an den ASP 90 der Warteschlangenkomponente zu übertragen. Statt allerdings den Prozedur-Aufruf über einen Echtzeit-RPC zu übertragen, zeichnet die Implementierung der "IRpcChannelBuffer"-Schnittstelle 170 in der Aufzeichnungseinrichtung 150 alle Prozeduraufrufe des Clients auf die Warteschlangenkomponente 86 (im Gegensatz zu den Aufrufen an die Prozeduren der "IUnknown"-Schnittstelle) in einem fortlaufenden Puffer auf. Die Aufzeichnungseinrichtung implementiert diese "IUnknown"-Prozeduren lokal und zeichnet somit diese Prozedur-Aufrufe im Puffer auf.
  • Nachdem der Client die Nutzung der Warteschlangenkomponente abgeschlossen hat (d.h., der Client gibt seinen Verweis an die Warteschlangenkomponente frei), leitet der MSQM-Ressourcen-Dispenser 176 den Puffer der Prozedur-Aufrufe an MSMQ weiter. Nach dem erfolgreichen Abschluß der Transaktion des Clients sendet MSMQ den die aufgezeichneten Prozedur-Aufrufe enthaltenden fortlaufenden Puffer als eine Nachricht an die Nachrichtenwarteschlange 158 der COM+-Anwendung, welche die Warteschlangenkomponente 86 enthält. Wird die Transaktion des Clients hingegen abgebrochen, verwirft der MSMQ den Puffer, sendet die Nachricht nicht, und die aufgezeichneten Prozedur-Aufrufe werden gelöscht. (In einigen Fällen, in denen ein Abbruch der Transaktion droht, leitet der MSMQ-Ressourcen-Dispenser den Puffer ganz einfach nicht an MSMQ weiter, da der Puffer bei einem Prozeß-Abbruch ohnehin verworfen würde.) Der MSMQ-Ressourcen-Dispenser 176 weist eine Schnittstelle 178 auf, um die Anfrage der Aufzeichnungseinrichtung zum Senden des gepufferten Prozedur-Aufrufs an die Nachrichtenwarteschlange zu empfangen. Der MSMQ-Ressourcen-Dispenser 176 stellt einen Cache von offenen MSMQ-Warteschlangen bereit und nutzt MSMQ-APIs, um den Puffer der Prozedur-Aufrufe über MSMQ an die Nachrichtenwarteschlange 158 zu senden.
  • Empfangseinrichtung
  • Unter erneuter Bezugnahme auf 2 ist die Empfangseinrichtung 152 ein von COM+ bereitgestelltes Objekt, das die die Warteschlangenkomponente 86 enthaltende Nachrichtenwarteschlange 158 der COM+-Anwendung überwacht. Die Empfangseinrichtung 152 wird beim Starten der COM+-Anwendung erstellt, wenn die COM+-Anwendung die in ihrem "Queue BLOB"-Attribut festgelegte Nachrichtenwarteschlange aufweist und die Nachrichtenwarteschlangen-Empfangseinrichtung auf "on" gesetzt ist. Die Empfangseinrichtung 152 öffnet die Nachrichtenwarteschlange 158 der COM+-Anwendung. und wartet auf den Eingang von Nachrichten. Sobald Nachrichten eingehen, fertigt die Empfangseinrichtung 152 einen Aktivitätsträger (Thread) ab, um eine Instanz der Abspieleinrichtung 154, welche die Nachrichten aufnimmt und verarbeitet, auszuführen. In der dargestellten QC-Architektur 130 ist eine einzelne Empfangseinrichtung 152 pro ASP 90 gezeigt.
  • Beim Starten der Empfangseinrichtung 152 kann die Nachrichtenwarteschlange 158 möglicherweise eine große Menge an Nachrichten von in einer Warteschlange angeordneten Aufrufen von Prozeduren mehrerer Clients 132 enthalten. Darüber hinaus kann die Empfangseinrichtung 152 verschiedene Nachrichtenwarteschlangen für COM+-Anwendungen im ASP 90 überwachen. Die Empfangseinrichtung 152 nutzt dagegen vorzugsweise einen Thread-Pool von geringerer Größe, von welchem die Threads der Abspieleinrichtung so verteilt werden, daß der Nachrichtenverarbeitungsdurchsatz maximiert wird. Die geringe Menge der Threads verhindert eine Überlastung des Prozessors des Server-Computers. Da ferner die in einer Warteschlange angeordneten Aufrufe von Prozeduren keine Echtzeit-Antwort erfordern, besteht nicht die Notwendigkeit, neue Threads für die in einer Warteschlange angeordneten Nachrichten sofort zu planen. Alternativ kann das Sammeln von Objektinstanzen der Warteschlangenkomponente mit einer nach oben und unten beschränkten Anzahl von gesammelten Objekten genutzt werden, um eine Überlastung zu verhindern. Bei mehreren Nachrichtenwarteschlangen verteilt die Empfangseinrichtung 152 die Abfertigung der Threads der Abspieleinrichtung vorzugsweise angemessen auf die Warteschlangen, so daß die Nachrichten einer Warteschlange noch nicht vollständig abgefertigt sind, bevor die Abfertigung an einer anderen Schlange beginnt.
  • Abspieleinrichtung
  • Wie in 5 dargestellt, ist die Abspieleinrichtung 154 in ein in einer COM+-Utility-Bibliothek (ebenfalls eine DLL-Datei im COM+-Verzeichnis) bereitgestelltes COM-Objekt implementiert. Wie oben beschrieben, wird die Abspieleinrichtung 154 im ASP 90 der Empfangseinrichtung durch die Empfangseinrichtung 152 erstellt und aufgerufen, wenn eine Nachricht mit Prozeduraufrufen für die Warteschlangenkomponente 86 eingeht. Die Abspieleinrichtung 154 hat ein auf "Transaktion angefordert" gesetztes Transaktionsattribut- Set. Dieses veranlaßt die COM+-Ausführungsumgebung 80, automatisch eine Transaktion zu starten, im Zuge welcher die Abspieleinrichtung gemäß der in obengenannter Patentanmeldung für Automatische Transaktionen beschriebenen Automatischen Transaktionsarchitektur erstellt wird. Die von der Abspieleinrichtung 154 an die Warteschlangenkomponente 86 wieder abgespielten Prozedur-Aufrufe werden außerdem automatisch mit dieser Transaktion in Beziehung gesetzt.
  • Nach der Erstellung ruft die Abspieleinrichtung 154 in der Empfangseinrichtung 152 Routinen auf, um die in einer Warteschlange angeordnete Nachricht, welche Prozedur-Aufrufe auf die Warteschlangenkomponente 86 enthält, abzurufen. Die Abspieleinrichtung 154 holt zunächst einen Puffer und nutzt anschließend die Routinen der Empfangseinrichtung, um die Nachrichten über eine "MQReceiveMessage"-API-Operation (ein Standard-MSMQ-API-Verfahren) in den Puffer zu laden. Die "MQReceiveMessage"-API-Operation wurde zum Teil der Transaktion der Abspieleinrichtung gemacht.
  • Danach instanziiert die Abspieleinrichtung 154 die Warteschlangenkomponente 86 im ASP 90 und fungiert als ein Stub-Manager in einem Stub-Objekt 180, der Schnittstellen-Stubs 182–183 steuert, die entsprechend der Standard Marshaling Architektur des Microsoft COM RPC (d. h. aus den Microsoft Schnittstellendefinitionssprachbeschreibungen (MIDL-Beschreibungen) der Warteschlangenkomponente 86) oder entsprechend dem Marshaler der Microsoft Automation Type Library generiert sind. Als Stub-Manager lädt die Abspieleinrichtung 154 die (mitunter auch als "Stublets" bezeichneten) Schnittstellen-Stubs 182–183 für die Schnittstelle 87 der Warteschlangenkomponente, sobald deren entsprechende Schnittstellenidentifikatoren (IIDs) in der Nachricht auftreten. Die Abspieleinrichtung 154 nutzt die Stublets 182–183, um das Arrangieren der Prozedur-Aufruf-Daten aus der Nachricht rückgängig zu machen und die rückumgewandelten Prozedur-Aufrufe an die Warteschlangenkomponente 86 auszugeben. Die Abspieleinrichtung 154 interpretiert außerdem von der Aufzeichnungseinrichtung 150 eingegebene Sicherheitsköpfe durch Aufrufen der geeigneten Sicherheitsdienste.
  • Ständige Server-seitige Abbrüche
  • Die Empfangseinrichtung 152 und die Abspieleinrichtung 154 kooperieren, um "vergiftete Nachrichten" oder "ständige Server-seitige Abbrüche" zu behandeln. (Eine "vergiftete Nachricht" ist im gegebenen Kontext eine Nachricht, die Prozedur-Aufrufe umfaßt, die ständig zu Transaktionsabbrüchen führen, wenn sie an die Warteschlangenkomponente wieder abgespielt werden). Genauer gesagt wird, wenn es beim Wiederabspielen einer Gruppe von Prozedur-Aufrufen an die Warteschlangenkomponente 86 zu einem Abbruch der Transaktion der Abspieleinrichtung kommt, die Arbeit der Warteschlangenkomponente wiederholt. Der Transaktionsabbruch bewirkt zudem, daß MSMQ als Teil seiner Verarbeitung des Transaktionsabbruchs die Prozedur-Aufruf-Nachricht zurück in die Nachrichtenwarteschlange 158 der COM+-Anwendung für einen Wiederholungslauf verschiebt. In der dargestellten QC-Architektur 130 bricht die Abspieleinrichtung 154 die Transaktion bei Empfang eines einen Fehler oder einen Ausfall anzeigenden Rückgabewerts (z. B. eines HRESULT-Fehlerwerts) von der Warteschlangenkomponente 86 ab. Falls die Verarbeitung eines Prozedur-Aufrufs in der Warteschlangenkomponente einen Abbruch gewährleistet, kann die Warteschlangenkomponente 86 außerdem die "SetAbort()"-Prozedur (wie in der obengenannten Patentanmeldung für Automatische Transaktionen beschrieben) aufrufen, um die Transaktion abzubrechen.
  • In der dargestellten QC-Architektur 130 sind fünf der COM+-Anwendung zugewiesene Nachrichtenwarteschlangen gezeigt, und zwar eine normale Eingabewarteschlange, eine erste Wiederholungswarteschlange, eine zweite Wiederholungswarteschlange, eine dritte Wiederholungswarteschlange und eine Endablage-Warteschlange. Die QC-Architektur nutzt diese Warteschlangen zur Behandlung von ständigen Server-seitigen Abbrüchen. Insbesondere durchläuft die QC-Architektur 130, falls das Wiederabspielen der Prozedur-Aufrufe an die Warteschlangenkomponente 86 mehrmals zu einem Transaktionsabbruch führt, folgende Schritte: (1) die Abspieleinrichtung 154 empfängt die Prozedur-Aufruf-Nachricht von der Warteschlange der COM+-Anwendung; (2) die Abspieleinrichtung 154 instanziiert die Warteschlangenkomponente 86 und spielt die Prozedur-Aufrufe an die Warteschlangenkomponente ab; (3) die Transaktion wird abgebrochen und wiederholt und (4) MSMQ sendet die Nachricht an den Anfang der Warteschlange der COM+-Anwendung, von welcher sie abgerufen wurde.
  • Bei nachfolgenden Abbrüchen durchlauft die Abspieleinrichtung 154 mit der „vergifteten Nachricht" die Folge der Wiederholungswarteschlangen der COM+-Anwendung. Alternative Ausführungsformen der QC-Architektur können eine andere Anzahl an Wiederholungen und Intervallen als die nachfolgend für die dargestellte Architektur beschriebenen nutzen. Insbesondere sendet die Abspieleinrichtung 154 eine nach einem Abbruch an die normale Eingabewarteschlange zurückgesandte Nachricht an die erste Wiederholungswarteschlange. Die Empfangseinrichtung 152 bedient die erste Wiederholungswarteschlange ein Mal pro Minute, bis diese abgearbeitet ist, wobei diese die Nachricht über die Abspieleinrichtung 154 in einem Intervall von etwa einer Minute an die Warteschlangenkomponente abspielt.
  • Wurde die Nachricht zum dritten Mal an die erste Wiederholungswarteschlange zurückgesandt, sendet die Abspieleinrichtung 154 die Nachricht an die zweite Wiederholungswarteschlange. Die Empfangseinrichtung 152 bedient die zweite Widerholungswarteschlange im Drei-Minuten-Takt, bis diese abgearbeitet ist. Diese wiederum spielt die Nachricht über die Abspieleinrichtung 154 in denselben Zeitabständen an die Warteschlangenkomponente 86 ab.
  • Wurde die Nachricht zum dritten Mal an die zweite Wiederholungswarteschlange zurückgesandt, sendet die Abspieleinrichtung 154 die Nachricht an die dritte Wiederholungswarteschlange. Die Empfangseinrichtung 152 bedient die dritte Wiederholungswarteschlange im Fünf-Minuten-Takt, bis diese abgearbeitet ist. Diese wiederum spielt die Nachricht über die Abspieleinrichtung 154 in denselben Zeitabständen an die Warteschlangenkomponente 86 ab.
  • Wurde die Nachricht zum fünften Mal an die dritte Wiederholungswarteschlange zurückgesandt, sendet die Abspieleinrichtung 154 die Nachricht an die Endablage-Warteschlange der COM+-Anwendung. Die Endablage-Warteschlange wird allerdings nicht von der Empfangseinrichtung 152 bedient. Die Nachricht verbleibt in der Endablage-Warteschlange, bis sie (mit Hilfe des unten beschriebenen Programms zum Verschieben von Warteschlangenkomponenten-Nachrichten) verschoben oder mittels des MSMQ-Explorers (einem Hilfsprogramm zur Steuerung von MSMQ) bereinigt wird.
  • Bei jedem Abbruch erstellt die Abspieleinrichtung 154 eine Ereignislog-Nachricht. Die Abspieleinrichtung 154 erstellt eine zusätzliche Ereignislog-Nachricht, wenn eine Nachricht aus einer Warteschlange in eine andere Warteschlange verschoben wird. Sie erstellt außerdem eine weitere Nachricht, wenn die Nachricht in die Endablage-Warteschlange verschoben wird. Die Abspieleinrichtung 154 kann die Nachricht vor dem Verschieben in eine andere Warteschlange zusätzlich so verändern, daß die Nachricht mehr Diagnoseinformation enthält.
  • Die Warteschlangenkomponente 86 kann optional einen zugeordneten Ausnahmezustandsbehandler 188 umfassen, der durch einen für die Warteschlangenkomponente 86 im Katalog 165 eingetragenen „Exception_CLSID"-Eintrag festgelegt ist. Der Ausnahmezustandsbehandler ist ein COM-Objekt, das eine „IPlaybackControl"-Schnittstelle 190 unterstützt. Wenn der Ausnahmezustandsbehandler 188 für die Warteschlangenkomponente 86 registriert wird, ruft die Abspieleinrichtung 154 zunächst die "IPlaybackControl"-Schnittstelle 190 des Ausnahmezustandsbehandlers auf, bevor sie jegliche Prozedur-Aufrufe von der Nachricht wieder abspielt. Die Warteschlangenkomponente 86 kann die "IPlaybackControl"-Schnittstelle 190 selbst bereitstellen und sich selbst als Ausnahmezustandsbehandler im "Exception_CLSID"-Eintrag festlegen. Wird kein "Exception_CLSID"-Eintrag festgelegt, sucht die Abspieleinrichtung 154 außerdem nach diesem und ruft die "IPlaybackControl"-Schnittstelle 190 an der Warteschlangenkomponente 86 zur Ausnahmebehandlung auf.
  • Die "IPlaybackControl"-Schnittstelle 190 dient dazu, den Ausnahmezustandsbehandler 188 zu informieren, daß eine Nachricht kurz davor steht, in die Endablage-Warteschlange verschoben zu werden, um so eine alternative Behandlung des ständigen Abbruchs zu ermöglichen. Der Ausnahmezustandsbehandler kann die Sammlung von Problemdiagnose-Informationen oder die Erzeugung eines Objekts oder einer Nachricht, welches bzw. welche den Client über ein konsistentes und ernstes Problem als Reaktion auf die Aufrufe der Abspieleinrichtung an diese Schnittstelle informiert, implementieren. Besitzt die Warteschlangenkomponente 86 keinen zugehörigen Ausnahmezustandsbehandler, wird die "vergiftete Nachricht" einfach in die Endablage-Wartschlange verschoben, wenn die Wiederholungen wie oben beschrieben abgearbeitet wurden. Existiert dagegen ein Ausnahmezustandsbehandler, ruft die Abspieleinrichtung 154 die Prozeduren der "IPlaybackControl"-Schnittstelle ein letztes Mal auf, bevor die Nachricht in die Endlage-Warteschlange verschoben werden würde. Führt das Wiederabspielen des Prozeduraufrufs an die Warteschlangenkomponente 86 bei diesem letzten Mal immer noch zu einem Abbruch, wird die „vergiftete Nachricht" in die Endablage-Warteschlange verschoben.
  • Auf der Client-Seite kann es andererseits vorkommen, daß MSMQ die Nachricht nicht an die Eingabewarteschlange der COM+-Anwendung weiterleiten kann. Dies kann beispielsweise der Fall sein, wenn die Warteschlangen-Zugangskontrolle verhindert, daß die Nachricht vom Client an den Server gesandt wird. In einem solchen Fall sendet MSMQ die Nachricht an eine Client-seitige "Xact Dead Letter"-Warteschlange des Warteschlangenmanagers. Die QC-Architektur 130 stellt eine Vorrichtung zur Überwachung von Warteschlangen für unzustellbare Nachrichten 194 bereit. Die Überwachungsvorrichtung 194 instanziiert den durch den "Exception_CLSID"-Katalog-Eintrag für die Warteschlangenkomponente 86 auf dem Client-Computer 92 festgelegten Ausnahmezustandsbehandler 188 und gibt einen "Querylnterface()"-Aufruf mit dem IID der "IPlaybackControl"-Schnittstelle 190 aus. Verläuft dies erfolgreich, ruft die Überwachungsvorrichtung die "IPlaybackControl::FinalClientRetry()"-Prozedur auf und spielt die Prozedur-Aufrufe von der Nachricht an die Client-seitige Implementierung der Warteschlangenkomponente 86 wieder ab. Diese Client-seitige Warteschlangenkomponente kann optional Diagnoseinformation bewahren oder Maßnahmen ergreifen, um die Wirkung einer vorangegangenen Transaktion umzukehren (auszugleichen). Wird das Wiederabspielen ausgeführt, dann wird die Nachricht aus der Warteschlange für unzustellbare Nachrichten entfernt. Wird das Wiederabspielen abgebrochen oder sind der Ausnahmezustandsbehandler 188 und die "IplaybackControl"-Schnittstelle 190 nicht verfügbar, verbleibt die Nachricht in der Warteschlange für unzustellbare Nachrichten zur manuellen Behandlung.
  • Programm zum Verschieben von Nachrichten von Warteschlangenkomponenten
  • Die QC-Architektur 130 stellt ein als „Programm zum Verschieben von Warteschlangenkomponenten" bezeichnetes Verwaltungswerkzeug bereit, das es dem Systemverwalter oder einer anderen Person ermöglicht, Nachrichten manuell aus einer Warteschlange der COM+-Anwendung in eine andere zu verschieben. Wie oben beschrieben, behandelt die QC-Architektur 130 ständige Server-seitige Abbrüche, indem sie die Nachricht in eine Endablage-Warteschlange verschiebt und so verhindert, daß die Empfangseinrichtung 152 und die Abspieleinrichtung 154 die Nachricht in einer „Endlosschleife" ununterbrochen wiederholen. In einigen Fällen läßt sich die Ursache der ständigen Abbrüche auf dem Server-Computer 84 beheben. So können Abbrüche beispielsweise dadurch hervorgerufen werden, daß eine Ressource (z. B. eine Datenbank) nicht verfügbar ist. Nach einer manuellen Berichtigung dieser Situation kann die zuvor vergiftete Nachricht mit Hilfe des Programms zum Verschieben von Nachrichten von Warteschlangenkomponenten manuell zurück in die Eingabewarteschlange der COM+-Anwendung verschoben werden, um so weitere Wiederholungen zu ermöglichen. Das Programm zum Verschieben Nachrichten von Warteschlangenkomponenten verschiebt die Nachrichten vorzugsweise als eine Transaktion, so daß keine Nachrichten verloren gehen oder dupliziert werden, falls es während des Verschiebens zu einem Fehler kommt. Das Programm zum Verschieben von Nachrichten von Warteschlangenkomponenten kann programmäßig über OLE Automation, beispielsweise unter Nutzung einer Visual Basic Script, betrieben werden.
  • Schnittstellen
  • 8 zeigt eine Programmliste 200, welche die "IPlaybackControl"-Schnittstelle 190 definiert. Wie oben beschrieben, wird diese Schnittstelle durch den Ausnahmezustandsbehandler 188 implementiert, der im Katalog 165 für die Warteschlangenkomponente 86 registriert ist, um sich an der Nicht-Standard-Behandlung von ständigen Server-seitigen Abbrüchen und Client-seitigen MSMQ-Übermittlungsfehlern zu beteiligen. Die Schnittstelle 190 umfaßt eine "FinalClientRetry()"-Prozedur und eine "Final ServerRetry()"-Prozedur.
  • Die "FinalClientRetry()"-Prozedur informiert den Ausnahmezustandsbehandler 188 auf dem Client-Computer 92 (falls dieser definiert ist), daß alle Versuche, die Nachricht über MSMQ an den Server-Computer 84 zu übermitteln, abgelehnt wurden und die Nachricht in der "Xact Dead Letter"-Warteschlange (Xact-Warteschlange für unzustellbare Nachrichten) gelandet ist. So kann es möglicherweise sein, daß die Berechtigungen der Warteschlange eine Übertragung der Nachricht an die Warteschlange nicht zulassen. Sobald Nachrichten in der "Xact Dead Letter"-Warteschlange eingehen, ruft die QC-Architektur 130 die "FinalClientRetry()"-Prozedur auf, um so den Ausnahmezustandsbehandler zu informieren. Der Ausnahmezustandsbehandler kann dann eine auf die Warteschlangenkomponentenklasse bezogene Ausnahmemaßnahme, wie beispielsweise das Aufzeichnen des Fehlers in anwendungsspezifischer Sprache oder das Senden einer Mail-Nachricht an den Endbenutzer oder Verwalter, oder sogar eine Client-seitige Kompensationsmaßnahme, wie beispielsweise das Umkehren der Wirkung einer vorangegangenen Transaktion, vornehmen. Falls der für die Warteschlangenkomponente identifizierte Ausnahmezustandsbehandler diese Schnittstelle nicht implementiert oder deren "FinalClientRetry()"-Prozedur-Aufruf ein Fehlerergebnis zurücksendet, verbleibt die Nachricht in der Xact-Warteschlange für unzustellbare Nachrichten.
  • Die "FinalServerRetry()"-Prozedur informiert den Ausnahmezustandsbehandler der Warteschlangenkomponente auf dem Server-Computer 84, daß alle Versuche, die zurückgestellte Aktivierung an die Warteschlangenkomponente wieder abzuspielen, gescheitert sind (z. B. durch einen HRESULT-Fehler oder einen Transaktionsabbruch) und daß die Nachricht dabei ist, in die Endablage-Warteschlange der COM+-Anwendung verschoben zu werden. Der Server-seitige Ausnahmezustandsbehandler kann eine auf die Warteschlangenkomponentenklasse bezogene Ausnahmemaßnahme, wie beispielsweise das Aufzeichnen des Fehlers in anwendungsspezifischer Sprache oder das Senden einer Mail-Nachricht an den Endbenutzer oder Verwalter, oder sogar eine Client-seitige Maßnahme, wie beispielsweise das Umkehren der Wirkung einer vorangegangenen Transaktion, vornehmen. Vorzugsweise sollte die Warteschlangenkomponente jede Anstrengung unternehmen, um diese Transaktion erfolgreich abzuschließen, andernfalls ist für eine Wiederverarbeitung der Nachricht ein manueller Eingriff erforderlich. Falls der für die Warteschlangenkomponenten-Klasse registrierte Ausnahmezustandsbehandler die "PlaybackControl"-Schnittstelle nicht implementiert oder die Implementierung des "FinalServerRetry()"-Aufrufs ein Fehlerergebnis zurücksendet oder die Transaktion abgebrochen wird, erfolgt die Verschiebung der Nachricht in die Endablage-Warteschlange.
  • In einer Warteschlange angeordnete Prozedur-Aufrufe enthaltende Nachricht
  • Wie aus 9 und 10 ersichtlich, weist eine die Prozedur-Aufrufe des Clients umfassende Nachricht 220, die von der Aufzeichnungseinrichtung 130 in der QC-Architektur 130 aufgezeichnet wird, ein Format auf, das in 10 dargestellt ist und Datenstrukturen nutzt, die in der in 9 dargestellten Programmliste 220 definiert sind. Gemäß diesem Nachrichtenformat umfaßt die Nachricht 220 einen Nachrichtenkopf 224 und einen Nachrichtenkörper 226. Der Nachrichtenkörper 226 umfaßt einen Behälter(container)-Abschnitt 228 und einen oder mehrere Prozedur-, Sicherheits- oder Diagnoseabschnitte 230. Die Behälter-, Prozedur-, Sicherheits- und Diagnoseabschnitte 228 und 230 beginnen mit einem geeigneten Abschnittstyp-Kopf 234, 236. Die Abschnittsköpfe 234, 236 umfassen weiterhin alle einen gemeinsamen Kopf (die "_CommonHeader"-Struktur in 9). Der Behälterabschnitt 228 besitzt einen Behälterabschnittskopf 234, wohingegen die Prozedurabschnitte jeweils einen langen oder kurzen Prozedurkopf 236 und Parameterdaten 238 umfassen.
  • Der Nachrichtenkopf 224 enthält eine Menge an entweder von der Aufzeichnungseinrichtung oder von MSMQ gesetzten Nachrichteneigenschaften, die mit dem Nachrichtenkörper übermittelt werden. Diese Nachrichteneigenschaften umfassen eine Priorität, eine Nachrichten-ID, eine Korrelations-ID, einen MSMQ-Pfadnamen und einen Antwortwarteschlangennamen. Die Priorität ist ein Wert, der gesetzt werden kann, um die Reihenfolge zu bestimmen, in welcher die Nachrichten von der Eingabewarteschlange der COM+-Anwendung wieder abgespielt werden. Ein höherer Prioritätswert kann von der Client-Anwendung zugewiesen werden, damit bestimmte Operationen bevorzugt verarbeitet werden, wie beispielsweise bei einer Bankanwendung die Bevorzugung der Autorisierung von Kreditkarten vor der Verarbeitung von Schecks. Die Nachrichten-ID identifizert die einzelne Nachricht. Die Korrelations-ID wird in der QC-Architektur 130 genutzt, um eine Menge von in einer Warteschlange angeordnete Prozedur-Aufrufe enthaltenden Nachrichten in einem Arbeitsfluß zu gruppieren. Die ursprüngliche Nachricht, die den Arbeitsfluß beginnt, erstellt eine Nachricht mit einer nicht vorhandenen Korrelations-ID. Die Nachrichten-ID der ursprünglichen Nachricht wird zur Korrelations-ID aller innerhalb des Arbeitsflusses nachfolgenden Nachrichten. Der MSMQ-Pfadname besteht aus dem Namen eines Zielcomputers, einem linksseitigen Schrägstrich (d.h. "\") und einem Namen einer Warteschlange auf dem Bestimmungscomputer, z.B. "MachineName\payroll". Ein Punkt als Maschinenname kennzeichnet "diesen Computer", d.h. den Client-Computer. Der Name der Antwortwarteschlange kennzeichnet eine Warteschlange für Antwortnachrichten vom Server-Computer.
  • Der (in der Programmliste 206 von 9 durch die Strukturdeklaration "_CommonHeader" definierte) gemeinsame Kopf 232, 233 in jedem der Abschnitte 228, 230 umfaßt zwei Werte, und zwar einen Typ und eine Länge. Der Typwert identifiziert, wie in der nachstehenden Tabelle gezeigt, den Typ des Abschnitts. Der Längenwert bezieht sich auf die Länge des Abschnittkopfs und dessen Inhalte. Folglich wird durch das Hinzufügen der Länge an einen Zeiger auf den aktuellen "_CommonHeader" zum nächsten "_CommonHeader" übergegangen.
    Tabelle 1. Abschnittstypen-Feld
    Abschnittstyp Feldwert
    Behälter "CHDR"
    Prozedur "METH"
    Kurzprozedur "SMTH"
    Sicherheit "SECD"
    Sicherheitsverweis "SECR"
    Diagnose "DIAG"
  • Der Behälter-Abschnitt 228 umfaßt einen Behälter-Kopf 234. Wie durch die "_ContainerHeader"-Strukturdeklaration in 9 definiert, umfaßt der Behälter-Kopf 234 eine GUID-Signatur, Versionsnummern und einen Moniker zur Erstellung des Server-Objekts. Die GUID-Signatur ("guidSignature") identifiziert die Nachricht als eine Nachricht von einer Aufzeichnungseinrichtung an eine Abspieleinrichtung in der QC-Architektur 130. Unterschiedliche GUID-Signatur-Werte können genutzt werden, um verschiedene Abspieleinrichtungs-Klassen zu identifizieren. Der Moniker ist eine Streamform eines COM-Monikers zur Erstellung der Warteschlangenkomponente 86. In alternativen Architekturen kann der Behälter-Kopf zusätzliche Werte umfassen, wie beispielsweise eine Nachrichtenprotokollversionsnummer und Client-seitige Version-Identifikatoren.
  • Der (in den Strukturdeklarationen "_ShortMethodheader" und "_MethodHeader" in 9 definierte) Prozedur-Kopf 236 stellt einen Prozedur-Aufruf auf die Warteschlangenkomponente 86 dar. Der Prozedur-Kopf kann ein langer oder ein kurzer Kopf sein, wobei der Unterschied darin besteht, daß der lange Prozedur-Kopf einen Schnittstellenidentifikator (IID) festlegt. Der IID für den kurzen Prozedur-Kopf wird vom neuesten langen Prozedur-Kopf, der in einem Links-Nach-Rechts-Durchlauf der gesamten Nachricht aufgetreten ist, impliziert. Der Prozedur-Kopf 236 umfaßt einen Prozedur-Identifikator, eine Datenrepräsentation, ein Markierungsfeld, eine Länge, eine Unterbrechungsmarkierung und einen IID (für einen langen Prozedur-Kopf). Der Prozedur-Identifikator ("dwMethodld") ist ein Index der Tabelle 104 der virtuellen Funktionen (3) der aufzurufenden Prozedur. Die Datenrepräsentation umfaßt den "RPCOLEDATREP"-Wert von einer "RPCOLEMESSAGE" gemäß der Vereinbarung der Standard Marshaling Architektur von COM RPC, der einer der durch den Schnittstellenproxy 166–167 an die "IRPCChannelBuffer"-Schnittstelle 170 der Aufzeichnungseinrichtung 150 während des Arrangierens des Prozedur-Aufrufs (4) gemäß der Vereinbarung der Standard Marshaling-Architektur von COM RPC dargestellten Parameter ist. Das Markierungsfeld umfaßt das "RPCOLEMESSAGE rpcFlags"-Feld gemäß der Vereinbarung der Standard Marshaling-Architektur von COM RPC, das auch von den Schnittstellenproxies an die Aufzeichnungseinrichtung 150 während des Arrangierens des Prozedur-Aufrufs dargestellt wird. Das Längenfeld umfaßt das "RPCOLEMESSAGE cbBuffer"-Feld gemäß Vereinbarung der Standard Marshaling-Architektur von COM RPC, das auch durch die Schnittstellenproxies an die Aufzeichnungseinrichtung 150 während des Arrangierens des Prozedur-Aufrufs dargestellt wird. Die Unterbrechungsmarkierung umfaßt entweder 0 oder 1, um die verwendete Arrangier-Prozedur anzuzeigen. Eine 0 bedeutet, daß ein MDL-generierter Schnittstellenproxy genutzt wurde. Der IID in einem langen Prozedur-Kopf zeigt die Schnittstelle derjenigen Warteschlangenkomponente 86 an, deren Prozedur aufgerufen wurde.
  • Die Parameterdaten 238 im Prozedur-Abschnitt sind die vom Schnittstellenproxy 166–167 des Prozedur-Aufrufs erzeugten, arrangierten Parameterdaten.
  • Der Nachrichtenkörper 226 kann außerdem Sicherheitskopf-Abschnitte, Sicherheitsverweis-Abschnitte und Diagnoseabschnitte umfassen, wie sie im Abschnittstyp des gemeinsamen Kopfs des Abschnitts identifiziert sind (die Werte sind in obenstehender Tabelle 1 abgebildet). Ein Sicherheitskopf-Abschnitt umfaßt einen Sicherheitskopf entsprechend der "_SecurityHeader"-Datenstrukturdeklaration von 9. Ein Sicherheitskopf-Abschnitt umfaßt an der Aufzeichnungseinrichtung extrahierte Sicherheitsinformation, die zur Überprüfung des Zugangsprivilegs beim Wiederabspielen von Prozeduraufrufen genutzt wird. Diese Sicherheitsinformationen können sich von Prozedur zu Prozedur unterscheiden. Der Sicherheitsverweis-Abschnitt umfaßt einen Sicherheitsverweiskopf, der auf einen vorherigen Sicherheitskopf-Abschnitt in der Nachricht verweist, um eine Wiederholung der Sicherheitsinformationen zu vermeiden, wenn dieselben Sicherheitsinformationen einen nachfolgenden Prozedur-Aufruf in der Nachricht betreffen. Der Diagnose-Abschnitt besteht aus Daten, die an den Nachrichtenkörper angefügt werden, wenn die Nachricht nach einem Server-seitigen Abbruch zwischen Warteschlangen der COM+-Anwendung verschoben wird. Die Diagnosedaten können beispielsweise die Zeit und die Ursache für den Fehler umfassen. Die Diagnose-Abschnitte werden von der Abspieleinrichtung 154 während des Wiederabspielens der Nachricht ignoriert, können allerdings zur Vereinfachung eines manuellen Eingriffs genutzt werden (z.B. nachdem die Nachricht in der Endablage-Warteschlange der COM+-Anwendung eingeht).
  • Nachdem Prinzipien unserer Erfindung unter Bezugnahme auf eine dargestellte Ausführungsform beschrieben und dargestellt wurden, ist festzuhalten, daß die dargestellte Ausführungsform hinsichtlich ihrer Gestaltung und Details geändert werden kann, ohne daß sie von diesen Prinzipien abweicht. Es versteht sich, daß, sofern nichts Anderweitiges angegeben ist, die vorstehend beschrieben Programme, Prozesse oder Verfahren sich weder auf einen bestimmten Typ einer Computervorrichtung beziehen noch auf einen solchen beschränkt sind. Verschiedene Computervorrichtungstypen für allgemeine oder spezielle Anwendungen können in Verbindung mit der vorstehend beschriebenen Lehre genutzt werden oder dieser entsprechende Operationen ausführen. Bestandteile der dargestellten, in Software abgebildeten Ausführungsform können in Hardware implementiert werden und umgekehrt.
  • Angesichts der zahlreichen möglichen Ausführungsformen, auf welche sich die Prinzipien unserer Erfindung anwenden lassen, ist festzuhalten, daß die dargelegten Ausführungsformen lediglich illustrativen Charakter besitzen und nicht als den Umfang unserer Erfindung einschränkend zu betrachten sind. Vielmehr beanspruchen wir als unsere Erfindung jedwede Ausführungsformen, die in den Bereich der nachfolgenden Ansprüche fallen, sowie diesbezügliche Äquivalente.

Claims (15)

  1. Objektlaufzeitdienste-System (130) in einem verteilten Computernetzwerk zum Laufenlassen von Objekten (86) auf einem Computer, wobei die Objekte auf objektseitigen Computer Schnittstellen (87) mit Prozeduren zum Aufrufen durch Clients (132) auf Client-seitigen Computer in dem verteilten Computernetzwerk aufweisen, wobei ein mit den Objektschnittstellen (87) verbundenes Attribut das Objekt als in einer Wartschlange angeordnete Aufrufe von Prozeduren unterstützend identifiziert, wobei das System umfaßt: eine Referenz zur Verwendung durch einen Client (132) auf einem Client-seitigen Computer zum asynchronen Aufrufen von Prozeduren eines Objekts; eine Aufzeichnungseinrichtung (150) auf einem Client-seitigen Computer, die betreibbar ist, um als ein Proxy zu fungieren und stellvertretend für das Objekt (86) zu handeln und Aufrufe von Prozeduren des Clients für das Objekt als direkte Aufrufe zum stellvertretenden Handeln für Schnittstellen zu empfangen, wodurch eine Unterbrechung einer Vielzahl von Aufrufen von Prozeduren bewirkt wird, die in einer ersten Transaktion durch einen Client (132) abgegeben wurden, um Prozeduren eines Objekts (86) auf einem Objekt-seitigen Computer aufzurufen, und die Aufrufe von Prozeduren als eine Nachricht aufzuzeichnen; eine Nachrichtenwarteschlange (158) zum Einreihen der Nachricht zu einem späteren Zeitpunkt, wobei die Nachricht bei erfolgreichem Abschluß der ersten Transaktion an die Nachrichtenwarteschlange übergeben wird; und eine Abspieleinrichtung (154) auf dem Objekt-seitigen Computer, die betreibbar ist, um die Aufrufe von Prozeduren aus der Nachricht zu extrahieren und die Aufrufe von Prozeduren an das Objekt zu einem späteren Zeitpunkt in einer zweiten Transaktion auszugeben.
  2. System nach einem vorangehenden Anspruch, dadurch gekennzeichnet, daß die Aufzeichnungseinrichtung (150) bewirkt, daß eine Datenstromdarstellung (230) der Vielzahl von Aufrufen von Prozeduren in einer Prozeduraufrufnachricht zur Eingabe in die Nachrichtenwarteschlange (158) arrangiert wird.
  3. System nach einem vorangehenden Anspruch, dadurch gekennzeichnet, daß die Abspieleinrichtung (154) als Antwort auf Empfangen einer Datenstromdarstellung der Vielzahl von Aufrufen von Prozeduren in einer Nachricht das Arrangieren der Datenstromdarstellung rückgängig macht und die Aufrufe von Prozeduren an die Objektklasseninstanz (86) ausgibt.
  4. System nach einem vorangehenden Anspruch, ferner umfassend: einen Objektkonfigurationsspeicher (165), der Informationen über Objekteigenschaften enthält, die Eigenschaften von in dem System ausführbaren Objektklassen repräsentieren, wobei die Informationen über Objekteigenschaften angeben, welche Objektklassen in einer Warteschlange angeordnete Aufrufe von Prozeduren unterstützen.
  5. System nach Anspruch 4, ferner umfassend: eine Einrichtung (150, 160) zur Aufzeichnung von Aufrufen von Prozeduren, die betreibbar ist, um besagte Aufzeichnungseinrichtungen (150) für Objektinstanzen von Objektklassen bereitzustellen, die zum Unterstützen von in einer Warteschlange angeordneten Aufrufen von Prozeduren vorgesehen sind.
  6. System nach einem vorangehenden Anspruch, ferner umfassend: eine Einrichtung (154, 180) zur Widergabe von Aufrufen von Prozeduren, die betreibbar ist, um genannte Abspieleinrichtungen (154) für Objektinstanzen von Objektklassen bereitzustellen, die zum Unterstützen von in einer Warteschlange angeordneten Aufrufen von Prozeduren vorgesehen sind.
  7. System nach einem vorangehenden Anspruch, dadurch gekennzeichnet, daß die Aufzeichnungseinrichtung bei Abschluß der Transaktion die Nachricht an die Programmierschnittstelle für Nachrichtenwarteschlangenbildungsanwendungen übergibt.
  8. System nach Anspruch 7, dadurch gekennzeichnet, daß die Abspieleinrichtung die Aufrufe von Prozeduren an das Objekt in einer separaten Transaktion ausgibt.
  9. System nach einem vorangehenden Anspruch, dadurch gekennzeichnet, daß die Aufzeichnungseinrichtung die Nachricht an die Programmierschnittstelle für Nachrichtenwarteschlangenbildungsanwendungen übergibt, nachdem der Client eine Referenz zu dem Objekt freigibt.
  10. Verfahren zum asynchronen Remoting von Aufrufen von Prozeduren eines Client-Programms (132) auf einem Client-seitigen Computer an ein Objekt (86) auf einem Objekt-seitigen Computer über eine Nachrichtenwarteschlange (158), in Computer in einem verteilten Computernetzwerk (86, 92), wobei das Verfahren umfaßt: Bereitstellen einer Referenz zur Verwendung durch einen Client (132) auf einem Client-seitigen Computer zum asynchronen Aufrufen von Prozeduren eines Objekts (86); als Antwort auf die Ausgabe eines Satzes von Aufrufen von Prozeduren für das Objekt in einer ersten Transaktion eines Clients: Empfangen von Aufrufen von Prozeduren des Clients an dem Objekt als direkte Aufrufe an Proxy-Schnittstellen, wodurch der Satz von Aufrufen von Prozeduren unterbrochen wird, und Aufzeichnen der Aufrufe von Prozeduren des Satzes in einer Nachricht; Eingabe der Nachricht in eine mit dem Objekt verbundene Nachrichtenwarteschlange; Einreihen der Nachricht zu einem späteren Zeitpunkt, wobei die Nachricht bei erfolgreichem Abschluß der ersten Transaktion in die Nachrichtenwarteschlange eingereiht wird; und Extrahieren der Aufrufe von Prozeduren aus der Nachricht; und Ausgeben der Aufrufe von Prozeduren an das Objekt auf dem Objekt-seitigen Computer zum späteren Zeitpunkt in einer zweiten Transaktion.
  11. Computerprogramm mit computerlesbaren Codes, die geeignet sind, um alle Schritte von Anspruch 10 durchzuführen, wenn das Programm auf einem Computer läuft.
  12. Computerprogramm nach Anspruch 11, ferner umfassend: eine Aufzeichnungskonstruktionseinrichtung, die eine Aufzeichnungseinrichtung als Antwort auf eine Anforderung einer Referenz zu einem Objekt (86) eines Clients (132) erzeugt.
  13. Computerprogramm nach Anspruch 11 oder 12, dadurch gekennzeichnet, daß die Aufzeichnungseinrichtung Daten der Aufrufe von Prozeduren in einem Datenstrom einer Nachricht arrangiert und die Nachricht in eine mit dem Objekt verbundene Warteschlange eingibt.
  14. Computerprogramm nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, daß die Abspieleinrichtungsextraktion Rückgängigmachen des Arrangierens des Datenstroms in der Nachricht umfaßt.
  15. Computerprogramm nach einem der Ansprüche 11 bis 14, verkörpert in einem computerlesbaren Medium.
DE69936627T 1998-08-17 1999-08-17 In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen Expired - Lifetime DE69936627T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/135,378 US6425017B1 (en) 1998-08-17 1998-08-17 Queued method invocations on distributed component applications
US135378 1998-08-17
PCT/US1999/018749 WO2000010080A1 (en) 1998-08-17 1999-08-17 Queued method invocations on distributed component applications

Publications (2)

Publication Number Publication Date
DE69936627D1 DE69936627D1 (de) 2007-09-06
DE69936627T2 true DE69936627T2 (de) 2008-05-21

Family

ID=22467835

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69936627T Expired - Lifetime DE69936627T2 (de) 1998-08-17 1999-08-17 In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen

Country Status (5)

Country Link
US (1) US6425017B1 (de)
EP (1) EP1025493B1 (de)
JP (2) JP2002522843A (de)
DE (1) DE69936627T2 (de)
WO (1) WO2000010080A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016006111A1 (de) 2016-05-18 2017-11-23 John Philipp de Graaff Die vorliegende Erfindung bezieht sich auf ein Verfahren das universell angelegt, mehrere Formen von Warteschlangen für Daten (Queues) zu einer verbindet. So kann derselbe Datenraum für mehrere Queues genutzt werden, vorzugsweise für eine Ein- und Ausgabe-Queue und dabei ein FIFO- bzw. eine wahlfreie Ausgabe-Verhalten annehmen

Families Citing this family (167)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6742050B1 (en) * 1997-03-31 2004-05-25 Intel Corporation Inter-object messaging
US6453334B1 (en) 1997-06-16 2002-09-17 Streamtheory, Inc. Method and apparatus to allow remotely located computer programs and/or data to be accessed on a local computer in a secure, time-limited manner, with persistent caching
JP3508513B2 (ja) * 1997-11-07 2004-03-22 株式会社日立製作所 計算機システムの運用管理方法
WO1999035571A2 (de) * 1998-01-02 1999-07-15 Acos International Limited Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
GB2340267B (en) * 1998-07-31 2003-02-05 Sony Uk Ltd Data storage in ole stystems
JP2000090027A (ja) * 1998-09-10 2000-03-31 Fujitsu Ltd オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体
US20040154027A1 (en) * 1998-10-14 2004-08-05 Jean-Jacques Vandewalle Method and means for managing communications between local and remote objects in an object oriented client server system in which a client application invokes a local object as a proxy for a remote object on the server
US6829770B1 (en) 1999-02-23 2004-12-07 Microsoft Corporation Object connectivity through loosely coupled publish and subscribe events
DE19910535A1 (de) * 1999-03-09 2000-09-14 Siemens Ag Verfahren zur automatischen Wiedergewinnung von Engineeringdaten aus Anlagen
FR2792435B1 (fr) * 1999-04-15 2001-07-13 Cit Alcatel Procede de modification d'un protocole entre objets distribues
US6804818B1 (en) * 1999-04-29 2004-10-12 International Business Machines Corporation Integration mechanism for object-oriented software and message-oriented software
US6687831B1 (en) * 1999-04-29 2004-02-03 International Business Machines Corporation Method and apparatus for multiple security service enablement in a data processing system
JP3690720B2 (ja) * 1999-09-14 2005-08-31 インターナショナル・ビジネス・マシーンズ・コーポレーション クライアントサーバーシステム、オブジェクトのプール方法および記憶媒体
US6654782B1 (en) * 1999-10-28 2003-11-25 Networks Associates, Inc. Modular framework for dynamically processing network events using action sets in a distributed computing environment
US6920636B1 (en) * 1999-12-15 2005-07-19 Microsoft Corporation Queued component interface passing for results outflow from queued method invocations
US6970849B1 (en) 1999-12-17 2005-11-29 Microsoft Corporation Inter-server communication using request with encrypted parameter
US6996720B1 (en) 1999-12-17 2006-02-07 Microsoft Corporation System and method for accessing protected content in a rights-management architecture
US7047411B1 (en) 1999-12-17 2006-05-16 Microsoft Corporation Server for an electronic distribution system and method of operating same
CA2293062A1 (en) * 1999-12-22 2001-06-22 Ibm Canada Limited-Ibm Canada Limitee Efficient use of domain socket pairs in communication for tightly coupled transactions
US7415662B2 (en) 2000-01-31 2008-08-19 Adobe Systems Incorporated Digital media management apparatus and methods
US20020087546A1 (en) * 2000-01-31 2002-07-04 Michael Slater Apparatus, methods, and systems for digital photo management
US6973498B1 (en) 2000-03-23 2005-12-06 Microsoft Corporation Local queue creation security
WO2001073551A2 (en) * 2000-03-29 2001-10-04 Nextset Software Inc. System and method of providing an asynchronous interface between a client system and an enterprise javabeans-enabled server
US8073994B2 (en) 2000-05-03 2011-12-06 At&T Laboratories Data transfer, synchronising applications, and low latency networks
US6891953B1 (en) * 2000-06-27 2005-05-10 Microsoft Corporation Method and system for binding enhanced software features to a persona
US7017189B1 (en) * 2000-06-27 2006-03-21 Microsoft Corporation System and method for activating a rendering device in a multi-level rights-management architecture
US7158953B1 (en) * 2000-06-27 2007-01-02 Microsoft Corporation Method and system for limiting the use of user-specific software features
US6981262B1 (en) 2000-06-27 2005-12-27 Microsoft Corporation System and method for client interaction in a multi-level rights-management architecture
US7539875B1 (en) 2000-06-27 2009-05-26 Microsoft Corporation Secure repository with layers of tamper resistance and system and method for providing same
US7051200B1 (en) 2000-06-27 2006-05-23 Microsoft Corporation System and method for interfacing a software process to secure repositories
US7171692B1 (en) * 2000-06-27 2007-01-30 Microsoft Corporation Asynchronous communication within a server arrangement
US20020046045A1 (en) * 2000-06-30 2002-04-18 Attila Narin Architecture for an electronic shopping service integratable with a software application
US7225159B2 (en) * 2000-06-30 2007-05-29 Microsoft Corporation Method for authenticating and securing integrated bookstore entries
FI20001617A (fi) * 2000-07-06 2002-01-07 Nokia Mobile Phones Ltd Tiedonsiirtomenetelmõ ja -jõrjestely
US7096252B1 (en) * 2000-10-05 2006-08-22 Stmicroelectronics, Inc. System and method for interfacing network station subsystems
US7062567B2 (en) 2000-11-06 2006-06-13 Endeavors Technology, Inc. Intelligent network streaming and execution system for conventionally coded applications
US8831995B2 (en) 2000-11-06 2014-09-09 Numecent Holdings, Inc. Optimized server for streamed applications
US20020078251A1 (en) * 2000-12-18 2002-06-20 Philips Electronics North America Corp. Self-determining command path architecture
US7272833B2 (en) * 2000-12-26 2007-09-18 International Business Machines Corporation Messaging service in a federated content management system
US7188342B2 (en) * 2001-04-20 2007-03-06 Microsoft Corporation Server controlled branding of client software deployed over computer networks
US7296032B1 (en) 2001-05-17 2007-11-13 Fotiva, Inc. Digital media organization and access
US6971001B1 (en) * 2001-05-17 2005-11-29 Accenture Global Services Gmbh General and reusable components for defining net-centric application program architectures
US20020174169A1 (en) * 2001-05-21 2002-11-21 Schmid Hans Albrecht Process for operating a distributed computer network comprising several distributed computers
US20020188764A1 (en) * 2001-05-25 2002-12-12 Sun Microsystems, Inc. Method and apparatus for asynchronous component invocation
GB2378536B (en) * 2001-08-09 2005-12-21 Ibm A method of logging message activity
CA2354990A1 (en) * 2001-08-10 2003-02-10 Ibm Canada Limited-Ibm Canada Limitee Method and apparatus for fine dining queuing
AU2003235637A1 (en) * 2002-01-16 2003-07-30 Sap Aktiengesellschaft Proxy framework
US7096249B2 (en) * 2002-03-29 2006-08-22 Intel Corporation Method and system for distributing applications
US7216349B2 (en) * 2002-06-05 2007-05-08 International Business Machines Corporation System and method for triggering message queue applications
GB0215808D0 (en) * 2002-07-09 2002-08-14 Ibm A system and method for managing transactions in a messaging system
US20040260947A1 (en) * 2002-10-21 2004-12-23 Brady Gerard Anthony Methods and systems for analyzing security events
GB0225733D0 (en) * 2002-11-05 2002-12-11 Ibm Persistent messaging in a transaction processing environment
US7376957B1 (en) 2002-12-16 2008-05-20 At&T Delaware Intellectual Property, Inc. Method and system for recovering stranded outbound messages
US7200676B2 (en) 2003-03-26 2007-04-03 Microsoft Corporation Transmitting and receiving messages through a customizable communication channel and programming model
US20040249674A1 (en) * 2003-05-06 2004-12-09 Eisenberg Floyd P. Personnel and process management system suitable for healthcare and other fields
US7673307B2 (en) * 2003-05-29 2010-03-02 International Business Machines Corporation Managing transactions in a messaging system
US20040249853A1 (en) * 2003-06-05 2004-12-09 Microsoft Corporation Late bound subscription based event dispatching system and method
US7293254B2 (en) * 2003-09-18 2007-11-06 Microsoft Corporation Extensibility application programming interface and framework for meta-model objects
US7636733B1 (en) 2003-10-03 2009-12-22 Adobe Systems Incorporated Time-based image management
US20050097046A1 (en) 2003-10-30 2005-05-05 Singfield Joy S. Wireless electronic check deposit scanning and cashing machine with web-based online account cash management computer application system
US7730501B2 (en) * 2003-11-19 2010-06-01 Intel Corporation Method for parallel processing of events within multiple event contexts maintaining ordered mutual exclusion
US7613778B2 (en) * 2004-04-12 2009-11-03 Microsoft Corporation Progressive de-featuring of electronic messages
US7165118B2 (en) * 2004-08-15 2007-01-16 Microsoft Corporation Layered message processing model
US20060053035A1 (en) * 2004-09-09 2006-03-09 Eisenberg Floyd P Healthcare personnel management system
US7681181B2 (en) * 2004-09-30 2010-03-16 Microsoft Corporation Method, system, and apparatus for providing custom product support for a software program based upon states of program execution instability
WO2006042314A2 (en) * 2004-10-12 2006-04-20 Inventigo, Llc Methods and apparatus for message oriented invocation
JP2008527468A (ja) 2004-11-13 2008-07-24 ストリーム セオリー，インコーポレイテッド ハイブリッド・ローカル／リモート・ストリーミング
US7467389B2 (en) * 2004-11-23 2008-12-16 Sybase, Inc. System and methodology providing service invocation for occasionally connected computing devices
GB0427798D0 (en) * 2004-12-18 2005-01-19 Ibm Publish/subscribe messaging system
US7502843B2 (en) * 2004-12-30 2009-03-10 Microsoft Corporation Server queuing system and method
US7882236B2 (en) * 2005-02-04 2011-02-01 Microsoft Corporation Communication channel model
US7886295B2 (en) * 2005-02-17 2011-02-08 International Business Machines Corporation Connection manager, method, system and program product for centrally managing computer applications
US20060200705A1 (en) * 2005-03-07 2006-09-07 International Business Machines Corporation Method, system and program product for monitoring a heartbeat of a computer application
US8024523B2 (en) 2007-11-07 2011-09-20 Endeavors Technologies, Inc. Opportunistic block transmission with time constraints
US9716609B2 (en) 2005-03-23 2017-07-25 Numecent Holdings, Inc. System and method for tracking changes to files in streaming applications
US7900209B2 (en) * 2005-04-22 2011-03-01 Inventigo, Llc Methods and apparatus for message oriented invocation
US7634542B1 (en) * 2005-07-01 2009-12-15 Sprint Communications Company L.P. System and method to manage service instances for request processing
US7823170B2 (en) * 2005-08-31 2010-10-26 Sap Ag Queued asynchronous remote function call dependency management
US7827152B1 (en) 2005-10-26 2010-11-02 Oracle America, Inc. Asynchronous on-demand service startup
US7467388B2 (en) * 2005-11-22 2008-12-16 Microsoft Corporation Monitoring message queues and starting processing applications
US8261345B2 (en) 2006-10-23 2012-09-04 Endeavors Technologies, Inc. Rule-based application access management
US7876949B1 (en) 2006-10-31 2011-01-25 United Services Automobile Association Systems and methods for remote deposit of checks
US8799147B1 (en) 2006-10-31 2014-08-05 United Services Automobile Association (Usaa) Systems and methods for remote deposit of negotiable instruments with non-payee institutions
US7885451B1 (en) 2006-10-31 2011-02-08 United Services Automobile Association (Usaa) Systems and methods for displaying negotiable instruments derived from various sources
US7873200B1 (en) 2006-10-31 2011-01-18 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US8351677B1 (en) 2006-10-31 2013-01-08 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US8708227B1 (en) 2006-10-31 2014-04-29 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US10380559B1 (en) 2007-03-15 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for check representment prevention
US8959033B1 (en) 2007-03-15 2015-02-17 United Services Automobile Association (Usaa) Systems and methods for verification of remotely deposited checks
US8538124B1 (en) 2007-05-10 2013-09-17 United Services Auto Association (USAA) Systems and methods for real-time validation of check image quality
US8433127B1 (en) 2007-05-10 2013-04-30 United Services Automobile Association (Usaa) Systems and methods for real-time validation of check image quality
US9009292B2 (en) * 2007-07-30 2015-04-14 Sybase, Inc. Context-based data pre-fetching and notification for mobile applications
US8204870B2 (en) * 2007-08-03 2012-06-19 Sybase, Inc. Unwired enterprise platform
US9058512B1 (en) 2007-09-28 2015-06-16 United Services Automobile Association (Usaa) Systems and methods for digital signature detection
US9159101B1 (en) 2007-10-23 2015-10-13 United Services Automobile Association (Usaa) Image processing
US8358826B1 (en) 2007-10-23 2013-01-22 United Services Automobile Association (Usaa) Systems and methods for receiving and orienting an image of one or more checks
US9898778B1 (en) 2007-10-23 2018-02-20 United Services Automobile Association (Usaa) Systems and methods for obtaining an image of a check to be deposited
US9892454B1 (en) 2007-10-23 2018-02-13 United Services Automobile Association (Usaa) Systems and methods for obtaining an image of a check to be deposited
US7996316B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association Systems and methods to modify a negotiable instrument
US7996314B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US7996315B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8046301B1 (en) 2007-10-30 2011-10-25 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8001051B1 (en) 2007-10-30 2011-08-16 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8290237B1 (en) 2007-10-31 2012-10-16 United Services Automobile Association (Usaa) Systems and methods to use a digital camera to remotely deposit a negotiable instrument
US8320657B1 (en) 2007-10-31 2012-11-27 United Services Automobile Association (Usaa) Systems and methods to use a digital camera to remotely deposit a negotiable instrument
US7900822B1 (en) 2007-11-06 2011-03-08 United Services Automobile Association (Usaa) Systems, methods, and apparatus for receiving images of one or more checks
US7896232B1 (en) 2007-11-06 2011-03-01 United Services Automobile Association (Usaa) Systems, methods, and apparatus for receiving images of one or more checks
US8892738B2 (en) 2007-11-07 2014-11-18 Numecent Holdings, Inc. Deriving component statistics for a stream enabled application
US9021503B2 (en) 2007-11-16 2015-04-28 Microsoft Technology Licensing, Llc Coordinating application state and communication medium state
US8505030B2 (en) * 2007-11-16 2013-08-06 Microsoft Corporation Coordinating resources using a volatile network intermediary
US8719841B2 (en) * 2007-11-16 2014-05-06 Microsoft Corporation Dispatch mechanism for coordinating application and communication medium state
US20090198496A1 (en) * 2008-01-31 2009-08-06 Matthias Denecke Aspect oriented programmable dialogue manager and apparatus operated thereby
US10380562B1 (en) 2008-02-07 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for mobile deposit of negotiable instruments
US8286198B2 (en) * 2008-06-06 2012-10-09 Apple Inc. Application programming interfaces for data parallel computing on multiple processors
US8351678B1 (en) 2008-06-11 2013-01-08 United Services Automobile Association (Usaa) Duplicate check detection
US8422758B1 (en) 2008-09-02 2013-04-16 United Services Automobile Association (Usaa) Systems and methods of check re-presentment deterrent
US10504185B1 (en) 2008-09-08 2019-12-10 United Services Automobile Association (Usaa) Systems and methods for live video financial deposit
US7962411B1 (en) 2008-09-30 2011-06-14 United Services Automobile Association (Usaa) Atomic deposit transaction
US8275710B1 (en) 2008-09-30 2012-09-25 United Services Automobile Association (Usaa) Systems and methods for automatic bill pay enrollment
US7885880B1 (en) * 2008-09-30 2011-02-08 United Services Automobile Association (Usaa) Atomic deposit transaction
US7974899B1 (en) 2008-09-30 2011-07-05 United Services Automobile Association (Usaa) Atomic deposit transaction
US8391599B1 (en) 2008-10-17 2013-03-05 United Services Automobile Association (Usaa) Systems and methods for adaptive binarization of an image
US7949587B1 (en) 2008-10-24 2011-05-24 United States Automobile Association (USAA) Systems and methods for financial deposits by electronic message
US7970677B1 (en) 2008-10-24 2011-06-28 United Services Automobile Association (Usaa) Systems and methods for financial deposits by electronic message
US8806611B2 (en) * 2008-12-02 2014-08-12 At&T Intellectual Property I, L.P. Message administration system
US8452689B1 (en) 2009-02-18 2013-05-28 United Services Automobile Association (Usaa) Systems and methods of check detection
US10956728B1 (en) 2009-03-04 2021-03-23 United Services Automobile Association (Usaa) Systems and methods of check processing with background removal
US20100287565A1 (en) * 2009-05-11 2010-11-11 International Business Machines Corporation Method for managing requests associated with a message destination
US8301706B2 (en) 2009-06-15 2012-10-30 Microsoft Corporation Routing of pooled messages via an intermediary
US8542921B1 (en) 2009-07-27 2013-09-24 United Services Automobile Association (Usaa) Systems and methods for remote deposit of negotiable instrument using brightness correction
US9779392B1 (en) 2009-08-19 2017-10-03 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a publishing and subscribing platform of depositing negotiable instruments
US8977571B1 (en) 2009-08-21 2015-03-10 United Services Automobile Association (Usaa) Systems and methods for image monitoring of check during mobile deposit
US8699779B1 (en) 2009-08-28 2014-04-15 United Services Automobile Association (Usaa) Systems and methods for alignment of check during mobile deposit
US9361165B2 (en) * 2009-12-03 2016-06-07 International Business Machines Corporation Automated merger of logically associated messages in a message queue
US9940670B2 (en) * 2009-12-10 2018-04-10 Royal Bank Of Canada Synchronized processing of data by networked computing resources
US20110154289A1 (en) * 2009-12-18 2011-06-23 Sandya Srivilliputtur Mannarswamy Optimization of an application program
US20110173591A1 (en) * 2010-01-13 2011-07-14 Target Brands, Inc. Unit Test Generator
US8661454B2 (en) * 2010-01-26 2014-02-25 Target Brands, Inc. System and method for receiving and transmitting event information
US8549538B2 (en) * 2010-03-18 2013-10-01 Microsoft Corporation Coordinating communication medium state for subtasks
US8250234B2 (en) 2010-04-26 2012-08-21 Microsoft Corporation Hierarchically disassembling messages
US8566800B2 (en) * 2010-05-11 2013-10-22 Ca, Inc. Detection of method calls to streamline diagnosis of custom code through dynamic instrumentation
US9129340B1 (en) 2010-06-08 2015-09-08 United Services Automobile Association (Usaa) Apparatuses, methods and systems for remote deposit capture with enhanced image detection
US10380565B1 (en) 2012-01-05 2019-08-13 United Services Automobile Association (Usaa) System and method for storefront bank deposits
US9104404B2 (en) * 2012-05-07 2015-08-11 Oracle International Corporation System and method for supporting a deferred reference to an object in an objected-oriented programming language environment
US11663628B2 (en) 2012-05-14 2023-05-30 Iqzone, Inc. Systems and methods for unobtrusively displaying media content on portable devices
US11599907B2 (en) 2012-05-14 2023-03-07 Iqzone, Inc. Displaying media content on portable devices based upon user interface state transitions
US8924252B2 (en) * 2012-05-14 2014-12-30 Iqzone, Inc. Systems and methods for providing timely advertising to portable devices
US10552810B1 (en) 2012-12-19 2020-02-04 United Services Automobile Association (Usaa) System and method for remote deposit of financial instruments
US11138578B1 (en) 2013-09-09 2021-10-05 United Services Automobile Association (Usaa) Systems and methods for remote deposit of currency
US9286514B1 (en) 2013-10-17 2016-03-15 United Services Automobile Association (Usaa) Character count determination for a digital image
CN106104414B (zh) * 2013-11-13 2019-05-21 Twc专利信托公司 存储设备以及存储和提供数据的方法
US10402790B1 (en) 2015-05-28 2019-09-03 United Services Automobile Association (Usaa) Composing a focused document image from multiple image captures or portions of multiple image captures
US9900302B2 (en) 2016-06-22 2018-02-20 FinancialForce.com, Inc. Seamless authentication for an application development platform
US10984359B2 (en) 2016-06-23 2021-04-20 FinancialForce.com, Inc. Combining batch and queueable technologies in a salesforce platform for large volume parallel processing
US10496741B2 (en) 2016-09-21 2019-12-03 FinancialForce.com, Inc. Dynamic intermediate templates for richly formatted output
JP6104447B1 (ja) 2016-10-31 2017-03-29 株式会社ソリトンシステムズ プログラム動作監視制御装置、分散オブジェクト生成管理装置、プログラム、及びプログラム動作監視システム
US10326720B2 (en) * 2017-05-05 2019-06-18 Dell Products L.P. Messaging queue service API optimization system
US11038689B2 (en) 2018-03-01 2021-06-15 FinancialForce.com, Inc. Efficient block chain generation
US11030752B1 (en) 2018-04-27 2021-06-08 United Services Automobile Association (Usaa) System, computing device, and method for document detection
US10846481B2 (en) 2018-06-29 2020-11-24 FinancialForce.com, Inc. Method and system for bridging disparate platforms to automate a natural language interface
US11200143B2 (en) 2019-01-08 2021-12-14 FinancialForce.com, Inc. Software development framework for a cloud computing platform
US10922485B2 (en) 2019-07-10 2021-02-16 FinancialForce.com, Inc. Platform interpretation of user input converted into standardized input
US11736776B2 (en) 2019-10-25 2023-08-22 Iqzone, Inc. Monitoring operating system methods to facilitate unobtrusive display of media content on portable devices
CN112671827B (zh) * 2020-11-25 2023-03-07 紫光云技术有限公司 一种分布式事务最终一致性方法
US11900755B1 (en) 2020-11-30 2024-02-13 United Services Automobile Association (Usaa) System, computing device, and method for document detection and deposit processing
US11741050B2 (en) 2021-01-29 2023-08-29 Salesforce, Inc. Cloud storage class-based variable cache availability
CN114936031B (zh) * 2022-07-22 2022-11-11 浙江中控技术股份有限公司 组件的调用方法及电子设备

Family Cites Families (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4677576A (en) 1983-06-27 1987-06-30 Grumman Aerospace Corporation Non-edge computer image generation system
US4635208A (en) 1985-01-18 1987-01-06 Hewlett-Packard Company Computer-aided design of systems
US4800488A (en) 1985-11-12 1989-01-24 American Telephone And Telegraph Company, At&T Bell Laboratories Method of propagating resource information in a computer network
US4821220A (en) 1986-07-25 1989-04-11 Tektronix, Inc. System for animating program operation and displaying time-based relationships
US5210874A (en) 1988-03-22 1993-05-11 Digital Equipment Corporation Cross-domain call system in a capability based digital data processing system
US4953080A (en) 1988-04-25 1990-08-28 Hewlett-Packard Company Object management facility for maintaining data in a computer system
AU601328B2 (en) 1988-05-26 1990-09-06 Digital Equipment Corporation Temporary state preservation for a distributed file service
US4972437A (en) 1988-06-24 1990-11-20 International Business Machines Corporation Method of controlling limited resource sessions in a data communications network
US5133075A (en) 1988-12-19 1992-07-21 Hewlett-Packard Company Method of monitoring changes in attribute values of object in an object-oriented database
US5125091A (en) 1989-06-08 1992-06-23 Hazox Corporation Object oriented control of real-time processing
US5430876A (en) 1989-06-27 1995-07-04 Digital Equipment Corporation Remote procedure callback system and method
US5297283A (en) 1989-06-29 1994-03-22 Digital Equipment Corporation Object transferring system and method in an object based computer operating system
DE69029441T2 (de) 1989-08-24 1997-06-12 Ibm System für den Aufruf von Prozeduren von einem Fernnetzwerkknotenpunkt
US5301280A (en) 1989-10-02 1994-04-05 Data General Corporation Capability based communication protocol
US5093914A (en) 1989-12-15 1992-03-03 At&T Bell Laboratories Method of controlling the execution of object-oriented programs
US5168441A (en) 1990-05-30 1992-12-01 Allen-Bradley Company, Inc. Methods for set up and programming of machine and process controllers
AU628264B2 (en) 1990-08-14 1992-09-10 Oracle International Corporation Methods and apparatus for providing a client interface to an object-oriented invocation of an application
US5151987A (en) 1990-10-23 1992-09-29 International Business Machines Corporation Recovery objects in an object oriented computing environment
US5119475A (en) 1991-03-13 1992-06-02 Schlumberger Technology Corporation Object-oriented framework for menu definition
US5430850A (en) 1991-07-22 1995-07-04 Massachusetts Institute Of Technology Data processing system with synchronization coprocessor for multiple threads
US5212793A (en) 1991-09-04 1993-05-18 International Business Machines Corp. Generic initiators
AU3944793A (en) 1992-03-31 1993-11-08 Aggregate Computing, Inc. An integrated remote execution system for a heterogenous computer network environment
US5581760A (en) 1992-07-06 1996-12-03 Microsoft Corporation Method and system for referring to and binding to objects using identifier objects
US5307490A (en) 1992-08-28 1994-04-26 Tandem Computers, Inc. Method and system for implementing remote procedure calls in a distributed computer system
DE69309485T2 (de) 1992-11-13 1997-07-10 Microsoft Corp Verfahren zur verteilung von schnittstellenzeigern fur fernprozeduranrufe
WO1994014115A2 (en) 1992-12-01 1994-06-23 Microsoft Corporation A method and system for in-place interaction with embedded objects
DE69327448T2 (de) 1992-12-21 2004-03-04 Sun Microsystems, Inc., Mountain View Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
US5315703A (en) 1992-12-23 1994-05-24 Taligent, Inc. Object-oriented notification framework system
EP0613083B1 (de) 1993-02-25 2002-01-23 Sun Microsystems, Inc. Transaktionsverwaltung in objektorientiertem System
US5574862A (en) 1993-04-14 1996-11-12 Radius Inc. Multiprocessing system with distributed input/output management
US5377350A (en) 1993-04-30 1994-12-27 International Business Machines Corporation System for cooperative communication between local object managers to provide verification for the performance of remote calls by object messages
US5519867A (en) 1993-07-19 1996-05-21 Taligent, Inc. Object-oriented multitasking system
US5577252A (en) 1993-07-28 1996-11-19 Sun Microsystems, Inc. Methods and apparatus for implementing secure name servers in an object-oriented system
CA2128387C (en) 1993-08-23 1999-12-28 Daniel F. Hurley Method and apparatus for configuring computer programs from available subprograms
CA2107299C (en) 1993-09-29 1997-02-25 Mehrad Yasrebi High performance machine for switched communications in a heterogenous data processing network gateway
US5455953A (en) 1993-11-03 1995-10-03 Wang Laboratories, Inc. Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket
US5517645A (en) 1993-11-05 1996-05-14 Microsoft Corporation Method and system for interfacing components via aggregate components formed by aggregating the components each with an instance of a component manager
US5742848A (en) 1993-11-16 1998-04-21 Microsoft Corp. System for passing messages between source object and target object utilizing generic code in source object to invoke any member function of target object by executing the same instructions
US5485617A (en) 1993-12-13 1996-01-16 Microsoft Corporation Method and system for dynamically generating object connections
US5481715A (en) 1993-12-15 1996-01-02 Sun Microsystems, Inc. Method and apparatus for delegated communications in a computer system using trusted deputies
US6330582B1 (en) 1994-03-21 2001-12-11 International Business Machines Corporation Apparatus and method enabling a client to control transaction message traffic between server and client processes
US5675796A (en) 1994-04-08 1997-10-07 Microsoft Corporation Concurrency management component for use by a computer program during the transfer of a message
US5734903A (en) * 1994-05-13 1998-03-31 Apple Computer, Inc. System and method for object oriented message filtering
US5625775A (en) 1994-06-13 1997-04-29 International Business Machines Corporation Modem communication interface in a data processing system
US5504898A (en) 1994-06-20 1996-04-02 Candle Distributed Solutions, Inc. Threaded environment for AS/400
JPH08123699A (ja) * 1994-10-26 1996-05-17 Hitachi Ltd 並行処理方法、並行処理システム及び並行処理用プログラムの変換ツール
US5687370A (en) 1995-01-31 1997-11-11 Next Software, Inc. Transparent local and distributed memory management system
JPH08212180A (ja) * 1995-02-08 1996-08-20 Oki Electric Ind Co Ltd プロセス間通信処理装置
US5822585A (en) 1995-02-21 1998-10-13 Compuware Corporation System and method for cooperative processing using object-oriented framework
US5907675A (en) 1995-03-22 1999-05-25 Sun Microsystems, Inc. Methods and apparatus for managing deactivation and shutdown of a server
US5802291A (en) 1995-03-30 1998-09-01 Sun Microsystems, Inc. System and method to control and administer distributed object servers using first class distributed objects
US5689708A (en) 1995-03-31 1997-11-18 Showcase Corporation Client/server computer systems having control of client-based application programs, and application-program control means therefor
US5797015A (en) 1995-04-18 1998-08-18 Pitney Bowes Inc. Method of customizing application software in inserter systems
US5889957A (en) 1995-06-07 1999-03-30 Tandem Computers Incorporated Method and apparatus for context sensitive pathsend
JPH0916417A (ja) * 1995-06-27 1997-01-17 Hitachi Ltd メッセージ通信方法およびメッセージ通信システム
US5764958A (en) 1995-11-30 1998-06-09 International Business Machines Corporation Method and apparatus for creating dynamic roles with a system object model
US5838910A (en) 1996-03-14 1998-11-17 Domenikos; Steven D. Systems and methods for executing application programs from a memory device linked to a server at an internet site
US5857201A (en) 1996-06-18 1999-01-05 Wright Strategies, Inc. Enterprise connectivity to handheld devices
US5864669A (en) 1996-07-11 1999-01-26 Microsoft Corporation Method and system for accessing a particular instantiation of a server process
US6253252B1 (en) 1996-07-11 2001-06-26 Andrew Schofield Method and apparatus for asynchronously calling and implementing objects
US5790789A (en) 1996-08-02 1998-08-04 Suarez; Larry Method and architecture for the creation, control and deployment of services within a distributed computer environment
US5884316A (en) 1996-11-19 1999-03-16 Microsoft Corporation Implicit session context system with object state cache
US5889942A (en) 1996-12-18 1999-03-30 Orenshteyn; Alexander S. Secured system for accessing application services from a remote station
US6094688A (en) * 1997-01-08 2000-07-25 Crossworlds Software, Inc. Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
US5913061A (en) * 1997-01-08 1999-06-15 Crossroads Software, Inc. Modular application collaboration
US5933593A (en) 1997-01-22 1999-08-03 Oracle Corporation Method for writing modified data from a main memory of a computer back to a database
US5857197A (en) 1997-03-20 1999-01-05 Thought Inc. System and method for accessing data stores as objects
US5958010A (en) 1997-03-20 1999-09-28 Firstsense Software, Inc. Systems and methods for monitoring distributed applications including an interface running in an operating system kernel
US6105147A (en) 1997-04-16 2000-08-15 Compaq Computer Corporation Using process pairs as transaction-coordinated resource managers
US6026428A (en) 1997-08-13 2000-02-15 International Business Machines Corporation Object oriented thread context manager, method and computer program product for object oriented thread context management
US6061796A (en) 1997-08-26 2000-05-09 V-One Corporation Multi-access virtual private network
US6134594A (en) 1997-10-28 2000-10-17 Microsoft Corporation Multi-user, multiple tier distributed application architecture with single-user access control of middle tier objects
US5958004A (en) 1997-10-28 1999-09-28 Microsoft Corporation Disabling and enabling transaction committal in transactional application components

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016006111A1 (de) 2016-05-18 2017-11-23 John Philipp de Graaff Die vorliegende Erfindung bezieht sich auf ein Verfahren das universell angelegt, mehrere Formen von Warteschlangen für Daten (Queues) zu einer verbindet. So kann derselbe Datenraum für mehrere Queues genutzt werden, vorzugsweise für eine Ein- und Ausgabe-Queue und dabei ein FIFO- bzw. eine wahlfreie Ausgabe-Verhalten annehmen

Also Published As

Publication number Publication date
JP2002522843A (ja) 2002-07-23
EP1025493B1 (de) 2007-07-25
US6425017B1 (en) 2002-07-23
JP4528742B2 (ja) 2010-08-18
DE69936627D1 (de) 2007-09-06
JP2006260588A (ja) 2006-09-28
WO2000010080A1 (en) 2000-02-24
WO2000010080B1 (en) 2000-05-04
EP1025493A1 (de) 2000-08-09

Similar Documents

Publication Publication Date Title
DE69936627T2 (de) In einer warteschlange angeordnete aufrufe von prozeduren für verteilte auf komponenten basierte anwendungen
DE69839145T2 (de) Kompensierender Betriebsmittelverwalter
DE60126016T2 (de) Serverseitige Kontrollobjekte zur Verarbeitung von kundenseitigen Benutzerschnittstellenelementen
DE60211254T2 (de) Fernereignis Behandlung in ein Paketnetzwerk
DE69728178T2 (de) Vorrichtung und verfahren zur fernen datenrückgewinnung
DE60125705T2 (de) Vorrichtung und Verfahren zur Implementierung eines HTTP Programmstacks auf einem Client
DE69637436T2 (de) Objektorientiertes Kommunikationssystem mit Unterstützung für mehrere entfernte Maschinentypen
DE69327448T2 (de) Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
DE69734175T2 (de) Transportunabhängige Anruf- und Dienstschnittstellen, die die Marshalling von integrierten Type-Codes sowie kompilierten Code erlauben
DE602005004334T2 (de) Nms zur Verarbeitung von Multi-Server Ereignissen
DE69820566T2 (de) Verfahren, Vorrichtung, und Programmprodukt zum Zugriff auf einen Server-basierten Verwaltungsinformationsdienst
DE69832354T2 (de) Netzwerkverwaltungsrahmenwerk
DE60025043T2 (de) Vorrichtung und verfahren mit verwendung von anwendungabhängigkeitsinformation für eine sicherungskopieherstellung in einem computersystem
DE60315558T2 (de) Verteiltes Rechnersystem für Vorrichtungsresourcen basierend auf Identität
DE69936162T2 (de) Verfahren und Gerät für ein objektorientiertes Unterbrechungssystem
DE69824879T2 (de) Verteilter web- anwendungs- server
DE602004004300T2 (de) Verfahren, System und Computerprogramm für das Senden und Empfangen von Meldungen durch einen individuellen Kommunikationskanal
DE602005006391T2 (de) System und verfahren zum asynchronen kommunizieren mit web-diensten unter verwendung von nachrichtensatzdefinitionen
DE60006217T2 (de) Techniken zum gewähren des zugriffs durch eine kontextsperre in einem gerät mit kleinem platzbedarf unter verwendung von einem eingangspunktobjekt
DE60008555T2 (de) Verfahren und vorrichtung zur effizienten übertragung von daten einer interaktiven anwendung zwischen klienten und server mit hilfe einer markup-sprache
DE69922693T2 (de) Systemem und verfahren für netzwerkvorrichtung und ein-ausgabegerätetreiber
DE69734432T2 (de) Verfahren und Vorrichtung zur Absendung von Clientverfahrenanrufen in einem Server Rechnersystem
DE69815946T2 (de) Informationsverarbeitungsvorrichtung
DE60109709T2 (de) Datenverwaltungsrahmenwerk für Verfahrensverwaltung
DE19705955A1 (de) Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung

Legal Events

Date Code Title Description
8364 No opposition during term of opposition