XStream <-> Альтернативные двоичные форматы (например, буферы протокола) - PullRequest
Новая
       20

XStream <-> Альтернативные двоичные форматы (например, буферы протокола)

3 голосов
/ 16 марта 2010

В настоящее время мы используем XStream для кодирования входов / выходов наших веб-сервисов в XML. Однако мы рассматриваем возможность перехода на двоичный формат с генератором кода для нескольких языков (protobuf, Thrift, Hessian и т. Д.), Чтобы сделать поддержку новых клиентов более легкой и менее зависимой от ручного кодирования (а также для лучшей поддержки наших форматов сообщений, которые включают двоичные данные) .

Однако большинство наших объектов на сервере - это POJO с XStream, которые обрабатывают сериализацию с помощью отражения и аннотаций, и большинство из этих библиотек предполагают, что они сами будут генерировать POJO. Я могу придумать несколько способов взаимодействия с альтернативной библиотекой:

  1. Напишите маршалер XStream для целевого формата.

  2. Напишите пользовательский код для маршалинга POJO в / из классов, сгенерированных альтернативной библиотекой.

  3. Подкласс сгенерированных классов для реализации логики POJO. Может потребоваться переписать. (Также я упоминал, что мы хотим использовать терракоту?)

  4. Используйте другую библиотеку, которая поддерживает как отражение (например, XStream), так и генерацию кода.

Однако я не уверен, какая библиотека сериализации лучше всего подходит для вышеуказанных методов.

1 Ответ

1 голос
/ 04 апреля 2011

(1) может не быть , что много работает, так как многие библиотеки сериализации включают вспомогательный API, который знает, как читать / записывать примитивные значения и разделители.

(2), вероятно, предоставляет вам самый широкий выбор инструментов: https://github.com/eishay/jvm-serializers/wiki/ToolBehavior (некоторые не зависят от языка). Недостатки, но, надеюсь, не совсем бесполезные тесты: https://github.com/eishay/jvm-serializers/wiki

Многие из этих инструментов генерируют классы, которые требуют написания кода для преобразования в / из ваших POJO. Инструменты, которые работают с POJO напрямую, обычно не зависят от языка.

(3) кажется плохой идеей (ничего не знать о вашем конкретном проекте). Обычно в моих классах сообщений нет никакой другой логики.

(4) Библиотека Protostuff (которая поддерживает формат протокола буфера) позволяет написать «схему» , чтобы описать, как вы хотите, чтобы ваши POJO сериализовались. Но написание этой схемы может оказаться более трудоемким и более подверженным ошибкам, чем просто написание кода для преобразования между вашими POJO и классами, сгенерированными некоторыми инструментами.

Protostuff также может автоматически генерировать схему с помощью отражения, но это может привести к формату сообщения, который кажется немного ориентированным на Java.

...