Dlaczego Web Sockets nie używają SOAP?

Question

Po pierwsze, nie zamierzam ani wrogości, ani negacji, chcę tylko poznać ludzkie myśli. Zajmuję się dwukierunkową komunikacją między klientem a serwerem; klient będący aplikacją internetową. W tym momencie mam kilka opcji: opatentowane przez MS połączenie duplex, z tego, co słyszę niewiarygodne i nienaturalne: kometa i gniazda internetowe (dla obsługiwanych przeglądarek).

Wiem, że to pytanie zostało zadane w inny sposób tutaj, ale mam bardziej szczegółowe pytanie dotyczące podejścia. Rozważając gniazda sieciowe są po stronie klienta, kod klienta znajduje się w JavaScript. Czy naprawdę jest intencją zbudowanie dużej części aplikacji bezpośrednio w JavaScript? Dlaczego W3C nie zrobił tego w serwisach internetowych? Czy nie byłoby łatwiej, gdybyśmy mogli korzystać z SOAP w celu zawierania umów i definiowania zdarzeń wraz z istniejącymi komunikatami? Po prostu czuję jak krótki koniec patyka.

Dlaczego nie uczynić prostym i skorzystać z dynamicznego charakteru JS i pozostawić większość kodu tam, gdzie należy ... na serwerze?

Zamiast

mysocket.send("AFunction|withparameters|segmented"); 

moglibyśmy powiedzieć

myServerObject.AFunction("that", "makessense"); 

i zamiast

... 
mysocket.onmessage = function() { alert("yay! an ambiguous message"); } 
... 

moglibyśmy powiedzieć

... 
myServerObject.MeaningfulEvent = function(realData) { alert("Since I have realistic data...."); alert("Hello " + realData.FullName); } 
... 

HTML 5 trwał wiecznie, aby zająć ... czy zmarnowaliśmy duży wysiłek w niewłaściwym kierunku? Myśli?

Answer 1

Brzmi dla mnie tak, jakbyście jeszcze nie w pełni pojęli koncepcje wokół Websockets. Na przykład można powiedzieć:

Zważywszy gniazd internetowych są po stronie klienta

To nie jest przypadek, gniazda ma 2 strony, można myśleć o nich jako serwerem a klientem, jednak po połączenie jest ustanowione rozróżnianie rozmycia - można wtedy pomyśleć o klient i serwer jako "peers" - każdy może napisać lub odczytać do rury, która je łączy (połączenie z gniazdem) w dowolnym momencie. Podejrzewam, że możesz czerpać korzyści z uczenia się trochę więcej o pracy HTTP nad TCP - WebSockets jest podobny/analogiczny do HTTP w ten sposób.

Jeśli chodzi o SOAP/WSDL, z punktu widzenia konwersacji wokół TCP/WebSocket/HTTP można traktować wszystkie konwersacje SOAP/WSDL jako identyczne z HTTP (tj. Normalny ruch na stronie WWW).

Wreszcie, należy pamiętać o skumulowany charakter programowania sieciowego, na przykład SOAP/WSDL wygląda następująco:

SOAP/WSDL 
--------- (sits atop) 
HTTP 
--------- (sits atop) 
TCP 

I WebSockets wyglądać następująco

WebSocket 
--------- (sits atop) 
TCP 

HTH.

Answer 2

WebSocket sprawia, że ​​Comet i wszystkie pozostałe techniki przekazywania HTTP są czytelne, umożliwiając wysyłanie żądań z serwera. Jest to rodzaj gniazda sandboxed i daje nam ograniczoną funkcjonalność.

Jednak interfejs API jest wystarczająco ogólny, aby autorzy bibliotek i bibliotek mogli ulepszyć interfejs w dowolny sposób. Na przykład, możesz napisać usługę RPC lub RMI w stylu WebSockets, która pozwala na wysyłanie obiektów przez przewód. Teraz wewnętrznie są one przekształcane do postaci szeregowej w nieznanym formacie, ale użytkownik usługi nie musi tego wiedzieć i nie dba o to.

więc myśleć z spec autorów POV, począwszy od

mysocket.send("AFunction|withparameters|segmented"); 

do

myServerObject.AFunction("that", "makessense"); 

jest stosunkowo proste i wymaga pisanie małą otoki wokół WebSocket tak że serializacji i deserializacji dzieje opaquely do aplikacji . Jednak przejście w odwrotnym kierunku oznacza, że ​​autorzy specyfikacji muszą stworzyć znacznie bardziej złożone API, które stanowi słabszą podstawę do pisania kodu na wierzchu.

Answer 3

JavaScript umożliwia klientom komunikację za pośrednictwem protokołu HTTP z XMLHttpRequest. WebSockets rozszerza tę funkcjonalność, aby umożliwić JavaScriptowi wykonanie arbitralnych operacji we/wy sieci (nie tylko HTTP), która jest logicznym rozszerzeniem i umożliwia korzystanie z wszelkiego rodzaju aplikacji, które muszą korzystać z ruchu TCP (ale nie mogą korzystać z protokołu HTTP) do JavaScript. Myślę, że logiczne jest to, że skoro aplikacje nadal przechodzą do chmury, to HTML i JavaScript obsługują wszystko, co jest dostępne na pulpicie.

Podczas gdy serwer może wykonywać operacje wejścia/wyjścia sieci innego niż HTTP w imieniu klienta JavaScript i udostępnia tę komunikację przez HTTP, nie zawsze jest to najbardziej odpowiednie lub wydajne rozwiązanie. Na przykład nie ma sensu dodawać dodatkowego kosztu podróży w obie strony podczas próby utworzenia internetowego terminalu SSH. WebSockets umożliwia JavaScriptowi bezpośrednią rozmowę z serwerem SSH.

