Summary
This article shows how to pass objects generated using Liquid XML Studio's XML Data Binder as parameters in a .Net WCF Web Service with Liquid XML Studio 2014 and earlier.
NOTE: Liquid XML 2015 now provides the option to 'Generate a Web Client Interface' from a WSDL. This option will generate WCF Web Client Interface code to enable you to access a Web Service from your generated library in C# and VB .Net, and serialize the values through the generated classes.
See Also: Using XML Data Binding Objects in a .Net Web Service
Example
In our example we are producing a Web Service that will provide information about a given product, given a product code.
The information returned describes the product, pricing, and stock levels.
The previous diagram show the XML Schema used to generate our data binding objects, the full schema is available here.
So we would like to build a web service with a web method that takes a ProductDetailsRequestType and returns a ProductDetailsResponseType.
Solution
Once we have generated our XML Data Binding class library from the schema, we can put together our WCF service contract. We need to specify that the data will use the XmlSerializerFormat instead of the default DataContractSerializer.
namespace ProductEnquiry
{
[ServiceContract(Namespace = "http://www.liquid-technologies.com/ProductDetailsSample")]
[XmlSerializerFormat]
public interface IProductEnquiryService { [OperationContract] [return: MessageParameter(Name = "ProductDetailsResponse")] ProductDetailsResponse RequestProductDetails( [MessageParameter(Name = "ProductDetailsRequest")] ProductDetailsRequest request); } }
Note that the web service uses the targetNamespace from the XML Schema we defined at the start of the example. The web method takes in and returns the Data Bound classes generated by Liquid XML Studio.
We now need to provide an implementation of the Service
namespace ProductEnquiry
{
public class ProductEnquiryService : IProductEnquiryService
{
public ProductDetailsResponse RequestProductDetails(ProductDetailsRequest request)
{
ProductDetailsResponse response = new ProductDetailsResponse();
response.ProductDetails.Name = "Widget";
response.ProductDetails.Description =
"The important widget that goes between the flange and the spindle";
response.ProductDetails.Price = 25.36;
response.ProductDetails.StockLevel = 15000;
return response;
}
}
}
If we left things here then the .Net framework would use its default serializer on our ProductDetailsRequest and ProductDetailsResponse objects. This works using reflection and would end up serializing a large amount of unwanted properties. Instead we are going to let these objects serialize themselves. In order to do this we must tell the framework about them.
[XmlSchemaProvider("MySchema")]
partial class ProductDetailsRequest
{
// This is the method named by the XmlSchemaProviderAttribute applied to the type.
public static XmlQualifiedName MySchema(XmlSchemaSet xs)
{
// This method is called by the framework to get the schema for this type.
// We return an existing schema from disk.
using (FileStream fs = new FileStream(@"ProductEnquiry.xsd", FileMode.Open))
{
XmlSchema s = XmlSchema.Read(fs, null);
xs.XmlResolver = new XmlUrlResolver();
xs.Add(s);
}
return new XmlQualifiedName("ProductDetailsRequestType",
"http://www.liquid-technologies.com/ProductDetailsSample");
}
}
In order for the framework to be able to correctly describe the web service we first need to tell it about the schema. This is done by adding the XmlSchemaProvider attribute to all classes that are in or out parameters in the web service.
The XmlSchemaProvider attribute tells the framework that information about the schema can be obtained by calling the “MySchema” method. Now when the WCF framework is trying to describe the web service it will call the MySchema method.
The WCF framework expects our implementation of MySchema to add all the schemas it needs to know about into the schema set collection, so if you are working with elements from external schemas (HL7, FpML etc) then you can add these to the schemas collection as well.
The return parameter from MySchemas is the fully qualified name of the type within our XSD that describes the parameter. Note this must be a complexType.
Testing
Because your web service contains complex parameters it is not possible to call it via the simple Web Service Explorer.
So in order to call it you need to either build yourself a test harness or use a test tool. Liquid XML Studio contains a handy tool for calling web services. This will automatically generate the request envelope and message, allowing you to modify can call it.
View Full Sample Request
View Full Sample Response
Examining Our Web Service
Because we have taken control of the serialization process the WSDL describing your web service contains the contents of the schemas that you added in via the MySchema method.
View Full WSDL for the sample Web Service
It is also possible to explore this graphically using the Web service Call Composer in Liquid XML Studio
Applies To
Liquid XML Studio - Developer Edition - Versions 7.0.2.746 and higher