Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Сериализация, имхо, вымирающее явление. Гораздо удобнее хранить объекты, скажем в XML — это удобочитаемо, просто и понятно. Тут нам на помощь приходит стандарт JAXB.
Кстати непонятно, почему еще в пятой Джаве не сделали аннотацию для Serializable.
Кстати непонятно, почему еще в пятой Джаве не сделали аннотацию для Serializable.
Удобнее — да, а по скорости загрузки-выгрузки Serializable решает. Хотя все тоже имхо и зависит от конкретного случая.
Сейчас плюс ко всему очень активно развивается SOA и соответственно технологии веб-сервисов — тут уж выбирать не приходится — только XML.
Сериализация в Джаве опять же работает только для Джавы, а парсить XML можно на любом языке.
Сериализация в Джаве опять же работает только для Джавы, а парсить XML можно на любом языке.
Не хочу вас обидеть, но, по-моему, вы напрасно объединяете веб-сервисы, XML и SOA
Веб-сервис — наиболее распространенная структурная единица SOA, интерфейсы и взаимодействие веб-сервисов осуществляется на XML (WSDL и SOAP соответственно). Где подвох?
Подвоха нет. Есть следующая неточность:
>> интерфейсы и взаимодействие веб-сервисов осуществляется на XML,
справедливая только в том случае, если это WSDL/SOAP-сервис.
SOAP — частный и вынужденный случай сериализации объектов (в XML). XML-RPC, из которого торчат ноги SOAP, в урезанном случае, может работать и без него (без сериализации объектов в XML, я имею в виду).
WSDL и WS-* — частный случай SOA. В общем случае существует и REST-web-service, и менее «мусорный» JSON-форматтер, так что выбирать есть из чего, необязательно XML-сериализация.
Как-то так.
>> интерфейсы и взаимодействие веб-сервисов осуществляется на XML,
справедливая только в том случае, если это WSDL/SOAP-сервис.
SOAP — частный и вынужденный случай сериализации объектов (в XML). XML-RPC, из которого торчат ноги SOAP, в урезанном случае, может работать и без него (без сериализации объектов в XML, я имею в виду).
WSDL и WS-* — частный случай SOA. В общем случае существует и REST-web-service, и менее «мусорный» JSON-форматтер, так что выбирать есть из чего, необязательно XML-сериализация.
Как-то так.
Hessian безо всяких XML работает, более удобен чем SOAP и уж в связке с .Net точно работоспособен.
А разве нельзя сериализировать в XML? Или это чем-то отличается?
Реализация другая бужет же. Или я что-то не понял в вашем вопросе?
Конечно можно. Можно сериализовать в какой хотите формат. Суть сериализации в том, чтобы потом вы могли ваш объект потом десереализовать и в итоге получилось тоже самое, что было в начале.
simple.sourceforge.net/ вот этим можно.
Можно. Но не штатными средствами. Из нештатных наш выбор — xStream.
Сериализация (в программировании) — процесс перевода какой-либо структуры данных в последовательность битов. Обратной к операции сериализации является операция десериализации — восстановление начального состояния структуры данных из битовой последовательности.
XML-документ — это тоже последовательность битов. В статье объясняется принцип и для чего это вообще нужно. Так же рассматривается один из способов сериализации объектов — бинарный.
Один из хороших примеров использование сериализации — это когда sevlet-container шарит сессии между ему подобными контейнерами в кластере.
В это случае от разработчика лишь требуется чтобы сессия была сериализуемой, то есть все объекты которые в нее складываются были сериализуемыми, и ваше приложение сразу готово к кластеризации.
Вторая полезная штука — это сохранение сессий на диск между рестартами сервера (сервлет-контейнера), чтобы у всех пользователей не потерялся контекст и не пришлось заново логиниться, например.
В данном случае XML совершенно не нужен. Я ни разу не заглядывал в бинарные файлы (или потоки) во что там превратилась моя сессия, ибо это совсем не нужно и неинтересно. И чем бинарней данные в этих случаях тем только лучше, потому что «производительность».
По-моему, говоря об xml Вы имели ввиду не сериализацию в полном понимании этого слова, а лишь некоторый messaging.
В это случае от разработчика лишь требуется чтобы сессия была сериализуемой, то есть все объекты которые в нее складываются были сериализуемыми, и ваше приложение сразу готово к кластеризации.
Вторая полезная штука — это сохранение сессий на диск между рестартами сервера (сервлет-контейнера), чтобы у всех пользователей не потерялся контекст и не пришлось заново логиниться, например.
В данном случае XML совершенно не нужен. Я ни разу не заглядывал в бинарные файлы (или потоки) во что там превратилась моя сессия, ибо это совсем не нужно и неинтересно. И чем бинарней данные в этих случаях тем только лучше, потому что «производительность».
По-моему, говоря об xml Вы имели ввиду не сериализацию в полном понимании этого слова, а лишь некоторый messaging.
А что сериализация нужна только для хранения? Пол JEE для обмена данными сериализацию использует. Там бинарный формат самый оптимальный.
По-моему, XML — это частный случай сериализации. Бинарная сериализация обычно используется для более компактного хранения и высокой производительности.
Кстати WS* может использовать бинарный обмен данными между веб-сервисами для повышения производительности и экономии канала.
Не знаком с JAXB, так что не могу ничего о нем сказать.
Кстати WS* может использовать бинарный обмен данными между веб-сервисами для повышения производительности и экономии канала.
Не знаком с JAXB, так что не могу ничего о нем сказать.
Для моей сферической сериализации хватает GSON. Ничего писать не надо: вход — объект, выход — строка. И наоборот
Я считаю что сериализацию использовать достаточно удобно — не нужны никакие сторонние классы, все просто и ясно.
Для веб-сервисов — согласен, удобнее XML.
Для веб-сервисов — согласен, удобнее XML.
Все ж не стоит путать действие (сериализацию) и формат (XML, байт-код).
класы то сторонние не нужны, но нужно ручками загнать в поток каждое поле и потом считать его назад. В отдельных случаях, согласен, нужна тонкая работа, но в общем случае мне не интересно как оно будет передаваться: ХМЛ там, или СОА, или Жасон — хочется загнать весь объект в поток, чтоб на другом конце из потока достать — рутиная работа.
Я не очень хорошо знаком с Java, но у меня сразу, как только дело доходит до байт-кода, возникает вопрос: есть ли бинарная совместимость данных после такой сериализации? Например, между разными ОС, или между 32 и 64-битными машинами, или между разными версиями ява-машины, ну и т. д. Просто если ее нет, то об этом следует говорить, чтобы люди выбирали XML или что-нибудь еще для передачи данных.
Пять раз уже повторили что сериализация и хранение объекта в виде XML это одно, и то же, — сериализация — общее название преобразования объекта в базовую структуру — массив байтов.
XML сериализация практически тоже самое, но для человека она более удобна для разбора, никакого более функционала не несёт, и никакой совместимости не добавит.
Для мультиплатформенного переноса объектов естественно придется поискать или написать адаптеры, что для двоично-сериализованных данных, что для xml-сериализованных.
XML сериализация практически тоже самое, но для человека она более удобна для разбора, никакого более функционала не несёт, и никакой совместимости не добавит.
Для мультиплатформенного переноса объектов естественно придется поискать или написать адаптеры, что для двоично-сериализованных данных, что для xml-сериализованных.
Хэй, откуда агрессия?
а) Один из этих 5 раз про сериализацию это повторил я. Вообще не понял, к чему тут это ваше замечание.
б) Насчет XML Вы неправы. Если данные сохранить как "123", то они везде прочитаются безо всяких адаптеров, а если сохранять в байт-коде, то это может быть «7B», «007B», «7B00», «0000007B» и т.д.
а) Один из этих 5 раз про сериализацию это повторил я. Вообще не понял, к чему тут это ваше замечание.
б) Насчет XML Вы неправы. Если данные сохранить как "123", то они везде прочитаются безо всяких адаптеров, а если сохранять в байт-коде, то это может быть «7B», «007B», «7B00», «0000007B» и т.д.
Есть совместимость, не волнуйтесь. Между разными ОС и архитектурами точно (в Java размеры типов int, long и т.д. фиксированы). А для совместимости между разными версиями самой Java, видимо, и используется поле STREAM_VERSION (версия сериализации).
Вот, что-то такое я и надеялся услышать, спасибо, прояснили вопрос. Я так-то не волнуюсь) К миру Java отношения имею мало. Просто в этом месте часто грабли бывают. Хорошо, что тут их нет вроде бы.
а не для версии ли сериализуемого объекта? ниже по треду сказали, что зря не вспомнили serialVersionUID. как раз для того и нужно, чтобы мы десериализатором более новой версии объекта не пытались разобрать байт-представление старой версии и наоборот.
> в Java размеры типов int, long и т.д. фиксированы
Некропост, но между x32 и x64 архитектурами есть большая разница. int кратен размеру слова. Т.е 4 байта для x32 систем и 8 байт для x64.
Чего не могу сказать, дак это совместимости сериализации между ними. Пока такой задачи не возникало. Доверюсь Sun/Oracle и буду надеяться, что это обеспечивается версией сериализации.
Некропост, но между x32 и x64 архитектурами есть большая разница. int кратен размеру слова. Т.е 4 байта для x32 систем и 8 байт для x64.
Чего не могу сказать, дак это совместимости сериализации между ними. Пока такой задачи не возникало. Доверюсь Sun/Oracle и буду надеяться, что это обеспечивается версией сериализации.
Очень дельное замечание. Я как-то мимо ушей пропустил вопрос с платформенной переносимостью. Big-Endian, Little-Endian всякие бывают. Автор как-то упустил этот момент. Но вот уже пояснили, что переносимость действительно есть.
По моему вы незаслуженно забыли рассказать о serialVersionUID.
Обсолютно согласен. Для специалиста с 4х летним стажем это непростительное упущение.
Так же описание того, что сериализация нужна для взаимодействия между системами является, я считаю, не совсем правильным. Взаимодействиями между системами лучше осуществлять основываясь на других принципах.
А вот пример реального применения: Останов enterprise сервера, на котором крутятся несколько тысяч логических процессов.
Так же описание того, что сериализация нужна для взаимодействия между системами является, я считаю, не совсем правильным. Взаимодействиями между системами лучше осуществлять основываясь на других принципах.
А вот пример реального применения: Останов enterprise сервера, на котором крутятся несколько тысяч логических процессов.
Скажите правильно ли я понял, что одно из применений механизма сериализации — это автоматизация процесса построения протоколов для взаимодействия приложений по сети? При этом данное взаимодействие может быть сколь угодно сложным за счёт того, что тип объекта и его данные однозначно востанавливаются на другом сервисе. И хотелось бы узнать какой подход применяется чаще при разработке в среде Java: разработка своего протокола или использование механизма сериализации? Так же насколько я понял допустимо использование смешенного подхода, когда часть данных передаётся в текстовом вде (например xml), а чать в виде байткода.
«и содержит объект контейнер contain» как-то шиворот-навыворот получились :)
я конечно понимаю, что тут в основном веб разработчики сидят, но не забывайте, что java язык не только для веба. Поэтому серилизация — это мощнейший инструмент для передачи данных между серверами, rmi, java baen'ов и т.д. И ни о каких xml даже речи не идет, когда надо производительность.
Статья очень скудная, скорее описывает протокол(хоят это почитать было интересно).
Ни слова не сказано про подводные камни, и тоности, даже про ключевое слово transient ни слова.
Статья очень скудная, скорее описывает протокол(хоят это почитать было интересно).
Ни слова не сказано про подводные камни, и тоности, даже про ключевое слово transient ни слова.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сериализация в Java