Цель Сериализации в webapplication

Ответы на первый и второй вопрос можно найти в этой ветке SO . Что касается вашего третьего вопроса, sessions.ser - это сериализованный сеанс. Однако

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

2. Да, по той же причине, указанной выше.

3. sessions.ser - это сериализованный сеанс. Tomcat сохранил его, поэтому его можно будет восстановить позже. Теперь вы поняли, зачем нам сериализуемые bean-компоненты, потому что вы можете захотеть сохранить объекты bean-компонентов в сеансе, а Tomcat сохранит сеанс в файловой системе, то есть session.ser. Итак, ваши bean-компоненты должны реализовывать Serializable, чтобы их можно было сохранить / восстановить в сеансе.

Между прочим, корректность сохранения и восстановления bean-компонента зависит от правильной реализации Serializable. Для этого я бы порекомендовал вам прочитать связанные темы в Эффективной Java.

Вау, много вопросов без особого контекста.

Что касается вашего №1, я предполагаю, что вы говорите о сериализации, о которой вы упоминаете в других своих пунктах о сериализации Java, не сериализация против параллелизма. Если это так, многие веб-приложения будут сериализовать или сохранять состояние объектов, чтобы оно оставалось устойчивым. Эту надежность можно использовать в HTTP-запросах (как в управлении сеансом), для более длительного хранения информации или для отправки по «сети» с точки зрения гарантии того, что все стороны получат копию указанной информации.

В HTTP нужно спросить себя, действительно ли это хорошая идея, поскольку по дизайну и масштабированию без сохранения состояния "хорошо", и если у вас есть резервное хранилище, такое как БД, почему БД не выполняет работу.

Sessions (and all attributes added to it) need to be serializable if the container wants to store the session. This may have two reasons:

1. the session has to be passed to an other node of a load balanced cluster
2. sessions need to be swapped out because of low memory

Another possible reason is to pass request attributes from one webapp to another using cross context dispathing. Both webapps have different classloaders so simple cast would not work.

So your tomcat seems to write the session to a file using serialization. A form bean is typically also stored in the session, so yes, it has to be serializable.

And last, there may be much more reasons for serializable like in any other application. Caches may need it to swap out cache content (like ehcache can do). Any other data part may be serialized to be stored as blob in a database, ...

1. Довольно хорошее описание из википедия :

   Сериализация имеет ряд преимущества. Он предоставляет:

   • метод сохранения объектов, который более удобен, чем запись их свойств в текст файл на диске и повторная сборка их, прочитав это обратно.
   • метод выдачи удаленных вызовов процедур, например, как в SOAP
   • метод распределения объектов, особенно в программном обеспечении комплектующие
     такие как COM, CORBA и т. д.
   • метод обнаружения изменений в изменяющихся во времени данных.

   Реальный (простой) пример: Скажите вы создаете экземпляр User в java. Теперь вы хотите отобразить этот объект в веб-браузере с использованием javascript. Один из вариантов - сериализовать объект таким образом, чтобы javascript может десериализовать объект (используя представление, понятное как java, так и javascript) и покажите это.

2. Это зависит от того, что вам нужно сделать с bean-компонентом формы относительно того, должно быть сериализовано или нет.
3. Приложение Tomcat Manager является веб- приложение, которое поможет вам развернуть и управлять другими веб-приложениями, чтобы Кот. Я не эксперт по котам, но Я думаю, что Tomcat Manager пытается запомнить информацию о сеансы, созданные в Интернете приложения, которыми он управляет. Это необходимо запомнить эту информацию даже когда процесс tomcat перезапущен. Итак, Tomcat Manager создает файл с именем "Session.ser" которое является сериализованным представлением информации, которая ему нужна помните обо всем управляемом сеансы приложений.