The deadline for external presenters to submit their session ideas for MIX 2009 is January 23rd. You can send your submissions to mixprpsl@microsoft.com. Here's what you need to include in the submission.
Title: Ideally, the title is short, catchy, and descriptive
Abstract: One or two sentences that describe what an attendee would hear and learn in the session
Speaker: Your name
Speaker Bio: A little about who you are and why you're the perfect person to present the session
Speaker Contact Info: Your e-mail address and phone number
Target Audience: Creative, Technical, or Business
Session Type: Full or Mini
MIX 2009 has introduced a new mini-session format that gives 20 minutes to focus on a specific topic. These mini-sessions are a complement to the standard 75 minute sessions.
The conference runs March 18-20.
VSLive is a Microsoft sponsored conference for developers working with Visual Studio and .Net. The 2009 conference is February 24-26 in San Francisco (with workshop days before and after the sessions). Here are some of the sessions that WCF developers might be interested in.
Build Distributed Apps in .NET 3.5 SP1 (pre-conference workshop) by Rockford Lhotka
In this workshop you will learn how to design WPF, Web Forms, ASP.NET MVC and WCF service applications using a combination of object-oriented and service-oriented architecture and design principles. This workshop is about getting things done in .NET, leveraging your knowledge from .NET 2.0 to build performant, scalable and maintainable applications using the features of .NET 3.5 SP1. You'll see applications end-to-end, from the database through the business logic to the presentation layer, and you'll see how object-oriented techniques increase maintainability, while n-tier client/server and SOA complement each other to balance performance, scalability and decoupling of applications.
Managing Data with Silverlight by Billy Hollis
Silverlight 2.0 is fully data-enabled. Unlike the media-focused first version, you have many options to get data into and out of Silverlight 2.0 applications, LINQ capabilities to work with data on the client, and multiple choices for containing data on the client. This session will look at ways to get data into Silverlight, including ADO.NET Data Services and other REST-based services, WCF, and web services, and how each works end-to-end with data objects on the client to provide a complete and stateful data experience for the user.
An Introduction to Windows Communication Foundation by Robert Green
This session will provide an introduction to Windows Communication Foundation, and answer a number of questions such as: What is WCF? Why was it invented? How does it compare to Web services or .NET Remoting? How is it better than those? What is a service? How do I create one? How do I host one? How do I call one from my applications? What do I need to do to make sure clients and services can communicate? Once we answer these types of questions, you will be able to start creating your own WCF services and have a much better understanding of how to work with this promising new technology.
Code Name "Dublin": Windows Application Server by Aaron Skonnard
Microsoft recently announced a set of enhanced Windows Server capabilities code named "Dublin" that offer greater scalability and easier manageability around WCF/WF applications. Dublin extends IIS/WAS to provide a standard host environment for applications that use these core .NET technologies to simplify the deployment, configuration, management, and scalability of composite applications, while allowing developers to use their existing skills with Visual Studio, .NET, and IIS. This session introduces you to the new world of Dublin.
What's New in WCF/WF 4.0 by Aaron Skonnard
.NET 4.0 brings several improvements in the areas of WCF and WF, including improved REST capabilities, a new workflow model, seamless integration between WF and WCF, and a new visual designer. It also provides the ability to author completely declarative (XAML-based) Workflow services that can be more easily deployed, hosted, and managed. This session walks you through the various new 4.0 features and shows you how to write code using them today.
Understanding Transactions in WCF by Robert Boedigheimer
Transactions play an important role in keeping our systems in a consistent state, making sure that combined operations all succeed or all fail. When working with (web) services, transactions are more complex than within a single AppDomain. Fortunately, we have transactions support in WCF to help us manage this complexity. This session looks at how transactions work in WCF, the different transaction managers used by WCF in different scenarios, and of course how to use transactions in WCF.
Web 2.0 + WCF by Aaron Skonnard
WCF provides first-class support for building "Web" services that embrace REST design principles using standard Web protocols and data formats. This session illustrates how to build WCF services that support the HTTP uniform interface and different resource representations like XML, JSON, and Atom/AtomPub to enhance your Web 2.0 mash-ups. We'll specifically look at the new features in WCF, the WCF REST Starter Kit and ADO.NET Data Services.
Building RESTful Services using Windows Communication Foundation by Jon Flanders
REST is an architectural style for building services. It has been popular outside of the Microsoft development community for many years, and is quickly becoming the de facto standard inside as well. Microsoft has enabled this style of services with a new programming model and runtime enhancements in Windows Communication Foundation (WCF) 3.5. This programming model enables developers to build services using a RESTful architecture. This session covers the basics of REST, how to build this type of service using WCF 3.5, and other features (such as AJAX/JSON, Feeds, and ADO.NET Data Services) that this web programming model enables.
Supporting POX/REST with WCF by Michiel van Otegem
For web services WCF uses SOAP by default and although this is a good thing for some scenarios, there are a lot of scenarios where this is overkill and POX/REST is good enough. Also, some services or clients don't support SOAP, for instance because they were built before SOAP became widespread. This session looks at supporting POX/REST messaging and how to support it side-by-side with other protocols. Topics discussed include message processing, message signing, session management and WCF REST Starter Kit.
Mashing-up WCF and WF by Miguel Castro
.NET 3.0 introduced us to W*F technologies. (Hey, did we just coin a new term there?) While many jumped on the WCF bandwagon and others on the WF one, some people tried to jam the two of them together, only to find that it was a bit cumbersome and lacking in elegance (and don't get us started on the difficulty of the web service activities).. Enter .NET 3.5. Two new Workflow activities have been added to the mix that are specifically designed to marry the worlds of Workflow Foundation and Windows Communication Foundation. Before you stay up all night trying to figure out exactly how these things work, come join this session. You'll get an end-to-end explanation of what these two new activities are and how they work.
Pablo Cibraro published an article the other day demonstrating how to write unit and integration tests for services built using the WCF REST Starter Kit. One of the things Pablo includes is object mocking for the operation context, which I've had people ask for help with in the past. Sample code is included for an RSS-based catalog service with tests.
I saw an announcement the other day that Sam Ruby will become co-chair of the W3C HTML working group at the beginning of next year. The HTML working group impacts web application development more than most other standards even though there's rarely a direct dependency on their deliverables. Sam has been very pragmatic in working on developing standards and I hope that he'll be able to untangle some of the issues that that group is facing. Congratulations to Sam for taking on this project.
The posting schedule will be light for the remainder of the year. Readership during major US holidays falls off about 60% so I no longer publish new posts on those days. Even on non-holiday days, readership is about 30% lower during these last two weeks of the year due to people being on vacation. That's why you'll primarily see news, announcements, and commentary rather than technical posts.
Microsoft Press has been doing a 25th anniversary book offer where they put up a free pdf download for selected books for a limited time. The December books include one that you might be interested in if you're doing network programming.
Understanding IPv6 by Joe Davies
The other book this month is Writing Secure Code for Windows Vista by Michael Howard and David LeBlanc. Note that this is different than the base book Writing Secure Code. It's a much shorter update that provides content about security features that are new in Windows Vista. If you haven't read the base book, I'd recommend getting and starting with that, although it isn't part of the free offer.
The download period for these books only runs through the 24th so grab them now if you're interested.
An update to Orcas SP1 is being rolled out that will be available through Windows Update. The update contains application compatibility fixes for the .NET Framework following the Orcas SP1 release. If for some reason you need to install it directly, the downloadable package is available now.
There's one fix in the update that affects WCF serialization. We fixed a race condition that caused an exception in System.ServiceModel.TypedHeaderManager due to the same type being added to the cache twice in rare cases.
Why does turning on reliable sessions sometimes cause the client to take much longer to fail an authentication check?
As part of doing an authenticated operation, the client must send a request to the server that contains information about the client's identity. This is just an abstract description of what actually goes on. The identity information and the request may be spread out across one or more messages or protocols. The authentication check on the server determines whether the information provided by the client is sufficient to allow the client to perform the operation. If the authentication check passes, the server continues with the operation as normal. If the authentication check fails, the server fails the client request by sending back an error message.
An error message may be formatted as a transport protocol error message, such as an HTTP status code, or some other mechanism for communicating errors. The details of how errors are communicated vary from application to application. The important point to note is that an authentication failure is communicated via an error indication that looks different than the expected application message.
Without a reliable session, any errors or exceptions encountered while processing a client request will cause the request to fail. If the client encounters anything but the expected application message, it knows that's an error and can report the failure immediately.
With a reliable session, the client is supposed to ignore some kinds of errors and exceptions while letting others through. The client is supposed to ignore a recoverable error and use the reliable protocol to retransmit messages or otherwise recover from the error. The client is not supposed to ignore an unrecoverable error because nothing the reliable session can do will make an unrecoverable error better. Of course, there's no clear marking indicating which errors are recoverable and which are not. The server has no idea what kinds of things the client might be able to recover from.
Thus, distinguishing a recoverable error from an unrecoverable error is a heuristic process performed by the reliable session. The reliable session has to make a guess about the intent of the error. Since an authentication failure is a type of error, the reliable session will report the error quickly if it correctly guesses that the error is unrecoverable and will take a while to report the error if it incorrectly guesses that the error is recoverable and spends some time trying to recover from it. The variability of details for how errors are communicated means that different application configurations may result in different guesses being made for the same underlying condition.
After writing the series on the Silverlight cross domain policy format I ran across a quick utility by Frank La Vigne for checking the cross domain policy files on a server. It's one of those simple deals that lets you type in a domain name and see what policy files it offers.
If you need a reminder on the different policy formats, here's how they work.
Many of the WCF runtime classes that support adding new state do so through a common extension model. The extension model has three pieces: an extensible runtime object whose behavior can be modified by attaching state exceptions, extensions that modify the runtime object, and a collection that holds all of the extensions being used with a particular instance of the runtime object.
An extensible runtime object implements the IExtensibleObject interface, which provides a place for the extensions to be attached. The unusual generic type is used to make sure that only extensions designed for the extensible object can be added.
public interface IExtensibleObject<T> where T : IExtensibleObject<T> { IExtensionCollection<T> Extensions { get; } }
An extension collection works like a standard collection, with the additional ability to find an extension in the collection based on its type. You'll notice that the same generic type signature carries through all of the extension model classes.
public interface IExtensionCollection<T> : ICollection<IExtension<T>>, IEnumerable<IExtension<T>>, IEnumerable where T : IExtensibleObject<T> { E Find<E>(); Collection<E> FindAll<E>(); }
Finally, the extensions that go in the extension collection have two methods that they implement.
public interface IExtension<T> where T : IExtensibleObject<T> { void Attach(T owner); void Detach(T owner); }
Attach is called when the extension is added to an extension collection. Detach is called when the extension is removed from the collection. The extension is only associated with a particular owner extensible object between the calls to Attach and Detach.
Extensible objects appear in a few places: service hosts, instances, operation invocations, and client proxies. These correspond to the extensible types ServiceHostBase, InstanceContext, OperationContext, and IContextChannel. Attaching an extension to one of these objects allows you to share state within the lifetime of that scope.
Here's a past example demonstrating using the extension model to attach state to a client proxy.
The 2009 SOA and Business Process conference will be held at the conference center on the Microsoft campus on January 28th and 29th. This is a two-day, two-track conference covering products and solutions related to service-oriented applications.
The best practices track has sessions related to technologies and patterns for businesses.
The technology track has sessions related to service development, deployment, and management technologies.
I have a service operation that throws an exception to return an error back to the client. When the service operation is transactional, the transaction is aborted after calling this operation. How do I return the error under the transaction?
A service operation call fails when the invoked method completes abnormally due to an unhandled exception. The service can choose to handle an operation failure in a graceful way by applying an error handling policy. A common error handling policy is to convert the unhandled exception into a response message that is sent back to the client. The service operation still fails, but the failure proceeds such that the behavior is anticipated and allowed by the contract of the web service, so both the client and server can recover from the error and continue executing. This allows the client to handle the error condition mostly the same as a successful service operation call.
However, the service operation really did fail due to the unhandled exception. A transaction has a standard behavior when the invoked method completes abnormally, which is to abort. Although the error handling policy of the service has done something graceful about substituting an error response message for the application response, rolling back is the graceful error behavior of a transaction.
You can craft the corresponding error response message yourself and send it if you want the effect of a failed message exchange without a failed transaction. This behavior would be confusing though because the client probably expects to use the application response in the next step of the transacted work. While you may have averted the transaction rollback for now, there's no guarantee that the client can make any useful progress.
About 20 posts ago, back before PDC, this was the next topic in the queue to be posted. It has been somewhat delayed by all of the talk of product announcements and details about future releases. Since it was becoming lonely and forgotten I thought I'd get back onto talking about the product that you're actually using. I think I'm going to keep the style of not linking continuity between posts. No one complained when the forward references went away and it seems to make the posting schedule a bit more flexible to accommodate announcements and current events.
I'm using XmlSerializer for my messages but when I send a fault by throwing a FaultException, the fault exception detail gets serialized by DataContractSerializer. Is there some way to avoid data contracts here?
Yes, there is a convoluted way of implementing fault serialization yourself to customize how this is done.
In Orcas SP1/Indigo SP2, we added a new feature to make this simple. The XmlSerializerFormat attribute now has an additional property called SupportFaults. If you set it to true, XmlSerializer is used for reading and writing faults. If you set it to false, DataContractSerializer is used instead. The default is false since that was the behavior before.
A new virtual lab that I don't think I've mentioned was posted a while ago on MSDN. The lab covers exposing a WCF service using REST, as well as covering communicating with JSON in WCF.
REST, AJAX, and Web 2.0 in Windows Communication Framework
Here are the previous virtual labs that have been published as well for WCF.
Building AJAX/JSON Services using WCF
Syndication using Windows Communications Foundation
A Server Scenario Lab with Windows Communication Foundation
Understanding Windows Communication Foundation
The Fundamentals of Programming the Windows Communication Foundation
Reliable and Transacted Messaging with the Windows Communication Foundation
The state machine for a non-destructive receive has some noticeable similarities to the state machine for a general-purpose communication object, but it's intentional for these two state machines to be different. A non-destructive receive tries with minimal overhead to provide support for at-least once delivery of messages, and through transactions support for exactly-once delivery of messages.
A fresh receive starts in the Received state, corresponding to a message that is a locked and unprocessed. As I mentioned before, there's no publicly visible state corresponding to an unlocked and unprocessed message.
Completing the receive can only be done while in the Received state. It's illegal to try to complete a receive more than once. Completion converts the non-destructive receive to a destructive receive, with the assistance of a transaction if one is provided. Calling Complete moves the state from Received to Completing. While in the Completing state, the OnComplete callback is invoked. Finally, the state moves from Completing to Completed when all of the preparations are complete.
Abandoning the receive can be done while in the Received, Abandoning, and Abandoned states. It's legal to try to abandon the receive more than once, although the successive abandons don't have any additional effect. Abandoning converts the non-destructive receive back into an unlocked message. Calling Abandon moves the state from Received to Abandoning. While in the Abandoning state, the OnAbandon callback is invoked. Finally, the state moves from Abandoning to Abandoned when all of the preparations are complete.
Faulting the receive can be done while in any state. It's legal to try to fault the receive after it has been completed, abandoned, or faulted before, but the successive faults don't have any additional effect. Faulting places the receive in doubt. It's no longer possible to determine from within the system what the state of the resource is. Fault races with Abandon such that the abandon might win and you get a fast unlock behavior or the fault might win and you get a slow unlock behavior (due to the lock timing out). In either case, the result is that the message is unlocked. Fault races with Complete such that the complete might win and you delete the message or the fault might win and you unlock the message. A message that fails to complete because of a fault might be presented more times than necessary but not fewer times than necessary. By employing a transaction it's possible to maintain a strong delivery guarantee because the doubt of the receive does not spread to the transaction.
You should take the time to understand the earlier articles in the series for context if you haven't already.
The three basic operations that we talked about for queuing with non-destructive receives are peek, lock, and delete. Rather than creating a new channel shape for peeked receives, you continue to use the same IInputChannel interfaces. The binding is configured such that either every receive through the channel is a destructive receive or every receive through the channel is a non-destructive receive. There is no option for a mixed mode or optional behavior.
When a message is read non-destructively, the queue channel attaches a ReceiveContext message property to the message that represents the lock. You never see a message until peek and lock have executed.
public abstract class ReceiveContext { public readonly static string Name = "ReceiveContext"; protected ReceiveContext(); public static bool TryGet(Message message, out ReceiveContext property); public static bool TryGet(MessageProperties properties, out ReceiveContext property); public ReceiveContextState State { get; protected set; } protected object ThisLock { get; } public virtual void Abandon(TimeSpan timeout); public virtual IAsyncResult BeginAbandon(TimeSpan timeout, AsyncCallback callback, object state); protected abstract void OnAbandon(TimeSpan timeout); protected abstract void OnEndAbandon(IAsyncResult result); protected abstract IAsyncResult OnBeginAbandon(TimeSpan timeout, AsyncCallback callback, object state); public virtual void EndAbandon(IAsyncResult result); public virtual void Complete(TimeSpan timeout); public virtual IAsyncResult BeginComplete(TimeSpan timeout, AsyncCallback callback, object state); protected abstract IAsyncResult OnBeginComplete(TimeSpan timeout, AsyncCallback callback, object state); protected abstract void OnComplete(TimeSpan timeout); protected abstract void OnEndComplete(IAsyncResult result); public virtual void EndComplete(IAsyncResult result); protected virtual void Fault(); protected virtual void OnFaulted(); } public enum ReceiveContextState { Received, Completing, Completed, Abandoning, Abandoned, Faulted }
What you do get to decide is whether the non-destructive receive should be converted into a destructive receive. There are two methods on the ReceiveContext that control the receive.
The Abandon method reverts the non-destructive receive and unlocks the message. This is an immediate action and precludes further attempts at processing the message until it is read again.
The Complete method converts the non-destructive receive to a destructive receive. If there is an ambient transaction, then the Complete method will execute in the context of that transaction. Should the transaction roll back, the destructive receive will revert back to a non-destructive receive with you continuing to hold the lock on the message.
Before talking about the new model for queued transports that we've added to WCF 4.0, let's first look at the traditional transacted receive pattern.
Some downsides of the transacted model are that we have to have a transaction the entire time through the loop and that if there are multiple consumers reading from the queue, there's no guarantee that if you abort a transaction then the same instance will get the message the next time. This makes defining error logic in a distributed system more challenging.
Here's a similar barebones description of a model based on locking, which I'll go into more detail for next time as well as talk about the programming interfaces. You'll notice that in the end you get exactly the same outcome, but the changes to how the receive is done have mitigated the downsides.
I mentioned a few months ago that there would be a series of WCF screencasts being published. Aaron has done a bunch of these, including putting two more up this week. Each screencast is a short, targeted piece talking about a particular topic on WCF.
Here are the previous ones if you missed them.
I haven't previously denoted an anniversary date for WCF because there are so many to choose from. There's the date we were done, the date that downloads were available, the dates when various versions of Windows Vista came out that put WCF into public retail for the first time, and so on. The anniversary of the average of those potential anniversary dates comes to around today but that feels unexciting as a way to select the day. I kind of like using the first day of public downloads so that may be what I celebrate next year.
Last year I didn't need to worry about anniversary celebrations because we had just released Orcas at the one year mark. This year there has been no new release of WCF although we did get to deliver the mini-WCF in Silverlight 2.
Another of the topics that you'll hear a lot about for asynchronous and decoupled programming in WCF 4.0 is queuing. WCF has previously supported queuing through the one-way channel shapes with a combination of datagram and session options. The session in a one-way queued session channel is just a way of defining a unit of work for the messages. You can think of the one-way datagram channel as being equivalent to a one-way session channel where each of the sessions contains a single message. The sessions are interesting when multiple or more messages need to be processed at once. However, just having a channel shape for one-way communication does not cover the common cases for building large-scale applications that use queues to decouple themselves into parts.
When a message is processed from a queue in the current system, it might either be processed in a non-transacted fashion (at most one attempt at delivery) or in a transacted fashion. Since part of the appeal of queued communication is the capability for reliable delivery, almost everyone chooses to process the messages in a transacted fashion. Transacted processing begins running into problems when you want to scale the application so that there are multiple readers competing for messages from the queue.
To reduce the cost of coordination between instances of receivers, it is desirable for the multitude of readers to not have to share common state apart from the queue itself. When a transaction rollback occurs after a message has been received, the rollback places the queue into the originally observed state. This results in the transacted message experiencing a second round of competition between the readers and a second round of processing that looks the same as the first round, which is good for the eventual processing of the message.
Unfortunately, you often want to be selective about replaying some things the same way and other things a different way the second time a message is processed. Similarity and differentiation between actions in processing attempts allows you to build error handling and alternative choices of execution. For example, you might want the same reader to process the message again but apply a different action the second time through. Enforcing that an action is the same as or different from before requires remembering what the time before was like. You can see how this requirement to remember actions might lead to additional state coordination between the readers to manage this collective memory.
The change to the queue model is an alternative state coordination approach that adds another choice to the selection between transacted and non-transacted processing. I'll spend next time describing this state coordination pattern.
Even though these additions to queued communication enable implementing many more applications in a natural way, I don't expect that we'll be able to add everything that we want to for queuing in a single release. There's a broad variety of scenarios that rely on decoupled communication between two parties and there's really a lot more to do before we can say that WCF can represent every interesting way of linking together two systems.