1. WEB400 Loose Coupling & Serialization Patterns Clemens Vasters newtelligence AG (clemensv@newtelligence.com)

2. Agenda Definitions Objectives Development Approaches Designing Messages Enabling resiliency Q&A

3. Definition: Loose Coupling Macro: Varying implementations J2EE .Net,.Net v1 .Net v1.1, etc. SOA is the solution Micro: Flexible/Resilient implementation Optional data & unions New messages New operations Smart contract & schema design is the solution

4. Definition: Serialization The transformation of a graph of objects to a stream and back again Roll your own System.Xml.Serialization System.Runtime.Serialization The transformation of a CLR type into an XSD schema and back again Roll your own System.Xml.Serialization

5. Definition: Pattern “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same thing twice.” -- Christopher Alexander

6. Objectives Learn the best mechanisms to achieve “micro” loose coupling for data Learn how to make messages flexible & resilient to change Learn how loose coupling manifests itself in the programming model Disclaimer: Some of the code/schema has been cut to fit on slides

7. Development Approaches Two options for developing messages Code first: “I like the CLR” Schema first: “I like XSD” We love both of them Code first is more familiar but implicit Schema first is explicit but less familiar We map from schema  code To achieve loose coupling you must understand XSD – code or schema first

8. Code First Development The best way to avoid unsupported schema constructs If you can do it in code – it is supported Use the [SoapDocumentMethod] Controls the contract that is emitted Useful settings ParameterStyle=SoapParameterStyle.Bare Use=SoapBindingUse.Literal Examine the induced contract often

9. Schema First Development Some schemas cannot be mapped We are working on documenting this Develop schema & contract separately Use WSDL import to associate them Do not use “parameters” message part You want “bare” semantics Always, always, always use doc/literal Encoding – what is that?

10. Schema First Development Use disco.exe to retrieve documents Use wsdl.exe /server to create stub Modify stub to make it all work Strip abstract class & method modifiers Add Location to [WebServiceBinding] Add Binding to [SoapDocumentMethod] Add your implementation This is easier than creating a subclass

11. Designing Messages Each message part resolves to an element (doc/literal) You have a lot of options with varying degrees of “coupledness” for the element types xsd:anyType aka System.Object xsd:string aka System.Object User-defined types (UDTs hereafter) You must choose wisely…

12. Object  xsd:anyType Send anything you want If the serializer supports & knows about it Very open – lots of flexibility Very open – shoot yourself in the foot Must negotiate semantics out of band <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://people"> </schema> public string AddPerson( [XmlElement(Namespace="http://people")] object person) {...}

13. String  xsd:string Better know as “XML as string” Slightly less open than anyType, but has many of the same issues Just about anything can be represented as a string <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://people"> </schema> public string AddPerson( [XmlElement(Namespace="http://people")] string person) {...}

14. User-defined Types (UDTs) Most commonly used Not resilient to change by default </schema> public string AddPerson( [XmlElement(Namespace="http://people")] Person person) {...}

15. UDTs and optional data Elements can be optional Defines must-haves & nice-to-haves </schema>

16. UDTs and optional data UDT contains xxxSpecified “buddy” member Value determines element presence [XmlType(Namespace="http://people")] public class Person { public string name; public string name; public string ssn; public string ssn; public int age; public int age; [XmlIgnore()] [XmlIgnore()] public bool ageSpecified; public bool ageSpecified;}

17. UDTs and unions XSD supports a choice between elements </schema>

18. UDTs and unions UDT contains choice “buddy” member [XmlType(Namespace="http://people")] public class person { public string name; public string name; [XmlElement("driverslicence", typeof(string))] [XmlElement("driverslicence", typeof(string))] [XmlElement("passportnumber", typeof(string))] [XmlElement("passportnumber", typeof(string))] [XmlElement("ssn", typeof(string))] [XmlElement("ssn", typeof(string))] [XmlChoiceIdentifier("ItemElementName")] [XmlChoiceIdentifier("ItemElementName")] public string Item; public string Item; [XmlIgnore()] [XmlIgnore()] public ItemChoiceType ItemElementName; public ItemChoiceType ItemElementName;}

19. Designing Messages Code Code

20. Enabling resiliency Changing without breaking Clients work without recompile Data is not lost on roundtrip Requires forethought There is no magic for this -- yet Most mechanisms for UDTs xsd:anyType & xsd:string don’t need help Namespace versioning is not versioning New namespace != new version New namespace == new elements & types

21. Element/Attribute wildcards Better know as open content model Substitution with some restrictions Very resilient user-defined type ;-) </schema>

22. Element/Attribute wildcards Use XmlElement & XmlAttribute as programming model You process the XML directly [XmlType(Namespace="http://people")] public class person { [XmlAnyElement()] [XmlAnyElement()] public XmlElement[] Any; public XmlElement[] Any; [XmlAnyAttribute()] [XmlAnyAttribute()] public XmlAttribute[] AnyAttr; public XmlAttribute[] AnyAttr;}

23. Wildcards and UDTs Need resiliency for your UDT? Wildcards to the rescue <sequence> <any processContents="lax" minOccurs="0" <any processContents="lax" minOccurs="0"maxOccurs="unbounded"/></sequence> </schema>

24. Wildcards and UDTs Use your fields as you always would Optionally add more data in the future [XmlType(Namespace="http://people")] public class person { public string name; public string name; public string ssn; public string ssn; [XmlAnyElement()] [XmlAnyElement()] public XmlElement[] Any; public XmlElement[] Any; [XmlAnyAttribute()] [XmlAnyAttribute()] public XmlAttribute[] AnyAttr; public XmlAttribute[] AnyAttr;}

25. Processing wildcards A version attribute is useful, especially with wildcards <sequence> <any processContents="lax" minOccurs="0" <any processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </sequence> </schema>

26. Processing wildcards Switching for proper processing public string AddPerson([XmlElement(Namespace="http://people")] Person person) { switch (person.version) { switch (person.version) { case "1.0": case "1.0": return DoAddPersonV1(person); return DoAddPersonV1(person); default: default: return DoAddPersonV2(person); return DoAddPersonV2(person); }}

27. XmlElement Parameters Code first only Generates an fairly open content model [WebMethod] public void AddPerson(System.Xml.XmlElement person) {...} <schema>

28. Enabling resiliency Code Code

29. Summary Think hard about loose coupling If you think it is going to change, it will This is similar to security – you need to design it in SOA & WS enable loose coupling, but they don’t guarantee it There are many tools to achieve this Both code first & schema first are valid Choose which mechanism is right for you

30. Resources Web sites http://msdn.microsoft.com/webservices http://www.w3.org/XMLSchema Newsgroups microsoft.public.dotnet.xml microsoft.public.dotnet.framework.aspnet.we bservices Contacts http://radio.weblogs.com/0108971 clemensv@newtelligence.com douglasp@microsoft.com http://www.douglasp.com

31. Community Resources http://www.microsoft.com/communities/default.mspx Most Valuable Professional (MVP) http://www.mvp.support.microsoft.com/ Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http://www.microsoft.com/communities/newsgroups/default.mspx User Groups Meet and learn with your peers http://www.microsoft.com/communities/usergroups/default.mspx

32. evaluations evaluations

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