Przegląd modelu kanału

Stos kanału programu Windows Communication Foundation (WCF) to stos komunikacji warstwowej z co najmniej jednym kanałem, który przetwarza komunikaty. W dolnej części stosu jest kanał transportowy, który jest odpowiedzialny za dostosowanie stosu kanału do bazowego transportu (na przykład TCP, HTTP, SMTP i innych typów transportu). Kanały zapewniają model programowania niskiego poziomu do wysyłania i odbierania komunikatów. Ten model programowania opiera się na kilku interfejsach i innych typach zbiorczo znanych jako model kanału WCF. W tym temacie omówiono kształty kanałów, konstrukcję podstawowego odbiornika kanału (w usłudze) i fabrykę kanałów (na kliencie).

Stos kanału

Punkty końcowe programu WCF komunikują się ze światem przy użyciu stosu komunikacyjnego nazywanego stosem kanału. Poniższy diagram porównuje stos kanału z innymi stosami komunikacyjnymi, na przykład TCP/IP.

Po pierwsze podobieństwa: W obu przypadkach każda warstwa stosu zapewnia abstrakcję świata poniżej tej warstwy i uwidoczniła abstrakcję tylko do warstwy bezpośrednio nad nią. Każda warstwa używa abstrakcji tylko warstwy bezpośrednio poniżej niej. Również w obu przypadkach, gdy dwa stosy komunikują się, każda warstwa komunikuje się z odpowiednią warstwą w innym stosie, na przykład warstwa IP komunikuje się z warstwą IP i warstwą TCP z warstwą TCP itd.

Teraz różnice: Chociaż stos TCP został zaprojektowany w celu zapewnienia abstrakcji sieci fizycznej, stos kanału został zaprojektowany w celu zapewnienia abstrakcji nie tylko sposobu dostarczania komunikatu, czyli transportu, ale także innych funkcji, takich jak to, co znajduje się w komunikacie lub jaki protokół jest używany do komunikacji, w tym transport, ale o wiele więcej. Na przykład element powiązania niezawodnej sesji jest częścią stosu kanału, ale nie znajduje się poniżej transportu ani samego transportu. Ta abstrakcja jest osiągana przez wymaganie dolnego kanału w stosie w celu dostosowania bazowego protokołu transportu do architektury stosu kanału, a następnie poleganie na kanałach dalej w stosie w celu zapewnienia funkcji komunikacji, takich jak gwarancje niezawodności i bezpieczeństwo.

Komunikaty przepływają przez stos komunikacji jako Message obiekty. Jak pokazano na rysunku powyżej, dolny kanał jest nazywany kanałem transportu. Jest to kanał odpowiedzialny za wysyłanie i odbieranie wiadomości do i z innych stron. Obejmuje to odpowiedzialność za przekształcenie Message obiektu do i z formatu używanego do komunikowania się z innymi stronami. Nad kanałem transportu może istnieć dowolna liczba kanałów protokołu, z których każdy jest odpowiedzialny za zapewnienie funkcji komunikacji, takiej jak niezawodne gwarancje dostarczania. Kanały protokołu działają na komunikatach przepływających przez nie w postaci Message obiektu. Zazwyczaj przekształcają komunikat, na przykład dodając nagłówki lub szyfrując treść albo wysyłając i odbierając własne komunikaty kontroli protokołu, na przykład potwierdzenia potwierdzenia potwierdzenia.

Kształty kanału

Każdy kanał implementuje co najmniej jeden interfejs znany jako interfejsy kształtu kanału lub kształty kanału. Te kształty kanału zapewniają metody zorientowane na komunikację, takie jak wysyłanie i odbieranie lub żądanie i odpowiadanie, że kanał implementuje i użytkownika wywołań kanału. Na podstawie kształtów kanału jest IChannel interfejs, który zapewnia metodę GetProperty<T> przeznaczoną jako mechanizm warstwowy w celu uzyskania dostępu do dowolnych funkcji uwidocznionych przez kanały w stosie. Pięć kształtów kanałów, które rozszerzają IChannel się, to:

• IInputChannel

• IOutputChannel

• IRequestChannel

• IReplyChannel

• IDuplexChannel

Ponadto każdy z tych kształtów ma odpowiednik, który rozszerza System.ServiceModel.Channels.ISessionChannel<TSession> obsługę sesji. Są to:

• IInputSessionChannel

• IOutputSessionChannel

• IRequestSessionChannel

• IReplySessionChannel

• IDuplexSessionChannel

Kształty kanału są wzorowane po niektórych podstawowych wzorcach wymiany komunikatów obsługiwanych przez istniejące protokoły transportu. Na przykład jednokierunkowa obsługa komunikatów odpowiada IInputChannel/IOutputChannel parze, żądanie-odpowiedź odpowiada IRequestChannel/IReplyChannel parom i dwukierunkowej komunikacji dwustronnej odpowiada IDuplexChannel (która rozszerza obie metody i ).IInputChannelIOutputChannel

Programowanie za pomocą stosu kanału

Stosy kanałów są zwykle tworzone przy użyciu wzorca fabryki, w którym powiązanie tworzy stos kanału. Po stronie wysyłania powiązanie służy do kompilowania ChannelFactoryelementu , który z kolei tworzy stos kanału i zwraca odwołanie do górnego kanału w stosie. Aplikacja może następnie użyć tego kanału do wysyłania komunikatów. Aby uzyskać więcej informacji, zobacz Programowanie na poziomie kanału klienta.

Po stronie odbierającej powiązanie jest używane do tworzenia IChannelListenerelementu , który nasłuchuje przychodzących komunikatów. Element IChannelListener udostępnia komunikaty do aplikacji nasłuchiwania, tworząc stosy kanałów i przekazując odwołanie aplikacji do górnego kanału. Następnie aplikacja używa tego kanału do odbierania komunikatów przychodzących. Aby uzyskać więcej informacji, zobacz Service Channel-Level Programming (Programowanie na poziomie kanału usługi).

Model obiektu kanału

Model obiektów kanału to podstawowy zestaw interfejsów wymaganych do implementowania kanałów, odbiorników kanałów i fabryk kanałów. Istnieją również niektóre klasy bazowe, które ułatwiają implementacje niestandardowe.

Odbiorniki kanału są odpowiedzialne za nasłuchiwanie przychodzących komunikatów, a następnie dostarczanie ich do warstwy powyżej za pośrednictwem kanałów utworzonych przez odbiornik kanału.

Fabryki kanałów są odpowiedzialne za tworzenie kanałów używanych do wysyłania komunikatów i zamykania wszystkich kanałów utworzonych podczas zamykania fabryki kanałów.

ICommunicationObject to podstawowy interfejs, który definiuje podstawową maszynę stanu, którą implementują wszystkie obiekty komunikacyjne. CommunicationObject Zapewnia implementację tego podstawowego interfejsu, z którego mogą pochodzić inne klasy kanałów, a nie z ponownego implementowania interfejsu. Nie jest to jednak wymagane: niestandardowy kanał może implementować ICommunicationObject bezpośrednio i nie dziedziczyć z klasy CommunicationObject. Żadna z klas na rysunku 3 nie jest traktowana jako część modelu kanału; są one pomocnikami dostępnymi dla niestandardowych implementatorów kanałów, którzy chcą tworzyć kanały.

W poniższych tematach opisano model obiektów kanału oraz różne obszary programistyczne, które ułatwiają tworzenie kanałów niestandardowych.