Member Avatar for glenak

Hi,

So, I did create a client and a server, and all of them work pretty well. When I send messages to the server, rather than sending one message at a time, I put the information in a class, say like a Person class - I put set the Person's age, name, height, etc - create an object of the person class and send it. Server receives it and is able to open it up and get the information.

Now, I got a question. The only reason my server can get this information is because the server is in my computer, and I all I have to do is write a:

import personPackage.Person

and I can do what I wish. If my server were on another computer, it wouldn't be able to do that import, and hence, it won't be able to get messages from the client.

My question is, how do I go about solving this problem? I was thinking of jar files. You know, how sometimes I put in external JARS in my library and I'm able to import and use classes - is this the right method? How do I go about doing this?

THanks

  • 2 Contributors
  • 1 Reply
  • 86 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by ~s.o.s~
Member Avatar for ~s.o.s~

Assuming you are creating a chat application, there are at least two ways of going about this one:
* Create a language/platform independent protocol for your chat. This has the advantage that a client written in any language can communicate with your server, it need not always be a Java client. E.g. XMPP (specifically aimed at RTC)
* Write and read Java objects, as simple as it gets. The practical drawback being you can only use Java clients to communicate with your server. Technically, you can use any language provided it can serialize/deserialize its object as per the Java serialization specification but we wouldn't go there.

Regarding the common classes: one way of tackling this problem is to create a separate project which contains your VO's and interfaces. The JAR exported from this project would be used by your server application along with being shipped to the client. Again, the catch here being that updating your interfaces/VO's might require that you ship the updated JAR to your client so that it can be operational and still communicate with the updated server.

Also, to ensure that simple updates to value objects (adding helper methods) don't break your existing clients, *always* provide an explicit `serialVersionUID` for your serializable classes. If you don't, an automatic one is generated for you. Simple structural changes might cause a new serialVersionUID to be generated which isn't desirable.

Edited by ~s.o.s~ because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.