WEB400 Loose Coupling & Serialization Patterns Clemens Vasters newtelligence AG

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

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

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

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

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

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

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

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?

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

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…

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=" targetNamespace=" </schema> public string AddPerson( [XmlElement(Namespace=" object person) {...}

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=" targetNamespace=" </schema> public string AddPerson( [XmlElement(Namespace=" string person) {...}

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

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

UDTs and optional data UDT contains xxxSpecified “buddy” member Value determines element presence [XmlType(Namespace=" 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;}

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

UDTs and unions UDT contains choice “buddy” member [XmlType(Namespace=" 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;}

Designing Messages Code Code

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

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

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

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>

Wildcards and UDTs Use your fields as you always would Optionally add more data in the future [XmlType(Namespace=" 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;}

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>

Processing wildcards Switching for proper processing public string AddPerson([XmlElement(Namespace=" 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); }}

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

Enabling resiliency Code Code

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

Resources Web sites Newsgroups microsoft.public.dotnet.xml microsoft.public.dotnet.framework.aspnet.we bservices Contacts

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.