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

Question

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

Я знаю, что этот вопрос здесь задавался по-другому, но у меня есть более конкретный вопрос по поводу подхода.Учитывая, что веб-сокеты выполняются на стороне клиента, клиентский код находится на 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 Works на вершине TCP - Websockets аналогичны / аналогичны HTTP таким образом.

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

Наконец, помните сложенную природу сетевого программирования, например, мыло / WSDL выглядит так:

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

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

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

Хет

Answer 2

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

В то время как сервер может сделать не-HTT-сеть ввода / вывода от имени клиента JavaScript и сделать эту связь по сравнению с http, это не всегда самая подходящая или эффективная вещь. Например, не имеет смысла добавить дополнительную стоимость поездки на поездку при попытке сделать онлайн-терминал SSH. Websockets позволяет JavaScript говорить непосредственно на SSH-сервере.

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

Answer 3

Как вы отмечали WebSockets низкий наклад. Отказ Накладные расходы похожи на нормальные розетки TCP: всего два байта больше на раму по сравнению с сотнями для Ajax / Comet.

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

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

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

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

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

Для меня Novnc. Проект (клиент VNC, использующий только JavaScript, Hanvas, Websockets). Низкоустройшая природа WebSockets имеет решающее значение для достижения разумных показателей. Пока серверы VNC не включают поддержку Websockets, Novnc включает в себя WSProxy, которая является универсальным веб-сервером TCP Proxy.

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

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

• Обеспечивает как клиентскую и серверную структуру для обработки соединений.

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

• Последовательный интерфейс независимо от того, какой транспорт используется транспортировка.

• Автоматический кодирование / декодирование данных JavaScript DataTypes.

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

Answer 4

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

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

Так что думая со спецификации авторов POV, идут от

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

к

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

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

Answer 5

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

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

Answer 6

Websocket JSR была согласована рядом сторон (Oracle, Apache, Eclipse и т. Д.) Все с очень разными повестками дня. Это также так же, как они остановились на уровне передачи сообщений и покинули более высокий уровень. Если то, что вам нужно, это Java для JavaScript RMI, проверьте Fermi Framework.