Почему объекты передачи должны реализовать сериализуемый?
Я понял сегодня, что вслепую только что следовал за этим требованием в течение многих лет, действительно никогда не спрашивая почему. Сегодня, я натыкался на NotSerializableException с объектом модели, который я создал с нуля, и я понял хватит.
Мне сказали, что это было из-за репликации сессии между сбалансированными с загрузки серверами, но я знаю, что видел другие объекты в объеме сессии, которые не реализуют сериализуемый. Действительно ли это - настоящая причина?
3 ответа
Это настоящая причина. То, действительно ли это будет иметь значение на практике, полностью зависит от того, действительно ли веб-сервер или сервер приложений сериализует объект (или проверяет, что он является сериализуемым, но на самом деле единственный способ сделать это - действительно сериализовать его).
Большинство серверов приложений имеют возможность (по крайней мере) не соблюдать строгость в отношении этого. Если вы не используете серверы с балансировкой нагрузки, которые фактически разделяют состояние, возможно, вы видели это без проблем.
Я думаю, что концепция сродни вопросу, почему твердую пищу нужно пережевывать, прежде чем проглотить для переваривания. Но, конечно, разница в том, что переваренная пища не может быть десериализована в любом случае.
Я помню, как использовал Sun RPC (сегодня он называется ONC RPC), который выполняет кодирование XDR. потому что компьютерные платформы/системы представляют свои данные в соответствующих формах. Например, big endian vs small endian.
Но JVM, независимо от машины, является big-endian, поэтому эндианальность не должна быть причиной.
Структура данных в памяти компьютера имеет указатели, и все элементы объекта могут не располагаться на одном блоке памяти. Однако, когда вы передаете объект через i/o в другую систему, вы не можете передать распределение памяти этого объекта.
Объект должен быть сериализован перед сохранением в базе данных, потому что вы не можете и не хотите воспроизводить динамически изменяющееся расположение системной памяти.
Наш уровень представления данных в сетях основан на битовых потоках. Поэтому, когда вы хотите передать данные от одной системы к другой, вы должны преобразовать размерные данные, представленные в памяти, в данные, которые могут быть переданы по сети байт за байтом. Фактически, бит за битом, что часто сопровождается сжатием и шифрованием. Процедуры сжатия и шифрования являются оо-структурно-слепыми и предполагают битовые потоки. Сетевые коммутаторы оо-структурно-слепые. Сетевая передача даже не видит битов. Биты кодируются в сигнал передачи, который часто представляет собой аналоговые синусоиды, а затем модулируется. Эти процессы не работают на многомерных/иерархических схемах оо-структурированных данных.
Я полагаю, что вы можете выполнить обфускацию и шифрование на уровне объектов, но вам все равно придется позволить системе преобразовать их в битовые потоки, предварительно преобразовав их в потоки символов.
Маршаллинг - это когда у пастуха есть стадо овец, и он перебрасывает им мост из одной овцы через неспокойные воды. Поэтому маршаллер должен маршаллировать наши объекты в последовательные схемы с записанными в них ссылками, чтобы, когда стадо информационных овец выйдет с другого конца моста, мы смогли собрать их обратно в иерархические схемы с помощью сопряженного демаршаллера. В нашем случае овец перегоняют не просто по мосту, а по узким и опасным извилинам и оползням, где сетевое передающее оборудование на каждом повороте хранит копию перегоняемой овцы, чтобы обеспечить возможность повторной отправки копии в случае, если какая-либо из овец упадет в овраг.
Потому что для передачи по сети они должны быть сериализованы в форму, которая может быть помещена в сеть.
Например, двоичный файл или xml, Json или аналогичный
Здесь есть дополнительная информация ... Следует ли какой-либо объект домена не сериализовать?