Udostępnij przez


Tworzenie aplikacji kolejkowych RPC-Message

Aby skorzystać z transportu MSMQ w aplikacji RPC, wymaga to niewiele wysiłku. W przypadku obsługi komunikatów synchronicznych należy określić tylko transport kolejki komunikatów (ncadg_mq) jako sekwencję protokołu. Protokół ncadg_mq obsługuje wszystkie standardowe cechy datagramu z wyjątkiem wywołań rozgłaszanych. Należy również pamiętać, że obecnie transport kolejki komunikatów nie obsługuje dynamicznych punktów końcowych.

Stosując atrybut [message] do zdalnych deklaracji procedur w pliku IDL, automatycznie implementujesz kolejkowanie komunikatów trybu asynchronicznego dla tych wywołań. Dzięki temu aplikacje klienckie i serwerowe mogą kontrolować wiele właściwości skojarzonych z komunikatami i kolejkami komunikatów, w tym:

  • Jakość usług
  • Potwierdzenie odbioru
  • Dziennikowanie
  • Priorytet połączenia
  • Trwałość kolejki procesów serwera

Jakość usług to nakład pracy, który transport wykona w celu dostarczenia wywołania do procesu serwera. Ekspresowa przesyłka zostanie umieszczona w pamięci, więc jest dość szybka, ale połączenie zostanie utracone, jeśli komputer lub połączenie sieciowe zawiedzie w nieodpowiednim momencie. Odzyskiwalna dostawa zostanie zapisana do pliku na dysku do momentu jej dostarczenia, więc połączenie nie zostanie utracone, nawet w obliczu awarii komputera. Zapewnia to gwarantowane dostarczanie, ale kosztem wydajności, ponieważ każde wywołanie jest zapisywane na dysku.

Możesz również ustawić transport MSMQ, aby czekał na potwierdzenie, że wywołanie dotarło do kolejki docelowej (serwera) przed zwróceniem odpowiedzi. Wybranie tej opcji powoduje zablokowanie klienta do momentu potwierdzenia wywołania przez serwer. W przeciwnym razie kontrolka zwraca się do klienta natychmiast po wywołaniu.

Za pomocą dziennika można rejestrować wywołania na dysku. Jeśli dziennik jest włączony, każde wywołanie jest rejestrowane na dysku, gdy jest przesyłane do następnego przeskoku w drodze do procesu serwera.

Priorytet wywołania można stosować w połączeniu z atrybutem funkcji RPC [komunikat], aby wywołania o wyższym priorytecie miały pierwszeństwo przed wywołaniami o niższym priorytecie, nawet jeśli te o wysokim priorytecie dotrą później. Priorytet wywołań będzie również działać w ograniczony sposób z synchronicznymi wywołaniami RPC, ale synchroniczne wywołania RPC nie mogą nawarstwiać się w taki sam sposób, jak wywołania asynchroniczne.

Proces klienta steruje wszystkimi powyższymi właściwościami, wywołując RpcBindingSetOption. Po ustawieniu te właściwości pozostają w mocy, dopóki nie zostaną zmienione w innym wywołaniu RpcBindingSetOption.

Proces serwera RPC może kontrolować okres istnienia kolejki odbierania. Domyślnie kolejka jest usuwana po zakończeniu procesu serwera. Jednak proces serwera może użyć RpcServerUseProtseqEpEx podczas konfigurowania punktu końcowego, by zlecić transportowi utrzymywanie kolejki i akceptowanie żądań wywołań, nawet gdy proces serwera nie jest uruchomiony. W takim przypadku wywołania są kolejkowane i wykonywane później, gdy proces serwera ponownie się połączy.

Notatka

Jeśli używasz asynchronicznych wywołań [komunikatu] w interfejsie, musisz zarejestrować interfejs, wywołując RpcServerRegisterIf lub RpcServerRegisterIfEx przed wywołaniem RpcServerUseProtseqEpEx(ncadg_mq). Po włączeniu sekwencji protokołu wszystkie wywołania oczekujące już w kolejce dla serwera zaczną być odczytywane z kolejki. Jeśli odpowiedni interfejs RPC nie został zarejestrowany, wywołania zakończy się niepowodzeniem. Taka sytuacja może wystąpić, jeśli masz stały punkt końcowy dla zdalnych wywołań procedur, serwer został zamknięty, a klienci nadal wysyłają wywołania do serwera. Te wywołania zostaną ułożone w kolejce, czekając na odczyt po powrocie serwera do trybu online.

 

Aby uzyskać więcej informacji, zobacz RpcBindingSetOption, RpcServerUseProtseqEpExi [komunikat], ncadg_mq.