The document explores service-oriented development using Windows Communication Foundation (WCF), highlighting key concepts such as service contracts, message-based communication, and dynamic loading. It emphasizes the importance of loosely coupled integration, versioning, and a focus on schema and contract rather than class sharing. WCF is presented as a powerful framework that supports various message exchange patterns and robust security, making it suitable for modern distributed computing.

1. Service Oriented Development with Windows Communication Foundation Jason Townsend

2. Evolution of Service Orientation

3. Object-Oriented Polymorphism Lets you treat derived class members just like their parent class' members. Process of using an operator or function in different ways for different set of inputs given. The ability of objects belonging to different types to respond to method calls of the same name, each one according to an appropriate type-specific behavior. Encapsulation Often used interchangeably with information hiding. Reduces software development risk by shifting the code's dependency on an uncertain implementation (design decision) onto a well-defined interface. Subclassing Subclass is a class that inherits some properties from its superclass.

4. Component-Based Interface-based Insists that Interfaces are to be added to components. The entire system is thus viewed as Components and the interfaces that helps them to coact. Dynamic Loading Dynamic loading is a mechanism by which a computer program can, at runtime, load a library (or other binary) into memory, retrieve the addresses of functions and variables contained in the library, execute those functions or access those variables, and unload the library from memory. Runtime Metadata Enabled the ability to build systems that dynamically loaded and bound to new functionality at runtime.

5. Service-Oriented Message-based Communication is made by the sending of messages to recipients. Forms of messages include function invocation, signals, and data packets. Schema and Contract Use schema to describe the structure of messages Use contract to define acceptable message exchange patterns. Binding via Policy Use policy to define service semantics used for binding.

6. Tenets of Service Orientation

7. Boundaries are Explicit Based on the underlying concept of encapsulation, this tenet specifies the publishing and consumption of functionality as sets of services that abstract their underlying implementation. With WCF, the attribute-based programming enables developers to explicitly define external service contracts. Without explicitly defining these, nothing within the class will be exposed publicly. WCF provides an opt-in model for explicitly defining service boundaries.

8. Autonomous Evolution Services are Autonomous. Autonomy We design the system to support the inevitable evolution of the service’s implementation over time. As we build our services, we need to assume that their internal implementation will evolve (become versioned) over time and that our services as well as the services on which we depend could change location at (almost) any time.

9. Share Schema & Contract, Not Class Services share schema and contract, not class. This is how ASMX works. Service publishes a contract (WSDL, XSD) No types are shared between service and its client (by default) Neither service requires knowledge of each others’ internal workings in order to exchange data.

10. Compatibility Based on Policy Service compatibility is determined based on policy. Services communicate through dynamically negotiated communications channels that support the necessary semantics. Service policy statements created automatically based on configuration, class attributes, and method signatures. Client channels automatically configured via retrieved service policy.

11. Why Service Orientation? Facilitates loosely coupled standards based integration. Enables independence in deployment, versioning, and management of the client (caller) and the server (called). Promotes reuse of application investments over time.

12. WCF Design Goals

13. WS-* Used as a reference to many web service based standards covering topics such as: XML Specifications Messaging Specifications Metadata Exchange Specifications Security Specifications Privacy Reliable Messaging Specifications Resource Specifications Web Services Interoperability organization (WS-I) Specifications Business Process Specifications Transaction Specifications Management Specifications

14. XML Specifications XML (eXtensible Markup Language) XML Namespaces XML Schema XPath XQuery XML Information Set XInclude XML Pointer

15. Messaging Specifications Simple Object Access Protocol (SOAP) SOAP Message Transmission Optimization Mechanism WS-Notification WS-BaseNotification WS-Topics WS-BrokeredNotification WS-Addressing WS-Transfer WS-Eventing WS-Enumeration

16. Metadata Exchange Specifications WS-Policy WS-PolicyAssertions WS-PolicyAttachment WS-Discovery WS-Inspection WS-MetadataExchange Universal Description, Discovery, and Integration (UDDI) WSDL 2.0 Core WSDL 2.0 SOAP Binding Web Services Semantics (WSDL-S) WS-Resource Framework (WSRF)

17. Security Specifications WS-Security XML Signature XML Encryption XML Key Management (XKMS) WS-SecureConversation WS-SecurityPolicy WS-Trust WS-Federation WS-Federation Active Requestor Profile WS-Federation Passive Requestor Profile Web Services Security Kerberos Binding Web Single Sign-On Interoperability Profile Web Single Sign-On Metadata Exchange Protocol Security Assertion Markup Language (SAML) XACML

18. Privacy P3P Reliable Messaging WS-ReliableMessaging WS-Reliability WS-RM Policy Assertion

19. Resource Specifications Web Services Resource Framework WS-BaseFaults WS-ServiceGroup WS-ResourceProperties WS-ResourceLifetime WS-Transfer Resource Representation SOAP Header Block

20. Web Services Interoperability Organization (WS-I) Specifications WS-I Basic Profile WS-I Basic Security Profile Simple Soap Binding Profile

21. Business Process Specifications WS-BPEL WS-CDL Web Services Choreography Interface WS-Choreography XML Process Definition Language

22. Transaction Specifications WS-BusinessActivity WS-AtomicTransaction WS-Coordination WS-CAF WS-Transaction WS-Context WS-CF

