1. Messaging with Web Services Enhancements 2.0 Benjamin Mitchell Independent Consultant Microsoft Regional Director – UK Blog http://benjaminm.net/ http://benjaminm.net/ benjaminm@benjaminm.net

2. What We Will Cover: Overview of Web Services Enhancements 2.0 What problems does Messaging solve? Why does Messaging solve them? What types of Messaging models are there? How can I use these programming models today?

3. Web Services Enhancements WSE implements many WS-* specifications Simple, low-level object model for developers Available for free download Logically part of the.NET Framework, but kept separate while still evolving Fully supported by Microsoft until at least 2008 Version 1.0 Dec 2002, Version 2.0 May 2004 Version 2.0 SP 2 pre-release available now Benefits Allows MS to gather real world feedback Allows early adopters to use the latest standards

4. WSE 2.0 Designed to bring advanced Web Services technologies based on standard protocols to developers Integrates with Visual Studio.NET and.NET Framework What do you get with WSE? WS-AddressingWS-SecurityWS-PolicyWS-SecurityPolicyWS-TrustWS-SecureConversationWS-ReferralWS-AttachmentsInteroperability

5. User Code How does WSE work? SoapContext TraceSecurity Referral Policy Custom Security Token Manager Custom Filters

6. Problem Statement Issues with connected systems Bandwidth and Latency Domain boundaries Coordination and Management Solution Less transparency More Explicitness Implementation Message-based programming models

7. Transparency Transparent programming models are easy But, they obscure: Location of code execution Complete context of execution You don’t know that you don’t know

8. Explicitness Explicit programming models leave more for the developer to do They do not obscure as much: Network activity is apparent Context and timing is known You know you don’t know so you take precautions Enables communication to offline services

9. About Messaging Several programming models within the "messaging" bucket Eventing (often called Pub/Sub) DialogsQueuesRequest-Response Key benefits More natural fit for many business processes Allows for more asynchronous processing Many configurations "Smart" routers Offline machines Etc…

10. Web Services and Messaging A way of exposing functionality using a set of interoperable protocols Messages exchanged based on a shared schema Independent of the programming language used No shared classes Unless you intentionally share them

11. Messaging Implementations MSMQClassic Offline Queuing ASMX Easy to use WSE V2 Transport Independence Host anywhere

12. MSMQ Messaging The classic messaging API MessageQueue class Two important methods SendReceive Can provide reliable, in order, only once delivery as well as transaction support Requires MSMQ at both ends of the pipeline

13. ASMX Messaging Easiest way to message with SOAP Create an *.asmx file Write a class Decorate methods with [WebMethod] OneWay or RequestResponse

14. WSE 2.0 Messaging WSE 2.0 includes a SOAP-based messaging API Transport independence Intra-AppDomain For testing Raw TCP HTTP Host Independence Windows application ASP.NET Windows Service

15. WSE 2.0 Messaging SoapSender and SoapReceiver One way messages Deal with the SoapEnvelope rather than method parameters Must implement method dispatching based on SoapEnvelope.Context.Adressing.Action No automated reply messages The Receiver must implement a new Sender Sender must indicate reply address

16. Demonstration 1 SoapSender and SoapReceiver

17. WSE 2.0 Messaging (Continued) SoapClient and SoapService One-way and two-way Uses SoapSender/SoapReceiver Offers XML Serialization support Operation-based dispatching The Action is used to deliver the message to a Method Automatic replying

18. Demonstration 2 SoapClient and SoapServer

19. WSE 2.0 Messaging (Continued) Channels Queued model Raw, explicit programming

20. Programming Models ReceivingPollingPushAdaptationAdapterMapper Errors Dead letter channel FaultsGateway Aggregating Gateway Router

21. Programming Models: Receiving Push-model Implicit message receive Message is processed when message arrives Allows for Activation CLIENT

22. Demonstration 3 Push-model messaging with ASMX

23. Programming Models: Receiving Polling to receive messages Explicit message receive Lets recipient control when message is processed CLIENT

24. Demonstration 4 Message Polling with WSE 2.0

25. Programming Models: Adaptation Application not always messaging aware Too costly to re-code entire app Adapters translate app-specific data and behavior into Messages APPLICATION ADAPTER

26. Message on wire is serialized into common format Message data on system not always serializable Message mapper deals with this MAPPER Programming Models: Adaptation DATA MESSAGE

27. Programming Models - Errors Two errors messaging is well-suited to deal with Dead letters Invalid messages Exceptions Exceptions can occur before dispatch In user code Soap Faults map to Exceptions Fault codes are QNames

28. Design: Gateway Wraps application-specific logic Most Web services are gateways GATEWAY APP CODE

29. Design: Gateway Aggregator is gateway that combines several messages into one internal action GATEWAY APP CODE

30. Design: Router Routes a message from a source to a destination ROUTER SOURCE DESTINATION

31. Design: Router Several type of routers Splitters Aggregators Filters ROUTER ROUTER ROUTERABC ABZ

32. Design: Router And content-based routers AROUTER B ABC =ABC =DEF

33. Design: Pub/Sub Publication and Subscription Message pattern One message to subscribe One to many messages publishing event information Observer pattern over a distributed system

34. Design: Pub/Sub More on pub/sub EVENT SERVICE SUBSCRIBER SUBSCRIBE EVENTS

35. Design: Pub/Sub Two models for getting event data Push – notification includes data Pull – subscriber sends a request for the subscription data after receiving the event Push is usually best for Web services Pull is good when subscribers may not be interested in the data and the data is large or processor intensive

36. Demonstration 5 Eventing

37. Design: Reliability Strongest and most resilient systems implement reliable messaging Reliable messaging requires: Idempotent processing Durable storage NODE NODE

38. Design: Dialogs and Queues Dialogs are virtual connections between two nodes With the help of queues, dialogs can be reliable and persistent across system resets

39. NODE Design: Dialogs and Queues More on dialogs and queues NODE

40. Design: Long-Running Operations Long-running operations A key gain of messaging Allows closer modeling of real-life business scenarios Examples User interaction is needed Batch processing across multiple nodes

41. Design: Long-Running Operations Example NODE NODE NODE NODE NODE

42. Design Guidelines Avoid RPC and CRUD designs Tends to encourage RPC like behavior Interface may imply stateful interactions like enumeration Interface is likely to be overly chatty Don’t be too loose or extensible Focus on encapsulating business processes Use contracts to reduce coupling

43. Session Summary Messaging allows for apps that more closely match business processes Applications that use messaging are more closely matched with business processes Existing technology can be used to support messaging WSE 2.0 provides extensible messaging with web services across multiple protocols

44. Call to Action Start designing with messaging in mind Download WSE 2.0 Service Pack 1 Download the Hands-On Labs on WSE Messaging from Aaron Skonnard http://msdn.microsoft.com/webservices/buildi ng/wse/default.aspx http://msdn.microsoft.com/webservices/buildi ng/wse/default.aspx

45. For More Information Blogs http://benjaminm.net Rebecca Dias WSE Product Manager http://weblogs.asp.net/rdias http://weblogs.asp.net/rdias Hervey Wilson Lead Developer WSE http://dynamic-cast.com http://dynamic-cast.com Newsgroupmicrosoft.public.dotnet.framework.webservices.enhancementsBooks Enterprise Integration Patterns – Gregor Hohpe and Bobby Woolf