Continuing the series of milestones, Thursday marked the 800th post. As expected, that works out to extremely near one post per weekday for 3 years. An astounding 594 of the posts have managed to be about WCF despite the introduction of a variety of other topics over the last year.
At the 401th post on July 31st, 2007, the guess for today's event was March 9th, 2009. That represents an error of less than 1.5 weeks during an interval of time exceeding 1.5 years, or a scheduling error of only 1.9%.
Here are the milestone dates so far:
A few months ago Wenlong Dong announced an improvement to HTTP request scalability when WCF is hosted in IIS. In order to take advantage of the improvement you need the combination of IIS7 or later and Orcas SP1 installed. Since this isn't the ubiquitous configuration yet, you need to follow the instructions that Wenlong provides in order to enable the improvement for your deployment.
The improvement works by replacing the existing synchronous WCF HttpModule and HttpHandler that is installed into IIS with an asynchronous version of the module and handler. The asynchronous module and handler allow IIS to pass many more concurrent requests to WCF at once than was previously possible. The synchronous module and handler would fill up with work much sooner due to the exhaustion of available threads. Although IIS has a backup queuing system for requests, it was not designed to run at these limits and so the system slows down and stops scaling as well after a certain point. The difference in scalability can be substantial when the number of concurrent requests is in the thousands.
The reason that the original WCF module and handler used the synchronous approach is that in past versions of IIS there was no other pushback besides synchronous blocking of the request handoff to prevent IIS from working itself to death. This is why you'll see strong cautions not to use the module and handler with earlier versions of IIS. There's no technical limitation preventing you from building a scalable solution on earlier versions of IIS but you would have to build request throttling to prevent your server from spinning up more work than it can handle. IIS7 added a new request throttling feature that provides this pushback, which is why the scalable approach works well there.
Stephen Forte has a series of articles on getting started trying out the modeling capabilities of the Oslo preview. Stephen starts off with some application data modeling and then introduces domain entities and the transformation of models to SQL. Here are the articles in the series:
Why does IIS7 with Kerberos use the server machine's credentials to decrypt the ticket rather than the application pool's credentials?
What you're probably seeing here is the kernel mode authentication feature that was added in IIS7 for Windows Server 2008. Ordinarily, the service ticket would be decrypted by the user account that the application pool is running under. With kernel mode authentication, the service ticket would be decrypted by the machine account just as if the service was running as one of the built-in machine accounts such as NetworkService. The difference is significant because it affects the service principal you need to use when describing the service.
You can restore the old behavior of using the application pool's credentials by configuring the useAppPoolCredentials setting on the application or web site. You can also turn off kernel mode authentication entirely.
There are some advantages to using kernel mode authentication that you would be giving up though. First, kernel mode authentication is quite a bit faster. Second, if you use different identities for application pools that service different parts of the same web site, you'll quickly discover that using the application pool's credentials runs into the limitation of only being able to configure one service principal for the service. Using kernel mode authentication means that the different parts of the web site can use the same service principal even though the application pools have different identities.
What registration in IIS is responsible for processing SVC files?
There are two parts to the registration. One part is related to ASP.NET and the other part is related to WCF. The ASP.NET part is that the ASP.NET ISAPI has to be a service extension for IIS. The WCF part is that the HTTP handler has to be a managed handler.
The commands for setting up the two parts are "aspnet_regiis –i –enable" from the 2.0 framework tools and "ServiceModelReg.exe -r" from the 3.0 framework tools.
This results in a managed handler "System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and an ISAPI module "%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" for *.svc files in IIS. In the IIS handler mappings, the managed handler has to be above the ISAPI module for this to work.
Together, the two parts start an HTTP pipeline and pass the resulting requests into WCF.
More good articles on framework installation issues by Aaron Stebner are available than the ones related to the verification and cleanup tools I posted about last week. Here's a quick selection of a few of the articles about WCF.
The first article covers how to diagnose issues with ServiceModelReg, which is the command line tool run during setup that is responsible for updating the WCF configuration with IIS. There's also a specific diagnosis for solving issues related to the temporary files used by ServiceModelReg. If this advice doesn't help work out the problem, it's often useful to try the most recent version of the framework in case the setup issue is resolved by improvements to the installation logic. There are several cases where installing Orcas SP1 instead of an earlier version of WCF can workaround setup failures with earlier framework versions due to a more robust installer. Finally, as a last resort you may want to check out the general advice in the framework troubleshooting guide for diagnosing and resolving issues.
Moonlight 1.0, which is the open source implementation of Silverlight 1.0 for Linux, officially released last week. The official release just means that all features and certification tests are complete. Source and ongoing development snapshots continue to be available. Moonlight development continues with Moonlight 2.0, the open source implementation of Silverlight 2.
Last time I mentioned Aaron Stebner's sample programs for testing the registry for framework installations. Aaron has a few more tools dealing with framework installations that you may find useful.
First is the framework setup verification tool, which can perform a variety of verification checks against a framework installation. These checks include verification of files, directories, and essential registry keys and values used by the framework and execution tests of a few simple framework applications. If you're having trouble determining whether your framework installation is correct, this tool may help provide some additional information.
.NET Framework Setup Verification Tool
Second is the framework cleanup tool, which can scrub away bits left by different versions of the framework. The cleanup tool deletes files, directories, registry keys and values, and installer data that may be left behind by a framework installation. This is intended for use when a framework installation is broken and normal installing and uninstalling no longer works.
.NET Framework Cleanup Tool
How can a program check whether WCF is installed?
The installation status of WCF can be quickly checked by looking for the registry keys put in place by the installer. Take a look at the values under the key:
HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup\Windows Communication Foundation
These include the DWORD InstallSuccess (should be equal to 1) as well as the version and installation paths of the installed copy.
For other installation checks, take a look at Aaron Stebner's sample programs for testing the registry for framework installations. There's a slightly simpler version that only uses the registry and a slightly more complex version that also uses mscoree.dll.
Stephen Walther is publishing rough drafts of chapters for an upcoming book on the ASP.NET MVC framework. These chapters are only available for a limited time (until the book is done) and since the material isn't final, everything is subject to change.
Chapter 1: An Introduction to ASP.NET MVC
Chapter 2: Building a Simple ASP.NET MVC Application
Chapter 9: Understanding Routing
The latest information about ASP.NET MVC can be found in the list of supporting technologies.
Past entries that you should have read by now:
The fault strings mentioned in part 6 look mostly the same for each of the faults that we use. Each fault string is a standard URI beginning with http://schemas.microsoft.com/ws/2006/05/framing/faults/ followed by the name of the fault. The fault names we use include a few that are defined in the code but never placed on the wire and are:
Most are fairly self-explanatory from the name.
The four transfer modes are called singleton (mode 1), duplex (mode 2), simplex (mode 3), and singleton sized (mode 4). I described modes 1 and 2, which are used for TCP, in part 2.
Mode 1 is used for transferring streamed TCP messages. A mode 1 transfer looks like this: version, mode, via, encoding, upgrades, preamble end, one unsized envelope, end.
Mode 2 is used for transferring buffered TCP messages. A mode 2 transfer looks like this: version, mode, via, encoding, upgrades, preamble end, any number of sized envelopes, end.
Mode 3 is used for transferring multiple messages as a group with MSMQ called a sessiongram. A mode 3 transfer looks like this: version, mode, via, encoding, any number of sized envelopes, end.
Mode 4 is used for transferring single messages with MSMQ. A mode 4 transfer looks like this: version, mode, via, encoding, raw message bytes.
I can't think of much more to say about message framing. You should be able to build an implementation of your own now with some minimal testing and inspection of the messages that get exchanged.
At the end of last week a new CTP release of Oslo was made available for download. Oslo is an application development platform that uses domain models, languages, and tools to improve the productivity of application design. At one time Oslo was very tightly coupled to certain development technologies such as WCF and WF. Over time though Oslo has had some additional decoupling from specific messaging or workflow approaches and has had a broadening of applicable domains.
Here are a few other resources associated with the release:
Stefan is a skeptic about SOAP protocols and advocates REST as a way of reaching the goals of service-oriented application design. This conference presentation is Stefan talking about the principles of REST for an hour and the benefits of applying REST to distributed systems.
I've so far only talked about what happens when things go right when messages are exchanged using the framing format. There's one more record type to describe that is used to communicate errors: record type 8 for fault records. If you go back through the previous articles and compare them to the list of records in part 1, you'll see that we've covered all of the other 12 record types.
A fault record is sent when an error is encountered while processing a message frame in the framing format. Sending a fault record is optional to let the other party know that something is wrong. Whether or not a fault record is sent, the framing connection has to be closed after the error. However, the use of faults may help the two sides to resynchronize and recycle the underlying network connection by starting a new framing session.
A fault record starts with the byte 8 followed by the size of the fault string and followed by the fault string itself. A fault string is a standard URI and encoded using UTF-8 rather than an actual description of the fault itself. The fault receiver is responsible for taking some recovery action based on the fault string or translating the fault string into an error message for the user. The size is encoded in the usual way.
Here are some of the various reasons why a fault may occur.
I'll wrap up the series next time by covering the table of fault URIs and touching on a few miscellaneous topics.