Java-сервер ‹-› c# + javascript + java + * клиенты

Какую "технологию" вы бы предложили для обмена сообщениями между сервером Java и несколькими клиентами, написанными на C#, Javascript и Java?


Предыстория:

В нашем текущем проекте мы пытаемся создать общий интерфейс пользовательского интерфейса на Java (работающий на сервере), который затем «соединяется» с несколькими интерфейсами пользовательского интерфейса с помощью различных адаптеров пользовательского интерфейса (работает на клиенте, сервере или обоих) . Хотя нашей серверной технологией всегда будет Java, будут клиенты C# (Silverlight), JavaScript и Java. Возможно, в будущем будет еще больше (разные смартфоны, планшеты).

Серверная часть пользовательского интерфейса и интерфейсы пользовательского интерфейса взаимодействуют через набор более или менее простых сообщений (в основном пары имя/значение), каждое из которых инкапсулирует определенное изменение свойства/состояния/данных на клиенте или сервере соответственно. В течение одного цикла запроса несколько таких простых сообщений объединяются в одно большое сообщение, которое затем передается от бэкенда к интерфейсу или наоборот. На данный момент отправка и получение сообщений осуществляется через единую точку входа как на клиенте, так и на сервере. Таким образом, нет серверных методов, представленных как WebService и т. Д., Просто потому, что в нашем случае это определенно будет медленным.

Наш текущий прототип состоит исключительно из сервера Java, настольного клиента Java (Swing) и веб-клиента Java (Vaadin). Сообщение, которым обмениваются серверная и клиентская части, фактически представляет собой список POJO (каждый из которых представляет определенное «изменение»), сериализованных/десериализованных в/из XML. Все идет нормально.

Теперь к столу подходят C# и Javascript. Поскольку мы хотим работать с каким-то объектом в каждой технологии, мы подумали, что было бы неплохо указать сообщения/изменения/pojos на каком-то абстрактном языке, а затем сгенерировать объекты для каждого целевого языка. В какой-то момент эти объекты могут быть сериализованы/десериализованы и отправлены по сети (возможно, через http/s). Для этого мы подумали о буферах протокола Google или Thrift. Что вы думаете?

На данный момент нашего синхронного цикла запрос-ответ достаточно, но вскоре нам понадобится асинхронный запрос-ответ или сервер-пуш соответственно. Вот почему мы сразу подумали об использовании чего-то вроде ActiveMQ. Что вы думаете? Слишком много? Если нет, то как мы можем выполнить генерацию объекта, упомянутую выше (xsd, jaxb,? для js)? Есть ли лучшие способы? Я никогда не использовал ActiveMQ, но, согласно веб-сайту, это должно быть возможно с Java, C # (Spring.NET) и каким-то образом с Javascript (STOMP). Однако мне кажется, что это довольно сложно...

Любые советы, подсказки, опыт или комментарии по этой или смежным темам будут действительно полезны.

Заранее спасибо.


person Pauli    schedule 14.01.2011    source источник


Ответы (2)


Я бы рекомендовал использовать веб-сервисы. Язык WSDL определяет объекты и сообщения вашего протокола в абстрактной форме. Большинство современных языков, таких как Java и C#, имеют инструменты для преобразования WSDL в собственные типы и библиотеки для обработки ввода-вывода.

person Konstantin Komissarchik    schedule 14.01.2011
comment
Как я уже сказал, в настоящее время существует единственная точка входа на сервере/клиенте. По сути, именно здесь позже приходит запрос (HTTP), который инкапсулирует несколько сообщений, каждое из которых сопоставляется с POJO. Я не эксперт в веб-сервисах, но, насколько я понимаю, мне нужно будет предоставить несколько методов в качестве веб-сервиса (по одному для каждого изменения/POJO), чтобы получить соответствующий WSDL для создания объектов на целевом языке. Возможно, я ошибаюсь, но тогда это приведет к одному HTTP-запросу на изменение, что будет даже медленнее, чем WS по своей природе. А как насчет WSDL и JavaScript? - person Pauli; 15.01.2011
comment
Вы можете спроектировать свой WS так, как это имеет для вас смысл. Нет причин, чтобы было много мелких запросов. Это может быть несколько сложных запросов. Просто спроектируйте ввод и вывод службы соответствующим образом. - person Konstantin Komissarchik; 18.01.2011

Последние два года я занимаюсь созданием похожей системы: бэкэнд для нашего проекта — это c#, java и куча других языков, фронтенд — это телефонные клиенты для ios, android, symbian, все распространенные веб-браузеры и даже десктопные приложения для Windows.

Для всех этих сервисов мы используем JSON, так как он кажется наиболее широко поддерживаемым форматом на всех языках и платформах, он довольно быстро декодируется на клиентах по сравнению с решением на основе xml (особенно веб-браузеры/javascript) и имеет довольно низкие накладные расходы, которые очень хорошо сжимает, что отлично подходит для клиентов, которым не хватает пропускной способности.

person Martin Jespersen    schedule 14.01.2011
comment
JSON звучит разумно для меня. Вот почему я подумал о protobuf от Google, который в основном представляет собой двоичный JSON. Но как вы сделали сериализацию. Вы сериализовали свои объекты вручную в JSON с обеих сторон или у вас были (сгенерированные) объекты для каждого сообщения и целевого языка, которые сериализуются через библиотеку JSON? А как вы общались? Простой HTTP? - person Pauli; 15.01.2011
comment
Для c#/mvc мы используем модели и DataContractJsonSerializer. Для javascript мы используем, среди прочего, библиотеку json2, которая является дополнением для браузеров, таких как ie7, которые не имеют встроенной поддержки объекта JSON, и там это просто чистый json, поскольку инициализация объекта замедляется из-за количества данные, которые мы обрабатываем. javascript-часть нашей установки на самом деле очень длинная и сложная история, поскольку некоторых инструментов, которые нам нужны, не было на рынке, когда мы начинали проект два года назад, поэтому у нас есть довольно много собственных решений из-за наших потребностей в производительности. . - person Martin Jespersen; 15.01.2011
comment
Что касается остальных языков, которые я не знаю, я никогда не касался этой части проекта. - person Martin Jespersen; 15.01.2011
comment
Что касается общения, мы работаем на многих разных платформах, и, вероятно, их больше, чем я знаю. те, которые, как я знаю, мы используем: iis, apache и jetty (через них мы запускаем шлюз присутствия в реальном времени, используя библиотеку cometd). - person Martin Jespersen; 15.01.2011