SOA Design Patterns: Dual Protocols
W jaki sposób pokonać ograniczenia standardowego protokołu inwentarza usług, nie łamiąc przy tym zgodności ze standardami?
Wzorzec Canonical Protocol zaleca wykorzystania jednego, standardowego, protokołu do komunikacji między usługami w ramach jednego inwentarza. Domyślnie oczywiście, protokołem tym są jakiegoś rodzaju usługi webowe (Basic WS, WS-*, REST), jednak nie jest to twarde wymaganie. Niezależnie od wyboru standardowego protokołu, mogą zdarzyć się sytuacje, kiedy jest on z jakichś przyczyn nieodpowiedni.
Przyczyny te mogą dotyczyć m.in.
- ograniczenia zakresu wykorzystania usługi do tej samej maszyny, co oznacza brak konieczności komunikacji zdalnej
- ograniczenie zakresu wykorzystania usługi do tej samej technologi
- konieczność zapewnienia zgodności wstecz dla klienta o szczególnych wymaganiach
Rozwiązaniem problemu niedopadowania protokołu standardowego jest wzorzec Dual Protocols. Jak sama nazwa wskazuje, wzorzec ten zaleca zastosowanie dwóch (ogólnie – wielu) protokołów dostępu do jednej usługi. Każda usługa inwenatrza powinna bowiem być udostępniona w oparciu o protokół standardowy; dodatkowo zaś może udostępniać inne punkty końcowe obsługujące protokoły specyficzne dla danego zastosowania.
Wzorzec ten jest świetnym przykładem tego, do czego w architekturze zorientowanej na usługi możemy wykorzystać WCF. Dual Protocols może być świetnie zaimplementowany za pomocą różnych binding-ów przypisanych do jednej usługi. Dzięki temu możemy zrobić śmiałe założenia, że cała komunikacja w naszym systemie jest zorientowana usługowo, natomiast:
- komponenty zbudowane w oparciu o .NET mogą korzystać z komunikacji via TCP
- komponenty wdrożone na tych samych maszych mogą korzystać z komunikacji IPC
Dzięki temu i wilk jest syty, i owca cała.
