Say what you will say and listen to what you will listen to …

1. Say what you will say and listen to what you will listen to … About the importance of contracts and metadata… Clemens Vasters, newtelligence AGclemensv@newtelligence.com

2. This talk • Thinking about data • Thinking about types • Thinking about passing typed data • Thinking about exchanging data • Thinking about behaviors around data • How is this relevant to today’s launch event?

3. Data

4. There … FF FE 43 00 6C 00 65 00 6D 00 65 00 6E 00 73 00 20 00 56 00 61 00 73 00 74 00 65 00 72 00 73 00 2C 00 20 00 47 00 69 00 6C 00 6C 00 65 00 73 00 68 00 FC 00 74 00 74 00 65 00 20 00 39 00 39 00 2C 00 20 00 32 00 31 00 33 00 35 00 32 00 20 00 4B 00 6F 00 72 00 73 00 63 00 68 00 65 00 6E 00 62 00 72 00 6F 00 69 00 63 00 68 00 2C 00 20 00 47 00 65 00 72 00 6D 00 61 00 6E 00 79 00

5. … are many … Clemens Vasters, Gilleshütte 99, 41352 Korschenbroich, Germany

6. … ways to … NAM,Clemens VastersSTR,Gilleshütte 99 CIT,Korschenbroich*41352 CTY,Germany

7. … represent … <Address> <Name>Clemens Vasters</Name> <Street>Gilleshütte 99</Street> <City>Korschenbroich</City> <Postcode>41352</Postcode> <Country>Germany</Country> </Address>

8. … information and … Address address = new Address(“Clemens Vasters“,“Gilleshütte 99“, “Korschenbroich“, “41352“, “Germany“);

9. ….none is wrong … DataSet ds = GetDataSet();DataTable dt = ds.Tables[“Address“]; dt.Rows.Add( new object[]{“Clemens Vasters“,“Gilleshütte 99“, “Korschenbroich“, “41352“, “Germany“});

10. ….or right clemensv@newtelligence.com

11. A Billion € Problem… • Many ways to represent information • Many ways to turn information into “data” • Many ways to represent data • The difficulty is not choice, it’s agreement. • Agreement requires eliminating ambiguity. • Agreement != Democracy

12. Attempting to agree:Name and Location var FirstName;

13. Attempting to agree:Name and typed Location wchar_t * FirstName;

14. Attempting to agree:Name, Location, Type and Implemented Behavior string FirstName;

15. Attempting to agree:Location and Data <item>Clemens</item>

16. Attempting to agree:Name, Location and Data <FirstName> Clemens</FirstName>

17. Attempting to agree:Name, Location, Type and Data <FirstName xsi:type="xsd:string"> Clemens</FirstName>

18. Elements of Agreement (Step 1) • Name: Common understanding of names for data elements and their interpretation • Location: Common understanding of (relative) location of data inside a context • Type: Common understanding of persistent or transient representation of data elements • Data: Representation of information under agreement on name, location and type.

19. How about implementation? • Sorry, we can't reach agreement on that ... • Implementation realizes requirements in the scope of a (sub-)system context • How do you agree on implementation across applications, frameworks and languages; organizations and software suppliers? • Impl. agreement contradicts modularity • Same behavior of data for all tiers and layers? • Same behavior of data for all modules? • Same behavior of data for all applications?

20. Where does that lead us? • We can agree on data, types and location. • We can't agree on implementation. • Data can be exchanged • Implementation cannot  Conclusion: Trying to agree on data and implemen-tation (aka. "objects") might be a problem.

21. How good are your types? string FirstName = "Q?C&89/&%$$";

22. How good are your types? string FirstName = null;

23. How good are your types? • string FirstName = • "This is a very long string which will likely not fit into your database, because the database field for this element does only allow 40 characters to be stored and this is easily longer";

24. Agreeing on types is hard (1/2) • Data types describe storage and behavioral rules. • Agreeable storage requirements: • Strings: Bounded sequences of characters,Integers: Bounded, integral numbers,Floats: Bounded, floating point numbers • Agreement on storage rules is still scoped: CLR, XML, JVM, SPARC, IA64, IA32

25. Agreeing on types is hard (2/2) • Can't agree on implemented behavior, but on rules for behavior • 1 + 1 = 2 • "1"+"1"="11" • 2003-02-29 bad, 2004-02-29 good • FirstName: minLength=1, maxLength=40, pattern="\p{L}+" • Particular record may only appear once in a sequence (uniqueness)

26. Common ground • XML 1.0 provides storage rules • XML Schema provides extensible type set • XML Schema provides ability to restrict • XML Schema is a way to express (and impose) agreement on data!

27. Restricting <xsd:simpleType name="nameType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\p{L}[\p{L}\p{P}0-9\s]+"/> </xsd:restriction></xsd:simpleType> <xsd:simpleType name="phoneNumberType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[0-9\+][0-9\-\(\)\s]*" /> <xsd:maxLength value="26" /> </xsd:restriction> </xsd:simpleType>

28. Composing <xsd:complexType name="addressType"> <xsd:sequence> <xsd:element name="City"> <xsd:simpleType> <xsd:restriction base="nameType"> <xsd:maxLength value="80" /> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="Country" type="countryNameType" /> <xsd:element name="CountryCode" type="countryCodeType" /> <xsd:element name="PostalCode"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:maxLength value="10" /> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="AddressLine"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:maxLength value="160" /> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType>

