BYTE.com > Tangled in the Threads > 2002 > March
WSDL Interop Adventures
By Jon Udell
March 4, 2002
(WSDL Interop Adventures
: Page 1 of 1 )
I come neither to praise WSDL, nor to bury it, but only to better understand
it. The Web Services Description
Language, intended to make consumption of web services more frictionless,
has itself lately generated a fair amount of friction. The concept, which can
(sometimes) dramatically be seen in action in Visual Studio.NET, is that WSDL
makes web services self-explanatory. You just walk up to a service (i.e.,
access its WSDL file), and it says: "Here are the services, methods, and
types that I define." Consider, for example, a service called "PlaceFinder,"
available at xmethods.org. Naming its
WSDL file in VS.NET's Add Web Reference dialog enables you to write code
like this:
com.geographynetwork.www.PlaceFinder ws = new
com.geographynetwork.www.PlaceFinder();
com.geographynetwork.www.LocationInfo l = ws.findPlace("New York");
Console.WriteLine(l.candidates[0].description1);
Console.WriteLine(l.candidates[0].x.ToString());
Console.WriteLine(l.candidates[0].y.ToString());
At each step along the way, VS.NET's IntelliSense (namespace completion)
makes the API of this service quite magically discoverable. When you call
ws.findPlace, for example, the UI shows you that a string argument is
required, and a LocationInfo object will be returned. After assigning that
object to a variable ("l"), typing its name plus a dot reveals that
"candidates" is an available member, and that it is an array of Location
objects. Accessing one of those location objects reveals that it has numeric
members called "x" and "y", and a string called "description1."
Four SOAP Toolkits
This is just plain wonderful when it works, but it often doesn't. I'd heard
conflicting reports as to why not, so I sat down with a collection of SOAP
toolkits to see what I could discover. The toolkits, all of which can both
produce and consume SOAP services, were:
|
