To add to what Anne is saying here.... >From a practical standpoint, many toolkits out there - some *very* widely used - strictly require WSDL files for client configuration / proxy generation, so although WSDL is not required by the SOAP protocol per se, if you are interested in having your service reachable from as wide an audience as possible, providing a WSDL description is HIGHLY recommended. If that's not a concern, and you know exactly who is supposed to be consuming your service and what they are using, then of course you are free to communicate the technical interface details as you see fit.
XMethods has a policy that all services have WSDL descriptions, which we validate on submission with some integrity checks. Having that WSDL ensures that the listings are as useful as possible - those that have toolkits that require WSDL have it without exception, those that don't still benefit because they can derive the technical details in a consistent, standardized manner. regards, Tony > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 30, 2002 9:37 AM > To: [EMAIL PROTECTED] > Subject: RE: WSDL? > > > Just to be a little more explicit... > > > > > 3) Are these files always needed when offering a web service via SOAP? > > You are never required to provide a WSDL file. But if you want to "offer" > this service (and by "offer" I assume that you intend to make it avilable > to a variety of clients) then you need to provide technical information > to these clients about how to use the service. > > A WSDL file provides a complete technical description of your > web service. It describes > - what the web service does (the operations that the service > supports, and the messages (including type information) that > must be exchanged for each operation) > - how to communicate with the service (which protocol(s) it > supports, whether you're using RPC style or document style, > and how the messages are encoded) > - where to find the service (it's access point) > > If you don't provide a WSDL file, then you'll need to provide this > technical specification in some other way (perhaps a written > document describing how to use the service or perhaps via a > telephone conversation.) The advantage of providing a WSDL file is > that most SOAP toolkits now have the ability to generate a client > interface from the WSDL file. Otherwise clients will have to > construct these interfaces by hand. > > Most SOAP toolkits (Systinet WASP, .NET, IBM WSTK, Apache Java2WSDL, > etc.) now provide tools to generate WSDL from your server code. You > usually don't need to write the WSDL by hand. If you're using a tool > that doesn't generate WSDL, then I recommend that you use a WSDL > editor tool such as Omniopera (www.omniopera.com) to help you write > it. Then look at lots of sample WSDL files to guide you. > > The biggest source or errors in WSDL files come from errors in > namespace usage. As a best practice, always qualify all of your > element names. Keep these thoughts in mind: > - your default namespace should be the WSDL namespace (the > namespace that defines the <definitions>, <types>, <message>, > <portType>, <operation>, <service>, and <port> elements. Any > element or attribute that you use that's not in this namespace > needs to be qualified. > - your target namespace is not the same as your default > namespace. To reference elements defined in your WSDL file, > you should define a tns: namespace that points to your > target namespace. > > Regards, > > Anne Thomas Manes > CTO, Systinet > www.systinet.com >
