11 Annex I: How to eliminate extra element in the .NET SDMX Web Service

11.1 Problem statement

For implementing an SDMX compliant Web Service the standardised WSDL file should be used that describes the expected request/response structure. The request message of the operation contains a wrapper element (e.g. “GetGenericData”) that wraps a tag called “GenericDataQuery”, which is the actual SDMX query XML message that contains the query to be processed by the Web Service. In the same way the response is formulated in a wrapper element “GetGenericDataResponse”.

As defined in the SOAP specification, the root element of a SOAP message is the Envelope, which contains an optional Header and a mandatory Body. These are illustrated below along with the Body contents according to the WSDL:

The problem that initiated the present analysis refers to the difference in the way SOAP requests are when trying to implement the aforementioned Web Service in .NET framework. 

Building such a Web Service using the .NET framework is done by exposing a method (i.e. the getGenericData in the example) with an XML document argument (lets name it “Query”). The difference that appears in Microsoft .Net implementations is that there is a need for an extra XML container around the SDMX GenericDataQuery. This is the expected behavior since the framework is let to publish automatically the Web Service as a remote procedure call, thus wraps each parameter into an extra element. The .NET request is illustrated below:

Furthermore this extra element is also inserted in the automatically generated WSDL from the framework. Therefore this particularity requires custom clients for the .NET Web Services that is not an interoperable solution.

11.2 Solution

The solution proposed for conforming the .NET implementation to the envisioned SOAP requests has to do with the manual intervention to the serialisation and deserialisation of the XML payloads. Since it is a Web Service of already prepared XML messages requests/responses this is the indicate way so as to have full control on the XML messages. This is the way the Java implementation (using Apache Axis) of the SDMX Web Service has adopted.

As regards the .NET platform this is related with the usage of XmlAnyElement parameter for the .NET web methods.

Web methods use XmlSerializer in the .NET Framework to invoke methods and build the response.

The XML is passed to the XmlSerializer to de-serialize it into the instances of classes in managed code that map to the input parameters for the Web method. Likewise, the output parameters and return values of the Web method are serialized into XML in order to create the body of the SOAP response message.

In case the developer wants more control over the serialization and de-serialization process a solution is represented by the usage of XmlElement parameters. This offers the opportunity of validating the XML against a schema before de-serializing it, avoiding de-serialization in the first place, analyzing the XML to determine how you want to de-serialize it, or using the many powerful XML APIs that are available to deal with the XML directly. This also gives the developer the control to handle errors in a particular way instead of using the faults that the XmlSerializer might generate under the covers.

In order to control the de-serialization process of the XmlSerializer for a Web method, XmlAnyElement is a simple solution to use. 

To understand how the XmlAnyElement attribute works we present the following two web methods:

In this method the input parameter is decorated with the XmlAnyElement parameter. This is a hint that this parameter will be de-serialized from an xsd:any element. Since the attribute is not passed any parameters, it means that the entire XML element for this parameter in the SOAP message will be in the Infoset that is represented by this XmlElement parameter.

The difference between the two is that for the first method, SubmitXml, the XmlSerializer will expect an element named input to be an immediate child of the SubmitXml element in the SOAP body. The second method, SubmitXmlAny, will not care what the name of the child of the SubmitXmlAny element is. It will plug whatever XML is included into the input parameter. The message style from ASP.NET Help for the two methods is shown below. First we look at the message for the method without the XmlAnyElement attribute.

Now we look at the message for the method that uses the XmlAnyElement attribute.

The method decorated with the XmlAnyElement attribute has one fewer wrapping elements. Only an element with the name of the method wraps what is passed to the input parameter.

For more information please consult: http://msdn.microsoft.com/en-us/library/aa480498.aspx

Furthermore at this point the problem with the different requests has been solved. However there is still the difference in the produced WSDL that has to be taken care. The automatic generated WSDL now doesn’t insert the extra element, but defines the content of the operation wrapper element as “xsd:any” type.

Without a common WSDL still the solution doesn’t enforce interoperability. In order to “fix” the WSDL, there two approaches. The first is to intervene in the generation process. This is a complicated approach, compared to the second approach, which overrides the generation process and returns the envisioned WSDL for the SDMX Web Service.

This is done by redirecting the request to the “/Service?WSDL” to the envisioned WSDL stored locally into the application. To do this, from the project add a “Global Application Class” item (.asax file) and override the request in the “Application_BeginRequest” method. This is demonstrated in detail in the next section.

This approach has the disadvantage that for each deployment the WSDL end point has to be changed to reflect the current URL. However this inconvenience can be easily eliminated if a developer implements a simple rewriting module for changing the end point to the one of the current deployment.

11.3 Applying the solution

In the context of the SDMX Web Service, applying the above solution translates into the following:

The SOAP request/response will then be as follows:

GenericData Request

GenericData Response

For overriding the automatically produced WSDL, in the solution explorer right click the project and select “Add” -> “New item…”. Then select the “Global Application Class”. This will create “.asax” class file in which the following code should replace the existing empty method:

The SDMX_WSDL.wsdl should reside in the in the root directory of the application. After applying this solution the returned WSDL is the envisioned. Thus in the request message definition contains: