Advice on which technologies to use for a client-server desktop application

Question

I am writing a desktop application in Java which will allow clients to authenticate to a server with their credentials, and afterwards view and manipulate some data (orders, invoices, employees etc.) stored on the server.

I have decided to use Java to write the client, with SWT for the GUI. However, since I haven't previously worked on any large Java projects, I am not sure what technologies to use to make my job easier in writing the server.

The server application will be a frontend for an internal RDBMS, allowing the successfully-authenticated clients to perform various operations on the data the user has permission to work on (not all users have the same role). This will, in simpler terms, work in a similar fashion to a multiuser RDBMS where each database user is only allowed to execute certain stored procedures and nothing more.

I would like to have to deal as little as possible with serialization, duplicated code, writing my own protocol for client-server communication, hand-written object-relational mapping etc. It would be nice to be able to have some data bindings between models and GUI and to abstractize away the networking (by some form of RPC, I imagine).

The first question to be asked is whether the protocol would be stateful or stateless, but I assume stateless is better (providing the user with some session id after successfully authenticating). The next question is what technologies/protocols/libraries should I use? RPC or something else? SOAP, something else over HTTP, not HTTP? I realize this is somewhat a matter of preference, but I'm not really aware of what options I have. I am interested in what's commonly used in the Java world etc.

I would probably also need some way of sharing the model classes' definition (to avoid code duplication) across the client and the server. The client would bind the models to the view and propagate the changes to the server (serializing the model before sending it probably). The server would then deserialize the model object and push it onto the database via some object-relational mapper. Of course, that's oversimplified and is just the way I imagine it would work, but I'm open to any suggestions.

My initial impulse was to use Python for the server, because that would make things more interesting for me (plus I have more experience). However, I'm thinking that going in this direction might over-complicate things. It's probably easier to write some model class and use it in both the client and the server than write it once in Python and once in Java and make sure to never forget to sync the changes (but then again, I might be able to use some common format to describe the model and then have it generate code in both Java and Python; I think ASN.1 does something like that). Do you think I can do this using a Python server without too much time wasted caused by the fact that the client is Java?

Thank you for taking your time to read this. All of your suggestions are appreciated.

Answer 1

If you implement the server as a bunch of web services then you don't really have to worry about syncing your model classes between the server and the UI.

Every time you change something on the server it will impact your web services definitions (WSDL) and as a consequence will have to be remapped in your UI accordingly.

Java has several tools that will automatically convert a WSDL into Java classes for you.

You could as well build a single jar with all your model classes and share it with your client and then use Spring to create proxies which could even share the same interfaces of your web services implemented on your server (which share the same model classes).

About creating web service proxies using Spring look here:

http://static.springsource.org/spring/docs/2.0.x/reference/remoting.html

PS: too bad you're not doing this in .NET, it would be so much easier.

Answer 2

The next question is what technologies/protocols/libraries should I use? RPC or something else? SOAP, something else over HTTP, not HTTP? I realize this is somewhat a matter of preference, but I'm not really aware of what options I have. I am interested in what's commonly used in the Java world etc.

I would check out the Socket and ServerSocket class.
For uses on it, see this.

Answer 3

You can see http://www.jboss.org/netty link, and this http://www.jboss.org/netty/documentation documentation about Netty client server socket framework. Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Maybe it helps you.

Answer 4

It's simpler if you use the same language on both sides. If you use Java, I would create first interfaces with the methods you will want to invoke from the client and related classes (i.e. data structures)- I would keep the data types simple, although if you are using Java on both sides this won't be necessary, if you keep simple interfaces it will be easier if you later need interop with other languages. This should be a module which generates a jar you can include in both client and server.

Then you implement the interfaces on the server. Once you have those, to invoke them I would use an RPC-like system which converts client-side method invocations to server remote procedure calls transparently. RMI, SOAP, XMLRPC can all be used for this; setting them up should be simple and switching among them too, so you can try what works best for you (IIRC, RMI tends to be a networking pain, SOAP libraries tend to be somewhat complex and XMLRPC might not be 100% accurate/transparent).