Java: an appropriate way to pass messages between client and servlet?

My system successfully transfers objects from client to servlet. However, this is primitive as it was built to serve Java 1.1. The message object it sends consists of int (representing one of seventy types) and String tokens that need to be parsed (tokens can contain a list, a list of objects, etc.). Not good!

So, I want to refactor this to Java 1.5. Using an enum instead of an int is definitely an improvement, but I'm not sure how to send the rest of the message. Creating seventy different classes to represent each type is of course not the right way.

Any pointers on how I should refactor this?

0


a source to share


4 answers


There is no need to create another class to represent each type of message. You are creating one message class with the properties you need. Something like that:

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
}

      

And then you create objects as needed. For instance:



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

      

etc.

+2


a source


You can use serialized objects.

They should be easily transmitted over the network.



In your situation, you just need a serialized "message" class. Then you can read and write it to the stream.

Here is a tutorial on using serialized objects. There are many.

+3


a source


You can also serialize objects to XML and revert to objects using xStream .

0


a source


The first question is, why do you feel the need to make changes? Is it because the current system does not support any feature that you are planning to add? Or do you just want to go and clean up for cleaning? If the latter, I highly recommend leaving the sleeping false bugs.

Second question: I am assuming this is an applet. Do you ever plan on using a different interface? Or expose this server as a shared service? If not, then I come back to the first question. If so, then you almost certainly want to avoid language-specific serialization.

If you plan on exhibiting as a service, then the following standard service is a good idea. REST is perhaps the simplest, most useful POST XML file. You can do SOAP as well, but I've always found it overkill.

Or you can go with a standard url-encoded POST ... which should be easier to implement than wrapping everything in XML.

0


a source







All Articles