Skip to Content
Last modified by Artur on 2025/09/10 11:19
From version 1.2
edited by Helena
on 2025/05/27 13:49
Change comment: Update document after refactoring.
To version 7.1
edited by Artur
on 2025/09/10 11:19
Change comment: Migrated property [LightLLMprompt] from class [SKMS.Methodology.Code.MethodologyClass]

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -xwiki:XWiki.helena
1 +xwiki:XWiki.arturkryazhev
Tags
... ... @@ -1,0 +1,1 @@
1 +Attribute|Code|Statistical data and metadata exchange
Content
... ... @@ -10,16 +10,17 @@
10 10  
11 11  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:
12 12  
13 -[[image:1747854006117-843.png]]
13 +[[image:1748343057850-568.png]]
14 14  
15 15  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.
16 16  
17 17  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>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] 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:
18 18  
19 -[[image:1747854039499-443.png]]
20 20  
21 -[[image:1747854067769-691.png]]
20 +[[image:1748343077495-340.png]]
22 22  
22 +[[image:1748343095198-522.png]]
23 +
23 23  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.
24 24  
25 25  == 11.2 Solution ==
... ... @@ -30,10 +30,11 @@
30 30  
31 31  Web methods use XmlSerializer in the .NET Framework to invoke methods and build the response.
32 32  
33 -[[image:1747836776717-914.jpeg]]
34 34  
35 -The XML is passed to the XmlSerializer to de-serialize it into the instances of classes in managed [[code>>doc:sdmx:Glossary.Code.WebHome]] that (% style="color:#e74c3c" %)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.
35 +[[image:1748343115246-390.png]]
36 36  
37 +The XML is passed to the XmlSerializer to de-serialize it into the instances of classes in managed [[code>>doc:sdmx:Glossary.Code.WebHome]] 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.
38 +
37 37  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.
38 38  
39 39  In order to control the de-serialization process of the XmlSerializer for a Web method, **XmlAnyElement** is a simple solution to use.
... ... @@ -40,22 +40,26 @@
40 40  
41 41  To understand how the **XmlAnyElement** [[attribute>>doc:sdmx:Glossary.Attribute.WebHome]] works we present the following two web methods:
42 42  
43 -[[image:1747854096778-844.png]]
44 44  
46 +[[image:1748343136642-797.png]]
47 +
45 45  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>>doc:sdmx:Glossary.Attribute.WebHome]] 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.
46 46  
47 -[[image:1747854127303-270.png]]
48 48  
51 +[[image:1748343153949-683.png]]
52 +
49 49  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>>doc:sdmx:Glossary.Attribute.WebHome]].
50 50  
51 -[[image:1747854163928-581.png]]
55 +[[image:1748343180527-572.png]]
52 52  
53 53  Now we look at the message for the method that uses the **XmlAnyElement** [[attribute>>doc:sdmx:Glossary.Attribute.WebHome]].
54 54  
55 -[[image:1747854190641-364.png]]
56 56  
57 -[[image:1747854236732-512.png]]
60 +[[image:1748343195709-593.png]]
58 58  
62 +[[image:1748343209556-271.png]]
63 +
64 +
59 59  The method decorated with the **XmlAnyElement** [[attribute>>doc:sdmx:Glossary.Attribute.WebHome]] has one fewer wrapping elements. Only an element with the name of the method wraps what is passed to the **input** parameter.
60 60  
61 61  For more information please consult: [[http:~~/~~/msdn.microsoft.com/en-us/library/aa480498.aspx>>http://msdn.microsoft.com/en-us/library/aa480498.aspx]]
... ... @@ -62,12 +62,10 @@
62 62  
63 63  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.
64 64  
65 -[[image:1747854286398-614.png]]
71 +[[image:1748343238333-226.png]]
66 66  
67 -Without a common WSDL still the solution doesn’t enforce interoperability. In order to
73 +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>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] Web Service.
68 68  
69 -“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>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] Web Service.
70 -
71 71  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.
72 72  
73 73  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.
... ... @@ -76,27 +76,28 @@
76 76  
77 77  In the context of the [[SDMX>>doc:sdmx:Glossary.Statistical data and metadata exchange.WebHome]] Web Service, applying the above solution translates into the following:
78 78  
79 -[[image:1747854385465-132.png]]
83 +[[image:1748343320957-784.png]]
80 80  
81 81  The SOAP request/response will then be as follows:
82 82  
83 83  **GenericData Request**
84 84  
85 -[[image:1747854406014-782.png]]
89 +[[image:1748343334141-710.png]]
86 86  
87 87  **GenericData Response**
88 88  
89 -[[image:1747854424488-855.png]]
90 90  
94 +[[image:1748343349364-875.png]]
95 +
91 91  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>>doc:sdmx:Glossary.Code.WebHome]] should replace the existing empty method:
92 92  
93 -[[image:1747854453895-524.png]]
94 94  
95 -[[image:1747854476631-125.png]]
99 +[[image:1748343378195-828.png]]
96 96  
97 -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:
98 98  
99 -[[image:1747854493363-776.png]]
102 +[[image:1748343367090-262.png]]
100 100  
104 +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:
101 101  
102 -{{putFootnotes/}}
106 +
107 +[[image:1748343398861-686.png]]
1748343057850-568.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +18.5 KB
Content
1748343077495-340.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +3.0 KB
Content
1748343095198-522.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +21.5 KB
Content
1748343115246-390.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +44.9 KB
Content
1748343136642-797.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +10.5 KB
Content
1748343153949-683.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +12.1 KB
Content
1748343180527-572.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +29.6 KB
Content
1748343195709-593.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +31.4 KB
Content
1748343209556-271.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +2.0 KB
Content
1748343238333-226.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +15.5 KB
Content
1748343320957-784.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +9.6 KB
Content
1748343334141-710.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +28.8 KB
Content
1748343349364-875.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +30.7 KB
Content
1748343367090-262.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +22.6 KB
Content
1748343378195-828.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +833 bytes
Content
1748343398861-686.png
Author
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.arturkryazhev
Size
... ... @@ -1,0 +1,1 @@
1 +16.1 KB
Content
SUZ.Methodology.Code.MethodologyClass[0]
SKMS.Methodology.Code.MethodologyClass[0]
Index
... ... @@ -1,0 +1,1 @@
1 +11