Co do składni, jego część oparta jest na XMLHttpRequest. Jak zostało wskazane w innym poście, WebSockets to dość niski poziom API, który może być zawijany w bardziej zrozumiały. Ważniejsze jest to, że WebSockets obsługuje wszystkie niezbędne aplikacje, niż że ma najbardziej elegancką składnię (czasem skupienie się na składni może prowadzić do bardziej restrykcyjnej funkcjonalności). Autorzy bibliotek zawsze mogą sprawić, że ten bardzo ogólny interfejs API będzie łatwiejszy do zarządzania innym programistom aplikacji.

Answer 4

Jak zauważyłeś, WebSockets ma niskie koszty stałe. Narzut jest podobny do normalnych gniazd TCP: tylko dwa bajty więcej na ramkę w porównaniu do setek dla AJAX/Comet.

Dlaczego niski poziom zamiast jakiejś wbudowanej funkcjonalności RPC? Niektóre myśli:

• to nie jest takie trudne do podjęcia istniejącego protokołu RPC i warstwę go na protokole gniazdo niskiego poziomu. Nie można pójść w przeciwnym kierunku i zbudować niskiego poziomu połączenia, jeśli założymy narzut RPC.

• Obsługa WebSockets to dość banalna, aby dodać do wielu języków po stronie serwera. Ładunek jest po prostu ciągiem znaków UTF-8 i prawie każdy język ma wbudowaną efektywną obsługę tego. Mechanizm RPC nie tak bardzo. Jak radzisz sobie z konwersjami typów danych między Javascriptem a językiem docelowym? Czy musisz dodawać podpowiedzi do typu po stronie JavaScript? A co z argumentami o zmiennej długości i/lub listami argumentów? Czy budujesz te mechanizmy, jeśli język nie ma dobrej odpowiedzi? Itd.

• Który z mechanizmów RPC zostałby zamodelowany? Czy wybrałbyś już istniejący (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) lub zupełnie nowy?

• Kiedy obsługa klienta jest dość uniwersalna, wiele serwisów z normalnym gniazdem TCP doda obsługę WebSockets (ponieważ dodawanie jest dość banalne). To samo nie jest prawdą, jeśli WebSockets był oparty na RPC. Niektóre istniejące usługi mogą dodawać warstwę RPC, ale w większości usług WebSockets będą tworzone od zera.

Dla mojego noVNC projektu (klienta VNC przy użyciu tylko JavaScript, płótno, WebSockets) nisko nad głową charakter WebSocket ma kluczowe znaczenie dla osiągnięcia rozsądnego działania. Dopóki serwery VNC nie obsługują WebSockets, noVNC zawiera wsproxy, które jest ogólnym proxy WebSockets do gniazda TCP.

Jeśli zastanawiasz się nad wdrożeniem interaktywnej aplikacji internetowej i nie zdecydowałeś się na język po stronie serwera, to sugeruję, aby przyjrzeć się Socket.IO, która jest biblioteką dla node (JavaScript po stronie serwera za pomocą silnika Google V8).

Oprócz wszystkich zalet węzła (ten sam język po obu stronach, bardzo wydajny, biblioteki mocy itp.), Gniazdo.IO daje ci kilka rzeczy:

• Udostępnia bibliotekę szkieletową klienta i serwera do obsługi połączeń.

• Wykrywa najlepszy transport obsługiwany przez klienta i serwer. Transport obejmuje (od najlepszych do najgorszych): rodzime WebSockets, WebSockets używające emulacji flash, różne modele AJAX.

• Konsekwentny interfejs bez względu na rodzaj transportu.

• Automatyczne kodowanie/dekodowanie typów danych JavaScript.

Utworzenie mechanizmu RPC na górze Socket.IO byłoby trudne, ponieważ obie strony mają ten sam język z tymi samymi rodzimymi typami.

Answer 5

Wpadłem na ten sam problem, w którym potrzebowałem zrobić coś w rodzaju call('AFunction', 'foo', 'bar'), zamiast serializować/dekretyzować każdą interakcję. Wolałbym zostawić większość kodu na serwerze i po prostu użyć Javascriptu, aby obsłużyć widok. WebSockets były lepiej dopasowane ze względu na naturalne wsparcie dla komunikacji dwukierunkowej. Aby uprościć tworzenie aplikacji, stworzyłem warstwę na górze WebSockets, aby wykonać zdalne wywołania metod (takie jak RPC).

Opublikowałem bibliotekę RMI/RPC pod adresem http://sourceforge.net/projects/rmiwebsocket/. Po skonfigurowaniu komunikacji między stroną internetową a serwletem można wykonywać połączenia w dowolnym kierunku. Serwer używa odbicia, aby wywołać odpowiednią metodę w obiekcie po stronie serwera, a klient używa metody wywołania JavaScript do wywoływania odpowiedniej funkcji w obiekcie po stronie klienta. Biblioteka używa Jackson, aby zająć się serializacją/deserializacją różnych typów Javy do/z JSON.

Answer 6

WebSocket JSR został wynegocjowany przez wiele stron (Oracle, Apache, Eclipse itp.), Wszystkie z bardzo różnymi programami.Równie dobrze zatrzymali się na poziomie transportu komunikatów i zostawili konstrukty wyższego poziomu. Jeśli potrzebujesz RMI do JavaScript RMI, sprawdź kod FERMI Framework.