Почему веб-сокеты не используют SOAP?

Question

Во-первых, я не собираюсь ни враждебности, ни пренебрежения, просто хочу знать мысли людей. Я смотрю на двунаправленную связь между клиентом и сервером; клиент, являющийся веб-приложением. На данный момент у меня есть несколько вариантов: проприетарное связывание MS, ненадежное и неестественное: кометы и веб-сокеты (для поддерживаемых браузеров).

Я знаю, что этот вопрос здесь задавался другими способами, но у меня есть более конкретный вопрос к подходу. Учитывая, что веб-сокеты на стороне клиента, клиентский код находится в JavaScript. Это действительно намерение построить большой кусок приложения непосредственно в JavaScript? Почему W3C не делал этого в веб-сервисах? Не было бы проще, если бы мы могли использовать SOAP для предоставления контракта и определения событий вместе с существующим обменом сообщениями? Просто похоже на короткий конец палки до сих пор.

Почему бы не упростить и не воспользоваться преимуществами динамической природы JS и не оставить большую часть кода там, где он принадлежит .... на сервере?

Вместо

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

мы могли бы сказать

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

и вместо

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

мы могли бы сказать

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

HTML 5 занял целую вечность ... мы потратили много сил в неправильном направлении? Мысли?

Answer 1

Похоже, вы еще не полностью поняли концепции Websockets.Например, вы говорите:

Учитывая, что веб-сокеты находятся на стороне клиента

Это не так, сокеты имеют 2 стороны, вы можете рассматривать их как сервер иКлиент, однако, как только соединение установлено, различие размывается - вы можете также думать о клиенте и сервере как о «равноправных узлах» - каждый может в любой момент записать или прочитать канал, который их соединяет (соединение с сокетом).Я подозреваю, что вам было бы полезно узнать немного больше о работе HTTP поверх TCP - WebSockets подобен / аналогичен HTTP таким образом.

Относительно SOAP / WSDL, с точки зрения разговора, окружающегоTCP / WebSocket / HTTP вы можете думать, что все разговоры SOAP / WSDL идентичны HTTP (то есть нормальному трафику веб-страницы).

Наконец, запомните стековую природу сетевого программирования, например SOAP / WSDLэто:

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

И WebSockets выглядят так

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

HTH.

Answer 2

Как вы заметили, WebSockets имеет низкие издержки .Издержки аналогичны обычным сокетам TCP: всего на два байта на кадр по сравнению с сотнями для AJAX / Comet.

Почему низкоуровневый, а не какая-то встроенная функциональность RPC?Некоторые мысли:

• Нетрудно взять существующий протокол RPC и наложить его на протокол низкоуровневого сокета.Вы не можете пойти в обратном направлении и создать низкоуровневое соединение, если предполагается использование RPC.

• Поддержка WebSockets довольно тривиально для добавления на несколько языковна стороне сервера.Полезная нагрузка - это просто строка UTF-8, и практически каждый язык имеет встроенную эффективную поддержку для этого.Механизма RPC не так уж много.Как вы обрабатываете преобразования типов данных между Javascript и целевым языком?Вам нужно добавить тип подсказки на стороне Javascript?Как насчет аргументов переменной длины и / или списков аргументов?Вы строите эти механизмы, если у языка нет хорошего ответа?И т.д.

• Какой механизм RPC будет смоделирован после?Вы бы выбрали существующий (SOAP, XML-RPC, JSON-RPC, Java RMI, AMF, RPyC, CORBA) или совершенно новый?

• Как только поддержка клиента станет достаточно универсальнойзатем многие службы, имеющие обычный сокет TCP, добавят поддержку WebSockets (потому что добавить это довольно просто).То же самое не верно, если WebSockets был основан на RPC.Некоторые существующие сервисы могут добавлять слой RPC, но по большей части сервисы WebSockets будут создаваться с нуля.

Для моего проекта noVNC (клиент VNC использует только JavascriptCanvas, WebSockets) низкая нагрузка на WebSockets имеет решающее значение для достижения разумной производительности.До тех пор, пока серверы VNC не включают поддержку WebSockets, noVNC включает wsproxy, который является универсальным прокси-сервером для сокетов WebSockets to TCP.

Если вы думаете о реализации интерактивного веб-приложения и не выбрали язык на стороне сервера, то ярекомендуем взглянуть на Socket.IO , который является библиотекой для узла (Javascript на стороне сервера с использованием движка Google V8).

