Оригинал: вот.

На помощь пришли два класса XMLEncoder и XMLDecoder, которые позволяют записывать в и читать из XML экземпляры классов, которые имеют доступный конструктор без аргументов и геттеры/сеттеры для всех полей, значения которых необходимы для восстановления объекта.

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

import java.beans.XMLDecoder;
import java.beans.XMLEncoder;
import java.io.BufferedOutputStream;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
public class Serializer {
    public static <T> byte[] toByte(T t) {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        XMLEncoder e = new XMLEncoder(new BufferedOutputStream(baos));
        e.writeObject(t);
        e.close();
        return baos.toByteArray();
    }
    public static <T> T fromByte(byte[] bytes){
        ByteArrayInputStream bais = new ByteArrayInputStream(bytes);
        return (T) new XMLDecoder(bais).readObject();
    }
}

1. Сначала ставим всю джаву:
# aptitude install java6-runtime
# aptitude install sun-java6-jdk

Модуль sun-java6-jdk находится не в main, а в non-free, так что /etc/apt/sources.list должен быть примерно таким:
deb http://mirror.yandex.ru/debian/ lenny main non-free
deb-src http://mirror.yandex.ru/debian/ lenny main non-free
После изменения sources.list:
# aptitude update

2. Качаем и ставим Tomcat
# wget http://apache.rinet.ru/dist/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.tar.gz
Распаковываем:
# tar -xzvf apache-tomcat-6.0.18.tar.gz
Переносим в /opt (тут нужны права su):
# mv apache-tomcat-6.0.18 /opt/tomcat

Создаём скрипт /etc/init.d/tomcat для запуска, остановки и перезапуска Tomcat’а с текстом:
#!/bin/sh
# Tomcat Init-Script
case $1 in
start)
sh /opt/tomcat/bin/startup.sh
;;
stop)
sh /opt/tomcat/bin/shutdown.sh
;;
restart)
sh /opt/tomcat/bin/shutdown.sh
sh /opt/tomcat/bin/startup.sh
;;
esac
exit 0

3. Добавляем Tomcat в автозагрузку:
# update-rc.d tomcat defaults

4. Прописываем пользователей для работы с админкой Tomcat’а в файлике /opt/tomcat/conf/tomcat-users.xml, например:
< ?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
<role rolename="manager"/>
<role rolename="admin"/>
<user username="tomcatusername" password="tomcatpassword" roles="admin,manager"/>
</tomcat-users>

5. Стартуем Tomcat:
# /etc/init.d/tomcat start

Теперь можно проверить работоспособность админки Tomcat’а по адресу: http://server_ip:8080/manager/html/.

Часть I

Обзор приложений RMI

Как правило, приложения RMI состоят из двух различных программ: сервера и клиента. Программа-сервер при этом создаёт удалённые объекты (remote objects), делает ссылки на эти объекты доступными и ожидает, пока клиенты не начнут вызывать методы этих объектов, а программа-клиент получает ссылки на один или несколько удалённых объектов на сервере и вызывает их методы. Технология RMI предоставляет механизм, с помощью которого сервер и клиент общаются и передают друг другу информацию. Иногда такие приложения называют распределёнными объектными приложениями (distributed object application).

Распределённые объектные приложения должны осуществлять следующее:

• Нахождение удалённых объектов. Приложения могут использовать различные механизмы получения ссылок на удалённые объекты. Например, приложение может зарегистрировать свои удалённые обхекты с помощью аппарата простых имён — ресстра RMI (RMI registry). В качестве альтернативы, приложение может передавать и вовзращать ссылки на удалённые объекты внтури других удалённых вызовов.
• Общение с удалёнными объектами. Детали взаимосвязи между удалёнными объектами управляется RMI. Для программиста удалённое общение выглядить почти так же, как и вызов обычных методов в Java.
• Загрузка определений классов, объекты которых передаются. Так как RMI позволяет передавать объекты, он также предоствляет механизмы загрузки определений классов и передачи информации объектов.

