SOAP versus REST

I've been working at writing web services for a large corporation. WS-* has been out there for a while - SOAP, WSDL, all the usual suspects. There are lots of web service implementations - Axis, XFire, WebLogic, all the Java EE app server vendors. There are tools built into every IDE - IntelliJ, Eclipse, NetBeans. With all this machinery in place it ought to be easy, right?

Why does all this feel like EJB 1.0 all over again?


We have Service Component Architecture and Service Data Objects from IBM and a host of others. Why are these such an improvement over session and entity beans?

Where is the simplicity in all this? What is all this complexity buying us?

The alternative is REST. The problem in making that argument is that it's an "architectural style", not a standard. There aren't any REST wizards out there. It's a tough sell when you're being asked to provide direction to a remote team, which is most likely outsourced. It's easier to put a wizard into their hands and tell them to start generating services. Won't that save the world?

The problem is that there's less time to think and design in this world of outsourcing. You can't iterate without change requests and lawyers being involved. Management would like to substitute process and wizards for craftsmen. They would prefer to reduce everything to the lowest common denominator. The perfect solution would be to make it so easy and automatic that secretaries could pump out code on their lunch hour.

Or, better yet, pre-packaged software.

Why is software so difficult? The analogies to buildings and manufacturing don't fit.