Java: подходящий способ передачи сообщений между клиентом и сервлетом? - PullRequest
0 голосов
/ 15 мая 2009

Моя система успешно передает объекты от клиента сервлету. Однако он примитивен, так как был создан для обслуживания Java 1.1. Объект сообщения, который он передает, состоит из int (представляющего один из примерно семидесяти типов) и строки токенов, которые необходимо проанализировать (токены могут содержать список, список объектов и т. Д.). Не хорошо!

Итак, я собираюсь изменить это на Java 1.5. Использование enum вместо int, безусловно, является улучшением, но я не уверен, как отправить остальную часть сообщения. Создание семидесяти различных классов для представления каждого типа, безусловно, не правильный путь.

Есть ли какие-нибудь указатели на то, как мне следует это изменить?

Ответы [ 4 ]

3 голосов
/ 15 мая 2009

Возможно, вы захотите использовать сериализованные объекты.

Они должны легко передаваться по сети.

В вашей ситуации вам просто понадобится сериализованный класс 'message'. Затем вы можете прочитать и записать его в поток.

Здесь - руководство по использованию сериализованных объектов. Там много всего.

2 голосов
/ 15 мая 2009

Нет необходимости создавать другой класс для представления каждого типа сообщения. Вы создаете один класс сообщений со свойствами, которые вам нужны. Примерно так:

public class Message implements Serializable{
     private Long id;
     private String msgText;
     //other necessary properties

     public Message(){
        this(0, "default message");
     }

     public Message(Long id, String msgText){
         setId(id);
         setMsgText(msgText);
         //etc
     }

     //getters and setters
}

И затем вы создаете объекты по мере необходимости. Например:

Message m1 = new Message(9, "The Eagle has landed");
//serialize m1 to server

Message m2 = new Message(27, "The Wren has landed");
//serialize m2 to the server

и т. Д.

0 голосов
/ 15 мая 2009

Первый вопрос: почему вы чувствуете необходимость вносить изменения? Это потому, что текущая система не поддерживает некоторые функции, которые вы планируете добавить? Или вы просто хотите пойти и почистить ради уборки? Если последнее, я настоятельно рекомендую оставить ложных спящих клопов.

Второй вопрос: я предполагаю, что это апплет. Будете ли вы когда-нибудь планировать использовать другой интерфейс? Или выставить этот сервер как универсальный сервис? Если нет, то я возвращаюсь к первому вопросу. Если да, то вы почти наверняка хотите держаться подальше от языковой сериализации.

Если вы планируете выставлять в качестве службы, то рекомендуется придерживаться некоторого «стандартного» протокола службы. REST - это, вероятно, самая простая полезная нагрузка XML для POST. Вы также можете сделать SOAP, но я всегда считал это излишним.

Или вы можете использовать стандартный POST в кодировке URL ... который проще реализовать, чем упаковывать все в XML.

0 голосов
/ 15 мая 2009

Вы также можете сериализовать объекты в XML и снова вернуться к объектам, используя xStream .

...