Messaging with Web Services Enhancements 2.0 Benjamin Mitchell Independent Consultant Microsoft Regional Director – UK Blog

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?

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

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

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

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

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

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

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…

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

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

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

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

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

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

Demonstration 1 SoapSender and SoapReceiver

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

Demonstration 2 SoapClient and SoapServer

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

Programming Models ReceivingPollingPushAdaptationAdapterMapper Errors Dead letter channel FaultsGateway Aggregating Gateway Router

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

Demonstration 3 Push-model messaging with ASMX

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

Demonstration 4 Message Polling with WSE 2.0

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

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

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

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

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

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

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

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

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

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

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

Demonstration 5 Eventing

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

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

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

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

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

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

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

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 ng/wse/default.aspx ng/wse/default.aspx

For More Information Blogs Rebecca Dias WSE Product Manager Hervey Wilson Lead Developer WSE Newsgroupmicrosoft.public.dotnet.framework.webservices.enhancementsBooks Enterprise Integration Patterns – Gregor Hohpe and Bobby Woolf