windows communication foundation indigo writing reliable and transacted distributed applications
Skip this Video
Download Presentation
Windows Communication Foundation (“Indigo”): Writing Reliable and Transacted Distributed Applications

Loading in 2 Seconds...

play fullscreen
1 / 25

Windows Communication Foundation Indigo : Writing Reliable and Transacted Distributed Applications - PowerPoint PPT Presentation

  • Uploaded on

Windows Communication Foundation (“Indigo”): Writing Reliable and Transacted Distributed Applications. Shy “BAD-P” Cohen COM307 Program Manager Connected Systems Division Microsoft Corporation. Moving To Service Orientation. Threads versus Messages BAD P! BAD, BAD P!

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Windows Communication Foundation Indigo : Writing Reliable and Transacted Distributed Applications' - kenna

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
windows communication foundation indigo writing reliable and transacted distributed applications

Windows Communication Foundation (“Indigo”): Writing Reliable and Transacted Distributed Applications

Shy “BAD-P” Cohen


Program Manager

Connected Systems Division

Microsoft Corporation

moving to service orientation
Moving To Service Orientation
  • Threads versus Messages
    • BAD P! BAD, BAD P!
    • Why don’t you come back? Please hurry… ♫
  • Keeping it Consistent
    • All together now!
challenges of implementing reliable distributed systems
Communication Issues

Network unavailable

Connection drops

Network loses messages

Messages may arrive out of order

Messages may take different paths

Retried messages may arrive after the ones that followed them

Processing Issues

Messages lost when processing fails

Interrelated Messages processed individually

Failure may leave the distributed system in an inconsistent state

Messages can’t be retried without side effects

Retried messages arriving twice, reordering, etc.

Challenges Of Implementing Reliable Distributed Systems

Service Instance






reliable sessions assurances
Reliable Sessions Assurances
  • Messages are delivered exactly once, in the same order as they were sent
    • Alternatively, you can choose to have them delivered in order in which they were received
  • Resilient to
    • Transport disconnections
    • SOAP or transport intermediary failures
  • Features
    • Connection verification and maintenance
    • Congestion and flow control
reliable sessions enabling
Reliable SessionsEnabling
  • Provided on Standard Bindings

netTcpBinding (off by default)

wsHttpBinding (off by default)

wsDualHttpBinding (always on)

  • Can be added to any custom binding



<binding configurationName=”ReliabilityHTTP”>






keeping it consistent
Keeping It Consistent
  • Atomic Transactions versus Compensation
  • Trading off coupling and complexity
    • Atomic Transactions: simpler, tighter coupling
    • Compensation: more complex, looser coupling
  • Both have their place
    • Choose the right model for the situation
transactions summary
  • Service Developer (Code)
    • Declares willingness to participate in an incoming (client initiated) transaction on contract operations
      • No transaction sharing on one-way operations! *
    • Specified implementation behavioral aspects at the service and method level
  • Client Developer (Code)
    • Creates transactions
    • Includes services & local TX-ed resources in their scope
  • Service Administrator (Config)
    • On/Off switch controls TX flow support for an endpoint
    • It’s about Trust
  • Increase availability
    • Mask network or service unavailability
  • Support scale out
    • Multiple readers from a single queue
  • Provide load leveling
    • Handle average, not peak load
  • Are a building block for compensating business transactions
    • Reliable, durable messaging to capture distributed state changes
    • Need to compensate for errors



  • Make one-way operations possible even when the service isn’t available
  • Supported via MSMQ
    • Programmer uses regular WCF channels
    • IT Pro manages the familiar MSMQ service



queues composing with txs
QueuesComposing with TXs
  • Operation requires 2 transactions
    • TX between client and queue to send
    • Another TX between service and queue to receive
  • If a transaction aborts
    • Message sent under the TX are discarded
    • Messages received under the TX are retried
queues meps
  • Datagrams
    • Standalone messages
    • Can be sent and received with or without using a transaction
    • “Exactly Once” or “Best Effort” delivery
  • “Sessiongram”
    • A grouping of related messages
    • Always processed together under a single TX
    • “Exactly Once, In Order” delivery
queues the dead letter queue
QueuesThe dead letter queue
  • Stores messages that could not be delivered
  • Can be processed like any other queue
  • New in Windows Vista: User specified DLQ
    • If not specified, the default is the system-wide DLQ
    • With a shared DLQ, processing service needs to implement all the contracts for all the messages going into it
    • Alternatively, use System.Messaging to process messages from the Dead Letter Queue
queues poison messages
QueuesPoison messages
  • Messages for whom processing fails, repeatedly, are considered “poison”
    • Failure = the processing transaction aborted
  • Message properties indicate how many times a message was delivered

MsmqMessageProperty msmqMessageProperty;

msmqMessageProperty = OperationContext.Current .IncomingMessageProperties[MsmqMessageProperty.Name]

as MsmqMessageProperty;

if (prop.TotalAbortCount > myRetryThreshold) { /* Do something */ }

queues poison messages21
QueuesPoison messages
  • New in Windows Vista: Automatic protection against repeated failures
    • By limiting NUMBER of retries
    • By controlling HOWretries are done


<binding configurationName=“QB"




rejectAfterLastRetry="false" />


3 retry cycles

1st attempt

To Poison Message Queue

2 retries

10 seconds between attempts

q s failure compensation
Q’sFailure compensation
  • Set up compensation services on the sending and receiving sides

<binding configurationName="MyQueueBinding“



deadLetterQueue= "net.msmq://MyClient/private/myCustomDLQ"



address ="net.msmq://MyServer/private/MyQueue;poison/”


bindingConfiguration ="MyQueueBinding"

contractType="Queue.IPurchaseOrder, Queues" />

when faced with challenges
When Faced With Challenges
  • WCF provides sophisticated session mgmt
    • Session lifetime and associated state
  • WCF assures
    • … that messages arrive exactly once
    • … in the order in which they were sent
  • WCF provides transacted state management
    • Computation and communication
  • WCF provides high availability
    • Durability, atomicity, and error handling
community resources
Community Resources
  • At the PDC
    • More on Windows Communication Foundation
      • Attend the other WCF presentations
      • Talk to me and the other WCF folks at the Lounge, Ask The Experts, or at any other time
    • More on System.Transactions
      • Go talk to Max (COM lounge) or Jim (FUN lounge)
      • Attend FUN320 tomorrow
    • Do the HOLs: WCF HOLs, FUN HOL13 (TXF & TXR)
  • After the PDC
    • MSDN dev center:
    • MSDN Forums
    • Channel 9 tag:
    • Contact me: [email protected]

© 2005 Microsoft Corporation. All rights reserved.

This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.