29. Versioning • There's versioning built into XML Schema •  It's so useful that you shouldn't use it. •  How can users tell looking at instances? • Proper use is: • Import into new namespace and extension/restriction • Replacement with new schema with different namespace • Design to extend using <any/>

30. DOM, DataSets and Serialization • XmlDocument: Hierarchical prog. model • DataSet: Relational prog. model • Serialization: OO prog. Model • All those map from and to the InfoSet • Type system for InfoSet is Schema • Allows validation of data for correctness • Allow generation of code enforcing rules

31. XSD.EXE • Generates classes from Schema • Turns complexType into classes • Translates enumeration restrictions into enums • Doesn't enforce other restriction facets • Generates DataSets from Schema • Turns complexType into tables • Turns "complexTypes in complexTypes" into relations between tables • Enforces length restriction facets • Also generates schema from classes • Good start point, but that's it

32. Contract

33. Contracts: Promises and Trust • Contracts between endpoints … • Are promises and guarantees to deliver stuff (and how) • Are promises and guarantees to accept stuff (and how) • Contract parts in Web Services • XSD: Data types • WSDL/XSD: Messages • WSDL/BPEL4WS: Message exchange patterns • WS-Policy: Quality of service rules and req’s • Contract parts in Enterprise Services • Metadata/IDL: Data types, messages, exchange patterns • Config/Negotiation: Quality of service rules and req’s

34. Contract Styles • “Method Calls” • Request/Response • Typically synchronous • Typically map 1:1 • Interface ↔ Impl. RPC Contract Schema Contract • “Messages” • Messaging • Synchronous & asynchronous • Multiple schema variants •  one endpoint Dialog Contract • “Messages” • Messaging Conversations • Asynchronous • Multiple schema variants •  one endpoint • “Come back when you’re ready” instead of request/response

35. EndpointAddress EndpointAddress EndpointAddress EndpointAddress CustomerModule ShippingModule OrdersModule ShippingModule ShippingModule XSDWSDLMEP XSDWSDLMEP XSDWSDLMEP XSDWSDLMEP ServicePolicy ServicePolicy ServicePolicy ServicePolicy Contracts at work Registry(UDDI) Router EndpointAddress Taxo-nomy XSDWSDLMEP ServicePolicy XSDWSDLMEP

36. Arrogance as design pattern If I send you a message that complies to your contract, you better take care of the message in a proper way! Errors? You better deal with them yourself! Queue Coordinator Coordinator Queue RM Queue RM

37. Cooperation as design pattern If I send you a message that complies to your contract, but it still fails the operation, you can let me know and I'll try to fix what I can. Coordinator Coordinator

38. OOA & OOD in a Services World • Analyze data and behavior requirements • OOA is a Good Thing • Design data, not "objects" • OOD design that yields "business objects" is a questionable thing to do. • Designing data and context-appropriate behavior ("services") is a Good Thing • There is no easy path from OOA to OOD if you want to build a scalable, distributed system of services.

39. Just do it.

40. XmlValidatingReader • XmlValidatingReader is a good friend • Direct or as reader for XmlDocument • Validates instances using Schema collections • Enforces all facets of type restrictions • Enforces contracts • Validation is an "edge service" like authentication • Can't trust incoming data, must verify outbound data • You pay performance tax, but it's worth the effort

41. From Schema to Metadata <xsd:simpleType name="nameType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\p{L}[\p{L}\p{P}0-9\s]+"/> </xsd:restriction></xsd:simpleType> <xsd:element name="FirstName"> <xsd:simpleType> <xsd:restriction base="nameType"> <maxLength value="80"/> </xsd:restriction> </xsd:simpleType></xsd:element> [Match(@"\p{L}[\p{L}\p{P}0-9\s]+"), MaxLength(80)] public string FirstName;

42. "It'll absolutely get there" • MSMQ 3.0 • Reliable messaging infrastructure • TCP, SOAP/HTTP Transports • Exposed through System.Messaging and Enterprise Services "Queued Components" • Guarantees delivery, supports transactions • Using Queues gives you … • Peace of mind. You know that it'll get there. • Fairness. Every machine runs at it's own pace. • Scalability. No need to be synchronous.

43. Presentation Data Implementing Services LooserCoupling XML HTML GUI EDI COM PublicInterface Presentation public class MyBusinessComponent { InternalImplemen-tation Services &ResourceAccess Data TighterCoupling SQL MQ WS XSD RPC

44. Services as a recursive pattern Presentation Services BusinessServices DataServices

45. On the edge:ASMX & Enterprise Services • IIS 6.0 and ASP.NET Web Services (ASMX) • Application infrastructure for implementing public interfaces for "far tiers" • Highly optimized for HTTP traffic, appropriate process model for Web Services • Windows Enterprise Services • Application infrastructure for implementing services for "near tiers" • Most appropriate process model for implementing robust, available backends • ASMX and Enterprise Services are a team

46. Anony-mous Network-Service ServiceAccount ASMX & ES in concert Browser RFC2617 Auth ACL PrincipalPermission ASP.NET Windows SSPI Roll Enterprise Services Application Identity:Domain/Account ServicedComponent ServicedComponent Component Component Component Component Component Component ADO.NET “Integrated Security=SSPI” Windows SSPI Roll Group SQL Server

47. Summary • For scalable systems to work, contract is needed • Data type definitions need to be stronger in distributed systems • Strong types enable better modularization • The .NET Framework enables you to make that work for you ….