Speaking of SOAP, and WSDL, here's something to think about. Look at the Blogger API. No IDL. How did it work? It's very broadly deployed and quite useful. It's gotten a lot of Web people excited about XML-RPC. No one has ever, as far as I know, asked for an IDL. Why?  [Scripting News]
This is a question I've been struggling with too. On one hand it seems really useful to be able to automatically generate stubs for a particular language to make the service call seemless to the language. On the on the other hand though, XML-RPC calls are so simple that you don't really need it. In theory SOAP shouldn't really be that much worse.
In the CORBA world IDL is central to everything you do and provides three major functions.
1. Skeleton generation to provide the framework used by the server to implement the logic.
2. Stub generation for the client to be able to access the server.
3. Documentation on the interface to the object.
1 and 2 are really necessary because of the prevalence of static languages like C and C++ at the time CORBA was developed.
With a modern dynamic language like Java or C# there is really no need for server skeletons any more. Java RMI over IIOP proves that with introspection capabilities you can even build CORBA apps in dynamic languages without the need for static skeletons. For WSDL there's absolutely no need for it on the server and in fact that isn't what it is used for. Now instead of generating static stubs from IDL, we generate IDL (i.e. WSDL) from dynamic introspection of objects. So no 2. is off the playing field, we don't need it anymore.
Client stubs are still useful and can cleanup the client code a bit, but again in dynamic languages this is only a minor convenience and not strictly necessary to use a service. In CORBA it was possible to build a client without a stub using DII, but almost nobody ever did because it was about as nasty as nasty can be. With XML-RPC and SOAP it really is pretty straight forward. The reason is simply that CORBA was about objects with persistent connections and server state. XML-RPC and SOAP, like the HTTP protocol that they sit on, are stateless. Whether the connection is persistent or not is irrelevant. If you want state you build it into your service. Also, despite the word object being part of the expansion of the acronym SOAP it really doesn't have anything to do with objects.
The value of the stubs is also lower in the WSDL sense because of this fact that you aren't manipulating objects. In CORBA you could get a reference to another object as the result of a call on an IDL interface. In order to introduce meaning into that result you have to have a stub to represent it. In web services that doesn't happen, you'll never get an object reference as a result because there is no such thing. Maybe you could get a URL that points to a WSDL for another service but that isn't the same thing as getting a reference to an actual object instance.
So looking at WSDL as a stub generation tool for client programming languages it's clearly useful, but it isn't absolutely necessary.
The final major use of IDL is as documentation on the interfaces. It's very handy to have a quick look at the IDL to see the makeup of a CORBA object and what methods it has. This doesn't substitute completely for real documentation, but it is still very useful. IDL is simple and easy to read to anyone familiar with any C derived language. Now here's a problem with WSDL, it should be useful for documentation too. It's not. Because of the verbose XML syntax it uses, WSDL is very hard to read. In fact they made this even worse by making the thing way more complex then it really needs to be. It leaves you with having to post process the IDL to generate something that is useful for documentation. I guess that isn't so bad, but doesn't justify the need for its existence.
So what are we left with from a developers perspective? Not much really. Basically WSDL makes it a little easier to build applications because you can generate language specific stubs. I consider this a nice to have thing, rather then an essential component of the web services architecture. If you keep your interfaces simple you really don't need it. In fact, in many ways it can complicate development when working with simple services because it requires more advanced support on the client. Now this doesn't mean WSDL is useless, in fact I'd say quite the contrary.
So what's it useful for? Tools! Without some type of IDL it really won't be possible to build nice easy to use visual tools for web services development. Something like the blogger API may be easy to use but it isn't something that I can plug into a visual builder, without coding support manually. Through WSDL and with a dynamic language I can build really powerful tools to make it easy to tie different web services together into an application. Having these tools is essential to the success of web services and will make things a lot easier on the developer.
WSDL is something most developers will never see. It will be generated automatically by the web services platform and consumed automatically by the web services development tools. The only thing that is kind of scary about this is if services start showing up that can't be accessed without using the WSDL description to get to them. That would create tool lock in and really hurt platforms where advanced tools are not part of the development process or culture.
The cost of WSDL is to the tool developer and since Dave Winer is a tool developer I can see why he might want to push back against it. I'm a tool developer too and I see some really exciting possibilities for integration of web services into places network services have never gone before. Some form of IDL is necessary to get there. If it gives us a real benefit beyond the cost isn't it worth it? At least as long as it's optional.
BTW, I'm not a particularly big fan of WSDL it self, I just think the IDL concept is necessary.
12:20:48 PM
|
Inspirational Technology