wtorek, 24 lutego 2009

OPC Unified Architecture (OPC UA) jako przykład nowoczesnego podejścia do tworzenia standardu

OPC Classic, czyli OPC bazujące na technologii DCOM, powoli odchodzi... dlaczego?? Dlatego, że to co na początku było motorem do upowszechnienia się standardu, czyli wygodny interfejs programistyczny bazujący na modelu DCOM, teraz jest raczej kulą u nogi. Dzisiaj świat zna nowsze i wygodniejsze (od COM i DCOM) sposoby komunikacji. Sam Microsoft prowadzając platformę .NET i WCF pokazał, że dni DCOM’a są policzone.

Twórcy OPC UA postanowili więc wybrać inne technologie, przy pomocy których ma się odbywać komunikacja. Wybór padł na Web Serwisy i binarne strumienie danych. Pierwsza z tych technologii jest już od kilku lat powszechnie uznanym standardem w komunikacji w sieci Internet. Jest więc ona już sprawdzona, a narzędzia pozwalające na jej wykorzystanie dostępne są na wielu platformach. Drugi sposób jest sposobem niestandardowym i polega na binarnym kodowaniu danych i wywołań, OPC UA precyzyjnie opisuje w jaki sposób kodowanie ma się odbywać.

Pojawia się jednak pytanie, na jak długo wystarczą te rozwiązania, co jeśli powstanie coś nowego, czy warto się więc na stałe wiązać z danym rozwiązaniem? Nauczka z DCOM’em daje chyba jednoznaczną odpowiedź: NIE. Twórcy OPC UA podeszli więc do tej sprawy w dość pomysłowy sposób.

Trzeba zauważyć, że OPC UA specyfikuje pewien abstrakcyjny opis usług (głównie w specyfikacji OPC UA części 4). Opis usług nie jest związany z żadnym konkretnym sposobem komunikacji lub technologią komunikacyjną. Dopiero inna część specyfikacji (specyfikacja OPC UA część 6) opisuje ich implementację z wykorzystaniem konkretnej technologii (ang technology mapping). Aktualnie specyfikacji zakłada użycie Web Serwisów i binarnych strumieni danych, ale pozostawia również furtkę, że w przyszłości wykorzystany zostanie inny sposób wymiany danych (zmieni się sposób przesyłania wiadomości, ale model usługowy i model informacyjny pozostanie bez zmian).

Dodatkowo OPC UA nie precyzuje natomiast konkretnego API (Application Program Interface – Intefejs programowy aplikacji), tak jak to miało miejsce w przypadku OPC Classic opartego o DCOM. OPC UA specyfikuje format przesyłanych wiadomości. Stosy komunikacyjne klienta lub serwera użyte do zaszyfrowania lub odszyfrowania danych, wywołań lub odpowiedzi również nie są definiowane. Stosy komunikacyjne różnych dostawców powinny być w stanie komunikować się, jeśli tylko używają tej samej technologii (ang. technology mapping).

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

1 komentarz:

Posty powiązane / Related posts