WEB390 Ouch! Common XML Web services headaches (and possible solutions) Christian Weyer Microsoft MSDN Regional Director

What to expect XML Web services in practice Not to say: „Real World“ experiences... Five common headaches Best Practices Lessons Learned Customers Feedback Quite a few demos

Web services make me sweat... Hm, what about message s? WS-Trust? WS-Security? WS-What? [WebMethod] rocks, sucks!?

Prepare your Web services Aspirin ® Including existing XML Schemas & validating the message Accessing the raw SOAP message on client and server side Dynamically invoking Web services Using existing types in Web services proxy classes Asynchronous programming: Web services invocation and server-side WebMethods

Headache #1: Leverage existing XML Schemas Several efforts exist for defining industry or domain specific standard XML Schemas E.g. SALT, MathML A lot of companies design data in XSD So no reinvention of the wheel, please [WebMethod] just generates XSD based on the.NET types Can control generation process through attributes But no built-in support to import external Schemas Would be nice to also validate messages against Schema

Leverage existing XML Schemas SoapExtensionReflector is your friend Use.NET attributes in your service code Map existing Schemas to your type classes Map existing Schemas to your method parameters Optionally validate incoming messages against the underlying XSD Use a SoapExtension

Using XML Schemas demo demo

Headache #2: Accessing the SOAP message Web services are actually all about transfering XML messages Do not think „Simple Object Access Protocol“!, better „Service Oriented Architecture Protocol“ Sometimes we want to see and work with the SOAP message from the wire „Look ma: it‘s XML, not objects!“ ASMX does not intrinsically allow us to view and access the SOAP streams

Accessing the SOAP message Client side: Use buckets/slots in proxy class to store streams and establish a context Use SoapExtension to inject functionality in ASMX pipeline Service side: Directly access the stream from HttpContext Pack this into a SoapExtension

SOAP from the wire demo demo

Headache #3: Dynamically call services Ready-set-go approach in.NET for connecting to XML Web services Create native proxy class from WSDL at design time There are situations where you actually do not know the WSDL yet At least in testing scenarios Think grid computing Need for dynamically binding to and invoking a service at runtime only

Dynamically call services Everything needed is in the.NET Framework CodeDom, Reflection, ServiceDescriptionImporter, ICodeCompiler,... Build a.NET assembly and use it simply by calling a few methods on a type Note: degraded performance! Caching may help out Leverage this feature SQL Server 2000 to invoke Web services at runtime Use.NET CLR from within a SPROC Leverage XSP‘s power

Dynamic Web services invocation ( from SQL Server) demo demo

Headache #4: Type Fidelity? Yes, Web services are all about XML messages But we need a programming model to work with.NET exposes types and classes for ease of development Types are modeled in assemblies which should be used in several layers of application Use these same types in several Web services, clients ‚Same‘ regarding XSD ( targetNamespace ) Trying to use existing types rather than proxy-built types Beware: Web services are not about type fidelity .NET Remoting

Type Fidelity? What counts are the XSD types in WSDL Have to be in the same namespace to be the same types Use [XmlType(Namespace=„My namespace“] on your type For VS.NET you have to tweak the generated classes on the client Types in different CLR namespaces Beware of code changes when regenerating Use wsdl.exe on command line Visual Studio.NET Add-In for handling issues would be nice to build Take a look at the proxy class tool of WSE Also good for the data binding problem

Using Types demo demo

Headache/Recommendation #5: Asynchronous programming The truth about today‘s Web services: They are not yet loosely coupled, asynchronous We nearly always use HTTP and the Web is slow, unreliable, bad You should always think to call Web services asynchronously You must do so in a Windows Forms app Decouple Web service call from GUI thread Think about one-way calls There are scenarios where asynchronously executing WebMethods may also help Not for simple services, but lenghty background I/O work

Asynchronous programming Client side: Three conceptual approaches: Polling, WaitHandles, Callbacks Thoroughly think which approach to use when Leverages the BeginXXX and EndXXX methods in proxy class Attention: WinForms & threads, multiple calls, faults Service side: Async. WebMethods to decouple background processing Use carefully, might block threads from thread pool

Asynchronous programming demo demo

Recap – what did we just see? Best practices from customer projects [WebMethod] is appropriate for starting It is not bad – but also not good alone Good interface and schema design wins! Debate: what is loosely coupled, what not? Where is it good, where not? A lot of headaches can be solved already now Use built-in, but unknown features Roll your own extensions And most important: This were just five selected headaches – be sure there are a lot more

There is more … trust me To WSDL or not to WSDL More control over WSDL generation Legend of passing Binary Data Never ending story of the Dataset Unfamous IXmlSerializable mysteries Where ASMX fails and IHttpHandler comes to rescue Databinding against proxy generated types Interoperability … and counting...

- Reminder - So you still like [WebMethod]? OK, it’s great – but always remember...

- Reminder - “ … love is the message and the message is love …” From a song by MSFB

Resources Christian‘s Weblog Expect samples there....NET XML Web services Repertory MSDN XML Web services Development Center MSDN Magazine Yasser Shohoud‘s book Real World XML Web services for VB and VB.NET developers

Ask The Experts Get Your Questions Answered Meet me! Wednesday, a.m. – 2.00 p.m. Thursday, a.m. – 2.00 p.m. Well, when sitting here this has just passed by …

Community Resources Most Valuable Professional (MVP) Newsgroups Converse online with Microsoft Newsgroups, including Worldwide User Groups Meet and learn with your peers

evaluations evaluations

© 2003 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.