DevTeach2004 : Common XML Web Services Headaches
Common XML Web Services Headaches.
Christian Weyer.
NET386
These session notes serve primarily to share the content of the session and as a reference for me. They may also provide some value to those interested in the session topics. Some of the information found in these notes may be inaccurate due to my typing errors or a lack of understanding of the subject matter. DevTeach policy is that session material is available online to registered attendees only, so I cannot respond to any requests for session PPTs or source.
"Web services make me sweat..."
Went through the ASP.NET HTTP request "pipeline" with each module (aspnet_isapi.dll, asmx engine, soap extensions, etc.)
Message Serialization (and deserialization) client proxy to soap extensions to web service method.
Headache #1
XML Schema in ASMX.
Web services are not about objects (soap) but about messages and XML.
[webmethod] uses code first to create schema rather than contract first.
No built-in mechanism to import existing schemas and map types. No way to simply validate messages against schemas.
Can plug in a soap extension schema for validation...
Contract First Development
Design and implement contract with WDL, then create code skeletons from it with helper tools like OmniOpia, XmlSpy.
Public class ValidationExtension : SoapExtension
[Validation]
XML Schema generated at runtime from helper method GetIntrinsicSchema in ValidationExtension class.
Reads the schema from the web service RESX resource file.
Code at Christian's blog.
Used Omniopia to create a WSDL.
"We need properties, not fields"
Right-clicked on .WSDL in VS.NET to use his company's (thinktecture) to create web service methods.
Replace "qualified" with "unqualified" in the generated .asmx (or the other way around.)
?wsdl is disabled so wsdl is not generated at runtime. Added "remove documentation..." in the WS web.config.
Then create wsdl on client side and perform similar process.
Headache #2
Accessing the SOAP Message
eYesoft web services soap extensions to grab or alter the soap messages.
Headache #3
Dynamically Call Services
Need to dynamically bind to and invoke a service at runtime only where you do not know the WSDL yet.
DynaWSLib adds ws.WSDL, ws.TypeName, ws.MethodName, and .AddParameter props/methods. No need to pre-generate WSDLs.
Headache #4
Type Fidelity?
Types are modeled in assemblies which should be used in several layers of application. Can be shared in an XML namespace for access by both producer and consumer.
Example includes a Person class. The client can use the ws.GetPerson method.
In a facade you only call a service component or whatever, but nothing more. The application is elsewhere.
Removed person class from the ASM and into a PersonLib.Person class.
Put the person type into its own XML namespace (Serialization.XmlType(Namespace="urn:...]
Uses a TypeHelper on the client.
Put types in their own XML namespace for access on the client.
Asynchronous calls
"Should use asynchronous calls by default."
Using delegates. Christian's example demos a callback returning a dataset.
Framework creates a new thread, callback is still in secondary thread. Must call Invoke(updateData)).. Must check on the source.
Summary: Very interesting, very new, very high-level stuff. Would love to investigate this further from Christian's blog and company site, though I don’t foresee having the time or pressing need to do so in the nearterm. 10 out of 10.