Freigeben über

Entwickeln von RPC-Message Queuing-Anwendungen

  • Artikel

Es ist sehr wenig Aufwand erforderlich, um den MSMQ-Transport in Ihrer RPC-Anwendung zu nutzen. Für synchrones Messaging müssen Sie nur den Nachrichtenwarteschlangentransport (ncadg_mq) als Protokollsequenz angeben. Das ncadg_mq-Protokoll unterstützt alle Standard-Datagrammfeatures mit Ausnahme von Rundfunkaufrufen. Beachten Sie außerdem, dass der Nachrichtenwarteschlangentransport derzeit keine dynamischen Endpunkte unterstützt.

Durch Anwenden des [message]-Attributs auf Remoteprozedurdeklarationen in der IDL-Datei implementieren Sie automatisch die Nachrichtenwarteschlange im asynchronen Modus für diese Aufrufe. Dies ermöglicht es den Client- und Serveranwendungen, viele der Eigenschaften zu steuern, die Nachrichten und Nachrichtenwarteschlangen zugeordnet sind, einschließlich:

  • Servicequalität
  • Empfangsbestätigung
  • Journaling
  • Anrufpriorität
  • Persistenz der Serverprozesswarteschlange

Die Dienstqualität ist der Aufwand, den der Transport zur Übermittlung des Aufrufs an den Serverprozess unternehmen wird. Eine Expressübermittlung wird im Arbeitsspeicher in die Warteschlange eingereiht, sodass sie ziemlich schnell ist, aber der Anruf geht verloren, wenn eine Computer- oder Netzwerkverbindung zur falschen Zeit ausfällt. Eine wiederherstellbare Zustellung wird in einer Datenträgerdatei bereitgestellt, bis sie übermittelt wird, sodass der Anruf auch bei einem Computerabsturz nicht verloren geht. Dies gewährleistet eine garantierte Zustellung, aber zu einem Leistungskostenaufwand, da jeder Aufruf auf den Datenträger geschrieben wird.

Sie können den MSMQ-Transport auch anweisen, auf die Bestätigung zu warten, dass der Anruf die Zielwarteschlange (Server) erreicht hat, bevor er zurückgibt. Wenn Sie diese Option auswählen, wird der Client blockiert, bis der Server den Aufruf bestätigt. Andernfalls kehrt die Steuerung sofort nach dem Aufruf an den Client zurück.

Mithilfe von Journaling können Aufrufe auf dem Datenträger protokolliert werden. Wenn das Journaling aktiviert ist, wird jeder Aufruf auf dem Datenträger protokolliert, während er auf dem Weg zum Serverprozess an den nächsten Hop übertragen wird.

Die Aufrufpriorität kann in Verbindung mit dem RPC-Funktionsattribut [message] verwendet werden, damit Aufrufe mit höherer Priorität Vorrang vor Aufrufen mit niedrigerer Priorität haben, auch wenn die Aufrufe mit hoher Priorität später eintreffen. Die Aufrufpriorität funktioniert auch eingeschränkt mit synchronem RPC, aber synchrone RPC-Aufrufe können nicht auf die gleiche Weise stapeln wie asynchrone Aufrufe.

Der Clientprozess steuert alle oben genannten Eigenschaften durch Aufrufen von RpcBindingSetOption. Nach dem Festlegen bleiben diese Eigenschaften in Kraft, bis sie in einem anderen Aufruf von RpcBindingSetOption geändert werden.

Der RPC-Serverprozess kann die Lebensdauer seiner Empfangswarteschlange steuern. Standardmäßig wird die Warteschlange gelöscht, wenn der Serverprozess beendet wird. Der Serverprozess kann jedoch rpcServerUseProtseqEpEx beim Einrichten des Endpunkts verwenden, um dem Transport mitzuteilen, dass die Warteschlange weiterhin vorhanden ist und Aufrufanforderungen akzeptiert werden, auch wenn der Serverprozess nicht ausgeführt wird. In diesem Fall werden die Aufrufe in die Warteschlange eingereiht und später ausgeführt, wenn der Serverprozess wieder online geschaltet wird.

Hinweis

Wenn Sie asynchrone [Message]-Aufrufe in einer Schnittstelle verwenden, müssen Sie die Schnittstelle registrieren, indem Sie RpcServerRegisterIf oder RpcServerRegisterIfEx aufrufen, bevor Sie RpcServerUseProtseqEpEx(ncadg_mq) aufrufen. Nachdem Sie die Protokollsequenz aktiviert haben, werden alle Aufrufe, die bereits auf die Warteschlange für den Server warten, aus der Warteschlange gelesen. Wenn die entsprechende RPC-Schnittstelle nicht registriert wurde, schlagen die Aufrufe fehl. Diese Situation kann auftreten, wenn Sie einen permanenten Endpunkt für Ihre Remoteprozeduraufrufe eingerichtet haben, der Server heruntergefahren wurde und Clients weiterhin Aufrufe an den Server senden. Diese Aufrufe werden in der Warteschlange gestapelt und warten darauf, gelesen zu werden, sobald der Server wieder online ist.

 

Weitere Informationen finden Sie unter RpcBindingSetOption, RpcServerUseProtseqEpEx und [message], ncadg_mq.