>> Okay, but if you're using HTTP and
>> WSDL, then you aren't using SOAP
> "Good point, but I still get the benefits of a URI-centric access method and can also support SOAP/RPC clients with the same code base and even the same code instance. Such a service is approachable to both communities."
Unfortunately WSDL does not support REST as we'll discuss next so the point is sort of moot.
>> WSDL is a fairly poor interface definition language for web services built using a web architecture.
> "I haven’t yet run into the limiting factors to which you refer, but I’m sure there are some there. WSDL is still in its first release. Like all standards it will evolve."
That's fine. But until it evolves support for REST it is my assertion that Internet-based e-business will not succeed. This will be blamed on a variety of factors but most will not realize that the failure was baked into the standards themselves.
> "WSDL does have the significant benefit of vendor support from most if not all the vendors who matter. The tools are emerging, corporate investment in WSDL will follow soon. I think the train is leaving the station."
The train can go as far as it wishes. When it becomes apparent that there is no engine we'll send another one after it. ;)
>> As soon as you follow a hyperlink to another web resource,…
> "This seems to imply that a human using a browser as the end user or a web service."
No, and this is key to understanding why REST will work on the Web and SOAP/WSDL will not. In any programming language or API designed to solve real problems ("automateMyBusiness"), not toy problems ("getStockQuote") you need a way connect information bits together. In programming languages we have pointers or references. In databases we have foreign keys. In file systems we have absolute paths.
Now consider this in a business messaging context. Any real business transaction must span many messages sent back and forth. These messages must refer and relate to each other somehow. SOAP and WSDL require you to build this relation yourself in a proprietary way. REST uses the standardized Web-way, which is the URI-bearing hyperlink. This has nothing to do with user interfaces and everything to do with building relationships between information components.
> I’m not sure REST is even in the web services game until there is such a standard. To me, the service definition is what gives web services its potential to be what the MBA’s like to call a disruptive technology. My company, like many others, has been putting services on the web since the mid/late 90’s.
Your two statements seem very odd beside each other? You've been solving the problem that people are trying to sell you tools to solve since the mid/late 90s, but you deny that the tool you are already using is "in the game."
WSDL is not a disruptive technology. It is IDL for the Web, a rehash of a rehash of a rehash. Common wisdom is that the previous standards failed because there was no standardization between Microsot's COM and OMG's CORBA. That's a myth. Previous incarnations failed because the model *does not scale* across organizational boundaries. It requires too much coordination.
And shared use of complex WSDL services requires more, not less, coordination than COM/CORBA because at least COM/CORBA had first-class pointer types. WSDL throws away all of the "loose coupling" advantages of XML. Two years ago it was common wisdom that the reason XML-based services would succeed where COM/CORBA ones failed was "loose coupling". Then WSDL came along and loose coupling was forgotten.
> "To a degree, they are all URI based. A standard absent a service description language does not bring much that’s new to the table. The language doesn’t have to be WSDL. There are many who would prefer RDF or some other standard that addresses something WSDL does not. It is the service contract, expressed in an industry-standard way, which is the essence of a web service, IMO."
WSDL service descriptions capture a tiny fraction of what you need to know in order to safely invoke a web service.
>> The REST static description languages under development are much simpler, easier to work with and yet more powerful than WSDL
> "Perhaps, but the complexity issue may turn out to be a distinction without a difference. My only real web services work thus far has been with Visual Studio.NET. I’ve written a web services wrapper for one of our existing API products – and I didn’t write a line of XML, i.e. no WSDL and no SOAP. I simply added preprocessor instructions to native code and the framework generated the proxy classes and WSDL for me. Developing the client from VS.NET is done with similar ease; just import the WSDL file and the service and its methods are exposed as native objects. The complexity of WSDL and SOAP is completely encapsulated (alas, their limitations are not)."
The tool helped you to define a service that is exactly as tightly coupled as the COM+ service you could have defined two years ago or the CORBA service four years ago. Only the WSDL version is much less sophisticated. "Yesterday's technologies tomorrow."
The service will be essentially impossible to evolve, it will be difficult to integrate with other, similar services and by definition it probably doesn't take advantage of XML standards in your industry. When someone elsewhere within Thomson publishes information that you would like to incorporate into your service you will have to do it through programming a bridge layer rather than simply making a hyperlink.
REST is about moving to the next level, the level we were promised three years ago before the SOAP/WSDL detour.
Paul Prescod
|
Previous Message
Up
