|
many thx for Mr. Prescod's refreshing counter arguement ( REST appears to be the only existing/emerging contender of any weight ) to 'web' services....basically iterating that the existing internet model ( plus xml of course ) can do all and more that SOAP ( or more specifically SOAP-RPC ) can do.
I have taken in the pros and cons of the arguement over the past years and must admit I am still confused... but a picture is definately emerging;
a) there are 1st order benefits; such as using xml which is much more impactful then deciding on using 'WSDL as a wrapper' for http based services. So making the 'wrong' mistake now is less important an issue as it was in the past.
b) the x in xml means that we will either converge or diverge quicker and easier then in the past; so why not have a heterogenous set of solutions, then migrate.
c) Why can't Google's API be composed within another remote service that delivers the service in any concievable method.... the key point is that a 'method with meta data' important; the technical details are less important.
I am not so certain that the most important issue is the development, deployment, and specification of 'web' services; we may see many varied different specifications..... possibly more important is the method by which the services are discovered, composed and ultimately consumed.
cheers, jim fuller
|