Mechanizm publikowania w OPC Unified Architecture (czyli jak zrealizować mechanizm asynchroniczny w synchronicznym świecie OPC UA).

W poprzedniej części opisałem ustawienia subskrypcji i elementów monitorowanych, teraz kontynuując przytoczony przykład chciałbym przybliżyć mechanizm publikowania.

Po stworzeniu subskrypcji i elementów monitorowanych oraz ustawieniu wszystkich potrzebnych parametrów, klient może przejść do obsługi mechanizmu publikowania. Zagadnienie mogłoby się wydawać proste: klient wywołuje funkcję Publish() (jak na poniższym rysunku), ale tak na prawdę wykorzystywana jest bardziej skomplikowana maszyneria.

W architekturach zorientowanych obiektowo (SOA) typowe jest, to że klient łączy się z serwerem, najczęściej jest to prosta operacja. Natomiast niespotykana jest (i często niemożliwa) sytuacja, w której to serwer nawiązuje połączenie do klienta, a przecież z takim mechanizmem mieliśmy do czynienia w subskrypcjach OPC Classic (opartych o technologię DCOM). Pamiętajmy jednak, że takie połączenia były co prawda doskonałym rozwiązaniem usprawniającym komunikację (oferując możliwość uzyskiwania odpowiedzi w sposób asynchroniczny), ale jeśli chodzi o konfiguracje połączenia to były bolączką tamtej specyfikacji, a powodów dla których takie połączenie mogło być nie możliwe bywało wiele (np. firewall, NAT lub np. problem związany z uprawnieniami). Jak więc są przysyłane powiadomienia o zdarzeniach czy nowych danych? Otóż klient używa funkcji Publish, wtedy serwer zbiera dane konieczne do wysłania i wysyła je. Następnie klient wykonuje Publish raz jeszcze. Teraz serwer (jeśli nowe dane się nie pojawiły) czeka z odpowiedzią, aż będzie miał gotowe dane. Oczywiście takie oczekiwanie nie może trwać wiecznie, a czas oczekiwania powinien być zależny od wybranego sposobu transmisji, jednak jeśli nowe dane się nie pojawią serwer powinien odpowiedzieć wiadomością KeepAlive. W ten sposób serwer potwierdza, że „żyje” i odpowiada. KeepAlive jest po prostu pustą odpowiedzią na wywołanie Publish. Metoda Publish jest więc pewnego rodzaju tokenem, który jest przesyłany od klienta do serwera i serwer dzięki niemu wie że może przy pomocy tokenu przesłać do klienta jakieś dane. Oczywiście klient musi czekać z kolejnym wywołaniem Publish, dopóki nie otrzyma odpowiedzi na poprzedni Publish. Taka strategia sprawdza się oczywiście w przypadku, gdy sieć (medium) poprzez którą przesyłamy dane jest szybka, a czas przesyłania jest bardzo krótki. Reasumując ta metoda działa więc jak pewnego rodzaju callback (na rysunku nazwane: "Quasi Callback"), chociaż oczywiście to klient wysyła token do serwera, umożliwiając serwerowi przesłanie danych razem z tokenem.

(To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, autor: Maciej Zbrzezny)