I wouldn't write-off SOAP/WSDL approach yet. The last time I used it in JavaEE6, it was surprisingly very easy and pleasant to work with. Server-side ========

I wouldn't write-off SOAP/WSDL approach yet. The last time I used it in JavaEE6, it was surprisingly very easy and pleasant to work with. Server-side =========== 1. Write the services 2. Prepare your DTO classes, annotate them 3. Run through JDK command line utility => output: XSD, WSDL Client-side ============ 1. Grab that WSDL+XSD 2. Run them through JDK client-side tool utility 3. Consume the generated code (if you use maven, you can also prepare a JAR and make em as dependencies) You can automate all of these via maven plugins easily for both sides. Yes, you'd have to recompile them but it gives you a bit of security/guarantees unlike REST. I thought my experience was not painful enough to warrant to ignore this solution depending on the use-case/situations (i.e.: you could always go overboard). Compare that to some random Netflix.rb (ruby based) library that internally relies on XPath... feels a bit shaky for me. But YMMV and definitely it's more of my preferences than other people's. I do aware of SOA-based solution by breaking down a big system to multiple services with the hope of each system can be independent of others and hopefully can be re-used easily by other services as well. The assumptions here is that each service has its own team (of 3-4 people) that maintain such systems. Sure, you can definitely write these services using anything you want and you certainly invalidate my opinions on that. But there's a price to be paid going toward this model: traceability is harder, collaboration effort also increases, more failure points, etc (I'm sure you're aware of these). No magic bullet I suppose.