WSDL for Radio UserLand

Disclaimer: I don't know WSDL, I'm only guessing what information it provides.

Proving a WSDL file is a way to make it easier for developers to use get started with your web service in their environment easily.

Imagine this Radio developer workflow (it's okay, workflow is good!):

(menubar) Web Services > Add Web Services

Dialog box pops up asking for an URL to a WSDL file.  If the clipboard contains an URL it picks it up.  Click OK.

Radio spits out messages in the message window telling the user it's parsing.  "Done!"

A rich outline appears which contains a listing of all the WSDL files that have been parsed.  The node for the WSDL file just parsed is expanded.  A list of the methods it exposes are listed underneath.  Expand the method and the parameters are listed.  Each parameter's icon represents the datatype of that parameter.  If WSDL has comments and URLs to docs those are provided in the outline too.  Right menus, double clicking, expanding, whatever.

Right click on the node for the method and choose Build calling code.  A new script outline appears with a complete script fragment for calling the SOAP method.

Right click on the node for the WSDL file and choose Build Client Glue for this Service.   Churn churn churn, and a new Tool GDB window appears with a table of scripts for calling all the methods defined in in the WSDL interface.

Right click on the node for the WSDL file and choose Build Server Glue for this Service.  Churn churn churn, and a new Tool GDB window appears with a table of SOAP handler scripts that implement the skeleton of the WSDL interface.

That's how WSDL provides value to SOAP developers, and how it could provide value to Radio/Frontier developers.

PS: This entry posted to my Conversant weblog via HTML mail in Outlook Express.

Written on March 3, 2001