DE602004011638T2 - Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem - Google Patents

Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem Download PDF

Info

Publication number
DE602004011638T2
DE602004011638T2 DE602004011638T DE602004011638T DE602004011638T2 DE 602004011638 T2 DE602004011638 T2 DE 602004011638T2 DE 602004011638 T DE602004011638 T DE 602004011638T DE 602004011638 T DE602004011638 T DE 602004011638T DE 602004011638 T2 DE602004011638 T2 DE 602004011638T2
Authority
DE
Germany
Prior art keywords
message
message object
streamed
handlers
pipeline
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
DE602004011638T
Other languages
English (en)
Other versions
DE602004011638D1 (de
Inventor
Eric B. Christensen
Douglas A. Walter
Michael J. Coulson
Kenneth D. Wolf
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
Publication of DE602004011638D1 publication Critical patent/DE602004011638D1/de
Application granted granted Critical
Publication of DE602004011638T2 publication Critical patent/DE602004011638T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40Business processes related to the transportation industry
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/765Media network packet handling intermediate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Health & Medical Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Image Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Multi Processors (AREA)
  • Medicines Containing Material From Animals Or Micro-Organisms (AREA)
  • Pharmaceuticals Containing Other Organic And Inorganic Compounds (AREA)
  • Preparation Of Compounds By Using Micro-Organisms (AREA)
  • Information Transfer Systems (AREA)
  • Pipeline Systems (AREA)
  • Sink And Installation For Waste Water (AREA)

Description

  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft Nachrichtenverarbeitung. Insbesondere betrifft die vorliegende Erfindung Verfahren, Systeme und Computerprogrammprodukte, die Puffererfordernisse für die Verarbeitung von Nachrichten reduzieren und daher ein Datenübertragungssystem zum Senden oder Empfangen relativ großer Nachrichten unter Verwendung einer gegebenen Puffergröße ermöglichen.
  • 2. Stand der Technik
  • Nachrichtenverarbeitung tritt in einer Vielzahl von Kontexten auf, wie unter anderem im verteilten Anwendungssupport, allgemein innerhalb von Kommunikationsprotokollen u.s.w. Eines der Probleme, die bei Nachrichtenverarbeitungssystemen laufend auftreten, betrifft die Verarbeitung von Nachrichten von unbegrenzter Größe. Herkömmliche Nachrichtenverarbeitungssysteme speichern Nachrichten einer angemessenen Größe üblicherweise in einem Puffer zwischen, große Nachrichten führen jedoch zu unkalkulierbaren und möglicherweise massiven Speichererfordernissen, wenn sie nicht zurückgewiesen werden. Groß ist dabei ein relativer Ausdruck und ist teilweise von dem Nachrichtenverarbeitungssystem selbst abhängig. Mit der Erhöhung der Netzgeschwindigkeiten hat sich jedoch auch die Nachrichtengröße erhöht, insbesondere angesichts der Beliebtheit des Austauschens von Multimediainhalten und graphischen Inhalten. Während hinsichtlich der Netzbandbreite Nachrichten von mehreren Megabytes gegebenenfalls keine großen Probleme mehr verursachen, können Nachrichten von mehreren Megabytes bei Berücksichtigung der Verarbeitungserfordernisse, wie unter anderem des Speichers und der Verarbeitungszeit, eine signifikante Belastung für Datenübertragungssysteme (messaging systems) darstellen, insbesondere wenn sie relativ regelmäßig empfangen werden.
  • Natürlich werden Computer mit stetig zunehmender Verarbeitungsleistung und verfügbarem Speicher heute kostengünstiger und mildern damit einige der durch große Nachrichten verursachten Erfordernisse hinsichtlich der Betriebsmittel. Angesichts der Weiterentwicklung der Gerätetechnik in den vergangenen Jahren kann ein Lösungsansatz in dem Erhöhen der verfügbaren Pufferspeichergröße und der Verarbeitungsgeschwindigkeit bestehen, um größere Nachrichten verarbeiten zu können. Die meisten Nachrichten sind eher vergleichsweise klein, und somit könnte eine Argumentation sein, dass gelegentliche große Nachrichten kein großes Problem darstellen.
  • Es gibt wenigstens zwei Gesichtspunkte oder Aspekte, die diese Argumentation unberücksichtigt lässt. Erstens und vor allem gilt die Prämisse, dass große Nachrichten nur gelegentlich eingehen werden. Es besteht stets die Möglichkeit, dass ein Datenübertragungssystem (messaging system) einem Dienstverweigerungsangriff ausgesetzt ist. Im Allgemeinen versucht ein Dienstverweigerungsangriff, ein Gerät mit Anforderungen zu überhäufen, so dass der empfangende Computer für die Verarbeitung mehr Zeit benötigt als der oder die sendende(n) Computer für die Erzeugung. Das Senden großer Nachrichten an ein Nachrichtenverarbeitungssystem ist ein logischer Ausgangspunkt für einen böswilligen Dienstverweigerungsangriff, und daher ist die Annahme, dass große Nachrichten nur gelegentlich empfangen werden, eine gefährliche Strategie für den Umgang mit großen Nachrichten. Zweitens arbeiten zahlreiche Nachrichtenverarbeitungssysteme gelegentlich an der Grenze ihrer Kapazität, und daher kann die Möglichkeit, dass eine große Nachricht zu einer Zeit starker Auslastung eintrifft, nicht übergangen oder vernachlässigt werden.
  • Aufgrund dieser und anderer in herkömmlichen Datenübertragungssystemen (messaging systems) anzutreffender Probleme sind Verfahren, Systeme und Computerprogrammprodukte zum Reduzieren der Puffererfordernisse bei der Verarbeitung von Nachrichten wünschenswert, so dass ein Datenübertragungssystem relativ größere Nachrichten unter Verwendung einer gegebenen Pufferspeichergröße senden oder empfangen kann.
  • WO 00/10302 betrifft einen Mikroprozessor, der ausgelegt ist, um Daten, die in einem Kopfteil (header portion) eines Datenpaketes erzeugt werden, zu lesen, zu verarbeiten und neu zu formatieren. Ein programmierbarer Header-Übersetzer (Programmable Header Translator) empfängt einen ungelösten Header-Datensatz (Unresolved Header Record), der unter anderem alle relevanten Headerfelder umfasst. Ein Headerpuffer (Header Buffer) stellt einen Pufferspeicher zur Aufnahme zeitweiliger Verkehrsspitzen und zum Speichern des ungelösten Header-Datensatzes (Unresolved Header Record) bereit, bis eine Header-Verarbeitungsmaschine (Header Processing Engine) verfügbar wird. Aus dem Headerpuffer (Header Buffer) entfernte Daten werden durch einen Header-Prozessorselektor (Header Processor Selector) in eine Header-Verarbeitungsmaschine (Header Processing Engine) geladen. Die Header-Verarbeitungsmaschine (Header Processing Engine) führt danach das notwendige Protokoll in Abhängigkeit von Algorithmen von in einem internen RAM (Direktzugriffsspeicher) gespeicherten Mikroprogramm aus.
  • US-A-2002/0118640 betrifft ein dynamisches System für die Leitwegplanung für Datenpakete durch einen Netzschalter, wodurch innerhalb des Schalters ein Weg der geringsten Latenzzeit ausgewählt wird. Um die Latenzzeit des Schaltens des Paketes zu reduzieren, nutzt der Schalter entweder Cut-Through-Routing oder frühe Weiterleitung. Cut-Through-Switching funktioniert durch Bereitstellen eines speziellen Weges geringer Latenzzeit zum Leiten eines Paketes, wenn der Zielport verfügbar ist, ohne das Paket in einem dazwischenkommenden Direktzugriffsspeicher (RAM) zu speichern. Wohingegen frühes Weiterleiten Speichern des Paketes in einem Direktzugriffsspeicher (RAM) und danach Weiterleiten des Paketes an wenigstens einen entsprechenden Ausgabeport umfasst, wobei dieser Schritt eingeleitet wird, bevor das gesamte Paket in dem Direktzugriffsspeicher (RAM) angekommen ist. Somit verwendet frühes Weiterleiten den Direktzugriffsspeicher (RAM), um eine Funktion durchzuführen, die etwas ähnlich der eines FIFO-Speichers ist. Wenn somit die ersten Bytes eines Paketes empfangen werden, kann das Paket überprüft werden (zum Beispiel der Header des Paketes), um zu bestimmen, an welchen der Schalterausgabeports das Paket weiterzuleiten ist. Der Eingabeport kann danach bestimmen, ob ein entsprechender Ausgabeport oder mehrere entsprechende Ausgabeports zur Bearbeitung des Paketes verfügbare Ressourcen haben.
  • KURZFASSUNG DER ERFINDUNG
  • Die Aufgabe der Erfindung besteht in der Reduzierung der Puffererfordernisse bei der Verarbeitung von Nachrichten und dadurch in dem Ermöglichen eines Datenübertragungssystems (messaging system) zum Senden oder Empfangen größerer Nachrichten unter Verwendung einer gegebenen Puffergröße.
  • Diese Aufgabe wird durch die Erfindung gemäß Beanspruchung in den Hauptansprüchen gelöst.
  • Bevorzugte Ausführungsbeispiele werden in den Unteransprüchen definiert.
  • Die vorliegende Erfindung betrifft Verfahren, Systeme und Computerprogrammprodukte, die die Puffererfordernisse in einem Datenübertragungssystem (messaging system) reduzieren, so dass das Datenübertragungssystem unter Verwendung einer gegebenen Puffergröße relativ größere Nachrichten senden oder empfangen kann. Gemäß Beispiel-Ausführungsformen der vorliegenden Erfindung, die weiter unten ausführlicher beschrieben werden werden, sendet ein Datenübertragungssystem Nachrichten über wenigstens einen Nachrichtentransport an einen Endpunkt oder empfängt es Nachrichten über wenigstens einen Nachrichtentransport von einem Endpunkt. Das Datenübertragungssystem kann ein dazwischenliegendes System (intermediary) zum Leiten eines Nachrichtenobjektes oder eines Endpunktes, der Nachrichten sendet und empfängt, sein.
  • In einer Beispiel-Ausführungsform wird wenigstens ein Nachrichtenhandler bereitgestellt, der eine entsprechende Verarbeitungsoperation identifiziert, die an einem Nachrichtenobjekt durchzuführen ist. Das Nachrichtenobjekt umfasst einen gestreamten Teil mit einer stromorientierten Schnittstelle. Zur Verwaltung des wenigstens einen Nachrichtenhandlers als geordnete Sammlung wird weiterhin eine Pipeline bereitgestellt. Das Nachrichtenobjekt wird durch den wenigstens einen Nachrichtenhandler in der Nachrichtenpipeline so verarbeitet, dass wenigstens ein Nachrichtenhandler den gestreamten Teil des Nachrichtenobjektes mit seiner entsprechenden Verarbeitungsoperation einkapselt. Die entsprechende Verarbeitungsoperation muss in einer zukünftigen Zeit durchgeführt werden und kapselt den gestreamten Teil des Nachrichtenobjektes ein, ohne den gestreamten Teil in einem Pufferspeicher zu materialisieren. In einigen Ausführungsbeispielen können mehrere Pipelines, einschließlich verschachtelter Pipelines, zur Verarbeitung des Nachrichtenobjektes mit verschiedenen Nachrichtenhandlern bereitgestellt werden.
  • Wenn die Pipeline eine Vielzahl von Nachrichtenhandlern umfasst, kann ein jeder der Handler den gestreamten Teil der Reihe nach so einwickeln, dass die Verarbei tungsoperationen, die den Nachrichtenhandlern entsprechen, auf dem gestreamten Teil des Nachrichtenobjektes geschichtet (layered) sind. Das Nachrichtenobjekt kann wenigstens einen Kopfteil (header portion), wenigstens einen Hauptteil (body portion) und wenigstens einen Anhangsteil umfassen, wobei wenigstens der Hauptteil (body portion) und/oder Anhangsteil im Allgemeinen den gestreamten Teil des Nachrichtenobjektes umfasst oder umfassen.
  • In Beispiel-Ausführungsformen kann das Nachrichtenobjekt zum Beispiel eine Nachricht Simple Object Access Protocol (eine SOAP-Nachricht) sein. Um eine SOAP-Nachricht zu leiten und anderweitig zu verarbeiten, können Header für die Nachricht in einem Puffer zwischengespeichert werden oder für Zugriff materialisiert werden, ohne dass der gestreamte Teil materialisiert werden muss. Das Leiten kann Duplizieren des Nachrichtenobjektes zur Übergabe an eine Vielzahl von Endpunkten umfassen.
  • Das Aufrufen des wenigstens einen Nachrichtenhandlers kann stattfinden, bevor ein Datenstrom zu dem Datenstromteil des Nachrichtenobjektes zugewiesen wird. Da der Datenstromteil nicht materialisiert werden muss, wenn die Nachrichtenhandler aufgerufen werden, können die Verarbeitungsoperationen der Nachrichtenhandler innerhalb der Pipeline für die Nachricht zuerst identifiziert werden, und danach kann der eigentliche Datenstrom, auf dem die Operationen durchgeführt werden werden, zu einem späteren Zeitpunkt zu dem Stromteil zugewiesen werden. Das Senden des Nachrichtenobjektes zu einem anderen Endpunkt oder das Empfangen des Nachrichtenobjektes von einem anderen Endpunkt kann bewirken, dass die Verarbeitungsoperationen, die den gestreamten Teil verkapseln, auf dem gestreamten Teil durchgeführt werden.
  • Zusätzliche Merkmale und Vorteile der Erfindung werden in der folgenden Beschreibung genannt werden und werden teilweise aus der Beschreibung ersichtlich sein oder können bei der praktischen Durchführung der Erfindung erlernt werden. Die Merkmale und Vorteile der Erfindung können mittels der insbesondere in den anhängenden Patentansprüchen dargelegten Geräten und Kombinationen realisiert und erzielt werden. Diese und weitere Merkmale der vorliegenden Erfindung werden aus der folgenden Beschreibung und den anhängenden Patentansprüchen umfassender erkennbar werden oder können durch die praktische Ausführung der Erfindung gemäß der folgenden Beschreibung erlernt werden.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Um die Art und Weise, auf die die oben beschriebenen und weitere Vorteile und Merkmale der Erfindung erzielt werden können, zu beschreiben, wird eine detailliertere Beschreibung der oben nur kurz beschriebenen Erfindung unter Bezugnahme auf spezifische Ausführungsbeispiele derselben, die in den anhängenden Zeichnungen veranschaulicht werden, gegeben werden. In dem Verständnis, dass diese Zeichnungen lediglich typische Ausführungsbeispiele der Erfindung darstellen und daher nicht als den Erfindungsbereich einschränkend zu verstehen sind, wird die Erfindung mit zusätzlicher Spezifität und zusätzlichem Detail durch die Nutzung der anhängenden Zeichnungen beschrieben und erläutert werden.
  • Kurze Beschreibung der Zeichnungen:
  • 1 veranschaulicht eine Beispielnachricht zur Verarbeitung durch ein Datenübertragungssystem (messaging system) gemäß der vorliegenden Erfindung.
  • 2A zeigt ein Beispiel des Auslesens eines Nachrichtenobjektes aus einem Datenstrom.
  • 2B zeigt ein Beispiel des Schreibens eines Nachrichtenobjektes in einen Datenstrom.
  • 3A veranschaulicht eine Beispiel-Pipeline zur Verarbeitung eines Nachrichtenobjektes.
  • 3B veranschaulicht ein verschachteltes Pipeline-Beispiel für Nachrichtenobjekt-Verarbeitung.
  • 4 veranschaulicht Einwickeln oder Einkapseln des gestreamten Nachrichtengehaltes eines Nachrichtenobjektes.
  • Die 5A bis 5C zeigen ein Beispiel des Leitens eines Nachrichtenobjektes.
  • 6 verschaulicht ein Beispiel des Duplizierens eines Nachrichtenobjektes, ohne den gestreamten Teil in einem Zwischenspeicher Puffern zu müssen.
  • Die 7A bis 7B zeigen Beispielhandlungen und Beispielschritte für Verfahren der Verarbeitung eines Nachrichtenobjektes, die Puffererfordernisse gemäß der vorliegenden Erfindung reduzieren; und
  • 8 veranschaulicht ein Beispielsystem, das eine geeignete Betriebsumgebung für die vorliegende Erfindung bereitstellt.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSBEISPIELE
  • Die vorliegende Erfindung erstreckt sich auf Verfahren, Systeme und Computerprogrammprodukte zum Verarbeiten eines Nachrichtenobjektes, das Puffererfordernisse für wenigstens einen Teil des Nachrichtenobjektes reduziert. Indem sie Puffererfordernisse reduziert, ermöglicht es die vorliegende Erfindung einem Datenübertragungssystem (messaging system), relativ größere Nachrichten unter Verwendung einer gegebenen Puffergröße zu senden und zu empfangen, als dies andernfalls möglich wäre. Die Ausführungsbeispiele der vorliegenden Erfindung können wenigstens einen Spezialrechner und/oder wenigstens einen Allzweckrechner umfassen, der verschiedene Rechnergeräte umfasst, wie weiter unten ausführlicher diskutiert werden wird.
  • 1 veranschaulicht ein Beispiel-Nachrichtenobjekt 100 für Verarbeitung durch ein Datenübertragungssystem (messaging system) gemäß der vorliegenden Erfindung. Eine Nachricht ist die Grundeinheit der Kommunikation zwischen Endpunkten. Das Nachrichtenobjekt 100 umfasst eine Headersammlung 110, die einen Header 112, einen Header 114, einen Header 116 und möglicherweise weitere enthält. Das Nachrichtenobjekt 100 umfasst weiterhin Inhalt 120. Wie gezeigt wird, wird die Headersammlung 110 des Nachrichtenobjektes 100 in einem Zwischenspeicher gepuffert, während der Inhalt 120 gestreamt wird. Ein Grund für die Pufferung eines Nachrichtenobjektes besteht darin, dass Header üblicherweise genutzt werden, wenn entschieden wird, was mit einer Nachricht geschehen soll, bevor dies eigentlich geschieht. Um zum Beispiel das Nachrichtenobjekt 100 zu einem geeigneten Endpunkt zu leiten, ist es üblicherweise notwendig, bestimmte Header zu prüfen. Leitweglenkung erfordert jedoch üblicherweise keine Überprüfung des Inhaltes. Dementsprechend können das Streamen des Inhaltes 120 und das Puffern der Header unter einigen Umständen der Einfachheit halber zweckmäßig sein.
  • Natürlich sind die Pufferung der Headersammlung 110 und das Streamen des Inhaltes 120 lediglich ein Beispiel des Nachrichtenaufbaus. Da Header relativ klein und recht gut definiert sind, stellen sie keine unbegrenzten Puffererfordernisse dar, die mit dem Nachrichteninhalt einhergehen. Dennoch schließt nichts in der vorliegenden Erfindung Streamen des gesamten Nachrichtenobjektes 100, einschließlich der Headersammlung 110, aus. Weiterhin muss betont werden, dass der Aufbau des Nachrichtenobjektes 100 lediglich eine von zahlreichen möglichen Anordnungen ist. Wenngleich Nachrichtenobjekte 100 oft eine separate Headersammlung 110 und Inhalt oder Hauptteil 120 umfassen werden, ist die vorliegende Erfindung nicht auf einen bestimmten Nachrichtenaufbau begrenzt, und alle Verweise auf einen bestimmten Nachrichtenaufbau sind lediglich als Beispiele zu betrachten und zu verstehen.
  • Der Aufbau des Nachrichtenobjektes 100 entspricht im Allgemeinen einer Nachricht des Typs Simple Object Access Protocol (SOAP-Nachricht). SOAP ist ein leichtes Datenübertragungsprotokoll auf Basis der eXtensible Markup Language (XML), die verwendet wird, um Daten in Webdienstanforderungen und Antwortnachrichten zu verschlüsseln, bevor diese über ein Netz gesendet werden. SOAP-Nachrichten sind für Webdienste gut geeignet, da sie von Betriebssystemen unabhängig sind und unter Verwendung verschiedener Internet-Protokolle, wie zum Beispiel das Simple Mail Transfer Protocol (SMTP), das HyperText Transfer Protocol (http), das Multipurpose Internet Mail Extensions (MIME), das Direct Internet Mail Encapsulation (DIME) u.s.w., transportiert und verschlüsselt werden können.
  • Ein Altzweck-SOAP-Nachrichten-Prozessor muss Zugriff auf wenigstens bestimmte Header haben, die in der Nachricht vorliegen, um ihre korrekte Verarbeitung zu bestimmen. Wie weiter unten ausführlicher beschrieben werden wird, kann in einer Beispiel-Ausführungsform eine Pipeline von Nachrichtenhandlern genutzt werden, um eine Nachricht zu verarbeiten. Ein jeder dieser Handler kann null oder mehr der in der Nachricht vorliegenden Header prüfen und auf diesen arbeiten. (Handler können auch den gestreamten Nachrichteninhalt prüfen und auf diesem arbeiten.) Die kombinierte Wirkung dieser Handler definiert die Verarbeitung, die die Nachricht beeinflussen wird. Nachdem der SOAP-Prozessor seine Aufgabe ausgeführt hat, gibt er die Nachricht an den Zielempfänger der Nachricht weiter.
  • Es ist jedoch zu beachten, dass der SOAP-Prozessor nicht die vollständige Nachricht in Pufferspeichern materialisieren musste, um korrekte Verarbeitung der Nachricht durchzuführen. Insbesondere muss ein SOAP-Prozessor lediglich Zugriff auf bestimmte Headerelemente und gegebenenfalls einige Hauptteilelemente haben, er muss jedoch keinen Zugriff auf andere Elemente haben. In den weiter unten beschriebenen Beispiel-Ausführungsformen können verschiedene Header einer SOAP-Nachricht gepuffert werden, wohingegen der Hauptteil einer SOAP-Nachricht nur bei Erfordernis gepuffert wird. Das Erzeugen des Hauptteiles einer SOAP-Nachricht nur bei Erfordernis wird im Wesentlichen erzielt, indem ein Verweis auf den Hauptteil weitergeleitet wird und indem es Konsumenten ermöglicht wird, die Inhalte auf Anforderung herauszuziehen.
  • In einer Beispiel-Ausführungsform weist die Nachrichten-Headersammlung 110 ein Finde-Verfahren zum Finden einzelner Header innerhalb der Headersammlung auf. Finden wird häufig von headerspezifischen Nachrichenhandlern verwendet, um den geeigneten Header abzurufen, entweder nach dem Headertyp, dem XML-Elementnamen des Headers, dem XML-Namensraum, in dem der Header definiert ist, und/oder dem Akteur/der Funktion, der oder die dem Endpunkt entspricht, für den der Header vorgesehen ist. Alle Header werden der Einfachheit halber innerhalb der Grenzen und Beschränkungen des verfügbaren Speichers in einem Zwischenspeicher gepuffert; wie jedoch weiter oben bereits ausgeführt wurde, schließt nichts in der vorliegenden Erfindung das Streamen von wenigstens einem Header aus, wenn die für eine jeweilige Implementierung geeignet oder zweckdienlich ist. Zum weiteren Schutz gegen Dienstverweigerungsangriffe kann eine Speicherquote, wie zum Beispiel 32 k-Byte, zum Puffern der Header eingerichtet werden.
  • Die 2A bis 2B zeigen Beispiele des Lesens eines Nachrichtenobjektes aus einem Datenstrom und des Schreibens eines Nachrichtenobjektes in einen Datenstrom. Die Formstierer 230A und 230B führen Konvertierung zwischen einer Datenstromdarstellung der Nachricht und der Speicher-Nachrichteninstanz durch. Wenn eine Nachricht von einem anderen Endpunkt über das Netz abgerufen wird, liest 220A der Formstierer 230A aus dem Datenstrom 210A aus und ruft 240A einen Nachrichtenhandler 250A auf, um die Nachricht zu verarbeiten. Wie weiter oben bereits beschrieben worden ist, werden die Nachrichtenhandler 250A und 250B üblicherweise wenigstens eine Pipeline von Nachrichtenhandlern sein.
  • Die 3A bis 3B veranschaulichen Beispiel-Pipelines zum Verarbeiten eines Nachrichtenobjektes. Sequentielle Ausführung der Nachrichtenhandler ist ein übliches Nachrichtenverarbeitungsmuster. Pipelines vereinfachen die Verwaltung von Asynchroncode-Nachrichtenhandlern. Eine Pipeline ist ein Nachrichtenhandler und kann an allen Orten verwendet werden, an denen ein Nachrichtenhandler verwendet werden kann. Pipelines enthalten eine geordnete Sammlung von Nachrichtenhandlern. In 3A umfasst die Pipeline 330 einen Nachrichtenhandler 332, einen Nachrichtenhandler 334 und einen Nachrichtenhandler 336. Wenn die Pipeline 330 zur Verarbeitung einer Nachricht 300 aufgerufen wird, ruft die Pipeline die einzelnen Nachrichtenhandler in ihrer Sammlung jeweils einzeln nacheinander auf, um die Nachricht zu verarbeiten. Die Wirkung, die eine Nachrichtenpipeline auf den gestreamten Inhalt hat, wird unten ausführlicher beschrieben werden.
  • Da eine Pipeline ein Nachrichtenhandler ist, können Pipelines verschachtelt sein, wie in 3B gezeigt wird. Wie weiter oben in Verbindung mit 3A beschrieben worden ist, geht die Nachricht durch einen jeden Handler in der Pipeline hindurch, wenn eine Pipeline zur Verarbeitung einer Nachricht 300 aufgerufen wird (außer wenn ein Fehler auftritt oder ein Handler entscheidet, dass die weitere Verarbeitung auszusetzen ist). Wenn einer der Handler in der Pipeline selbst eine Pipeline ist, wie in 3B gezeigt wird, geht die Nachricht durch einen jeden dieser Handler hindurch und so weiter. In 3B hat die Pipeline 330 drei Nachrichtenhandler: den Nachrichtenhandler 332, den Nachrichtenhandler 340 und den Nachrichtenhandler 336. Die Pipeline 340 hat ebenfalls drei Nachrichtenhandler: den Nachrichtenhandler 342, den Nachrichtenhandler 344 und den Nachrichtenhandler 346. Die Reihenfolge, in der die Handler aufgerufen werden, wird durch die Linie angedeutet. Wenn ein Nachrichtenhandler, wie zum Beispiel der Nachrichtenhandler 344, andeutet, dass keine weitere Nachrichtenverarbeitung auftreten dürfte, werden weder der Nachrichtenhandler 346 noch der Nachrichtenhandler 336 aufgerufen. Natürlich sind die in den 3A bis 3B veranschaulichten Pipeli nes Beispiele relativ einfacher Pipelines, und es ist zu beachten, dass weitaus kompliziertere Pipelines verwendet werden können.
  • 4 veranschaulicht das Einwickeln oder Einkapseln des gestreamten Nachrichteninhaltes eines Nachrichtenobjektes. Für gestreamten Nachrichteninhalt wickeln die Nachrichtenhandler den gestreamten Nachrichteninhalt mit der Verarbeitungsoperation des Nachrichtenhandlers ein oder kapseln die Nachrichtenhandler den gestreamten Nachrichteninhalt mit der Verarbeitungsoperation des Nachrichtenhandlers ein. Das Einwickeln oder Einkapseln tritt auf, da das Durchführen der Verarbeitungsoperation auf dem gestreamten Nachrichteninhalt an dem Punkt, an dem der Nachrichtenhandler aufgerufen wird, Puffern oder Materialisieren des gestreamten Nachrichteninhaltes erfordern würde, was den Zweck des Vorliegens des Nachrichteninhaltes als Datenstrom vereiteln würde.
  • Wie in 4A gezeigt wird, wird ein gestreamter Nachrichteninhalt 420 der Nachricht 400 mit verschiedenen Verarbeitungsoperationen eingewickelt oder eingekapselt, wenn er durch die Pipeline 410 hindurchgeht. Der Nachrichtenhandler 432 kapselt den gestreamten Nachrichteninhalt 420 in die Verarbeitungsoperation 432A ein. Der Nachrichtenhandler 434 wickelt den gestreamten Inhalt 420 und die Verarbeitungsoperation 432A in die Verarbeitungsoperation 434A ein. Schließlich kapselt der Nachrichtenhandler 436 den gestreamten Inhalt 420, die Verarbeitungsoperation 432A und die Verarbeitungsoperation 434A mit der Verarbeitungsoperation 436A ein.
  • Da diese Verarbeitungsoperationen auf dem gestreamten Inhalt schichtweise (layered) aufgelegt werden, wenn ein Konsument beginnt, auf den gestreamten Inhalt zuzugreifen, wird die geeignete Verarbeitungsoperation durchgeführt werden, geordnet wie die Nachrichtenhandler in der Pipeline 410 aufgerufen werden, ohne dass der gestreamte Inhalt materialisiert werden muss. Infolgedessen werden die Puffererfordernisse für die Verarbeitung der Nachricht 400 reduziert, was es einem Datenübertragungssystem (messaging system) ermöglicht, relativ größere Nachrichten unter Verwendung einer gegebenen Puffergröße zu senden oder zu empfangen. Wie weiter oben bereits angedeutet wurde, macht die geschichtete (layered) Verarbeitung das Datenübertragungssystem (messaging system) auch weniger empfindlich gegenüber Dienstverweigerungsangriffen auf Basis großer Nachrichten, da das Datenübertragungssystem (mes saging system) viel der erforderlichen Verarbeitung durchführen kann, ohne den Inhalt materialisieren zu müssen, was insbesondere vorteilhaft ist, wenn das Datenübertragungssystem (messaging system) eine Leitwegfunktion wie unten in Bezug auf die 5A bis 5C beschrieben durchführt. Es ist zu beachten, dass ein gewisses Puffern des gestreamten Inhaltes mit Wahrscheinlichkeit auftreten wird, da auf Datenstromteile oder Datenstromblöcke zugegriffen wird, jedoch ist dieses Puffern begrenzt, da es vielmehr auf der Datenblockgröße als auf dem gesamten Datenstrom basiert. An seinem endgültigen Bestimmungsort und dazwischenliegenden Systemen (intermediaries) kann der empfangene gestreamte Inhalt einfach auf einen anderen Datenstrom geschrieben werden, wie zum Beispiel eine Platte an dem endgültigen Bestimmungsort, oder auf einen Datenstrom für den nächsten Sprung oder die nächste Teilstrecke.
  • Zu diesem Zeitpunkt kann es hilfreich sein, die 4 in Bezug auf wenigstens zwei konkrete Beispiele zu diskutieren. Gehen wir davon aus, dass die Pipeline 410 einen gestreamten Inhalt 420 für eine zu schreibende Nachricht 400 vorbereitet. Der Nachrichenhandler 432 umfasst eine digitale Signaturoperation 432A, der Nachrichtenhandler 434 umfasst eine Verschlüsselungsoperation 434A und der Nachrichtenhandler 436 umfasst eine Kompressionsoperation 436A. Wenn die Nachricht 400 durch die Pipeline 400 hindurchgeht, werden die digitale Signaturoperation 432A, die Verschlüsselungsoperation 434A und die Kompressionsoperation 436A schichtweise (layered) auf den gestreamten Inhalt 420 abgelegt, kapseln sie diesen ein oder wickeln sie diesen ein. Wenn dementsprechend der gestreamte Inhalt 420 für den Transport geschrieben wird, stellt der gestreamte Inhalt 420 Teile oder Blöcke des Datenstroms bereit, die mit der digitalen Signaturoperation 432A digital signiert, durch die Verschlüsselungsoperation 434A verschlüsselt und mit der Kompressionsoperation 436A komprimiert werden.
  • Nehmen wir umgekehrt an, dass die Pipeline 410 den gestreamten Inhalt 420 für eine zu lesende Nachricht 400 vorbereitet. In dem Lesefall erfolgt das Ordnen der Nachrichtenhandler in der Pipeline 410 in der umgekehrten Reihenfolge zu dem obenstehenden Schreibbeispiel. Der Nachrichtenhandler 432 umfasst eine Dekompressionsoperation 432A, der Nachrichtenhandler 434 umfasst eine Entschlüsselungsoperation 434A und der Nachrichtenhandler 436 umfasst eine digitale Signaturprüfungsoperation 436A. Wenn die Nachricht 400 durch die Pipeline 400 hindurchgeht, werden die Dekompressionsoperation 432A, die Entschlüsselungsoperation 434A und die digitale Signaturprü fungsoperation 436A auf dem gestreamten Inhalt 420 schichtweise (layered) abgelegt, kapseln diesen ein oder wickeln ihn ein.
  • Wenn dementsprechend der gestreamte Inhalt 420 gelesen wird, stellt der gestreamte Inhalt 420 Teile oder Blöcke des Datenstroms bereit, die mit der Dekompressionsoperation 432A dekomprimiert werden, durch die Entschlüsselungsoperation 434A entschlüsselt werden, und die digitale Signatur wird mit der digitalen Signaturprüfungsoperation 436A geprüft. Was gelesen wird, ist daher eine dekomprimierte, entschlüsselte und auf die digitale Signatur überprüfte Version des signierten, verschlüsselten, komprimierten gestreamten Inhaltes 420. Das schichtweise Ablegen oder Einkapseln, das in der Pipeline 410 auftritt, kann als eine Reihe von Rückruffunktionen für die Objekte, die den Verarbeitungsoperationen innerhalb der einzelnen Nachrichtenhandler entsprechen, implementiert werden. Mit anderen Worten beginnen wir anfangs mit einem Datenstrom, danach macht die Dekompressionsoperation den Datenstrom zu einem dekomprimierten Datenstrom, die Entschlüsselungsoperation macht den Datenstrom zu einem entschlüsselten, dekomprimierten Datenstrom, und die digitale Signaturoperation macht den Datenstrom zu einem geprüften entschlüsselten, dekomprimierten Datenstrom, der genau das ist, was für den signierten verschlüsselten, komprimierten Datenstrom, der empfangen worden ist, erforderlich ist. Wenn die einzelnen Operationen durchgeführt werden, verfolgt das jeweilige Objekt, was die vorangegangene Operation war, um eine Kette von Rückrufen zu bilden. Dies ist lediglich eine mögliche Implementierung für das Einkapseln oder Einwickeln von Verarbeitungsoperationen – zahlreiche andere Implementierungen sind möglich und sind innerhalb des Bereiches des Einkapselns, des Einwickelns und des schichtweisen Ablegens zu berücksichtigen.
  • Die 5A bis 5C zeigen ein Beispiel des Leitens eines Nachrichtenobjektes 500. 5A ist ähnlich der 1 dahingehend, dass das Nachrichtenobjekt 500 eine Sammlung von Headern 510 umfasst, die den Header 1 512, den Header 2 514 und den Header 3 516 sowie den Hauptteil 520 beinhaltet. In 5B und wenn das Nachrichtenobjekt 500 den Router 530 erreicht, sieht sich der Router 530 die Sammlung von Headern 510 an, um zu bestimmen, wie die Nachricht geleitet werden kann. Es ist zu beachten, dass wie oben diskutiert worden ist, der Hauptteil 520 des Nachrichtenobjektes zum Leiten nicht materialisiert werden muss, sondern eingewickelt werden kann. Wie in 5C gezeigt wird, werden die Sammlung von Headern 510 und der Hauptteil 520 entsprechend geleitet. Indem der Nachrichten-Hauptteil 520 eingewickelt worden ist, kann der an dem Router 530 gelesene Datenstrom auf den geleiteten Datenstrom zurückgeschrieben werden, ohne dass er materialisiert werden muss. Daher werden die Puffererfordernisse für den Router reduziert, was ermöglicht, dass der Router 530 stabiler gegenüber Dienstverweigerungsangriffen gemacht wird.
  • 6 veranschaulicht des Duplizierens eines Nachrichtenobjektes, ohne dass der gestreamte Teil gepuffert werden muss, zum Beispiel beim Senden eines Nachrichtenobjektes zu mehreren Zielen. Eine der Auswirkungen, ein datenstrombasiertes Modell zu haben, besteht darin, dass das gleiche Nachrichtenobjekt nicht zwei Mal gesendet werden kann. Der Weiterleitungscode 660 ermöglicht, dass eine empfangene Nachricht gesendet werden kann, und führt automatisch die Arbeit durch, die erforderlich ist, um wenigstens eine neue Nachricht aufzubauen.
  • Ähnlich wie in 1 umfasst auch hier eine Quellendrahtnachricht 600 eine Sammlung von Headern 610 und einen gestreamten Hauptteil 620. Die Sammlung von Headern 610 und ein Teil 622 des gestreamten Hauptteils 620 sind bereits durch den Weiterleitungscode 660 verarbeitet worden. Es ist zu beachten, dass die Ziel-1-Drahtnachricht 600-1 eine Kopie der Headersammlung 610 und des Hauptteils 622, bezeichnet als Headersammlung 610-1 und als Hauptteil 622-1, umfasst.
  • Ein Block 624 des Hauptteils 620 erscheint als ein Datenstrom 624A zu dem Weiterleitungscode 660. Der Weiterleitungscode 660 liest aus dem Datenstrom 624A, um erneut den Block 624 innerhalb des Weiterleitungscodes 624 zu bilden. Es ist zu beachten, dass der Weiterleitungscode 660 den Block 624 des Hauptteils 620 puffert. Wie jedoch bereits angedeutet wurde, stellt das Puffern eines Blockes eines Datenstroms einen begrenzten Puffer dar, im Gegensatz zu dem Puffern des gesamten Hauptteils 620, das einen unbegrenzten Puffer darstellen würde. Der Weiterleitungscode 660 schreibt 664 den Block 624 auf den Ziel-1-Nachrichteninhalt 652-1 und den Ziel-2-Nachrichteninhalt 652-2, die als Datenstrom 624A-1 beziehungsweise 624A-2 erscheinen. Die Datenströme 624A-1 und 624A-2 werden danach als die Blöcke 624-1 und 624-2 auf die Ziel-1-Drahtnachricht 600-1 und die Ziel-2-Drahtnachricht 600-2 geschrieben. Wenn der Weiterleitungscode 660 die gesamte Quellendrahtnachricht 600 verarbeitet hat, werden sowohl das Ziel 1 als auch das Ziel 2 eine Kopie haben.
  • Die vorliegende Erfindung kann auch in Bezug auf Verfahren der Verarbeitung eines Nachrichtenobjektes, die Puffererfordernisse gemäß der vorliegenden Erfindung reduzieren, beschrieben werden. Es folgt eine Beschreibung von Handlungen und Schritten, die bei der praktischen Ausführung der vorliegenden Erfindung durchgeführt werden können. Üblicherweise beschreiben funktionale Schritte die Erfindung hinsichtlich der Ergebnisse, die erzielt werden, während nichtfunktionale Handlungen spezifische Aktionen zum Erzielen eines bestimmten Ergebnisses beschreiben. Wenngleich die funktionalen Schritte und die nichtfunktionalen Handlungen in einer bestimmten Reihenfolge beschrieben oder beansprucht werden können, ist die vorliegende Erfindung nicht zwangsläufig auf eine bestimmte Reihenfolge oder Kombination von Handlungen und/oder Schritten beschränkt.
  • Die 7A bis 7B zeigen Beispielhandlungen und Beispielschritte für Methoden der Verarbeitung eines Nachrichtenobjektes, die Puffererfordernisse gemäß der vorliegenden Erfindung reduzieren. Ein Schritt zum Spezifizieren (710) einer Objektdefinition für das Nachrichtenobjekt kann eine Handlung des Erzeugens (712) einer Nachrichtenobjekt-Definition für das Nachrichtenobjekt umfassen, die wenigstens einen gestreamten Teil definiert, und eine entsprechende datenstromorientierte Schnittstelle. Ein Schritt zum Bereitstellen (720) wenigstens eines Nachrichtenhandlers, der oder die eine entsprechende Verarbeitungsoperation zur Durchführung an dem Nachrichtenobjekt identifiziert, kann eine Handlung des Definierens (722) des wenigstens einen Nachrichtenhandlers umfassen. Ein Schritt zum Bereitstellen (730) einer Nachrichtenpipeline, die eine geordnete Sammlung wenigstens eines Nachrichtenhandlers umfasst, kann eine Handlung des Identifizierens und Ordnens (732) des wenigstens einen Nachrichtenhandlers, der oder die in eine konfigurierbare Pipeline einzubeziehen ist oder sind, umfassen.
  • Ein Schritt zum Verarbeiten (740) des Nachrichtenobjektes mit dem wenigstens einen Nachrichtenhandler der Nachrichtenpipeline dergestalt, dass wenigstens ein Nachrichtenhandler einen gestreamten Teil des Nachrichtenobjektes einkapselt, kann eine Handlung des Abrufens (742) des wenigstens einen Nachrichtenhandlers umfassen. Ein Beispielverfahren gemäß der vorliegenden Erfindung kann eine Handlung des Zuweisens (752) eines Datenstroms zu den Datenstromteil des Nachrichtenobjektes umfassen. Wie weiter oben bereits angedeutet wurde, kann die Zuweisung auftreten, nachdem der wenigstens eine Nachrichtenhandler der Nachrichtenpipeline aufgerufen worden ist.
  • Ein Schritt zum Puffern (760) des wenigstens einen Nichtdatenstrom-Teils des Nachrichtenobjektes kann eine Handlung des Speicherns (762) des wenigstens einen Nichtdatenstrom-Teils in einem Zwischenspeicher umfassen. Ein Schritt zum Empfangen (790) eines Nachrichtenobjektes von einem anderen Endpunkt oder einem dazwischenliegenden System (intermediary) kann eine Handlung des Lesens (792) des Nachrichtenobjektes aus einem Nachrichtentransport-Datenstrom umfassen. Ein Schritt zum Senden (780) eines Nachrichtenobjektes an einen anderen Endpunkt oder des Duplizierens (780) des Nachrichtenobjektes zur Übergabe an eine Vielzahl von Endpunkten kann eine Handlung des Schreibens (782) des Nachrichtenobjektes auf einen Nachrichtentransport-Datenstrom umfassen. Es ist zu beachten, das sowohl das Lesen als auch das Schreiben bewirken können, dass die Verarbeitungsoperationen von den Nachrichtenhandlern auf dem gestreamten Teil des Nachrichtenobjektes ausgeführt werden. Ein Beispielverfahren gemäß der vorliegenden Erfindung kann weiterhin eine Handlung des Materialisierens des gestreamten Teils eines Nachrichtenobjektes auf Anforderung umfassen.
  • Ausführungsbeispiele innerhalb des Erfindungsbereiches der vorliegenden Erfindung beinhalten weiterhin computerlesbare Speichermedien zum Ausführen von darauf gespeicherten computerausführbaren Anweisungen oder Datenstrukturen oder selbige aufweisend. Solche computerlesbaren Speichermedien können verfügbare Speichermedien sein, auf die ein Allzweckrechner oder ein Spezialrechner zugreifen kann. Beispielhaft und nicht einschränkend können solche computerlesbaren Speichermedien einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher (ROM), einen EEPROM-Speicher, eine CD-ROM oder eine optische Speicherplatte, eine Magnetspeicherplatte oder andere Magnetspeichervorrichtungen oder beliebige andere Speichermedien, die genutzt werden können, um gewünschte Programmcodeeinrichtungen in Form von computerausführbaren Anweisungen oder Datenstrukturen zu tragen oder zu speichern, und auf die ein Allzweckrechner oder ein Spezialrechner zugreifen kann, umfassen. Wenn Daten über ein Netz oder eine andere Kommunikationsverbindung (entweder festverdrahtet, drahtlos oder eine Kombination aus festverdrahtet und drahtlos) zu einem Computer übertragen werden, betrachtet der Computer die Verbindung richtig als ein computerlesbares Speichermedium. Das heißt, eine solche Verbindung wird richtigerweise als computerlesbares Speichermedium bezeichnet. Computerausführbare Anweisungen sind zum Beispiel Anweisungen und Daten, die bewirken, dass ein Allzweckrechner, ein Spezialrechner oder eine Spezial-Verarbeitungsvorrichtung eine bestimmte Funktion oder eine Gruppe von Funktionen ausführen.
  • 8 und die folgende Diskussion sollen eine kurze, allgemeine Beschreibung einer geeigneten Computerumgebung bereitstellen, in der die Erfindung implementiert werden kann. Wenngleich dies nicht erforderlich ist, wird die Erfindung in dem allgemeinen Kontext von computerausführbaren Anweisungen, wie zum Beispiel Programmmodulen, die von Computern in Netzwerkumgebungen ausgeführt werden, beschrieben werden. Im Allgemeinen umfassen Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen u.s.w., die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Computerausführbare Anweisungen, zugehörige Datenstrukturen und Programmmodule stellen Beispiele der Programmcodeeinrichtungen zum Ausführen von Schritten der hierin offengelegten Verfahren dar. Die jeweilige Folge solcher ausführbaren Anweisungen oder zugehöriger Datenstrukturen stellt Beispiele entsprechender Handlungen zur Implementierung der in den genannten Schritten beschriebenen Funktionen dar.
  • Der Durchschnittsfachmann wird erkennen, dass die Erfindung in Netzwerkrechenumgebungen mit zahlreichen Arten von Computersystemkonfigurationen, unter anderem Personalcomputer, Handgeräte, Mehrprozessorsysteme, mikroprozessorbasierte oder programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minirechner, Großrechner und ähnliche, praktisch ausgeführt werden kann. Die Erfindung kann auch in verteilten Rechenumgebungen praktiziert werden, in denen Aufgaben von lokalen und fernen Verarbeitungsgeräten, die über ein Kommunikationsnetz verknüpft sind (entweder durch festverdrahtete Verbindungen, drahtlose Verbindungen oder durch eine Kombination aus festverdrahteten und drahtlosen Verbindungen), ausgeführt werden. In einer verteilten Rechenumgebung können Programmmodule sowohl in lokalen als auch in fernen Speichergeräten vorhanden sein.
  • Unter Bezugnahme auf 8 umfasst ein Beispielsystem zum Implementieren der Erfindung ein Allzweckrechnergerät in Form eines herkömmlichen Computers 820, mit einer Verarbeitungseinheit 821, einem Systemspeicher 822 und einem Systembus 823, der verschiedene Systemkomponenten, einschließlich des Systemspeichers 822, mit der Verarbeitungseinheit 821 koppelt. Der Systembus 823 kann eine beliebige aus mehreren Arten von Busstrukturen sein, einschließlich eines Speicherbusses oder eines Speichercontrollers, eines Peripheriebusses und eines lokalen Busses unter Verwendung einer beliebigen aus einer Vielzahl von Busarchitekturen. Der Systemspeicher umfasst einen Nur-Lese-Speicher (ROM) 824 und einen Direktzugriffsspeicher (RAM) 825. Ein Basic-Input-Output-System (BIOS) 826, das die Grundroutinen enthält, die die Übertragung von Daten zwischen Elementen innerhalb des Computers 820, wie zum Beispiel während des Anfahrens, ermöglicht, können in dem Nur-Lese-Speicher (ROM) 824 gespeichert sein.
  • Der Computer 820 kann weiterhin ein Magnetfestplattenlaufwerk 827 zum Lesen von einer und Schreiben auf eine magnetische Festplatte 839, ein Magnetplattenlaufwerk 828 zum Lesen von oder Schreiben auf eine Magnetwechselplatte 829 und ein optisches Plattenlaufwerk 830 zum Lesen von oder Schreiben auf eine optische Wechselplatte 831, wie zum Beispiel eine CD-ROM oder andere optische Speichermedien, umfassen. Das Magnetfestplattenlaufwerk 827, das Magnetplattenlaufwerk 828 und das optische Plattenlaufwerk 830 sind über eine Festplattenlaufwerk-Schnittstelle 832, eine Magnetplattenlaufwerk-Schnittstelle 833 beziehungsweise eine optische Plattenlaufwerk-Schnittstelle 834 mit dem Systembus 823 verbunden. Die Laufwerke und ihre zugehörigen computerlesbaren Speichermedien stellen einen nichtflüchtigen Speicher computerlesbarer Anweisungen, Datenstrukturen, Programmmodule und anderer Daten für den Computer 820 bereit. Wenngleich die hierin beschriebene beispielhafte Umgebung ein Magnetfestplattenlaufwerk 839, eine Magnetwechselplatte 829 und eine optische Wechselplatte 831 verwendet, können andere Arten von computerlesbaren Speichermedien zum Speichern von Daten verwendet werden, wie unter anderem Magnetkassetten, Flash-Speicherkarten, Digitale Videoplatten (DVDs), Bernoulli-Wechselplatten, Direktzugriffsspeicher (RAMs), Nur-Lese-Speicher (ROMs) und ähnliche.
  • Programmcodeeinrichtungen, die wenigstens ein Programmmodul umfassen, können auf der Festplatte 839, der Magnetplatte 829, der optischen Speicherplatte 831, dem Nur-Lese-Speicher (ROM) 824 oder dem Direktzugriffsspeicher (RAM) 825 gespei chert werden, einschließlich eines Betriebssystems 835, wenigstens eines Anwendungsprogramms 836, anderer Programmmodule 837 und von Programmdaten 838. Ein Benutzer kann Befehle und Daten über die Tastatur 840, ein Zeigegerät 842 oder andere Eingabegeräte (nicht gezeigt), wie zum Beispiel ein Mikrofon, einen Joystick, ein Gamepad, eine Satellitenschüssel, einen Scanner oder ähnliches, in den Computer 820 eingeben. Diese und andere Eingabegeräte sind oft über eine serielle Schnittstelle 846, die mit dem Systembus 823 gekoppelt ist, mit der Verarbeitungseinheit 821 verbunden. Alternativ dazu können die Eingabegeräte durch andere Schnittstellen, wie zum Beispiel eine parallele Schnittstelle, einen Gameport oder einen universellen seriellen Bus (USB), verbunden sein. Ein Monitor 847 oder ein anderes Anzeigegerät ist ebenfalls über eine Schnittstelle, wie zum Beispiel einen Videoadapter 848, mit dem Systembus 823 verbunden. Zusätzlich zu dem Monitor umfassen Personalcomputer üblicherweise andere periphere Ausgabegeräte (nicht gezeigt), wie zum Beispiel Lautsprecher und Drucker.
  • Der Computer 820 kann in einer vernetzten Umgebung unter Verwendung von logischen Verbindungen zu wenigstens einem Ferncomputer, wie zum Beispiel den Ferncomputern 849a und 849b, arbeiten. Die Ferncomputer 849a und 849b können jeweils ein anderer Personalcomputer, ein Server, ein Router, ein Netzwerk-PC, ein Peergerät oder ein anderer gemeinsamer Netzwerkknoten sein und umfassen üblicherweise zahlreiche oder alle der oben in Bezug auf den Computer 820 beschriebenen Elemente, wenngleich nur die Speichergeräte 850a und 850b und ihre zugehörigen Anwendungsprogramme 836a und 836b in 8 veranschaulicht worden sind. Die in 8 veranschaulichten logischen Verbindungen sind unter anderem ein lokales Netzwerk (LAN) 851 und ein Weitverkehrsnetzwerk (WAN) 852, die hier beispielhaft und nicht einschränkend dargestellt werden. Solche Netzwerkumgebungen sind in Büronetzwerken oder in Unternehmensnetzwerken, in Intranets und dem Internet weit verbreitet.
  • Bei Verwendung in einer LAN-Netzwerkumgebung ist der Computer 820 über eine Netzwerkschnittstelle oder einen Adapter 853 mit dem lokalen Netzwerk 851 verbunden. Bei Verwendung in einer WAN-Netzwerkumgebung kann der Computer 820 ein Modem 854, eine Drahtlosverbindung oder andere Mittel zum Herstellen von Verbindungen oder Nachrichtenübertragung über das Weitverkehrsnetz (WAN) 852, wie zum Beispiel das Internet, umfassen. Das Modem 854, das ein internes oder ein externes sein kann, ist über die serielle Schnittstelle 846 mit dem Systembus 823 verbunden. In einer vernetzten Umgebung können in Bezug auf den Computer 820 oder auf Teile desselben beschriebene Programmmodule in dem Fernspeichergerät gespeichert sein. Es wird erkennbar sein, dass die gezeigten Netzwerkverbindungen beispielhaft sind und dass andere Mittel der Herstellung von Verbindungen oder Nachrichtenübertragung über das Weitverkehrsnetz 852 verwendet werden können.
  • Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihren wesentlichen Merkmalen abzuweichen. Die beschriebenen Ausführungsbeispiele sind in jeder Hinsicht ausschließlich als veranschaulichend, nicht jedoch als einschränkend, zu verstehen. Der Erfindungsbereich wird daher durch die anhängenden Patentansprüche, nicht jedoch durch die vorstehende Beschreibung, gekennzeichnet. Alle Änderungen, die mit den Patentansprüchen gleichwertig und vereinbar sind, sollen in den Geltungsbereich der Patentansprüche fallen.

Claims (28)

  1. Verfahren in einem Datenübertragungssystem (messaging system) mit einer gegebenen Puffergröße zum Senden oder Empfangen von Nachrichten (100, 300, 400, 500, 600) über einen oder mehrere Nachrichtentransporte (message transports), wobei das Verfahren zum Bearbeiten einer Nachricht ist, das zumindest für einen Teil der Nachricht die Puffererfordernisse reduziert, und wobei das Verfahren Schritte umfasst zum: Bereitstellen (720) eines oder mehrerer Nachrichtenhandler (332336, 342346), von denen jeder eine entsprechende Verarbeitungsfunktion (432A436A) identifiziert, die auf mindestens einem gestreamten Teil (120, 420, 520, 620) des Inhaltes eines Nachrichtenobjekts durchgeführt werden soll; Bereitstellen (730) einer Nachrichtenpipeline (330, 340), die eine geordnete Sammlung von dem einen oder den mehreren Nachrichtenhandlern umfasst; und Verarbeiten (740) des Nachrichtenobjekts mit dem einen oder den mehreren Nachrichtenhandlern aus der Nachrichtenpipeline, wobei mindestens ein Nachrichtenhandler den mindestens einen gestreamten Teil des Nachrichtenobjekts mit seiner entsprechenden Verarbeitungsfunktion verkapselt und wobei jede Verarbeitungsfunktion, die den mindestens einen gestreamten Teil verkapselt, zu einem zukünftigen Zeitpunkt durchgeführt wird, wenn der mindestens eine gestreamte Teil geschrieben oder gelesen wird, ohne dass der mindestens eine gestreamte Teil des Nachrichtenobjekts in einem Puffer zwischengespeichert wird.
  2. Verfahren nach Anspruch 1, wobei der Schritt des Bereitstellens einer Nachrichtenpipeline den Vorgang des Identifizierens und Ordnens (732) des einen oder der mehreren Nachrichtenhandler umfasst.
  3. Verfahren nach Anspruch 1, wobei das Nachrichtenobjekt einen oder mehrere Anhangsteile umfasst.
  4. Verfahren nach Anspruch 1, wobei der Schritt des Verarbeitens des Nachrichtenobjekts das Aufrufen des einen oder der mehreren Nachrichtenhandler aus der Nachrichtenpipeline einschließt, und wobei das Aufrufen stattfindet, bevor ein Datenstrom dem mindestens einen Datenstromteil des Nachrichtenobjekts zugewiesen wird (752).
  5. Verfahren nach Anspruch 1, wobei das Datenübertragungssystem ein Endpunkt ist, und das Verfahren des Weiteren einen Schritt zum Empfangen (790) des Nachrichtenobjekts von einem anderen Endpunkt oder einem dazwischenliegenden Punkt (530) umfasst, und wobei der Schritt des Empfangens des Nachrichtenobjekts verursacht, dass die mindestens eine Verarbeitungsfunktion auf den mindestens einen gestreamten Teil des Nachrichtenobjekts angewandt wird.
  6. Verfahren nach Anspruch 1, wobei das Nachrichtenobjekt einen oder mehrere nichtgestreamte Teile (112116, 510) umfasst, und wobei das Verfahren des Weiteren einen Schritt zum Zwischenspeichern (760) des einen oder der mehreren nichtgestreamten Teile umfasst.
  7. Verfahren nach Anspruch 1, wobei das Datenübertragungssystem einen Nachrichtenkonsumenten umfasst, und wobei das Verfahren des Weiteren einen Vorgang des Zwischenspeicherns auf Abfrage durch den Nachrichtenkonsumenten von dem mindestens einen gestreamten Teil des Nachrichtenobjekts umfasst.
  8. Verfahren nach Anspruch 1, das des Weiteren einen Schritt des Duplizierens (664) des Nachrichtenobjekts zum Liefern an eine Vielzahl von Endpunkten umfasst, ohne dass der mindestens eine gestreamte Teil des Nachrichtenobjekts in einem Puffer zwischengespeichert wird.
  9. Verfahren nach Anspruch 1, wobei eine Vielzahl von Nachrichtenpipelines bereitgestellt werden, und wobei das Verfahren des Weiteren einen Schritt zum Verarbeiten des Nachrichtenobjekts mit jedem des einen oder der mehreren Nachrichtenhandler aus jeder Nachrichtenpipeline umfasst.
  10. Verfahren nach Anspruch 9, wobei mindestens eine (340) der Nachrichtenpipelines in einer anderen Nachrichtenpipeline (330) verschachtelt ist.
  11. Verfahren nach Anspruch 1, wobei das Datenübertragungssystem ein Endpunkt ist, und wobei das Verfahren des Weiteren den Schritt des Sendens (780) des Nachrichtenobjekts an einen anderen Endpunkt umfasst, und wobei der Schritt des Sendens des Nachrichtenobjekts verursacht, dass die mindestens eine Verarbeitungsfunktion auf den mindestens einen gestreamten Teil des Nachrichtenobjekts angewandt wird.
  12. Verfahren nach Anspruch 1, wobei das Bereitstellen eines oder mehrerer Nachrichtenhandler das Definieren (722) des einen oder der mehreren Nachrichtenhandler umfasst; wobei das Bereitstellen der Nachrichtenpipeline das Identifizieren (732) und das Ordnen des einen oder der mehreren Nachrichtenhandler umfasst, die in einer konfigurierbaren Nachrichtenpipeline eingeschlossen sein sollen; und wobei das Verarbeiten des Nachrichtenobjekts das Aufrufen (742) des einen oder der mehreren Nachrichtenhandler aus der Nachrichtenpipeline umfasst, um das Nachrichtenobjekt zu verarbeiten.
  13. Verfahren nach Anspruch 12, wobei das Datenübertragungssystem ein Endpunkt ist, und wobei das Verfahren des Weiteren einen Vorgang des Schreibens (664, 782) des Nachrichtenobjekts auf einen Nachrichtentransportdatenstrom umfasst, wobei der Vorgang des Schreibens des Nachrichtenobjekts auf den Transportdatenstrom verursacht, dass die mindestens eine Verarbeitungsfunktion auf den mindestens einen gestreamten Teil des Nachrichtenobjekts angewandt wird.
  14. Verfahren nach Anspruch 12, wobei das Datenübertragungssystem einen Nachrichtenkonsumenten umfasst, und wobei das Verfahren des Weiteren einen Vorgang des Zwischenspeicherns auf Abfrage durch den Nachrichtenkonsumenten von dem mindestens einen gestreamten Teil des Nachrichtenobjekts umfasst.
  15. Verfahren nach Anspruch 12, wobei eine Vielzahl von Nachrichtenpipelines definiert wird, und wobei das Verfahren des Weiteren einen Vorgang zum Aufrufen des einen oder der mehreren Nachrichtenhandler von jeder Nachrichtenpipeline umfasst, um das Nachrichtenobjekt zu verarbeiten.
  16. Verfahren nach Anspruch 15, wobei mindestens eine der Nachrichtenpipelines in einer anderen Nachrichtenpipeline verschachtelt ist.
  17. Verfahren nach Anspruch 12, wobei das Nachrichtenobjekt einen oder mehrere Anhangsteile umfasst.
  18. Verfahren nach Anspruch 12, wobei das Aufrufen des einen oder der mehreren Nachrichtenhandler aus der Nachrichtenpipeline stattfindet, bevor ein Datenstrom dem mindestens einen Datenstromteil des Nachrichtenobjekts zugewiesen wird (752).
  19. Verfahren nach Anspruch 12, wobei das Datenübertragungssystem ein Endpunkt ist, und wobei das Verfahren des Weiteren den Vorgang des Lesens (792) des Nachrichtenobjekts aus einem Nachrichtentransportdatenstrom umfasst, wobei der Vorgang des Lesens des Nachrichtenobjekts aus dem Transportdatenstrom verursacht, dass die mindestens eine Verarbeitungsfunktion auf den mindestens einen gestreamten Teil des Nachrichtenobjekts angewandt wird.
  20. Verfahren nach Anspruch 12, wobei das Nachrichtenobjekt einen oder mehrere nichtgestreamte Teile umfasst, und wobei das Verfahren des Weiteren einen Vorgang des Speicherns (762) des einen oder der mehreren nichtgestreamten Teile in einem Puffer umfasst.
  21. Verfahren nach Anspruch 12, wobei das Verfahren des Weiteren einen Vorgang des Schreibens (664) des Nachrichtenobjekts auf eine Vielzahl von Transportdatenströmen zum Liefern an eine Vielzahl von Endpunkten umfasst, ohne dass der mindestens eine gestreamte Teil des Nachrichtenobjekts in einem Puffer zwischengespeichert wird.
  22. Verfahren nach Anspruch 1 oder 12, wobei die Pipeline eine Vielzahl von Nachrichtenhandlern umfasst, und wobei jeder der Vielzahl von Nachrichtenhandlern den mindestens einen gestreamten Teil des Nachrichtenobjekts mit seiner entsprechenden Verarbeitungsfunktion nacheinander verkapselt, so dass eine Vielzahl von Verarbeitungsfunktionen schichtweise (layered) auf den mindestens einen Datenstromteil des Nachrichtenobjekts gelegt wird.
  23. Verfahren nach Anspruch 1 oder 12, wobei das Nachrichtenobjekt einen oder mehrere Kopfteile (header portions) und mindestens einen Hauptteil (body portions) um fasst, und wobei der Hauptteil den mindestens einen gestreamten Teil des Nachrichtenobjekts umfasst.
  24. Verfahren nach Anspruch 23, wobei das Nachrichtenobjekt ein SOAP-Nachrichtenobjekt umfasst.
  25. Verfahren nach Anspruch 24, wobei das Datenübertragungssystem ein dazwischenliegendes System (530) (intermediary) ist, das für das Routing des Nachrichtenobjekts verantwortlich ist.
  26. Verfahren nach Anspruch 25, wobei das dazwischenliegende System mindestens einen Header für das Routen der Nachricht puffert, ohne den mindestens einen gestreamten Teil des Nachrichtenobjekts zwischenzuspeichern.
  27. Verfahren nach Anspruch 1 oder 12, wobei das Verfahren des Weiteren den Vorgang des Erzeugens (712) oder Spezifizierens (710) einer Nachrichtenobjektsdefinition für das Nachrichtenobjekt umfasst, und wobei die Nachrichtenobjektsdefinition den mindestens einen gestreamten Teil und eine entsprechende Datenstrom-orientierte Schnittstelle für das Nachrichtenobjekt definiert.
  28. Computerprogrammerzeugnis, das ein oder mehrere computerlesbare Datenträger umfasst, die computerausführbare Instruktionen tragen, die eingerichtet sind, alle Schritte des Verfahrens gemäß einem der Ansprüche 1 bis 27 zu implementieren.
DE602004011638T 2003-03-26 2004-03-25 Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem Expired - Lifetime DE602004011638T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US401220 2003-03-26
US10/401,220 US7185060B2 (en) 2003-03-26 2003-03-26 Message processing pipeline for streams

Publications (2)

Publication Number Publication Date
DE602004011638D1 DE602004011638D1 (de) 2008-03-20
DE602004011638T2 true DE602004011638T2 (de) 2009-02-05

Family

ID=32825009

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004011638T Expired - Lifetime DE602004011638T2 (de) 2003-03-26 2004-03-25 Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem

Country Status (22)

Country Link
US (1) US7185060B2 (de)
EP (1) EP1463262B1 (de)
JP (1) JP4510492B2 (de)
KR (1) KR101037839B1 (de)
CN (1) CN1534533B (de)
AT (1) ATE385644T1 (de)
AU (1) AU2004200727B2 (de)
BR (1) BRPI0400760A (de)
CA (1) CA2460288A1 (de)
CO (1) CO5560096A1 (de)
DE (1) DE602004011638T2 (de)
HK (1) HK1069495A1 (de)
IL (1) IL160571A0 (de)
MX (1) MXPA04002728A (de)
MY (1) MY139288A (de)
NO (1) NO331006B1 (de)
NZ (1) NZ531381A (de)
PL (1) PL366351A1 (de)
RU (1) RU2363982C2 (de)
SG (1) SG115638A1 (de)
TW (1) TWI339340B (de)
ZA (1) ZA200401581B (de)

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040205216A1 (en) * 2003-03-19 2004-10-14 Ballinger Keith W. Efficient message packaging for transport
US7331049B1 (en) * 2003-04-21 2008-02-12 Borland Software Corporation System and methodology providing typed event and notification services
US7343347B2 (en) * 2003-10-08 2008-03-11 Time Warner Inc. Electronic media player with metadata based control and method of operating the same
US7743386B2 (en) * 2004-03-12 2010-06-22 Sap Ag Context objects for accessing message content
US7653008B2 (en) 2004-05-21 2010-01-26 Bea Systems, Inc. Dynamically configurable service oriented architecture
US20060031481A1 (en) * 2004-05-21 2006-02-09 Bea Systems, Inc. Service oriented architecture with monitoring
US20060005063A1 (en) * 2004-05-21 2006-01-05 Bea Systems, Inc. Error handling for a service oriented architecture
US20050278335A1 (en) * 2004-05-21 2005-12-15 Bea Systems, Inc. Service oriented architecture with alerts
US20050273847A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Programmable message processing stage for a service oriented architecture
US20060080419A1 (en) * 2004-05-21 2006-04-13 Bea Systems, Inc. Reliable updating for a service oriented architecture
US20060136555A1 (en) * 2004-05-21 2006-06-22 Bea Systems, Inc. Secure service oriented architecture
US20050273517A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Service oriented architecture with credential management
US20050264581A1 (en) * 2004-05-21 2005-12-01 Bea Systems, Inc. Dynamic program modification
US20050273521A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Dynamically configurable service oriented architecture
US20050273516A1 (en) * 2004-05-21 2005-12-08 Bea Systems, Inc. Dynamic routing in a service oriented architecture
US8037123B2 (en) * 2004-08-27 2011-10-11 Microsoft Corporation Securely and efficiently extending data processing pipeline functionality
US8296354B2 (en) 2004-12-03 2012-10-23 Microsoft Corporation Flexibly transferring typed application data
JP4852906B2 (ja) * 2005-06-24 2012-01-11 富士ゼロックス株式会社 連携処理システム及び装置
US7634578B2 (en) * 2005-07-14 2009-12-15 Microsoft Corporation Node-to-node communication pipelines
US20070067488A1 (en) * 2005-09-16 2007-03-22 Ebay Inc. System and method for transferring data
US7949720B2 (en) * 2006-01-31 2011-05-24 Microsoft Corporation Message object model
US7720984B2 (en) * 2006-02-07 2010-05-18 Cisco Technology, Inc. Method and system for stream processing web services
US8996394B2 (en) * 2007-05-18 2015-03-31 Oracle International Corporation System and method for enabling decision activities in a process management and design environment
US8185916B2 (en) 2007-06-28 2012-05-22 Oracle International Corporation System and method for integrating a business process management system with an enterprise service bus
US7984100B1 (en) 2008-04-16 2011-07-19 United Services Automobile Association (Usaa) Email system automatically notifying sender status and routing information during delivery
US7895280B2 (en) 2008-09-03 2011-02-22 Microsoft Corporation Composing message processing pipelines
US8341280B2 (en) * 2008-12-30 2012-12-25 Ebay Inc. Request and response decoupling via pluggable transports in a service oriented pipeline architecture for a request response message exchange pattern
US20100206829A1 (en) * 2009-02-13 2010-08-19 L&P Property Management Company Product display
KR101428472B1 (ko) * 2013-02-15 2014-08-08 에스케이플래닛 주식회사 클라우드 스트리밍 서비스 제공을 위한 장치 및 이를 위한 방법

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05103016A (ja) * 1991-10-11 1993-04-23 Hitachi Ltd メツセージ送受信方法
JPH06324998A (ja) * 1993-05-14 1994-11-25 Fujitsu Ltd メッセージ受信方式
US5402416A (en) * 1994-01-05 1995-03-28 International Business Machines Corporation Method and system for buffer occupancy reduction in packet switch network
US5966663A (en) * 1997-01-14 1999-10-12 Ericsson Messaging Systems Inc. Data communications protocol for facilitating communications between a message entry device and a messaging center
US5983259A (en) * 1997-02-19 1999-11-09 International Business Machines Corp. Systems and methods for transmitting and receiving data in connection with a communications stack in a communications system
US5918020A (en) * 1997-02-28 1999-06-29 International Business Machines Corporation Data processing system and method for pacing information transfers in a communications network
US6226666B1 (en) * 1997-06-27 2001-05-01 International Business Machines Corporation Agent-based management system having an open layered architecture for synchronous and/or asynchronous messaging handling
US6038604A (en) * 1997-08-26 2000-03-14 International Business Machines Corporation Method and apparatus for efficient communications using active messages
EP0964559A1 (de) * 1998-06-08 1999-12-15 THOMSON multimedia Verfahren zur Übertragung von asynchronen Daten in einem Hausnetzwerk
GB2340701B (en) 1998-08-15 2003-06-25 Roke Manor Research Programmable packet header processor
GB0007698D0 (en) * 2000-03-31 2000-05-17 Discreet Logic Inc Editing video data
US7042891B2 (en) 2001-01-04 2006-05-09 Nishan Systems, Inc. Dynamic selection of lowest latency path in a network switch
US7095747B2 (en) * 2001-03-28 2006-08-22 Siemens Communications, Inc. Method and apparatus for a messaging protocol within a distributed telecommunications architecture
US6886041B2 (en) * 2001-10-05 2005-04-26 Bea Systems, Inc. System for application server messaging with multiple dispatch pools
US20030093471A1 (en) * 2001-10-18 2003-05-15 Mitch Upton System and method using asynchronous messaging for application integration

Also Published As

Publication number Publication date
TWI339340B (en) 2011-03-21
CO5560096A1 (es) 2005-09-30
KR20040084845A (ko) 2004-10-06
NO331006B1 (no) 2011-09-05
TW200502778A (en) 2005-01-16
US20040193687A1 (en) 2004-09-30
NO20041247L (no) 2004-09-27
CN1534533A (zh) 2004-10-06
MY139288A (en) 2009-09-30
ATE385644T1 (de) 2008-02-15
DE602004011638D1 (de) 2008-03-20
US7185060B2 (en) 2007-02-27
KR101037839B1 (ko) 2011-05-31
JP4510492B2 (ja) 2010-07-21
CA2460288A1 (en) 2004-09-26
IL160571A0 (en) 2004-07-25
CN1534533B (zh) 2012-05-16
EP1463262B1 (de) 2008-02-06
EP1463262A1 (de) 2004-09-29
PL366351A1 (en) 2004-10-04
BRPI0400760A (pt) 2005-01-11
RU2004108867A (ru) 2005-09-27
HK1069495A1 (en) 2005-05-20
AU2004200727B2 (en) 2010-01-28
NZ531381A (en) 2005-07-29
SG115638A1 (en) 2005-10-28
AU2004200727A1 (en) 2004-10-14
JP2004295894A (ja) 2004-10-21
MXPA04002728A (es) 2005-06-17
ZA200401581B (en) 2004-08-31
RU2363982C2 (ru) 2009-08-10

Similar Documents

Publication Publication Date Title
DE602004011638T2 (de) Verringern von Pufferanforderungen in einem Nachrichtenübermittlungssystem
DE60114097T2 (de) Verfahren und System zur Verbesserung der Netzleistungsfähigkeit unter Verwendung eines leistungssteigernden Proxies
DE602004004300T2 (de) Verfahren, System und Computerprogramm für das Senden und Empfangen von Meldungen durch einen individuellen Kommunikationskanal
DE69826930T2 (de) System und Verfahren zur wirksamen Fernplatte Ein-/Ausgabe
DE69635047T2 (de) Vernetzte server mit kundenspezifischen diensten zum herunterladen von videos
DE60211524T2 (de) Verfahren und vorrichtung zur verteilten lieferung von inhalten innerhalb eines computernetzwerkes
DE60027247T2 (de) Verfahren und Systeme zur Konvertierung von Datenformaten
DE10054923B4 (de) Verfahren zum Auffangen von Netzwerkpaketen in einem Computersystem, Computersystem zum Handhaben von Netzwerkpaketen sowie Paketauffängermodul zum Auffangen von Netzwerkpaketen in einem Computersystem
DE60221557T2 (de) Methode und gerät zur adressenübersetzung für gesicherte verbindungen
DE60038448T2 (de) Vorrichtung und verfahren zur hardware-ausführung oder hardware-beschleunigung von betriebssystemfunktionen
DE69628631T2 (de) Dateneingangs/-ausgangsvorrichtung durch Referenzierung zwischen zentralen Verarbeitungseinheiten und Ein-/Ausgabevorrichtungen
DE60212339T2 (de) Ein digitales fernsehen anwendungsprotokoll zum interaktiven fernsehen
DE60213297T2 (de) Multimediadatenübertragung durch vorwärtsgerichtetes Streamen
DE60033529T2 (de) Netzprozessor, speicherorganisation und verfahren
DE112006002644T5 (de) Mediendatenverarbeitung unter Verwendung von charakteristischen Elementen für Streaming- und Steuerprozesse
DE10297269B4 (de) Kennzeichnung von Paketen mit einem Nachschlageschlüssel zur leichteren Verwendung eines gemeinsamen Paketweiterleitungs-Cache
DE69735866T2 (de) Vorrichtung und Verfahren zur Erzeugung von voraussagbaren Antworten
DE60029879T2 (de) System zur mehrschichtigen Bereitstellung in Computernetzwerken
DE60027404T2 (de) Kreditbasiertes flusskontrollverfahren
DE69812777T2 (de) Verbindung von Ethernetkompatiblen Netzwerken
DE602005003142T2 (de) Vorrichtung und verfahren zur unterstützung von verbindungsherstellung in einem offload der netzwerkprotokollverarbeitung
DE69823368T2 (de) Verfahren und system zur identifizierung und unterdrückung von ausführbaren objekten
DE69935848T2 (de) System zur lieferung von daten über einen übertragungskanal mit niedrigen bitraten
EP1976202B2 (de) Anordnung und Verfahren zum Übermitteln eines Datenstroms über gebündelte Netzwerkzugangsleitungen, sowie Sende- und Empfangshilfsvorrichtung und Sende- und Empfangsverfahren dafür
DE112004002375B4 (de) Verfahren, System und Programm zum Verwalten von Datenleseoperationen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition