Tworzenie typów wiadomości Service Broker
A Typ komunikatu definiuje nazwę określonego rodzaju wiadomości i sprawdzanie poprawności, Service Broker wykonuje na tego rodzaju wiadomości.Aby określić typy wiadomości, których aplikacja będzie używać, najpierw planowania zadań, które należy wykonać aplikacji i danych, które jest niezbędne do wykonania każdego zadania.
Najczęściej podejścia dla aplikacji jest struktura wiadomości, tak aby każda wiadomość zawiera informacje wymagane dla jednego kroku zadania.Podczas każdej wiadomości zawiera informacje o jednym kroku zadania, aplikacja może łatwo komunikat, wykonania i wysłać odpowiedź w ramach pojedynczej transakcji.Dlatego dla wielu aplikacji, najprostszym sposobem ustalenia typów wiadomości i zawartość wiadomości jest określić granice transakcji dla zadań wykonywanych przez aplikację.Każdy krok distinct jest transakcji i odpowiada każdej transakcji typ komunikatu wymienianych między służbami.Informacje o stanie, wyniki lub dane wyjściowe są również typy wiadomości.
Protokoły komunikacyjne Service Broker są przeznaczone do pracy z tym stylem obsługi wiadomości.Protokół okno dialogowe fragmenty dużych wiadomości do tranzytu i gwarantuje, że duże wiadomości uniemożliwia małych wiadomości przesyłanych.
Wybieranie typu sprawdzania poprawności
Sprawdzanie poprawności określonych wiadomości zależy od zawartości wiadomości.Powszechną praktyką jest używanie najbardziej restrykcyjne sprawdzania poprawności dostępne podczas badania, a następnie wybrać mniej restrykcyjne sprawdzanie poprawności, aby zwiększyć wydajność, gdy aplikacja jest rozmieszczana.Na przykład jest możliwe wymiany jako treść wiadomości, która określa poprawności brak maszynowy dokumentu XML.przypadek aplikacji sprawdza poprawność komunikatu podczas przetwarzania XML.
Format komunikatu sieci zawiera nazwę typ komunikatu.Dlatego typ komunikatu nazwy są często wybierany w celu uniknięcia problemów sortowanie i konflikty nazw.Aby uzyskać więcej informacji dotyczących nazw, zobacz Naming Service Broker obiektów.
Wskazując sukcesów i niepowodzeń
Zazwyczaj aplikacji nie definiuje nowe typy wiadomości oznacza sukces lub niepowodzenie.Zamiast tego należy użyć instrukcja zakończenia KONWERSACJI zakończeniu konwersacji i że zadanie powiodło się.Jeśli zadanie nie powiodło się, należy dołączyć opcję błąd zwraca komunikat o błędzie konwersację.
Ogólnie rzecz biorąc tylko jeden z uczestników w konwersacji należy zakończyć konwersację, po ukończeniu zadania.Inny uczestnik wystawia tylko KONWERSACJĘ końcowy w odpowiedzi na komunikat błędu lub końcowy w oknie dialogowym.W dokumentacji usługa określa ogólnie uczestnik, który kończy się konwersacji, jeśli konwersacji zakończy się pomyślnie.Udostępnianie tej dokumentacji pomaga uniknąć problemów, gdzie kończy się żaden uczestnik konwersacji lub gdzie jednego uczestnika kończy konwersacji, podczas gdy inny uczestnik jest nadal wykonywania zadań.Oba punkty końcowe muszą mieć możliwość przetwarzania komunikatów o błędach, ponieważ oba punkty końcowe są dostarczane wewnętrznego Service Broker wiadomości.Na przykład, jeśli okno dialogowe okres istnienia wygaśnie przed zamknięciem okna dialogowego, oba punkty końcowe Service Broker komunikat o błędzie.
Albo uczestnik może zakończyć konwersację z powodu błędu w dowolnym czas.Omówienie obsługi komunikatów o błędach Service Broker, zobacz Obsługa komunikatów o błędach Service Broker.
Zobacz także