В дополнение ко всем преимуществам узла (один и тот же язык с обеих сторон, очень эффективный, библиотеки питания и т. д.), Socket.IO предоставляет вам несколько вещей:

• Предоставляет библиотеку инфраструктуры клиента и сервера для обработки соединений.

• Определяет лучший транспорт, поддерживаемый как клиентом, так и сервером.Транспортировка включает (от лучшего к худшему): собственные WebSockets, WebSockets, использующие эмуляцию флэш-памяти, различные модели AJAX.

• Согласованный интерфейс независимо от используемого транспорта.

• Автоматическое кодирование / декодирование типов данных Javascript.

Было бы не так сложно создать механизм RPC поверх Socket.IO, поскольку обе стороны имеют один и тот же язык содни и те же нативные типы.

Answer 3

JavaScript позволяет клиентам общаться через HTTP с XMLHttpRequest. WebSockets расширяет эту функциональность, позволяя JavaScript выполнять произвольные сетевые операции ввода-вывода (не только HTTP), что является логическим расширением и позволяет переносить все виды приложений, которым необходимо использовать трафик TCP (но может не использовать протокол HTTP) в JavaScript. Я думаю, что вполне логично, что, поскольку приложения продолжают перемещаться в облако, HTML и JavaScript поддерживают все, что доступно на рабочем столе.

Хотя сервер может выполнять сетевой ввод-вывод, отличный от HTTP, от имени клиента JavaScript и делать это сообщение доступным через HTTP, это не всегда является наиболее подходящим и эффективным способом. Например, не имеет смысла добавлять дополнительную стоимость туда-обратно при попытке сделать онлайн-терминал SSH. WebSockets позволяет JavaScript напрямую взаимодействовать с сервером SSH.

Что касается синтаксиса, его часть основана на XMLHttpRequest. Как указывалось в другой публикации, WebSockets - это API довольно низкого уровня, который можно обернуть в более понятный. Более важно, чтобы WebSockets поддерживал все необходимые приложения, чем тот, который имеет самый элегантный синтаксис (иногда сосредоточение внимания на синтаксисе может привести к более ограничительной функциональности). Авторы библиотек всегда могут сделать этот общий API более удобным для других разработчиков приложений.

Answer 4

WebSocket делает Comet и все другие методы HTTP push-типа удобочитаемыми, позволяя отправлять запросы с сервера.Это своего рода гнездо в песочнице и дает нам ограниченную функциональность.

Однако API является достаточно общим для авторов фреймворков и библиотек для улучшения интерфейса любым желаемым способом.Например, вы могли бы написать некоторые службы в стиле RPC или RMI поверх WebSockets, которые позволяют отправлять объекты по проводам.Теперь внутренне они сериализуются в каком-то неизвестном формате, но пользователь сервиса не должен знать и не заботится о них.От 1007 * до

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

сравнительно легко и требует написания небольшой оболочки вокруг WebSockets, чтобы сериализация и десериализация происходили непрозрачно для приложения.Но движение в обратном направлении означает, что авторам спецификаций необходимо создать гораздо более сложный API, который создает более слабую основу для написания кода поверх него.

Answer 5

WebSocket JSR был согласован рядом сторон (Oracle, Apache, Eclipse и т. Д.), И все они придерживались самых разных целей. Также хорошо, что они остановились на уровне транспорта сообщений и оставили конструкции более высокого уровня. Если вам нужен RMI от Java к JavaScript, проверьте FERMI Framework .

Answer 6

Я столкнулся с той же проблемой, когда мне нужно было сделать что-то вроде call('AFunction', 'foo', 'bar'), а не сериализовать / десериализовать каждое взаимодействие.Я также предпочел оставить большую часть кода на сервере и просто использовать Javascript для обработки представления.WebSockets лучше подходили благодаря естественной поддержке двунаправленной связи.Чтобы упростить разработку приложений, я строю слой поверх WebSockets для выполнения удаленных вызовов методов (например, RPC).

Я опубликовал библиотеку RMI/RPC по адресу http://sourceforge.net/projects/rmiwebsocket/. После настройки связи между веб-страницей и сервлетом вы можете выполнять вызовы в любом направлении.Сервер использует рефлексию для вызова соответствующего метода в объекте на стороне сервера, а клиент использует Javascript-метод 'call' для вызова соответствующей функции в объекте на стороне клиента.Библиотека использует Джексона , чтобы заботиться о сериализации / десериализации различных типов Java в / из JSON.