(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Nachrichteneigenschaften und -steuerung

In diesem Abschnitt werden Nachrichteneigenschaften und die Steuerung beschrieben.

Nachrichtenheader

Ein HTTP-Header namens BrokerProperties enthält alle BrokeredMessage-Header. Die Eigenschaften sind JSON-formatiert. Dies vereinfacht die Erweiterung der BrokeredMessage-Eigenschaften. Außerdem wird das Webprogrammiermodell berücksichtigt, indem das webfreundliche JSON-Format genutzt wird. Auf diese Weise wird das Erstellen und Nutzen von Nachrichteneigenschaften mit weniger Zeichenfolgenanalyse möglich. Im Folgenden sehen Sie ein Beispiel für BrokeredMessage-Header:

BrokerProperties:  { “SessionId”: “{27729E1-B37B-4D29-AA0A-E367906C206E}”, “MessageId”: “{701332E1-B37B-4D29-AA0A-E367906C206E}”, “TimeToLive” : 90, “CorrelationId”: “{701332F3-B37B-4D29-AA0A-E367906C206E}”, “SequenceNumber“ : 12345, “DeliveryCount“ : 2, “To“ : "http://contoso.com“, “ReplyTo“ : "http://fabrikam.com“,  "EnqueuedTimeUtc“ : " Sun, 06 Nov 1994 08:49:37 GMT“, "ScheduledEnqueueTimeUtc“ : " Sun, 06 Nov 1994 08:49:37 GMT“}

Die folgende Tabelle zeigt, wie BrokeredMessage-Eigenschaften HTTP-Headern zugeordnet werden.

 

BrokeredMessage-Bestandteile (SBMP) Typ HTTP-Header Zugriff HTTP Req/Res

ContentType

Zeichenfolge

Inhaltstyp

get, set

Req, Res

CorrelationId

Zeichenfolge

BrokerProperties{KorrelationsID}

get, set

Req, Res

SessionID

Zeichenfolge

BrokerProperties{SitzungsID}

get, set

Req, Res

DeliveryCount

int

BrokerProperties{Übermittlungsanzahl}

get

Res

LockedUntilUtc

DateTime

BrokerProperties{GesperrtBis}

get

Res

LockToken

GUID

BrokerProperties{Sperrtoken}

get

Res

MessageId

Zeichenfolge

BrokerProperties{NachrichtenID}

get, set

Res

Label

Zeichenfolge

BrokerProperties {Bezeichnung}

get, set

Req, Res

ReplyTo

Zeichenfolge

BrokerProperties{Antworten}

get, set

Req, Res

EnqueuedTimeUtc

DateTime

Date

get

Res

SequenceNumber

long

BrokerProperties{Sequenznummer}

get

Res

TimeToLive

TimeSpan

BrokerProperties-Auflistung {TimeToLive}

get, set

Req, Res

To

Zeichenfolge

BrokerProperties{An}

get, set

Req, Res

ScheduledEnqueueTimeUtc

DateTime

BrokerProperties{GeplanteWarteschlangenzeitUTC}

get, set

Req, Res

ReplyToSessionId

Zeichenfolge

BrokerProperties{AntwortAnSitzungsID}

get, set

Req, Res

Hinweise

  • DateTime-Header werden wie durch RFC2616 definiert formatiert (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3). Beispiel: "Sun, 06 Nov 1994 08:49:37 GMT".

  • BrokerProperties {TimeToLive} ist die Anzahl der Sekunden von TimeSpan (double).

  • ExpiresAtUtc besitzt keinen entsprechenden HTTP-Header, weil der Wert von Date und BrokerProperties {TimeToLive} begeleitet werden kann.

  • Nachrichtenheader mit einem get-Accessor können nur in der HTTP-Antwort (einer empfangenen Nachricht) auftreten. Wenn diese Header in der HTTP-Anforderung (der gesendeten Nachricht) vorhanden sind, werden sie einfach ignoriert. Nicht erkannte HTTP-Header werden ebenfalls ignoriert.

  • Wenn dieser Wert falsch formatiert ist, wird ein entsprechender HTTP-Statuscode an den Client zurückgegeben.

Nachrichteneigenschaften

Nachrichteneigenschaften sind vom Benutzer definierte Schlüssel-Wert-Paare, die in message.Properties enthalten sind. Für den SBMP-Thick Client sind diese Werte auf byte, sbyte, char, short, ushort, int, uint, long, ulong, float, double, decimal, bool, Guid, string, Uri, DateTime, DateTimeOffset und TimeSpan eingeschränkt.

Für REST/HTTP werden Uri und DateTimeOffset nicht unterstützt (wenn sie in der BrokeredMessage enthalten sind, sind sie nicht in den HTTP-Headern enthalten). GUID-Typen werden in Zeichenfolgen konvertiert und TimeSpan-Typen in "Sekunden gesamt". Aufgrund dieser Konvertierungen geht die Typgenauigkeit verloren. Jeder Eigenschaftenname, der dem eingeschränkten HTTP-Header entspricht (beispielsweise Connection, Expect usw.), wird ebenfalls ausgeschlossen.

Jedes Schlüssel-Wert-Paar in message.Properties wird einem HTTP-Header im folgenden Format zugeordnet:

prop_name: value

Dabei ist prop der Schlüsselname und value die Zeichenfolgendarstellung des Werts.

Der Typ des Werts wird abgeleitet. Wenn er in doppelte Anführungszeichen eingeschlossen ist, gilt Folgendes:

  • Wenn der Inhalt das Format einer RFC2616-Datums-/Uhrzeitangabe aufweist, wird er vom Broker als System.DateTime behandelt.

  • Andernfalls entfernt der Broker die Anführungszeichen und behandelt den Inhalt als System.String.

Wenn er nicht in doppelte Anführungszeichen eingeschlossen ist, gilt Folgendes:

  1. Wenn der Inhalt true oder false (Unterscheidung von Groß- und Kleinschreibung!) ist, behandelt der Broker ihn als System.Boolean mit dem entsprechenden Wert.

  2. Wenn der Inhalt als ganze Zahl analysiert werden kann, wird er vom Broker als System.Int64 behandelt.

  3. Wenn der Inhalt als Gleitkommazahl analysiert werden kann, wird er vom Broker als System.Double behandelt.

  4. Andernfalls weist der Broker die Nachricht zurück.

Beispiel:

product: Windows 7 Ultimate
price: 299.98
order-time: Fri, 04 Mar 2011 08:49:37 GMT

Nachrichtentext

Zwischen dem HTTP-Anforderungsantwort-Textdatenstrom und dem BrokerMessage.BodyStream werden keine Konvertierungen ausgeführt. Außerdem wird der Content-Type-Header aus der HTTP-Anforderung beibehalten und an den Nachrichtenempfänger zurückgegeben, damit die Anwendung die Bytes im Nachrichtentext richtig interpretieren kann.

Wenn die Nachricht mit dem SBMP-Thick Client ohne benutzerdefinierte XML-Objektserialisierung erstellt wird, wird für den Inhaltstyp standardmäßig application/msbin1 verwendet (dies ist DataContractBinarySerializer), wenn die Anwendung den Typ nicht explizit ändert (Beispiel: message.ContectType="application/EigenerTyp"), nachdem die Nachricht erstellt wurde. Dieser Inhaltstypwert wird an den HTTP-Consumer zurückgegeben. Die Entscheidung, wie die Bytes im Nachrichtentext deserialisiert werden sollen, liegt bei der Anwendung.

Die WCF Service Bus-Bindung legt ContentType auf den Wert ContentType des Nachrichtencodierers fest. Wenn z. B. ein Textnachrichtencodierer verwendet wird, ist application/soap+xml der erwartete Content-Type.

Nachrichtenkonvertierung

Die Konvertierung zwischen einer HTTP-Anforderungsantwort und einer Nachricht wird beim Anbieter des HTTP-Messaginglaufzeitmoduls ausgeführt. Die Konvertierungsmethoden werden so augmentiert, dass sie die Zuordnung der Header/Eigenschaften aus der Tabelle weiter oben in diesem Abschnitt enthalten und den Inhaltstyp der Nachricht beibehalten.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.