23. Management Specifications WS-Management WS-Management Catalog WS-ResourceTransfer WSDM

24. WCF Make WS-* Easy Binding selection abstracts WS-* internals WCF has Oasis Standard Bindings (3.5) Single Object model for Transports Choreographies Message Exchange Patterns (MEPs) Etc…

25. WCF Offers Features You Need Logging Tracing Instance Control Throttling Rich Configuration Extensibility Hosting Options And More….

26. Communicating through Messages Messages travel between communication parties Messages can be grouped into different message exchange patterns (MEPs) MEPs can be implemented synchronously or asynchronously WCF supports different MEPs WCF MEPs implemented by different kinds of channels

28. Channel Shaping Possible mismatch: Physical transport Logical message exchange patterns Channel shapes implemented in transport bindings Express support for Message Exchange Patterns WCF ServiceModel analyzes contract Which channel shapes will be supported? ServiceChannelFactory.BuildChannelFactory and DispatcherBuilder.GetSupportedChannelTypes have the details

29. Types of Contracts Service Contract Operations Behaviors Communication Shape Data Contract Schema and Versioning Strategy Message Contract Application specific headers and unwrapped body content

30. Contracts (Request-Reply) Most commonly used MEP It is easy to use and looks natural R/R can be implemented in WCF by several approaches Parameter list DataContract MessageContract Message Mind the “public face” of contracts, i.e. the metadata

31. Contracts (One-Way) One Way operations smell more feasible when decoupling is goal No return values, rather void Use IsOneWay property of OperationContract OneWay operations can still block Not really fire-and-forget semantics

32. Contracts (Duplex) Having peer communication parties Blurring the line between client and server Use CallbackContract property of ServiceContract Operations in contracts can be one-way, but need no to be If using non-one-way beware of threading issues

33. Contracts (Streaming) Buffered communication can be very expensive with large data WCF offers streamed transfer Contract parameters must have certain shape Use Message, IXmlSerializable or System.IO.Stream or derivate as type Use MessageContract Headers will be buffered Body as System.IO.Stream will be streamed Only works with appropriate binding

34. Bindings (Request-Reply) Almost all out-of-the-box bindings support request-reply MSMQ-based bindings do not For all bindings and MEPs: Beware of default min/max values on binding elements for e.g. message sizes and buffers and timeouts Beware of possible throttles on service behavior

35. Bindings (One-Way) All bindings support one-way operations Use OneWayBindingElement for custom bindings to shape channel Performs a message-level shape change Can take a IDuplexSessionChannel or a IRequestChannel and expose it as a IOutputChannel, or conversely it can take a IDuplexSessionChannel or a IReplyChannel and expose it as a IInputChannel

36. Bindings (Duplex) Duplex out-of-the-box netTcp wsDualHttp netNamedPipe netPeerTcp Manual duplex session-less, e.g. <compositeDuplex /> <oneWay /> <binaryMessageEncoding /> <httpTransport />

37. Bindings (Streaming) Enable streaming on the baked-in bindings All standard bindings besides MSMQ-based Enable streaming on the transport binding element, e.g. <httpTransport transferMode=„Streamed“ /> Possible transferMode values Buffered Streamed StreamedRequest StreamedResponse Only transport security and no reliable sessions allowed

38. MSMQ Transport MSMQ is different – always has been Duplex Message Exchange Patern over MSMQ-based binding can be achieved manually: Leverage message headers Access headers through OperationContext in user code Access headers through message inspectors in ServiceModel extensions Use GUID to correlate messages

39. REST Focus is on the URI HTTP GET http://dog.com/dogs.id/12 HTTP POST http://dog.com/updateDog GET is special, other verbs are application specific GET verb always means “View It” PUT/POST/DELETE mean “Do It” but depend on client implementation Content Type is the data model XML JSON Binary Etc... Support built on via WCF extensibility points

40. WS-* versus REST Which is better? Each has strengths: REST: proliferation of clients, easy to understand Flash Silverlight Javascript Etc… WS-*: rich Messaging Exchange patterns, Topologies, and Choreographies

41. WCF Security Claims based end-to-end security Secure end-to-end message exchanges Secure access to resources Record resource access requests X509, Username/Password, Kerberos, SAML, and custom credentials Message Security Confidentiality and Integrity Transport or Message Level Access to resources Authentication and Authorization

42. WCF Reliability and Transactions End-to-End Reliable Messaging In-Order guarantees Exactly once guarantees Transport-Independent Sessions Integration with ASP.NET Sessions in IIS-Hosted compatibility mode Transactions Guaranteed atomic success or failure across services

43. WCF Instancing, Concurrency, and Sessions Service classes can be instantiated Singleton Per-Call Per-Session Shareable Service code can be either: Single-threaded Re-entrant Multi-threaded

44. WCF Summary WCF is the future of distributed computing It combines the best of all existing Microsoft distributed computing stacks It uses WS-* standards for interoperability and .NET value-add for performance and integration with existing solutions.

46. Further Resources My Blog http://www.okcodemonkey.com Linkedin http://www.linkedin.com/in/okcodemonkey Bartlesville .NET User Group http://www.bdnug.com Twitter http://twitter.com/okcodemonkey Email [email_address]