(Presenter: Abolade Gbadegesin)
What they said:
You've heard how Live Mesh combines the world of the web and the world of digital devices. But what does it mean for you? Take a look under the hood at how the mesh works on the client and in the massively scalable cloud, and learn insights about how to light-up your own solutions for the mesh world. Go deep on FeedSync-based synchronization, authentication and policy, peer connectivity, and more.
What I said:
Mesh services link together users, devices, and storage across a pervasive and highly-scalable communications fabric. Items are represented in the REST style with resources and collections of resources. Both resources and collections can represent themselves as feeds over RSS or Atom, or through JSON and POX representations. A consumer can subscribe to notifications from a collection to track changes to the feed. For example, a distributed file system using FeedSync projects to a feed and performs sharing and synchronization of folders. The mesh attaches metadata to the mesh objects, such as the permissions for sharing access to an object.
The mesh services architecture scales out to support large numbers of users, devices, and mesh objects, with the workload of the mesh most directly scaling in proportion to the number of devices. The mesh services use soft state and HTTP caching to reduce load. When replicating content, the storage service initially uses a notification service to replicate the notification among interested clients. The notification service increases locality of the distribution. Live Framework clients also maintain a local replication store for user data reflected into the mesh. Synchronization of data can be done either from the mesh storage or by contacting and replicating together with local client peers. Each resource has both a stable identifier to give it a uniform name across clients and a home datacenter that is preferred for storage. A client can look up the home datacenter for a resource from a distributed database. When the wrong datacenter is queried for the object, the mesh returns an HTTP redirect to send the client to the correct datacenter.
The Live Mesh is built primarily using commodity hardware. The mesh is partitioned to assign objects to machines, monitor the health of the system, and recover from failures. The mesh performs self-monitoring and healing to deal with most errors, using a fail fast and recover policy to simplify operations. The Live Services team additionally has extensive tooling and operations support for centrally monitoring the health of the mesh. Individual machines are provisioned using xcopy deployment.
The Live Services mesh is a highly-scalable resource-oriented fabric that links together users, devices, and storage. The mesh services architectures scales to support large numbers of devices and objects using commodity hardware and a self-monitoring services backend. Although users currently think of the mesh as a singular entity, the Live Services operations team actually runs a number of mesh instances. In the future, it is planned to be possible to federate authentication credentials with foreign domain systems to a mesh instance and to run on-premises instances of the mesh in addition to the one in the cloud. Finally, connectivity and synchronization with the mesh will improve, for example to integrate with large scale web services hosted by non-Microsoft vendors.
(Presenter: Misha Shneerson)
Enhancements to the type system in the next version of .NET Framework allow for loose type-coupling of components comprising your application. This talk is an in-depth examination of the changes in the Common Language Runtime and managed languages. See how these changes help to simplify versioning and deployment of components targeting either COM based and/or fully managed applications. For Office developers, learn how to eliminate the need to redistribute primary interop assemblies.
Improvements in the compiler and CLR 4.0 allow for generating and embedding local types into your applications where more heavyweight mechanisms are required today. Primary interop assemblies are a well-known way of integrating with native libraries but include numerous methods and features that you may not be taking advantage of in your applications. These additional features expand the size of your application just in case you might want to call them in the future. With the CLR 4.0 the compiler can generate and embed a local interop type that is customized to exactly the features you are using, eliminating the need to load the PIA with a minimal increase in application size. This talk details the implementation of the local type and type embedding features in CLR 4.0. Taking advantage of type embedding can be done simply in Visual Studio by enabling a new embedded property in the property grid for the assembly reference in the project definition, or equivalently from the command line.
The local type feature can be used for more than just interacting with PIAs. When you define an interface that changes and evolves over time as it goes through different versions, the same CLR features can simplify the versioning experience of this add-in model. The use of local types decouples your application from a particular version of the interface, allowing different versions to be loaded as necessary. Any version of the interface can be cast to your local version of the interface. At runtime, the member uses on the objects are tested against the actual implementation of the interface.
Type embedding and the generation of local types for native-code integration and loosely-coupled type versioning will introduce a number of benefits for developers targeting the CLR 4.0. Among the benefits are:
(Presenter: Jim Hugunin)
The CLR has great support for dynamic languages like IronPython. Learn how the new Dynamic Language Runtime (DLR) adds a shared dynamic type system, a standard hosting model, and support for generating fast dynamic code. Hear how these features enable languages that use the DLR to share code with other dynamic and static languages like Microsoft Visual Basic .NET and C#.
The Dynamic Language Runtime and CLR 4.0 are working to bring static and dynamic languages closer together. Having a common platform allows dynamic languages to get optimization work invested in the CLR for free and simplifies the execution runtime. Key features coming for dynamic languages are improved expression trees, a consistent mechanism for dynamic dispatch (similar to how the CLR unified static dispatch), and caching of optimizations for dynamic invocation. The DLR will be delivered both through CodePlex and future versions of Visual Studio.
C# and VB are increasingly taking advantage of the DLR for binding to environments that don't use statically typed C# objects. Dynamic typing today requires different incantations for interacting with each different environment. In the CLR 4.0, there is an abstraction layer for dynamic dispatch that allows languages to translate type concepts to a common set of CLR/DLR actions. Examples of these actions are member actions (GetMember, InvokeMember, etc.), operator actions (unary, binary, cast), invocation, instantiation, and indexers. An object binder for the execution environment implements the standard set of actions to be performed by the runtime. The introduction of these concepts overlaps Anders Hejlsberg's talk "The Future of C#" and Jim makes frequent references to concepts and demos introduced by Anders. Jim goes deeper than Anders in explaining the IDynamicObject and MetaObject interfaces that are used to implement dynamically typed objects.
Other improvements for dynamic languages are in the areas of expression trees and call-site caching. Expression trees from LINQ have been augmented with assignments, flow control, and dynamic dispatch, allowing expressions to represent the full implementation of a method body. C# and dynamic languages will generate similar expression trees for similar programs, but each language is able to retain its own semantics. Call-site caching is an optimization to generate specialized code when a dynamic type is bound in a particular instance to a statically known type. Future invocations at the call site are able to reuse the optimization by sharing a commonly updated delegate.
The key features being added to support dynamic languages on the .NET platform are improved expression trees, a consistent mechanism for dynamic dispatch, and caching of optimizations for dynamic invocation. Over time, statically typed languages, such as C#, and dynamic languages are growing closer together. These investments in dynamic languages benefit developers using any of the languages on the .NET platform. Sharing this common runtime doesn't require dynamic languages to adopt a common set of semantics or in any way stray from the true intentions of the language. These improvements make the entire platform better and dynamic languages are positioned to take particular advantage of these improvements while retaining their unique character.
(Presenter: Anders Hejlsberg)
In this talk Microsoft Technical fellow and C# Chief Architect Anders Hejlsberg outlines the future of C#. He describes the many forces that influence and shape the future of programming languages and explain how they fit into C#.
In the last 10 years C# has expanded the capabilities of managed code with features such as generics and LINQ. Another revolution is coming in C# 4.0 to seamlessly interact with dynamically typed objects- essentially any environment that doesn't work on statically declared C# types. The future of programming is to allow developers to work at a higher level together with a runtime that is smarter at translating and executing programs efficiently. Developers are succeeding today with both static and dynamic languages, and C# will grow in the future to absorb the best features from both. This requires advancing the capabilities of C# in the areas of declarative programming, dynamic language integration, and concurrent execution.
Anders goes through an introduction to how C# and the CLR take advantage of the capabilities of the Dynamic Language Runtime for implementation and binding of language features to environments that don't assume the static C# type system. Today, integration with dynamically typed objects requires specially-crafted incantations for interacting with each environment. CLR 4.0 allows unification of the different ways of interacting with dynamically typed objects in the same way that the CLR 1.0 allowed unification of different ways of interacting with statically typed objects. Dynamic types, declared by statically typing an object as "dynamic", defer the selection of members to runtime. This is done in an extensible way through the IDynamicObject interface for language implementers.
Optional parameters and named parameters from VB as well as other syntax simplifications make calling COM objects as natural an experience as calling managed objects. Finally, generic types allow for decorating the class definition with in and out annotations to permit safe casting of types in covariant and contravariant fashions.
The key features coming in C# 4.0 are the integration with dynamically typed objects, optional and named parameters, improvements in COM interoperability, and covariance/contravariance of generic types. Further out are better ways to meta-program: building applications that write and compile code on the fly through deep integration with the C# compiler. These features raise the level of abstraction in programming languages and allow for the developer to focus on saying what they want to do while the runtime optimizes the low-level expression of the application.
Here is how PDC is going to work in terms of the articles that you'll see. I will try to continue to have things appear at the usual time in the morning although some days you may get things at a later time.
My talk is on Tuesday. Probably on Wednesday, but maybe later depending on when I get the content hosted, you'll see some slides and resources from the talk.
I'll be writing some of the PDC Proceedings articles that accompany many of the videos and slides on the PDC site. Here are the sessions that I'm planning to cover.
TL02 Under the Hood: Advances in the .NET Type System by Misha Shneerson and Andrew Whitechapel
TL10 Deep Dive: Dynamic Languages in Microsoft .NET by Jim Hugunin
TL16 The Future of C# by Anders Hejlsberg
TL56 Project "Velocity": Under the Hood by Anil Nori
BB06 Live Services: Mesh Services Architecture and Concepts by Abolade Gbadegesin
You'll get the original and unedited writeup for each of these sessions.
I'll attend a number of additional sessions, in the range of two to four, during the course of the week. You'll get a similar type of writeup for each.
Every day I'll post an article about one of the sessions. If I go to 10 sessions, you'll get articles for the next 10 days. You get the idea. At the end, I'll do a summary post and hopefully we'll have links to slides and videos ready for all of the sessions by then.
I'm not planning to write about the keynote sessions. Those are primarily about breaking news and I figure that you'll have a variety of sources to hear what happened.
Since a lot of people seemed to like the article on interpreting error messages when opening a queue, here is a bit of discussion on interpreting error messages when reading from a queue.
As with opening a queue, MSMQ reports many common errors using generic error messages when reading from a queue. For example, reading from a queue might give you an error message that looks like this.
An error occurred while receiving a message from the queue: The transaction specified cannot be imported. (-1072824242, 0xc00e004e). Ensure that MSMQ is installed and running. Make sure the queue is available to receive from.
You have to use the specific error code to figure out more. Following the generic instructions probably isn't going to help you solve the problem as quickly. Here are some suggestions for common transactional receive problems.
In this example, the error code is MQ_ERROR_TRANSACTION_IMPORT (0xC00E004E), which typically means that the transaction coordinator is not available. MSDTC might not be running or might be blocked by your security or firewall settings.
If the error code had been MQ_ERROR_TRANSACTION_USAGE (0xC00E0050), then the problem is probably a configuration error between the queue and your program. There may be a mismatch about whether the queue is transacted or non-transacted or whether you're reading from a local or remote queue.
If the error code had been MQ_ERROR_TRANSACTION_ENLIST (0xC00E0058), then the problem typically is with creating or obtaining a resource needed to participate in the transaction. This may be caused by a lack of resources or due to a programming error in the code using the transaction (as opposed to a programming error in the application like the previous one).
Next time: PDC 2008: What to Look For
I wrote an article about profiling WCF services but I found out this week that Wenlong Dong had published a great article a few months ago that points to a lot of the same resources that I did. Rather than listen to me, why not go read Wenlong's article on profiling WCF services with the Visual Studio performance profiling tools?
Next time: Diagnosing a Common Transactional Queue Error
I recently saw some application code that misused XmlWriter and which happened not to work all the time as a result. What they were doing was using XmlWriter to write to an underlying stream and then flushing that stream without having flushed the writer.
Depending on the intervening code and the specific document being written in the application code, this might work if all of the content happens to have been committed to the stream prior to it being flushed. It's possible that they picked this error up by copying code from partial samples that don't show what to do with the writer after completing the content.
This example is an extreme demonstration of the problem that should result in the content never getting flushed through.
using (FileStream stream = new FileStream("test.txt", FileMode.Create)){ XmlWriter writer = XmlDictionaryWriter.CreateTextWriter(stream); writer.WriteStartDocument(); writer.WriteElementString("test", "value"); writer.WriteEndDocument();}
An intuition to use here is that an XmlWriter is like a wrapping stream, except that the XmlWriter streams XML content rather than bytes. That analogy might get you in the right frame of mind for remembering to flush or close the writer so that the data is available when you flush or close its underlying stream. Since XmlWriter is a disposable object, you can also use it with a using block to make this clear in the case where you don't have long-lived writers.
Next time: Getting Started Profiling Services
The last week has been a hard push to get everything ready for PDC. Yesterday I checked in the final changes I had to the slides and hope to spend quite a lot of time this week not thinking about the talk at all. This is probably the quickest I've had a talk come together and solidify. There were only a few areas that needed major revisions from the first time I put the talk together. There was nevertheless a lot of agonizing and debate over details during the past month.
WCF: Zen of Performance and Scale
Tue 10/28 | 12:45 PM-1:30 PM | 515B
Presenter: Nicholas Allen
I mentioned a few days ago that after the dry run we were thinking about whether to stay as a lunch session or move to a longer breakout session. The PDC staff worked with us to find a great time and room but I ultimately decided to keep the original scheduling we had. The spirit of the talk just feels better as a lunch session even if the length is constrained by that format. There are some topics for which any amount of time is too short. I feel like the shorter time keeps the focus sharp and the pace fast. Without the luxury of a large time buffer I've really had to prioritize what was being said and make sure that only the best content survived.
I've seen that many people are accessing custom SOAP headers incorrectly. When you get a message with some SOAP headers, it's likely that at some point you will want to know the values of those headers. If the header you want is a well-known kind of header, then you may have direct access to the header as a property on the message.Headers collection. I'll use message.Headers as a bit of shorthand but you may have a variety of different access mechanisms to the same collection, such as on the Message object, through the operation context, and so on. If the header you want is not a well-known header, then you need to have some way of identifying and retrieving your custom message header.
This article is only about accessing the SOAP headers in a message. There may be other kinds of headers as well, such as HTTP headers, and there's no common access mechanism between SOAP level message headers and protocol level headers. Whenever you see the words message header in WCF, then that means a SOAP message header. Other kinds of protocol headers will be mapped by the implementation that handles that protocol. For example, the HTTP headers are attached to the message using message properties.
A message header is identified by a name and namespace. The name is the common name of the message header and the namespace is a way of avoiding conflicts between people creating names.
There are many incorrect ways of accessing the contents of a message header. You should not write out the XML of the message or message headers and try to parse out the message header value. You should not iterate or try to access into the message.Headers collection. That collection that you have access to contains information about the contract of the headers rather than the actual header values. You should not try to find free-standing instances of message headers and write out their XML or convert them to strings.
Instead, you should be using the GetHeader<T> method (if your header uses a typed object as its value) or the GetReaderAtHeader method (if you header contains unstructured XML) on the message.Headers collection to access the header values. There are many overloads depending on whether you know the name and namespace that identify the header, the index of the header, or other similar criteria. You'll notice that some of the overloads for accessing typed objects specify a serializer and some do not. The overloads where you don't specify a serializer use a default data contract serializer with some large quota value but things otherwise work the same.
Next time: Writers are Like Streams
XElement has a slightly different way of talking about XML than what WCF uses. This can lead to subtle bugs if you're not careful.
Everywhere you see XML used in WCF, it is processed using an XmlReader and XmlWriter. These classes allow you to work with XML with extremely high performance but the classes themselves are not particularly easy to use. For someone who hasn't used this particular model before, it is surprisingly difficult to create and build up XML documents. XElement is the center of a newer and much easier library of classes for working with XML although it doesn't get quite the same performance as XmlReader and XmlWriter, particularly when doing stream processing.
When working with WCF you'll frequently see a Name and Namespace pair of parameters. These parameters are both string types. The name is the common name and the namespace qualifies the common name so that many people can choose names without having to worry about conflicts. Since the namespace is primarily for avoiding conflicts, some people like to cheat a bit and just use the name in comparisons when conflicts are unlikely.
XElement also has a Name. However, rather than being a string, this name is actually the XName type, which contains both the common name and the namespace. Some people who are used to using the Name in WCF translate that to the Name in XElement, which represents a change in behavior. The correct parallel would be element.Name.LocalName instead of element.Name.
This difference can be hard to spot because it frequently just happens to work if you change both sides of the comparison in the same way at the same time. Additionally, your choice of serializer and contract definition may affect the default namespace. A lot of the older mechanisms and tools used an empty default namespace so again many things will happen to work. Other serializer and contract mechanisms, such as with data contracts, generate temporary namespace, which is much more likely to mysteriously stop working due to failed matches when you change the comparison behavior.
Next time: Examining Header Values
Someone asked me what PDC talks I'd go see that had no relation to what I was working on and didn't already know what was going to be said. Here are the top ones that I think I'd enjoy based on reading the abstracts. I'm playing by the more difficult set of rules where I can't pick talks that conflict with when I'm supposed to be speaking or answering questions at another talk.
Under the Hood: Advances in the .NET Type System by Misha Shneerson and Andrew Whitechapel
The Future of C# by Anders Hejlsberg
Project "Velocity": Under the Hood by Anil Nori
Learn about the architecture of Velocity, Microsoft's main memory distributed caching framework. Hear how Velocity was built to meet the performance, scale, latency, and availability requirements of large scale enterprise and web applications. Learn about Velocity components and discuss design tradeoffs and mechanisms for in-memory storage, data placement, and data replication for performance, scale, and availability. Also, hear how Velocity provides database capabilities like LINQ support, indexing, concurrency control, and data consistency.
Concurrency Runtime Deep Dive: How to Harvest Multicore Computing Resources by Niklas Gustafsson
Learn how the Concurrency Runtime provides an efficient and scalable infrastructure for multiple concurrent programming models by bringing together cooperative work scheduling and resource management into one component. This deep dive presentation gives you an idea of what it means to target the Concurrency Runtime with your domain-specific library or language. We also cover many of the internal algorithms of the runtime to help educate you on the applicability of the runtime to your scenarios.
Parallel Programming for Managed Developers with the Next Version of Microsoft Visual Studio by Daniel Moth
Come learn how the next version of Visual Studio and the Microsoft .NET Framework can help you write better performing and more scalable applications. We take a tour of new .NET APIs, including the Task Parallel Library (TPL) and Parallel LINQ (PLINQ). We also introduce new features in the debugger that help you quickly identify concurrency issues and visualize the internal state of your application.
I don't think I ever wrote about the changes made to WCF generated typed proxies in Orcas, although Wenlong had an article about the changes to proxy behavior back when they were made.
Generated proxies are the ones produced from the standalone client classes that are generated by tools such as svcutil. Internally, the generated proxy uses the other kind of typed proxy, the one created by instantiating a typed ChannelFactory. It's the ChannelFactory that actually knows about contracts, bindings, and the process of generating communication channels for exchanging messages with a web service. Initializing the ChannelFactory is a large portion of the expense of instantiating a proxy prior to the use of network resources.
In the original approach, instantiating a generated proxy would every time result in creating a new ChannelFactory. With this change, a cache of ChannelFactory objects was introduced so that if you're repeatedly instantiating similar proxy objects, the cost is much less. Of course, it would likely be even better for you to reuse proxies in your application code rather than rely on caching to make the creation of proxies cheaper. However, reusing proxies is something that would require changing individual applications while caching is something that we could do to make many applications faster.
Next time: Working with XElement Names
Yesterday came the announcement that Silverlight 2 is finished and ready to go although there was no accompanying download available yet. That download is supposed to appear on the Silverlight site sometime today and may already be available depending on when you're reading this.
Silverlight 2 considerably expands on the support for networking and the included subset of the .NET Framework as compared to the original Silverlight release. If you've been following along as I've talked about the development of Silverlight, then this should all be known to you. The final version of Silverlight 2 is essentially the same as the earlier release candidate.
As I mentioned a few days ago, we were tweaking the published details of my talk a bit to better reflect the talk style and content. Here's the updated blurb if you haven't seen it.
WCF: Zen of Performance and Scale by Nicholas Allen
Join us for an interactive lunch discussion about different kinds of performance and scale requirements that are a crucial part of any distributed systems development life cycle. Learn the principles of Windows Communication Foundation (WCF) throughput and responsiveness optimization. Hear about WCF scalability improvements in the next version of the Microsoft .NET Framework.
You'll notice that it's prominently mentioned that this is a lunch session, which are held in the same rooms as the standard breakout sessions but are a bit shorter in length to give you time to eat and generally presented at a slightly more relaxed pace. One of the reasons I liked the lunch session time is because it was a great fit for the Zen style of the talk.
The schedule for PDC is officially finished, but that just means the schedule that gets printed in the books is not changing. We're still thinking about whether to convert this talk from a lunch session to a standard breakout session. A breakout session is longer and can fit in more content. There's definitely more that I want to say, especially about the future of WCF, than can fit into any length session. However, I think that moving to a longer talk would lead to a more traditional style of presentation. A lot of the reason this talk is so fun is because the format lets me be more creative with how the material is presented. The talk content based on stories and experiences seems to fit in a bit better at lunch.
Which format would you prefer and why?
MSMQ reports many common errors using generic error messages. For example, opening a queue might give you an error message that looks like this.
An error occurred while opening the queue: The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization.
This error message suggests four or five things that might have gone wrong and how to fix them. However, you have to use the specific error code to figure out more.
The error code for this example is 0xC00E0003, which corresponds to MQ_ERROR_QUEUE_NOT_FOUND. The problem actually is the first one suggested, that the queue does not exist, or perhaps that you've specified the queue name incorrectly.
If the problem had been the second one suggested, that you don't have permission to access the queue, then you probably would have gotten MQ_ERROR_ACCESS_DENIED (0xC00E0025).
If the problem had been the third one suggested, that there was a failure sending or receiving from the queue, then that might have been caused by MQ_ERROR_REMOTE_MACHINE_NOT_AVAILABLE (0xC00E0069).
If the problem had been the fourth one suggested, that MSMQ is not running, then you instead could have seen MQ_ERROR_SERVICE_NOT_AVAILABLE (0xC00E000B).
Finally, if the problem had been the fifth one suggested, that there was an access violation opening the queue, then that possibly would have been caused by MQ_ERROR_SHARING_VIOLATION (0xC00E0009) when someone else has already opened the queue for exclusive access.
Next time: Proxy Caching Changes
Channel 9 is posting a collection of videos from the JAOO conference on programming language design that I found really interesting. JAOO stands for Java and Object Oriented but in a tremendous coincidence all of the videos happen to feature Microsoft speakers talking a lot but not exclusively about Microsoft products and languages. Really though, all of the videos are more about understanding how programming languages are designed than the design of any particular language so they're pretty accessible to everyone that has done a lot of programming.
Here are the talks from Channel 9.
Anders Hejlsberg and Guy Steele: Concurrency and Language Design
Erik Meijer, Dave Thomas and Pratap Lakshman: Perspectives on JavaScript and Language Design
Jeffrey Snover, Martin Fowler and Neil Ford: Domain Specific Languages
And, here is Ander's talk from the conference.
One concept that sometimes confuses ASP.NET developers when moving to WCF is the notion of session state. In ordinary WCF services, all of the session state is stored in local volatile memory. The application has to choose to copy over a portion of the session state to a durable storage location for that state to be preserved across running instances. WCF doesn't come with a built-in option for enabling persistent storage of session state or enabling access to the session state from other processes.
There are a couple ways to make WCF more like ASP.NET.
One way to make WCF more like ASP.NET is to make WCF exactly like ASP.NET by turning on ASP.NET compatibility mode. A WCF application that is hosted in IIS and uses HTTP as a transport binding runs together with the ASP.NET pipeline but does not have access to many of the ASP.NET features. Turning on compatibility mode integrates the WCF application with the ASP.NET pipeline and makes many of those features available. Obviously, this approach is only interesting when your WCF service is already very much like an ASP.NET application.
Another way to make WCF more like ASP.NET is to change the management of WCF session state to use remote durable storage rather than local volatile memory. This approach is more like the one used by workflow services to create durable applications. The management of service instances and instance contexts is controlled by the IInstanceProvider that creates and destroys service objects, the IInstanceContextProvider that creates and destroys instance contexts, and the IInstanceContextInitializer that sets up newly acquired instance contexts. Although durable services have different semantics than session state, there are common building blocks that can be used for both.
Next time: Diagnosing Common Queue Errors
Continuing the series on Internet history, fifteen years ago marked the creation of a standard for dynamically defining the network configuration of a machine. Building on earlier boot-strapping protocols, the dynamic host configuration protocol allowed machines to automatically obtain all of the configuration parameters needed to exchange packets with other hosts. With DHCP, it was no longer required to either manually configure machines with network configuration parameters or to manually configure networks to know about individual machines.
Adoption of DHCP took off because the protocol provided several key benefits to network administrators. In comparison, the older processes for configuring machines were labor intensive and error prone. DHCP provided a quick and cheap solution to several common problems.
Security and streaming are two features that often do not get along with each other. Although the concepts are not inherently in conflict, their implementations often do things that cause problems for the optimal execution of the other.
You may have seen that the message security channel, like the reliable messaging channel, in its native mode likes to buffer messages. This is because signing is one of the aspects of message security. The message signature is typically computed based on the contents of the message to allow detection of any changes. Although you could still achieve some benefit from streaming on the network and on the client, buffering of the message requires storage space on the server even though that storage space doesn't have to be in memory. Pre-computation of the message also negates one of the major benefits of streaming: the interleaving between computation and transmission of the data.
A stream security mechanism, such as SSL, is one way to avoid this buffering problem. Stream to stream transformations tend to be less likely to assume complete knowledge of the data than message to message transformations. One popular combination to use streaming with message security is to secure transmission of the messages with stream security and to use message security only for passing credentials.
HTTP authentication is another implementation that in some cases needs to buffer messages. HTTP defines a challenge and response for its basic authentication model. You might be able to predict the challenge and send the appropriate response as part of the request. If not, then the request needs to be transmitted from the beginning when the challenge response is supplied.
In most cases it would be difficult to completely regenerate the request. Instead, the transmitted portion of the request is buffered so that it can be transmitted again. It is unpredictable how much of the request needs to be buffered since the challenge is asynchronous with respect to the response. This leads to many implementations that either do not work with streaming or only work when the HTTP server behaves nicely. The server may read as little or as much of the request as it likes before deciding to initiate the challenge. In practice though, the server most likely would like to issue the challenge sooner rather than later so that it can stop processing the request.
Next time: Working with Session State
Earlier this week came the official announcement of the .NET Framework 4.0 and the application server role extensions in Windows Server called Dublin. These are the two products that I've been spending most of my time working on lately. .NET 4.0 obviously encompasses new versions of WCF and WF while Dublin extends the server capabilities of IIS and Windows Server for hosting managed service applications.
Here are the talks at PDC that are going to directly focus on WCF 4.0, WF 4.0, and Dublin, including the new talks in the October session update.
Dublin
Hosting Workflows and Services by Dan Eshner
Hear about extensions being made to Windows Server to provide a feature-rich middle-tier execution and deployment environment for Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF) applications. Learn about the architecture of this new extension, how it works, how to take advantage of it, and the features it provides that simplify deployment, management, and troubleshooting of workflows and services.
WCF 4.0 and WF 4.0
WCF 4.0: Building WCF Services with WF in Microsoft .NET 4.0. by Ed Pinto
Eliminate the tradeoff between ease of service authoring and performant, scalable services. Hear about significant enhancements in Windows Communication Foundation (WCF) 4.0 and Windows Workflow Foundation (WF) 4.0 to deal with the ever increasing complexity of communication. Learn how to use WCF to correlate messages to service instances using transport, context, and application payloads. See how the new WF messaging activities enable the modeling of rich protocols. Learn how WCF provides a default host for workflows exposing features such as distributed compensation and discovery. See how service definition in XAML completes the union of WF and WCF with a unified authoring experience that simplifies configuration and is fully integrated with IIS activation and deployment.
WCF: Tips and Tricks for Performance and Scale by Nicholas Allen
Join us for lunch to discuss the different kinds of performance and scale requirements that are a crucial part of any distributed systems development life cycle. Learn great tips from Nicholas Allen on Wndows Communication Foundation (WCF) throughput and responsiveness optimization throughout the lifecycle of a distributed system. Hear about WCF scalability improvements in the next version of the Microsoft .NET Framework.
WF 4.0: A First Look by Kenny Wolf
Programs coordinate work. The code for coordination and state management often obscures a program's purpose. Learn how programming with Windows Workflow Foundation (WF) 4.0 provides clarity of intent while preserving the functional richness of the .NET framework. See how easy it is to build workflows with the new Visual Studio workflow designer. Learn about text-based authoring options for WF. Hear how WF integrates well with other Microsoft technologies (WCF, WPF, ASP.NET). If you've looked at WF before, come and see the changes to data flow, composition, and new control flow styles. Significant improvements to usability, composability, and performance make Workflow a great fit for a broad range of solutions on both the client and the server.
WF 4.0: Extending with Custom Activities by Matt Winkler
Windows Workflow Foundation (WF) 4.0 coordinates and manages individual units of work, encapsulated into activities. WF comes with a rich library of activities. Learn how to extend this library by encapsulating your own APIs with custom activities. See how to compose those basic activities into higher level units using rules, flowchart, and state machine control flow styles. Learn how to build your own WF control styles. Learn how to customize and re-host the workflow authoring experience using the new WF designer framework.
While I wait for the title and abstract of my PDC talk to be updated with the correct content, here is what you can expect.
The theme of the talk is obtaining performance and scale from distributed systems built using WCF.
The style of the talk is Zen. At the end of the talk you will understand why things work the way they do and how to spelunk the depths of the system. There will be no graphs or benchmarks.
The level of the talk is 300 and up. You should be comfortable with distributed service design and WCF programming but knowledge of other Microsoft technologies is not required. The advanced listener will appreciate points that others might miss. The pace will be fast. You will be challenged by concepts but not by difficult code listings.
The time and place are unknown, but I think there are only two slots for lunch sessions so that narrows the possibilities down some.
The first part of the talk is an open question session for people to ask about their WCF performance problems. I will bring a few questions with me so that we can get started without having to wait for people to line up. You can submit your question as a comment to this post or using the contact form to be one of those prearranged questions. You don't have to be attending PDC to submit a question. Those attending the talk should think about whether they have a question they want to ask during the session.
The second part of the talk explains how to think about performance. I will introduce the one principle you need to know to understand nearly every aspect of WCF performance. We will get deep into the technology by applying a few basic concepts again and again.
The third part of the talk introduces new features in WCF that will help tackle the problem of building scalable distributed services. You will get just enough of an understanding of these features to start experimenting with the bits on your own. A story will be told.
Nobuyuki Akama has started a series of articles that give a very good introduction to WCF. The first two articles in the series have been posted so far. I like how detailed the examples and explanations are. You usually don't see that level of detail in introductory material. I think that you shouldn't have to wait for the advanced material before seeing how the system works and seeing exactly what happens on the network.
The current articles give some background about WCF and provide the server half of the sample application. The upcoming articles provide the client half of the sample application and talk about the hosting and activation of services.