|
>> 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.
>> 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. 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.
>> 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. I’m not sure that’s the case in this first generation of web services. This may be too limiting a view (I’m still working on it) but I see the direct end user of a web service in its current state as someone who’s writing software (e.g. Java, C#, a scripting language, an Excel macro, etc.). As the presentation standards have not yet been set in the WS community, I’m not sure we can say web services of any stripe are much more than an API at this point in time. Or in other words, there’s a fundamental difference between using a web service and using a web service client.
>> There are a couple of projects working on that [a service description standard for REST]
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. 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.
>> 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). While I don’t think Sun’s tools or any of the open source alternatives yet provide quite this level of abstraction, there’s no reason why they can’t, and I think they soon will. They just need to write transformations for native data types and method invocation to the SOAP equivalents and they can provide the same code generation features Msoft currently offers. Any organization serious about developing or using web services will be using tools like these, I think.
Thanks for the reply.
Regards,
Sean McRae
|
Previous Message
