SOAP v REST more pointless than vi v emacs

I'm over in San Francisco at the moment for the OASIS Symposium which has had some interesting elements. One thing that cropped up, yet again, was SOA as technology v SOA as thinking differently. In a side discussion on this I was talking to a couple of folks who worked from a couple of vendors, my point was that I shouldn't be caring about SOAP v REST or the myriad of wire protocols and syntax that these people seem currently obsessed with, all I want to do is link up Consumers with Producers. As a business choice is pointless, in the same way as the WiFi market has agreed on the 802.11x standards and the Telecoms industry has agreed on things as diverse as Billing (OSS/BSS) and the actual infrastructure (GSM, WCDMA, PBX etc), we don't WANT lots of different choices at the base level, we want that to be commodity.

The comment I received was "why would we want to make it commodity so you can switch Vendor [X] with Vendor [Y]'s product". And here in is the problem, the vendors are missing the point, helped on in no small part by the "Web 2.0" crowd and people arguing about REST v SOAP et al.

Lets be clear, I want to define the capabilities that are required, I want to define the information that will be exchange to help with those capabilities. And I want consumers to be able to easily interact with that service.



The only things that matter to me are simplifying the modeling and management of these links and enabling the actual invocation to take place, because its that invocation that delivers actual value (a service with no consumers is pointless).

The mechanism that makes it happen is pure cost. Now this is why I want it to be a commodity, but so should the vendors. Why?

Because simply put, it already is.

RPC, async calling etc have been done for years, we know how to do them. The only thing stopping them being standardised into a single solution is the fashion followers in IT and the vendors. But it doesn't matter. Look at something like OBIX which I heard about for the first time today. These guys are defining standards to enable the control systems in building to link up. Lighting, power, fire alarms etc etc all able to communicate with each other and be controlled using standards. And they are using the WS-* standards to do this, and the same is true of lots of other industry groups trying to solve actual business problems.

Its time for the vendors to wake up and realise that all the arguments about SOAP v REST v whatever are pointless. All that matters is that a standard is good enough not that it is perfect. Tools should be what makes interaction between a consumer and producer simple, not the thing that makes a developers life slightly easier or slightly harder, we shouldn't be developing things that have no actual value and which could easily be done automatically. Defining an interface and an end-point is both logically and physically simple, is ridiculous that we are arguing about the specifics of how you shift and XML document from A to B and what is "easier" to develop with.

The process should be

1) Design interface and documents - UML style of thing
2) Generate exchange format of those interface and documents - WSDL and XML Schema type of thing
3) Right-click generate consumer, right-click generate producer
4) Develop
5) Deploy
6) Infrastructure to enable management of routing, policy, QoS etc
7) Repeat as required

If this sounds far fetched then think of designing an EJB using the latest tools or XDoclet, effectively this is what they do already, all of the crap is generated and you can focus more on the actual logic and consumption.

All of the current trendy arguments about SOAP v REST and the like miss the point here, we are still coding RPC and async calls in multiple different ways, by hand 30+ years after they started and since the syntax and semantics have been well understood. Shipping an XML document is a trival element, and its about time we stopped jumping on another trendy bandwagon of technology and looked towards solving the actual challenges of making the technology invisible.

Because as was brilliantly pointed out today by Robert Carpenter, its that step that will make it ubiquitous, and sure commoditisation is next, but there are a whole heap of companies making huge amount of money in commodity markets. Will that mean software vendors might have to think like hardware vendors? In part, but also it means they will be able to attack the challenges that add real value to businesses, which is surely where higher margins are to be made.

Its time for IT to grow up and cope with what we have rather than creating yet more technologies to solve the same problem in almost the same way.