Transparent Services are just plain Wrong

Since a few weeks, we are playing with Google Web Toolkit, a very nice tool that compiles java code to JavaScript. Among the features of GWT, transparent remote server invocation is offered. The nice thing is that it right away forces you to consider services asynchronous which yields responsive user-interfaces. The wrong thing is that it seems to be fully version dependent to a point where, basically, one wishes to throw it all away.

The detailed story is simple: we have to webapps to integrate and, without an extra service, it seems impossible:

  • the Curriki editor called Currikulum Builder is built with GWT 1.3.3 and uses remote services and everything
  • our addition, skills-text-box, is based on GWT-Rocket which can only with GWT 1.4 upwards.

So a nice approach seems to keep the webapps separated just integrating in the client where need be. That integration could have used the remote services of the other, based on a common set of classes (which do not create version issues): but that does not work, something, either the transparent serialization or the transparent services, make the remote server calls fully incompatible: neither a 1.3 client can work with a 1.4 server nor a 1.4 client can work with a 1.3 server.

If, as it seemed advertised, all that was made with some standardized interface languages such as WSDL and SOAP, XML-RPC, or even plain XML documents, it would have not happened. But transparency is transparency, that’d be too much for the joe-bo of the programmers (which never ever want to look at a WSDL and prefer it to be only generated).

So now, I will just write another plug to my service, something that uses simple GET and returns an appropriate document. And this one I know it will scale upwards with any version.

Trackback URL for this post:

http://eds.activemath.org/en/trackback/214