Mr. Boy
Mr. Boy

Reputation: 63720

Creating a XML/SOAP client from multiple XSDs?

We're discussing an XML interface with a supplier and debating whether it should comprise multiple endpoints for different object types, or one only - the argument for multiple ones is to avoid one huge XSD.

I know .Net has great tools for writing a client/server from an XSD - auto-generation of classes, etc, if we are supplied multiple XSDs for multiple endpoints does that make this significantly harder or do the Visual Studio tools make this simple? I haven't done SOAP for some time, and not in C# so I don't know the details but need to try and guide what is delivered to our best interests!

Also: should I be requesting a WSDL or XSD... long time since I did this!

Upvotes: 2

Views: 1051

Answers (2)

Ye Peng
Ye Peng

Reputation: 183

XSD defines a schema which is a definition of how an XML document can be structured. You can use it to check that a given XML document is valid and follows the rules you've laid out in the schema.

WSDL is an XML document that describes a web service. It shows which operations are available and how data should be structured to send to those operations.

WSDL documents have an associated XSD that show what is valid to put in a WSDL document.

You need to request both WSDL and XSD so you can generate your web reference by some tool/software like svcutil.exe. It generates reference code and web config file and you can merge to your project. Usually I save WSDL and XSD(s) in one folder for svcutil to look up.

svcutil /wrapped /serializer:XmlSerializer /out:MyCode.cs /config:MyConfig.config /namespace:*,MyNameSpace "PathForWsdlAndXsd\Mywsdl.wsdl"

Upvotes: 1

tom redfern
tom redfern

Reputation: 31750

If you're calling the service over soap then I'm not sure why you're worried about having to generate classes from XSD directly.

Just ask your service provider to expose a soap endpoint with a WSDL address and you'll be able to generate all the client side code using visual studio, including service proxy, types, and bindings.

This is regardless of how granular the service operations and the XSD files defining the service types are.

I see references to "we'll provide an XSD" and wonder if they simply mean WSDL, or if there is some other way they might be doing this than SOAP

Well, maybe they're considering exposing http operations on resources in a REST style service using xml rather than json, in which case the XSDs would mostly be sufficient, assuming they told you what operations were available on what types. I'd class this as unlikely though. Alternatively they may want to expose a POX style service, but this is also unlikely.

If they're planning a soap service then you're going to have quite a difficult time making a call to it if all they are giving you are the XSDs, unless they also give you the service interface definition defining the operation contracts, otherwise how do you know what operations are supported.

Even if they do tell you the service definition you could still encounter problems calling a service exposed over SOAP 1.2, which tends to be less interoperable, so if you've got any control you should request a SOAP 1.1 service (unless you're both using the same technology stacks, in which case it shouldn't matter too much).

Upvotes: 1

Related Questions