The end of SOAP webservices.
It is probably a bit early to say this, but SOAP webservices doesn't have a future.
I had been a myopic fan of SOAP webservices and one of the early adopters of the technology in various implementations - .NET 1.0, axis, xfire, JAX-WS, BPEL, JSR 180 etc.
It is a great example of how excitement about a new technology can blind your judgment.
It failed the single most important test - it was just not _simple_ enough to succeed in the long term.
1. complexity meant few stable implementations. eg. jboss changed their webservice implementation twice or thrice already.
2. complexity meant inherent concerns about it's security after deployment. eg. how does it handle a malformed request?
3. it needed client & server support which meant changing platforms as your clients change. eg. javascript, actionscript, java, .NET clients.
4. it was supposed to be cross platform, but it required another standard (ws-i profile xx) to standardize the standard. Still, it is a challenge getting a .NET client to talk to a JAVA SOAP webservice.
The answer for the future is some form of REST API. The paradigm shift here is the focus on data instead of services. This has it's own problems. But, it is simple and works for all your clients - very important if you are developing a global distributed service. Examples of this include the GData API & JSR 311.
If you missed the SOAP webservice bandwagon, consider yourself lucky and develop yours using RESTful APIs.
It is probably a bit early to say this, but SOAP webservices doesn't have a future.
I had been a myopic fan of SOAP webservices and one of the early adopters of the technology in various implementations - .NET 1.0, axis, xfire, JAX-WS, BPEL, JSR 180 etc.
It is a great example of how excitement about a new technology can blind your judgment.
It failed the single most important test - it was just not _simple_ enough to succeed in the long term.
1. complexity meant few stable implementations. eg. jboss changed their webservice implementation twice or thrice already.
2. complexity meant inherent concerns about it's security after deployment. eg. how does it handle a malformed request?
3. it needed client & server support which meant changing platforms as your clients change. eg. javascript, actionscript, java, .NET clients.
4. it was supposed to be cross platform, but it required another standard (ws-i profile xx) to standardize the standard. Still, it is a challenge getting a .NET client to talk to a JAVA SOAP webservice.
The answer for the future is some form of REST API. The paradigm shift here is the focus on data instead of services. This has it's own problems. But, it is simple and works for all your clients - very important if you are developing a global distributed service. Examples of this include the GData API & JSR 311.
If you missed the SOAP webservice bandwagon, consider yourself lucky and develop yours using RESTful APIs.
Comments