If a type implements multiple kinds of collections, which pattern for collection types will be used when the object is serialized?
The order that is checked for supporting collection interfaces is:
The May 2009 CTP of Oslo was released earlier this week. Oslo is the codename for a model-driven development platform and at one point in the past was also the codename for the next version of WCF.
The CTP includes the M language for describing models, the Quadrant tool for visually editing with models, the Repository database application for storing models, and a few standard model implementations. You can also get:
I wrote a message inspector to look at the messages being sent but the messages I get look different than the messages being captured by network tracing tools. Why is that?
There are four different times that a message inspector might be invoked. For an IClientMessageInspector there is BeforeSendRequest and AfterReceiveReply; for an IDispatchMessageInpsector there is AfterReceiveRequest and BeforeSendReply. However, all four of these message notification events share the common property that the message notification is part of the application behavior rather than message transport. Moreover, even among the different application-level message notifications, your message inspector might not be the last to process the message. For example, there's no coordination requirement that you can use to guarantee the order of execution among multiple message inspectors.
This distinction between application behavior and message transport becomes clearer when you look at the overall order of operations in the system. Let's look at the client-side sending of requests because it's the simplest. The other three message inspector scenarios are symmetrical in the way you'd expect.
As you can see, quite a lot may have happened to the message after the message inspector last had view of it.
A common complaint is that the first call on a client object takes some disproportionately large amount of time, usually ten seconds or more, while successive calls are instantaneous. There are many reasons why this might happen so there's no generic resolution for this problem. Sometimes it is caused by a truly legitimate need to do a great deal more work than normal. For example, if the service you're talking with has been shut down, hibernated, and put away, restoring things to sufficient operation for processing your request may actually take a noticeable amount of time.
On the other hand, this sometimes is caused by indiscernible factors that vary from machine to machine. Frequently, these hard to diagnose and track down slowdowns are caused by a characteristic of distributed systems that Leslie Lamport noted a long time ago:
A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.
There are several cases that spring to mind working out differing machine configurations and sometimes just the vagaries of different pieces of software interacting. Three common ones go like this:
This release is paired with the beta for Visual Studio 2010.
There is also a pair of new forums specifically for beta questions. You can continue to submit feedback through Connect.
The last article in the levels of tracing series covers the logging of messages at the transport level. Transport level logging generally occurs in the message encoder as that is where the message bytes are actually processed but in some rare cases there are times when the transport sends messages without using a message encoder. In these cases, it's the transport that logs the message rather than the message encoder. All of this behavior for transport level logging is controlled by setting the logMessagesAtTransportLevel option.
If you've missed one of the parts in this series so far, here's the complete list.
A transport level message is one that is being processed by a message delivery component. Layered channels more often contribute their message (if they happen to have something interesting that neither the layer above or below has visibility into) at the service level. I'll use message delivery components in this case to mean just the network transport and message encoder.
The binary, text, MTOM, and JSON message encoders each trace messages at one of four different times:
The HTTP transport also has some special behavior for tracing messages at additional times:
NetFx 4.0 has transitioned from the occasional preview release to its first official beta. MSDN subscribers can pick up a copy of the beta today. Broader availability for the release will happen Wednesday. I'll edit in a direct link to the download page when that happens.
As this is the first beta release, there are a number of things left undone, although the majority of large features are in place. There are only a small number of big items that we kept out of beta 1 to ensure that the release had sufficient stability and quality to get good feedback about the other features. There are also going to be a small number of features moving the other way that appear in this release but aren't going to be in the final product.
Together with NetFx 4.0 you're also getting a beta release of Visual Studio 2010.
Last time I talked about the four switches that control which types of messages get logged:
Whether to log the entire message is more of a universal option so I'll focus on explaining how the other three options are used internally.
There are actually a very small number of circumstances for which messages are traced. However, some of those code paths trigger a wide variety of dependent operations. If you're trying to work out an issue by observing where message logging is occurring from, you will sometimes get a very specific understanding of what is happening and sometimes get absolutely no information at all. As a positive though, there's not much middle ground so it's relatively easy to recognize which of the two situations you're in.
A malformed message is one where there isn't enough information to figure out what the message means and processing can't continue.
A service level message is one that is being processed by an application or dispatch component rather than a message delivery component.
Next time, I'll wrap up the discussion of the different trace options by going through the different locations where logging happens for message delivery components.
Four .Net Services whitepaper downloads were republished with updates last week, including the ones for the access control service, service bus, and cloud hosted workflow services. Here's a look at what each covers at a glance from their abstracts.
An Introduction to Microsoft® .NET Services for Developers by Aaron Skonnard
This whitepaper is the first in a series of whitepapers dedicated to Microsoft® .NET Services, a core part of the Azure™ Services Platform. Microsoft® .NET Services provides a set of developer-oriented building block services commonly required by cloud-based and cloud-aware applications. This overview paper introduces Microsoft® .NET Services, each of its building block services, and how they fit together.
A Developer’s Guide to the Microsoft® .NET Access Control Service by Keith Brown
The goal of this whitepaper is to show developers how to use a claims-based identity model and the Microsoft® .NET Access Control Service – part of the Microsoft® .NET Services family – to implement single sign-on, federated identity, and role based access control in Web applications and services.
A Developer’s Guide to the Microsoft® .NET Service Bus by Aaron Skonnard
As applications begin moving towards the cloud computing platform offered by Windows® Azure, they will need the ability to bridge their existing on-premise software assets with any new assets running in the cloud, a strategy commonly referred to as software + services today. This type of integration can be accomplished through standard protocols assuming bidirectional connectivity is possible. While it’s usually simple to initiate communication from on-premise applications to services running in the cloud, the reverse is more difficult because on-premise software is usually running behind multiple firewalls or NAT devices. The Microsoft® .NET Service Bus addresses this problem space by making it easy to create secure bidirectional communication channels between on-premise software and services in the cloud.
A Developer’s Guide to the Microsoft® .NET Workflow Service by Matt Milner
This paper provides details about the Microsoft® .NET Workflow Service, its relation to Windows Workflow Foundation, and what developers need to know to begin building workflows to orchestrate message exchanges with the .NET Service Bus. It not only explains the current tools and capabilities but also outlines the vision for future releases.
The Axum team recently released the first experimental prototype of a language they've been working on for concurrent programming. Axum is built on principles for isolation and message passing like several preceding programming languages while having better integration with the mainstream languages and platforms available now. There are no particular plans yet to make Axum a product but you may have fun trying it out.
In addition to the prototype download above, here are some additional resources.
Today's article continues the series on tracing and message logging with a look at the different message logging configuration options.
The options I showed yesterday for message logging included four switches to control which types of messages get logged and two quotas to control how much data is logged.
The four switches are:
All of the switches are set to off by default.
The two quotas are:
The default for maxMessagesToLog is 10000 and the default for maxSizeOfMessageToLog is 256 kilobytes. I don't think the documentation for WCF mentions this anywhere but setting either of these values to -1 should disable the quota.
I've left out one particular option for message logging, which is the filtering system. I'll cover that after compiling some of the behind the scenes details of the options in this article.
Although often associated with event tracing, message logging is actually a separate facility from the standard levels of tracing. Message logging is not enabled by default just like event tracing is not enabled by default. You activate message logging by adding a trace source and listener to the configuration file as we saw last time. The first difference is that the trace source you need to add is System.ServiceModel.MessageLogging instead of the System.ServiceModel trace source that we were using for event tracing.
I've done the minimal changes to the previous example to show how message logging is enabled.
<configuration> <system.diagnostics> <sources> <source name="System.ServiceModel.MessageLogging"> <listeners> <add initializeData="c:\messagelog.svclog" type="System.Diagnostics.XmlWriterTraceListener" name="messagelog"> </add> </listeners> </source> </sources> </system.diagnostics> </configuration>
The second difference is that the System.SerivceModel.MessageLogging trace source ignores all of those different trace levels that we talked about. If you provide a trace level to this trace source, then it has no effect. Instead, there is a separate configuration section specifically for message logging.
<configuration> <system.serviceModel> <diagnostics> <messageLogging logEntireMessage="true" logMalformedMessages="false" logMessagesAtServiceLevel="false" logMessagesAtTransportLevel="true" maxMessagesToLog="100" maxSizeOfMessageToLog="65536"/> </diagnostics> </system.serviceModel> </configuration>
Next time I'll do a rundown of these options and some recommended settings for message logging.
Two new screencast videos on Channel 9 come from the Windows Protocol team demonstrating Network Monitor and other debugging tools. The videos are of sessions at an event for Windows protocol licensees a few weeks ago so the intended audience is primarily developers trying to build interoperable protocol stacks that talk with Windows. However, there's a lot of good content that is useful for advanced network application developers as well.
The video overview of Network Monitor is accessible and applicable even for people that aren't doing protocol development. If you've been looking for more in-depth documentation to get started taking network captures, this is a good introduction. The troubleshooting video is a bit more specialized to protocol developers that are working against the Windows protocol documentation. There are several WCF protocols covered by the protocol program but this type of debugging isn't needed as often when working with web service protocols.
You can get the Moonlight 2 preview as either binaries or source code.
The June edition of VSLive 2009 is next month June 8th through 10th in Las Vegas. If you're interested in attending to hear about WCF, there's a dedicated track on the first day as well as some related sessions on the third day.
VM3 Understanding Transactions in WCF by Michiel van Otegem
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.
VM6 WCF Extensibility In-Depth by Jesus Rodriguez
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 session, 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.
VM9 Advanced Access Control with WCF by Michiel van Otegem
WCF has many security features, some tied to the Windows platform, others to the WS-* standards for SOAP. Just the authentication and authorization features offer quite a few possibilities. Most of these are identity based, but the new world order is claims-based access. This session looks at the various ways in which you can authenticate and authorize with standard WCF and also looks at the "Geneva" Claims Based Access Platform for WCF.
VM12 WCF-WF Integration In-Depth with an Eye Towards Dublin by Jesus Rodriguez
The combination of Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) provides the building block for the next generation of Microsoft .NET applications. With the release of Microsoft .NET Framework 3.5 and the upcoming 4.0, developers now have multiple alternatives to build applications that combine WCF and WF. In this session, we illustrate some of the most common scenarios for integrating WCF and WF, and we explore mechanisms such as Durable Services, Workflow Services, rules-based authorization, line-of-business workflows, and other mechanisms that are best implemented by combining WCF and WF. We also share a series of best practices and techniques that developers can follow in order to implement a seamless integration between WCF and WF. Additionally, we explore how the Dublin Application Server provides a better ecosystem for WCF-WF integrated solutions.
VM15 Windows Workflow and WCF Help Make “Software + Services” a Reality by Michael Stiefel
The future of software is a combination of local software and Internet services interacting with one another. Software should run in locations that have the maximum compute power while minimizing the amount of data that has to be transferred. Sometimes mission critical software has to run even when disconnected to the Internet. When reconnected, the various data sources have to be reconciled. By bringing together the worlds of rich clients and services in the cloud, you can get the best of both worlds.
Two critical technologies for putting together these two worlds are Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF). WCF makes it possible for the different worlds to talk to each other. WF makes it possible for applications to run when and where it is appropriate, and to easily wait for data to arrive.
.NET Framework 3.5 has begun the integration of these two technologies which is more developed in .NET Framework 4.0. This gateway to the world of Software + Services and cloud computing is what we will explore.
VW4 Codename "Dublin": Windows Application Server by Aaron Skonnard
Microsoft recently announced a set of enhanced Windows Server capabilities codenamed "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".
Continuing from last time where I talked about the different levels of tracing, today covers how to configure trace sources for a particular level and when each trace level should be used.
A simple configuration for tracing combines a trace source with an inline specification of some trace listeners to receive trace events from that source.
<configuration> <system.diagnostics> <sources> <source name="System.ServiceModel" propagateActivity="true" switchValue="Warning,ActivityTracing"> <listeners> <add initializeData="c:\tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener" name="tracelog"> </add> </listeners> </source> </sources> </system.diagnostics></configuration>
I've used the System.ServiceModel trace source that provides most of the WCF tracing events with one of the standard text-based trace listeners. For larger configurations, you might build fancier relationships between trace sources and trace listeners that link the two together by reference, with the actual definitions elsewhere. This is mostly useful when you want to collect data from multiple trace sources at a single trace listener.
The configuration options for the System.ServiceModel trace source are the propagateActivity flag, the Warning trace level, and the ActivityTracing flag. Using the propagateActivity flag causes coordinating information to be added to calls so that their relationships can be tracked. The switchValue combines any of the trace levels that I talked about yesterday and optionally the addition of ActivityTracing events.
For a production environment the unfortunate reality is that most people will have to turn tracing off due to the performance overhead. This is something that we're looking to improve for 4.0.
When there's a specific problem, you can drop into the Error, Warning, or Information trace level as needed to get details about what's going wrong. You should probably go down that sequence of trace levels one at a time until you need additional information. An Information or Verbose trace level has so many trace events that it may be hard to find the problem. You'll also very quickly run out of storage space unless the trace listener deletes older data.
For a development environment you might want to try running at the Error or Warning trace levels routinely to make problems easier to track down.
Tracing is a mechanism for collecting error information and other processing milestones from across multiple components within an application. Tracing is generally not enabled by default. Rather, you have to elect through application configuration or coding to receive trace events from one or more trace sources. For example, the System.ServiceModel trace source is where many of the WCF trace events originate. Then, you need to connect the trace source to a trace listener. The trace listener is the active agent that does something with the trace events, such as writing them to durable storage.
A trace source is filtered to provide a variety of different levels of trace events. Trace levels are a nested set of classes of trace events. For example, the topmost trace level, Critical, only contains trace events that indicate the application has failed, such as uncatchable exceptions. The next trace level, Error, contains all of the trace events for the Critical trace level plus some more events. In this case, the Error trace level contains trace events for any type of exception whether or not the exception actually indicates application failure. By the time you get to the bottommost trace level, Verbose, it contains an extremely large amount of trace events.
Outside of these trace levels is the special ActivityTracing flag that tracks the transfer of control between activity boundaries. Two other special trace levels are the Off flag that contains no trace events and the All flag that is equivalent to the Verbose trace level with the ActivityTracing flag.
Next time I'll cover configuring trace sources and when to use each trace level.
Clemens Vasters has a series of articles talking about some of the queue and router capabilities in the .Net Services CTP released back in March. The earlier articles in the series cover the topology of queues and routers in the .Net Service Bus while later articles in the series go into detail on the HTTP and managed code interfaces for actually exchanging messages.