The Clumsy Pattern: Passing Data Around

In the long-awaited part 2 of The Clumsy Pattern, I discuss how we pass around data and objects around -- remote server communication.Not only do we spend a lot of time getting it right, we waste a lot of time arguing about how to do it, which solution is best, and why. We have lots of technologies and practices for remote communication.  Some examples from Java: RPC, home-grown sockets, serialization, RMI, CORBA, XML, REST, DTOs, SOAP, and many more. What's the one thing consistent about all of those?  99% of the time, I DON'T CARE! I want to be able to send data to and from a server quickly and consistently.  How the data gets de-rezzed and rezzed in the meantime matters to the end product only a tiny bit.  (sorry, only good video I could find, watch :10 through :45 for what I mean -- and hope you like Depeche Mode) These are really cool technologies, and fascinating to dive into for their own sake.  But when I'm trying to deliver software, I don't want to worship at a particular altar, it just doesn't matter.  You can typically accomplish any requirements using any of the technologies, but we so often just start waving techs around as a panacea instead of looking closely at the problem.
Example: We just had a client-server app using RMI with Spring Remoting's HttpInvoker.  Were we having troubles with too much data being sent from the server, and being tied to the same version of domain objects on client and server, having trouble with releasing.  (A Detailed analysis here, from a former architect on the team.)  We solved this by switching to RESTful web services all over.  We have specific data being sent down, and no longer depend upon the same module for domain objects. Now, take a look at the problem and the solution.  We weren't having a problem of how we sent the data over, we were having a problem of what we were sending.  We could have fixed that in place, using RMI, using a common module, with a couple of tweaks (managing serialization and not releasing domain, client, and server simultaneously).  Instead, we spent several man-months (I might dare to say close to a year of time) converting our modules, dealing with any RESTEasy quirks, and arguing over URIs.  And now we have 2-3 extra copies of objects in client, server, and web modules.
In the end, things are improved, and these problems are solved.  In fact, following REST patterns basically forced us to confront the problems.  I am glad we are where we are, we've gone to something more text- and test-friendly, all with just a browser.  But it wasn't REST that fixed our problems -- we did.

Comments are closed.