The .NET StockTrader was an end-to-end sample application released last year to demonstrate WCF and web service programming. A new version of StockTrader has been released to update the application with some of the new features in Orcas and Windows Server 2008. You can get StockTrader from MSDN.
The address filter mode that we looked at last time solved the problem of funneling all of the messages with a given prefix address to our service instance. Changing the filter mode still left us with the problem of dispatching from that universal contract to all of the logical operations that live inside the address space. This is exactly the problem that UriTemplate solves. By combining templates and WebServiceHost, both of the problems get taken care of for us.
Here is an equivalent contract and service implementation with some more semantics filled in for a particular application. All I've done is pick out part of the address space that I want to assign some implementation to.
[ServiceContract]public interface IService2{ [OperationContract] [WebGet(UriTemplate = "/resource/{index}")] string Get(string index); [OperationContract] [WebInvoke(UriTemplate = "/resource")] void Add(string value);}public class Service2 : IService2{ public string Get(string index) { Console.WriteLine("Get {0} {1}", WebOperationContext.Current.IncomingRequest.Method, OperationContext.Current.IncomingMessageHeaders.To); return null; } public void Add(string value) { Console.WriteLine("Add {0} {1}", WebOperationContext.Current.IncomingRequest.Method, OperationContext.Current.IncomingMessageHeaders.To); }}
Hosting this service is basically the same. I can take out the endpoint definition because that gets inferred automatically.
WebServiceHost host = new WebServiceHost(typeof(Service2), new Uri("http://localhost:8000/"));host.Open();Client();Console.ReadLine();host.Close();
Finally, I can use the exact same client code as last time even though in the service I've changed my way of writing the service from a centralized approach to an address-based approach.
ChannelFactory<IRequestChannel> factory = new ChannelFactory<IRequestChannel>(new WebHttpBinding());factory.Open();IRequestChannel proxy = factory.CreateChannel(new EndpointAddress("http://localhost:8000/"));using (new OperationContextScope((IContextChannel)proxy)){ Message request = Message.CreateMessage(MessageVersion.None, string.Empty, "data"); request.Headers.To = new Uri("http://localhost:8000/resource"); WebOperationContext.Current.OutgoingRequest.Method = "POST"; proxy.Request(request);}using (new OperationContextScope((IContextChannel)proxy)){ Message request = Message.CreateMessage(MessageVersion.None, string.Empty); request.Headers.To = new Uri("http://localhost:8000/resource/1"); WebOperationContext.Current.OutgoingRequest.Method = "GET"; WebOperationContext.Current.OutgoingRequest.SuppressEntityBody = true; proxy.Request(request);}
Next time: System Types in Metadata
Here is a basic service that defines a universal contract to program against for building a simple HTTP application. The service doesn't do anything, but you can ignore that in this example.
[ServiceContract]public interface IService{ [OperationContract(Action = "*", ReplyAction = "*")] Message Request(Message msg);}public class Service : IService{ public Message Request(Message msg) { Console.WriteLine("{0} {1}", WebOperationContext.Current.IncomingRequest.Method, msg.Headers.To); return null; }}
You might expect to run this service in a straightforward hosting environment.
ServiceHost host = new ServiceHost(typeof(Service), new Uri("http://localhost:8000/"));host.AddServiceEndpoint(typeof(IService), new WebHttpBinding(), "");host.Open();Console.ReadLine();host.Close();
And, talk to it with the ordinarily convoluted client programming model.
However, when you put these pieces together, it fails to work. The client turns out to be fine but there's a problem in the way that the service is hosted. More accurately, there's a problem with the interaction between the way the service is hosted and the way it's defined.
By specifying an address for hosting the application, we're claiming all of the messages that go to that address. We're also claiming all of the messages that go to suffixes of that address as long as someone else hasn't claimed them first. Unfortunately, the endpoint doesn't know what to do with these extra messages. It just ignores them.
What we want is for the endpoint to just take everything and let the service implementation decide what the addresses mean. We can do this by changing the service behavior.
The AddressFilterMode is a service behavior option that controls how the endpoint filters addresses. The default filter, Exact, only allows exact matches through. The filter we should be using instead, Prefix, uses a longest-prefix match to allow similar addresses through. The final filter, Any, just lets anything through.
We can fix this service with a service behavior that sets the AddressFilterMode to Prefix, but there's a better way to solve this problem instead that we'll look at next time.
Next time: Avoiding Address Filters
A few weeks ago Eyal Vardi left a comment on an article about tools mentioning his WCF debugger visualizers. A debugger visualizer is an extension to Visual Studio that drops in a custom user interface for visualizing types. These custom interfaces can often be a lot easier to work with than the standard property grid interface. Eyal has visualizers for bindings, messages, operation contexts, proxy objects, and other commonly used WCF types.
You can get the WCF Visualizers collection from CodePlex.
A few of the more noticeable changes in this week's site design might prompt some questions as to how the Web audience is evolving over time. I thought it would be interesting to take a look at the actual numbers that back up reader's requests and complaints by comparing a snapshot from this week with a snapshot from one year ago. In each time period I pulled out a sample of 10000 visitors. The 75% of you that read this through RSS can go back to wondering why anyone still uses a web browser.
Why have site features that don't work or don't look as good in Internet Explorer?
Browsers 1 year ago (1% or higher share)
Browsers this week (1% or higher share)
There's one number that is increasing very quickly and the rest are either flat or declining for the most part. I'll credit Silverlight for bringing in enough readers on Safari to make the cutoff.
Why all of the emphasis on font sizes, content spacing, and other issues for large displays?
Resolution of largest dimension 1 year ago
Resolution of largest dimension this week
I'm evidently atypical in not having moved to increasingly larger displays over the last few years. It turns out that automatic scaling and device independence is still weak enough that you have to do some fine tuning to work over even the most common variations of scale.
Next time: Web Address Filters
How do I find the address of a client connection to make a trust decision?
Don't base security decisions on the perceived client address. Any address that we have comes from the underlying socket implementation and could be spoofed. The data that the socket has is sourced by the client. You should be using a source of information that has a verification process that the server trusts, such as a certificate, to distinguish clients.
Next time: Reader Trends
Security programming today tends to contain large amount of plumbing code to handle the modeling, management, and evaluation of identities. An identity is the basis of many common security operations, such as authentication, personalization, authorization, and access control. There are a variety of different kinds of identities and ways of implementing security operations on top of those identities. Here are two libraries that help make dealing with identities easier.
Zermatt is a claims-based identity system that focuses on simplifying the use of claims in web services. You can download Zermatt from its Connect site.
LeastPrivilege.IdentityModel is a library by Dominick Baier that simplifies the existing identity model rather than introduces a new one. You can download LeastPrivilege.IdentityModel from leastprivilege.com.
Next time: Trusting IP Addresses
Looking for a guide to all of the web services protocols implemented by WCF? There's no single document that captures all of the information, but there is a group of documents that talk about the implemented protocols and some of the choices in those implementations. The level of detail varies from document to document as a few are high-level summaries across areas of the product while others are low-level details of a particular protocol.
Next time: Help with Security Programming
I don't actually promise to update the design every year but it makes it sound more exciting- as if there's some kind of recurring event that people might look forward to. This year's design focused on improving content readability. I removed some of the design elements and dead space to get enough room to expand the text size and content area. In the process I lost the indigo-themed color scheme although I hope to bring it back some day. Having both light and dark backgrounds in the main part of the page caused some grief due to the way element styles are used in this template.
The new design rolled out over the weekend to test for any major issues. I've fixed all the ones I know about so let me know if you see something broken. The site is less polished in Internet Explorer than Firefox due to the level of CSS support, but I was able to work around the one major rendering bug I hit.
Where can I get the IContextChannel that OperationContextScope requires?
OperationContextScope allows you to create a temporary scope in which context for a service operation can build up before and after the operation is actually called. The constructor for OperationContextScope takes an instance of IContextChannel, which is a type that you've probably never seen before. Why are you expected to have this unknown type? It's because you have instances of it floating around all the time even though there's no particular hint of this.
There are different ways to get an IContextChannel depending on whether you're using a proxy generated by svcutil or a proxy generated at runtime. In either case, pretend that I've got service contract called IService with a single method called Foo.
When I generate a service client using svcutil, the client object has a member called InnerChannel that works as an IContextChannel.
ServiceClient client = new ServiceClient(binding, new EndpointAddress(address));using (new OperationContextScope(client.InnerChannel)){ WebOperationContext.Current.OutgoingRequest.Headers["X"] = "from compiled proxy"; client.Foo();}client.Close();
Otherwise, if I'm using a ChannelFactory to create the proxy at runtime, the channel that I get back happens to be an IContextChannel as well.
ChannelFactory<IService> factory = new ChannelFactory<IService>(binding);factory.Open();IService proxy = factory.CreateChannel(new EndpointAddress(address));using (new OperationContextScope((IContextChannel)proxy)){ WebOperationContext.Current.OutgoingRequest.Headers["X"] = "from runtime proxy"; proxy.Foo();}factory.Close();
Next time: Standards Guide
A working draft for a 1.1 revision to XQuery went up earlier this week. The changes from XQuery 1.0 (which was finished just last year) to XQuery 1.1 appear to be small. There are two additional operators for grouping and windowing over a data stream. The group operator is fairly standard while the window operator is a bit more unusual. Applying a window controls what it means to draw a sequence of consecutive items from the stream.
You can get the complete specification from the W3C site.
XQuery 1.1 W3C Working Draft 11 July 2008
Channel 9 posted a video a few days ago with the C# 4.0 design team talking about some of their motivations and ideas for language design. I tend to enjoy the videos like this one that are focused on the people a lot more than the ones that are focused on the outputs of technology. It's hard to stay awake while watching someone write code on a board even when played at double speed. There's no problem keeping attention here even though they barely talk about what's changing with the language itself.
Over the past few days Tom Hollander has been posting his experiences hosting a queue-based WCF service in IIS. These posts go into a lot of detail about setting up the machines, configuring the service, and troubleshooting problems. If you're looking for a step-by-step guide, this is a great resource.
Slide decks are available from the Architect Insight Conference 2008 held in the UK at the end of April. These talks are fluffier than ones that I normally point to and since you only have the slides and not the audio, I recommend picking a few based on their titles and trying them out quickly to see if you find something interesting.
Here are two that I thought looked interesting.
Building an Enterprise Service Bus with BizTalk Server 2006 & WCF
Standardising SOA
You can access all of the content from the post event resources.
Some tips for building support for versioning into the naming of data contracts.
First, the primary route for versioning should be through the namespace part of the contract rather than the member name part of the contract. Versioning the contract through member names tends to leak across the service boundary more forcefully. The programming experience of the service often makes a member name directly visible while a namespace is more or less invisible.
Second, choose a single consistent scheme for identifying the version. Two popular schemes are the date of the contract and a sequential numbering system of major and minor versions. Both schemes provide the basic element required of a versioning identity, which is an unambiguous total order among the different versions. However, multiple schemes should not be mixed together for a single contract and preferably not for a single system as well.
The date scheme, http://company.com/year/month/name, has issues around granularity but can be very evocative since you probably already associate dates in your mind with other events. The issue with granularity is that you have to plan ahead for a maximum update frequency. In the previous example, two updates in the same month would collide with the same name, suggesting that a contract that is updated frequently might include additional levels of refinement, such as the day of the month. However, unnecessarily fine granularity makes the name cumbersome.
The numbering scheme, http://company.com/major/minor/name, gives less of a clue about what the version corresponds to but has fewer issues with granularity. Updates can happen as frequently as you want since you can just keep picking new numbers. However, you still have to give some thought to granularity when deciding how many numbering components to include. For example, a single version number may be sufficient if no distinction is needed between major and minor updates.
Next time: Finding a Client Channel
Simplicity is elusive. A few weeks ago I learned that part of transaction flow, propagating information about the source machine between the client and server, is more complicated than I thought. It's not that the details were inherently complicated but rather that they were inconsistent. The information was passed in a certain header of the message, except when using a particular transaction protocol and transport protocol together. Someone noticed that a few bytes could be saved by optimizing this particular combination and in that case put the information in a different header in a different format. Efficiency was achieved at the cost of forcing everyone trying to understand the protocol to think harder about it.
Most of the protocols that have stood the test of time on the web have sacrificed efficiency to achieve simplicity. Consider all of the protocols out there that are large, bloated, and redundant but easy to think about and tolerant to misunderstandings. What keeps them alive against their slimmer and more advanced competition other than that they were able to attract many people to speak them?
Next time: Naming Contracts for Versioning
Host headers in IIS are a way to associate multiple names with a single address. The typical use of host headers is to be able to host more than one web site at a single IP address by giving each of the web sites a distinct DNS name. Host headers also play a role in WCF beyond the definition of a web site. Metadata for a web service, such as that appearing WSDL, uses host headers as a way to pick a preferred name when talking about the service.
The user interface for setting host headers is relatively straightforward when the web site is hosted over HTTP but becomes a challenge when the web site is hosted over HTTPS. Here are the command line equivalents that you can use to set HTTPS host headers.
On IIS 6, you need to know the id of the web site. Assuming that SSL is taking place on the default port, the command looks like this.
cscript.exe adsutil.vbs set w3svc/<id>/SecureBindings ":443:<header>"
On IIS 7, the command line looks very different due to the more flexible but complicated support for different web site bindings. You can also use a name that's meaningful for you to distinguish web sites.
appcmd set site /site.name:<name> /+bindings.[protocol='https',bindingInformation='*:443:<header>']
To keep the example simple, I'm assuming that you're adding a new binding rather than modifying an existing binding.
Next time: Transaction Header Magic
Yesterday I talked about adding SOAP headers to an outgoing request using a variety of different methods. The most straightforward method was to create an OperationContextScope in your application code to establish an OutgoingMessageHeaders collection.
Although HTTP headers are similar in spirit to SOAP headers, manipulating an HTTP header through code looks a bit different. SOAP headers are elevated to a special significance in the programming model. Everything else, including HTTP headers, is relegated to a general-purpose but distinctly second-class collection of message properties.
On the OperationContextScope you'll find a parallel OutgoingMessageProperties collection that can be used for HTTP headers. In Orcas, the plain OperationContext also works as a WebOperationContext that gives the same first-class programming model to HTTP headers as you get with SOAP headers.
Here's a comparison of the two approaches.
using (new OperationContextScope((IClientChannel)proxy)){ HttpRequestMessageProperty requestProperty = new HttpRequestMessageProperty(); requestProperty.Headers["X-header"] = "value1"; OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = requestProperty; proxy.Operation();}using (new OperationContextScope((IClientChannel)proxy)){ WebOperationContext.Current.OutgoingRequest.Headers["X-header"] = "value2"; proxy.Operation();}
Next time: Configuring SSL Host Headers
How do I add SOAP headers to an outgoing request?
There are a few different ways to add headers to a message depending on how you need to control the header content and where you need to insert the header. I like to think of these methods as being split among the application, the proxy, and the protocol.
In your application code you can create an OperationContextScope around the request in order to change some of the request properties. Inside an OperationContextScope, you have a valid instance of OperationContext.Current, which allows manipulation of the message headers through the OutgoingMessageHeaders collection. Use of this method deeply bakes control of the headers into the application code. You would have to be responsible for copying the appropriate code wherever it was needed.
Now, assume that you want the header to be present whenever you're talking to a particular service and the header value can be determined consistently. Rather than having to put the same code at each call site, you can centralize the code in the proxy or in a protocol.
The simplest way to centralize header manipulation in the proxy is to create an instance of the IClientMessageInspector and attach that to the proxy. This gives you a hook for every message going through the proxy to modify the message headers.
An instance of IChannel similarly gives you a hook for every message going through the channel stack to modify the message headers. Using the Message Interceptor sample gives you an extensibility point in the binding that is similar in spirit to the extensibility point provided by a message inspector.
The primary difference from your perspective of a message inspector and a channel is a matter of timing. A message inspector always runs before any of the protocols in the binding while a channel can be positioned precisely in the protocol stack. In most cases you don't need precise positioning, so you should go with the simpler approach.
Next time: Adding Headers to a Call (HTTP Version)
The PDC website is doing a monthly countdown to the event by publishing session abstracts as they lock down. The July update is the second in this series and adds 16 new sessions to the list, including two on workflow.
Workflow Foundation: Futures
The next version of Workflow Foundation provides a rich platform for declarative programming. Learn about the new data flow model, rich composition model, and control flow styles, including: parallel execution, state machine, and flowchart. See how easy it is to build workflows with the new Visual Studio workflow designer and the new activities library, including activities for SharePoint and PowerShell. Hear how Workflow Foundation integrates with other declarative frameworks like Windows Presentation Foundation and Windows Communication Foundation.
Workflow Services
This session covers significant enhancements in Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) to deal with the ever increasing complexity of communication patterns. Learn how to use WCF to correlate messages to service instances using transport, context, and application payloads. Learn to use the new WF messaging activities to model rich protocols and how to use WCF as a rich default host for your workflows and expand the reach of WF with features like distributed compensation. See how service definition in XAML completes the union of WF and WCF with a unified authoring experience that dramatically simplifies configuration and is fully integrated with Microsoft Internet Information Services activation and deployment.
You can get the full list of sessions published so far here.
You will sometimes get an error message that mentions a timeout value. You can recognize these error messages by virtue of their containing a long and boring string of text followed by some numbers.
The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'.
In context, these numbers are exciting. This is primarily due to them being considered in immediate relation to a string of text that, as has previously been mentioned, is long and boring. Numbers are something that you can understand without having to read the rest of the text.
Unfortunately, these numbers are most often not particularly helpful and should be ignored.
When you see a timeout value in an error message, it is information about one of the call parameters. This isn't a statement that the timeout caused the error. It is a hint to help you think about what might have caused the error.
If the timeout value says 1 minute and you see the error after 3 seconds, then the timeout value is probably unrelated to the error.
If you find yourself waiting for quite a while and then see a timeout value for a shorter interval than you waited, then the timeout value may have some connection to the error. Often, this connection is that you should go looking for something else that went wrong because the thing that went wrong was supposed to have finished what it was doing before the timeout expired.
Next time: Adding Headers to a Call
Four more webcasts are coming this month to talk about some of the new web service features in Orcas. Each webcast is aimed at developers and lasts 60-90 minutes.
Transactional Windows Communication Foundation Services with Juval Lowy (Level 200) Monday, July 07, 2008 10:00 AM Pacific Time
Transactions are the key to building robust, high quality service-oriented applications. Windows Communication Foundation (WCF) provides a simple, declarative transaction support for service developers, enabling you to configure parameters such as enlistment and voting, all outside the scope of your service. In addition, WCF allows client applications to create transactions and to propagate transactions across service boundaries over a variety of transports. In this webcast, we explain how to configure transaction flow at the binding, contract, and service level, local versus distributed transactions, setting of service transactions, declarative voting, and the available configurations that best fit various application scenarios.
Using Windows Workflow Foundation to Build Services with Jon Flanders (Level 300) Wednesday, July 09, 2008 10:00 AM Pacific Time
Windows Workflow Foundation (WF) is a programming model, set of tools, and runtime environment which allows you to write declarative and reactive programs for Windows operating systems. WF is part of the Microsoft .NET Runtime, and it first appeared in Microsoft .NET 3.0. Windows Communication Foundation (WCF) is also a programming model, set of tools, and a runtime that first appeared in .NET 3.0. WCF is a framework for building applications that can communicate with each other over varied network protocols. In .NET 3.5, these programming models came closer together to allow easy integration, including allowing WF instances to use WCF to communicate to remote endpoints and allowing WF instances to become the service implementation for WCF endpoints. This is accomplished by two new Activities: ReceiveActivity and SendActivity as well as a new hosting infrastructure for service endpoints. In this webcast, we look at both sides of this integration to give you an overview of how to build WF/WCF applications.
WCF Extensibility Deep Dive with Jesus Rodriguez (Level 400) Friday, July 11, 2008 10:00 AM Pacific Time
Windows Communication Foundation (WCF) provides a rich messaging framework that extends beyond its capabilities for modeling and implementing services. One of the aspects where WCF really shines when compared with competitive Web services stacks is its rich extensibility model that allows developers to customize the default behavior of the framework. The better we understand the WCF extensibility model the better chance we have to make the right use of WCF in real-world applications. In this webcast, we dive deeply into the WCF extensibility model, detailing the different extensibility points of WCF subsystems such as Channels, Hosting, Security, Metadata, Encoding, and others. Specifically, we provide practical demonstrations of how custom channels, behaviors, operation invokers, authorization managers, and metadata extensions can be used to extend WCF effectively without affecting the consistency of the programming model. We also highlight a set of best practices developers should consider to address their specific scenarios properly when extending WCF.
Bringing Enterprise Data to Life with SharePoint Server and Windows Communication Foundation with Joe Klug (Level 300) Friday, July 18, 2008 10:00 AM Pacific Time
Do you want bring your business data to life in Microsoft Office Applications like Microsoft and SAP have provided in Duet? Do you want to provide your employees with a view into your business data with Microsoft Office SharePoint Server 2007? With Windows Communication Foundation (WCF) and the WCF Line-of-Business Adapter software development kit (SDK), it is now possible to provide this level of integration to any line-of-business (LOB) application. Whether you are using Microsoft Dynamics, SAP, JD Edwards, or any other business application, you can develop Microsoft Office business applications and SharePoint Web parts to access your business data. In this webcast, we provide an overview on using WCF for application integration with Microsoft Office client and server products. Next, we show you how you can use WCF-based adapters for integration between your LOB applications and Microsoft Office business applications. Finally, you learn how to develop Web parts that utilize custom adapters for accessing business data. Each demonstration in this webcast utilizes a custom WCF-based JD Edwards EnterpriseOne adapter.