Add SOAP to an existing GWT solution

Question

I am looking for a clean way to add service oriented access to an existing GWT application (client + RemoteService based server). The thing is that all the services are already in place, described by the @RemoteServiceRelativePath notation. It would be nice to be able to actually add the @WebService notation and have access to them both with RPC and XML/JSON/..

The real problem is that extending a current application to support other clients than the existing GWT one is a bit hard because of the GWT obfuscation. This also leads to an unneeded coupling between client and server since they both need to be deployed at the same time, because of the .gwt.rpc generated files.

I would like to reuse the existing RemoteService interfaces to define web services and connect to them with new clients via a plain-text protocol. Additionally, I would like to port the existing GWT client to the same protocol.

Is it possible to do this while using the same interfaces and implementation just by annotation? What would be the best way to port the existing client to use a plain text protocol, RequestBuilder? Or just inject a new serialization implementation that does xml / json?

I don't even know where to start with this, this is why I'm asking. Maybe it is better to rewrite all the services and port everything at once but it will break everything until this is finished.

Answer 1

This is rather late and GWT is not the wonderchild it once was. However, for the sake of tying loose ends here's the solution I went for:

• create a Java generator that parses all model (shared client/server classes) files through reflection and generates a Java file that reads/writes SOAP objects
• bootstrap the above into a generic Java handler that handles native objects + array, sets, maps
• write the service that can deal with the generated XML from the files above

It sounds a bit terse and a bit complicated but it 'only' took ~1 month to write the code to reliably convert >200 objects to their XML representation, automatically. The added benefit is that it allows mocking and cross-platform clients/servers.

As a summary, the generated code creates new methods 'fromXML' and 'toXML' that feed the fields that are public members (get/set) in the given class. So, given MyClass it would generate the MyClassSerializer and MyClassDeserializer Java classes that implement those SOAP-specific methods and also publish themselves to a 'dispatcher'. So whenever that dispatcher sees 'MyClass' it would know where to get the ser/deser functions from.

Answer 2

We've had a different approach since GWT the coupling of GWT between server and client side is not all bad but gives you a nice integration and you don't have to think too much about communication issues etc. For that, our application had a frontend tier which consisted of the full gwt stack (client + server-coupling) and on the server-side, we connected via spring and RPC to the service layer.

On that way you can use on the benefits of spring and you don't loose the comfort of GWT.

But I Would like to hear if somebody already has gone other ways ;)