Могу ли я (легко) использовать стороннюю библиотеку для обработки сериализации для Java RMI?

Question

Мне очень нравится простота вызова удаленных методов через RMI в Java, но многословность его формата сериализации является основным убийством (да, я оценил, спасибо). Кажется, что архитекторы в Sun сделали очевидную правильную вещь, когда проектировали RPC (свободно говоря) компонент, но потерпели грандиозную неудачу, когда дело дошло до реализации сериализации.

И наоборот, кажется, что архитекторы Thrift, Avro, Kryo (особенно), буферов протоколов (не так много), и т. Д. обычно делали очевидные правильные вещи при разработке своих форматов сериализации, но либо делают не предоставлять механизм RPC, предоставлять тот, который излишне запутан (или незрел), или другой, который больше ориентирован на передачу данных, чем вызов удаленных методов (идеально подходит для многих целей, но не для того, что я ищу).

Итак, очевидный вопрос: как я могу использовать прелесть вызова метода RMI, но использовать одну из вышеуказанных библиотек для проводного протокола? Это возможно без большой работы? Оцениваю ли я слишком жестко одну из вышеупомянутых библиотек ( NB В целом я очень не люблю генерацию кода; мне несколько не нравятся ненужные аннотации, а также немного больше конфигурирование XML; любые "бины" делают меня cringe - мне не нужен вес, в идеале я просто хочу реализовать интерфейс для своих удаленных объектов, как в RMI).

Answer 1

Давным-давно у меня было такое же требование.Я изменил аргументы методов rmi и возвращаемые типы на byte [].

Я сериализовал объекты с моим предпочтительным сериализатором в байтовый массив, затем вызвал мои модифицированные методы rmi.

Ну, как вы упомянулиСериализация Java слишком многословна, поэтому 5 лет назад я реализовал эффективный по пространству алгоритм сериализации.Это экономит слишком много места, если вы отправляете очень сложный объектный граф. Недавно мне пришлось перенести эту реализацию сериализации на GWT, потому что сериализация GWT в режиме Dev невероятно медленная.

Как пример;

метод rmi

public void saveEmployee(Employee emp){
  //business code
 }

вы должны изменить его, как показано ниже,

public void saveEmployee(byte[] empByte) {
        YourPreferredSerializer serialier =   YourPreferredSerializerFactory.creteSerializer();
        Employee emp = (Employee) serializer.deSerialize(empByte);
        //business code
    }

РЕДАКТИРОВАТЬ:

Вы должны проверить MessagePack ,это выглядит многообещающе.

Answer 2

Сериализация Java является только многословной, где она описывает классы и поля, которые это сериализует. В целом, формат такой же «самоописание», как и XML. Вы можете переопределить это и заменить его чем-то другим. Вот для чего нужны методы writeClassDescriptor и readClassDescriptor. Dirmi переопределяет эти методы, и поэтому он может использовать стандартную сериализацию объектов с меньшими накладными расходами.

То, как это работает, связано с тем, как работают его сеансы. Обе конечные точки могут иметь разные версии объекта, поэтому простое отбрасывание дескрипторов класса не сработает. Вместо этого происходит обмен дополнительными данными (в фоновом режиме), так что сериализованный дескриптор заменяется идентификатором сеанса. Увидев идентификатор, проверяется таблица поиска, чтобы найти объект дескриптора. Поскольку данные обмениваются в фоновом режиме, после создания сеанса существует короткий «период прогрева», и каждый раз, когда тип объекта записывается впервые.

В настоящее время Dirmi не может заменить формат проводов.

Answer 3

writeReplace () и readResolve (), вероятно, являются лучшей комбинацией для этого.Могучий могучий в правильных руках.

Answer 4

Я не думаю, что есть способ повторно подключить RMI, но это могут быть конкретные проекты замены - я специально думаю о DiRMI - может?И / или владельцы проектов могут быть заинтересованы в помощи (Брайан, его автор, очень компетентный инженер по программированию на Amazon.com).

Еще один интересный проект - Protostuff -- его автор тоже строит каркас RPC (я думаю);но даже без него поддерживается впечатляющий диапазон форматов данных;и делает это очень эффективно (в соответствии с https://github.com/eishay/jvm-serializers/wiki/).

Кстати, лично я считаю, что самая большая ошибка, которую допустило большинство проектов (например, PB, Avro), заключается в том, что должное разделение между RPC и сериализацией не разделяется.сделать RPC с использованием подключаемого формата данных или поставщиков сериализации мне кажется хорошей идеей.