Есть сервер на Java. К нему будут клиенты, пока на C++, потом - мало ли на чем.
Для общения клиента и сервера нужен какой-то протокол.
Было бы все в пределах JVM - можно было бы пересылать Java-объекты и все.
Можно пересылать строки, но это не выход.
=>
Нужно делать какой-то протокол, который смогут использовать все.
Я бы просто описал нужные мне структуры в C и пересылал бы их.
Но, я не знаю, что мне с ними делать в Java. Не буду же я их руками выдирать из byte[]
Отсюда вопрос:
Как работатать в Java со структурами C?
Либо: как лучше организовать такое взаимодействие? (XML и прочие громоздкие штуки не пройдут, т.к. клиенты предполагаются для мобильных устройств => ограничения в траффике)

1. Можно пересылать строки, это таки выход.
2. Можно пересылать byte[] - "выдирать", используя java.nio.ByteBuffer 

Нет. В них очень много избыточной информации (если, например, числа слать) + их потом парсить надо, что то же не айс.


Вот для этого хотелось бы какую-нибудь либу или какой-то автоматизированный метод. Т.к. разных сообщений может быть сколько угодно и для каждого писать свой парсер не рационально.
По идее, проблема должна быть не новая и что-то стандартное должно быть, только я не знаю что.

для byte[] - ByteBuffer.    

BSOD, 

XML можно сжимать перед передачей - экономия на трафике. 


Посмотрите еще CORBA.

На мобильных устройствах???   

А в чем проблема? 

Hessian - бинарный протокол и имеет реализацию для многих языков.

XML сжимать - не дело, всеравно много выйдет.
CORBA - боюсь тоже громоздкая штука для моих задач
Hessian - спасибо, сейчас читаю про него
Пока гуглил про hessian, наткнулся на http://code.google.com/intl/ru/apis/protocolbuffers/ . Вроде как тоже подходит. Кто что про него может скаать?

И все-таки, ради интереса, если бы я не мог выбирать протокол, допустим на клиенте, а был бы у меня только набор хидеров со структурками и спецификация - что тогда делать? Разбирать каждую структуру руками из ByteBuffer... а если их 100, 1000 ?

Да, разбирать каждую структуру. На мой взгляд, это не самая большая проблема. Для каждого сообщения наверное надо писать обработчик (логику). Заодно и парсер написать. Парсер - это же формальная работа.

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

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



Это сообщение отредактировал(а) COVD - 3.7.2010, 16:55

Ясно вообщем, итог выходит такой:
Если есть доступ к обеим сторонам и есть выбор - можно использовать бинарные протоколы. Они есть уже реализованные: Hessian, Google protobuffs и д.р. Там все уже реализовано, они довольно удобны (не надо писать свои обработчики для каждого сообщения, это все уже сделано). Для себя выбрал Google protobuffs, вроде как более компактная штука.
Если доступа нет, а есть только жестко заданная структура - тогда лучше не использовать Java, либо делать какой-то "мост" на C/С++ и им подобных, который будет преобразовывать данные в нужный формат.
Всем спасибо.

NioByffer что юзает apache в проекте MINA так какраз от си есть спец фишки типа getUnsignetInt()

Это сообщение отредактировал(а) Felixx - 16.11.2011, 05:57