W poprzedniej części artykułu opisane zostało podejście, przy pomocy którego abstrakcyjne opisane usługi mapowane są na określone technologie przesyłu danych i wywołań. Przyjrzyjmy się więc architekturze takiego rozwiązania.
Na samym dole znajdują się różne źródła danych, do których ma dostęp serwer OPC UA. Serwer OPC UA dysponuje pewnym interfejsem, do którego jest dostęp poprzez różne technologie i platformy programistyczne, takie jak:
Serwisy internetowe (Web Services, WS- ), np. oparte o WSE 2.0,
WCF,
Java
Stos w ANSI C
Oczywiście część z nich bazuje na przesyłaniu danych tekstowych, a część bazuje na strumieniach binarnych. Tutaj należy zwrócić uwagę na fakt, że w odróżnieniu od OPC Classic (bazującego na DCOM’ie), OPC UA definiuje dokładnie przesyłane dane (a nie interfejs programistyczny (API)).
Po stronie klienta, znajduje się zaimplementowana moduł klienta OPC UA oraz odpowiednie moduły pozwalające na skorzystanie z pewnej infrastruktury komunikacyjnej do wymiany danych.
W zasadzie nieistotne jest z jakiej infrastruktury, czy technologii komunikacyjnej korzystają klient czy serwer, ważne jest natomiast by obydwa te komponenty wpierały ten sam sposób wymiany danych.
(To tylko jedna z części artykułu zobacz pozostałe: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11)
Ciekawe informacje
OdpowiedzUsuńŚwietny i bardzo wartościowy wpis. Podoba mi się.
OdpowiedzUsuń