Следующая иллюстрация отражает распределённое приложение RMI, использующее реестр RMI для получения ссылки на удалённый объект. Сервер вызывает реестр для того, чтобы связать имя с удалённым объектом. Клиент ищет удалённый объект по его имени в реестре сервера и затем вызывает его метод. Иллюстрация также показывает, как система RMI использует существующий веб-сервер для загрузки определений классов (с сервера на клиент и с клиента на сервер) для объектов по мере необходимости.

Преимущества динамической загрузки кода

Одной из центральных и уникальных особенностей RMI является возможность загрузки определения класса объекта в случае, если класс не определён в виртуальной машине Java получателя. Все типы и поведения объекта, ранее доступные только на одной виртуальной машине Java, могут быть переданы в другую, возможно удалённую. RMI передаёт объекты по их действительным классам, следовательно не меняется их поведение при пересылке. Это позвляет вводить новые типы и поведения в удалённую виртуальную машину Java, а значит динамически расширять поведение приложения.

Приведённый в этой лекции пример «Вычислительный движок» использует эту возможность для внедрения нового поведения в распределённую программу.

Удалённые интерфейсы, объекты и методы

Как и любое приложение на Java, распределённое приложение, построенное с помощью RMI, состоит из интерфейсов и классов. Интерфейсы объявляют методы. Классы реализуют методы, объявленные в интерфейсах и, быть может, также объявляют дополнительные методы. В распределённом приложении некоторые реализации могут быть в одних виртуальных машинах Java и отсутствовать при этом в других. Объекты, методы которых могут вызываться из других виртуальных машин Java, называются удалёнными объектами (remote objects).

Объект становится удалённым при реализации удалённого интерфейса (remote interface), который обладает следующими свойствами:

• удалённый интерфейс наследуется от интерфейса java.rmi.Remote;
• каждый метод интерфейса, помимо своих собственных исключений, должен объявлять исключение java.rmi.RemoteException (служебное слово throws).

RMI по-разному работает с удалёнными и обычными объектами при передачи от одной виртуальной машины Java к другой. Вместо копирования реализации объекта в получающую виртуальную машину, RMI передаёт стаб (stub) удалённого объекта. Стаб похож на локального представителя (посредника) удалённого объекта и для клиента, вообще говоря, является удалённой ссылкой. Клиент вызывает метод локального стаба, который отвечает за исполнение метода на удалённом объекте.

Стаб удалённого объекта реализует то же множество удалённых интерфейсов, что и удалённый объект. Это свойство позволяет приводить стаб к любому из интерфейсов, реализованных удалённым объектом. Тем не менее, лишь методы, определённые в удалённом интерфейсе, доступны для вызова из получающей виртуальной машины.

Создание распределённого приложения с помощью RMI

Разработка распределённого приложения с помощью RMI включает следующие общие шаги:

1. Проектирование и реализация компонентов распределённой системы;
2. Компиляция исходников;
3. Предоставление сетевого доступа к классам;
4. Запуск приложения.

Проектирование и реализация компонентов приложения

Во-первых, необходимо определить архитектуру приложения, включая локальные объекты и объекты, доступные удалённые. Это включает следующие шаги:

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

Компиляция исходников

Как и для любой другой программы на Java, используется компилятор javac. Исходные файлы содержат объявления удалённых интерфейсов, их реализаций, любых серверных и клиентских классов.

Предоставление сетевого доступа к классам

На этом шаге предоставляется доступ к определениям классов (таких, как удалённые интерфейсы, связанные с ними типы и определения классов, которые необходимо скачивать с клиентов или серверов). Обычно доступ к определениям классов осуществляется с помощью веб-сервера.

Запуск приложения

Запуск приложения включает запуск удалённого реестра объектов RMI, запуск севера и запуск клиента.

В следующей части будет описано создание приложения «Вычислительный движок».