MVC is a model-view-controller framework for building ASP.NET applications, particularly resource-oriented applications. The basic mechanism of MVC defines routes that map incoming browser requests to actions provided by the application controller. This is a bit different than the traditional ASP.NET page approach because of the way routes give you fine-grained control for carving up the URL space served by the application.
The MVC 1.0 release candidate is available now along with some release notes. The final version of MVC should be coming within a few weeks.
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:
With the preamble exchange out of the way, it is now time to send some data. As before, we're going to get slightly different exchanges depending on the mode in which the framing protocol is being used.
You may recall from Part 2 that one of the modes for TCP connections was a request-reply mode used for streamed TCP connections. Request-reply streaming allows a single message to be exchanged on the framed connection.
After the preamble is completed, the initiator of the connection sends an unsized envelope record to exchange a message. An unsized envelope record starts with the byte 5 followed by one or more data chunks and followed by a terminating byte 0. This chunking approach is very similar to the way data is transferred using HTTP chunking. Each chunk consists of a non-zero size followed by a payload that contains the size's worth of octets. The size is encoded in the usual way. Finally, the receiver might send choose to send an unsized envelope record back in response.
The other mode for TCP connections in Part 2 was a duplex mode used for buffered TCP connections. Buffered duplex allows many messages to be exchanged in either direction between the two parties.
After the preamble is completed, the endpoints exchange sized envelope records. A sized envelope record starts with the byte 6 followed by a non-zero size and followed by the size's worth of octets. You might think of this as an HTTP message that specifies the content length instead of using a chunked encoding. The same variable sizing is used as always.
Regardless of the transfer mode used for the message, the framing connection is closed in the end by sending an end record. An end record is the byte 7. As we'll see later though, closing the framing connection doesn't necessarily mean freeing the network resources.
Ted Neward is writing a series illustrating the tricks and pitfalls of translating a basic WCF service into F#. You can get the first two and a half parts covering contracts, data types, and service definitions here.
After the message encoding is communicated, the framing protocol starts to diverge based on the mode record that was provided.
In the modes used by TCP, which are all duplex and half-duplex communication modes, there is now an opportunity for the two sides to negotiate additional framing options. This is also the first time that the communication backchannel has data to exchange. In the modes used by MSMQ, which are all one-way communication modes, there is no negotiation capability so these described records are not present.
Optionally, the initiator of the connection sends an upgrade request record to negotiate additional framing options. An upgrade request record starts with the byte 9 followed by the size of the upgrade string and followed by the upgrade string itself. An upgrade string is an opaque blob that uniquely identifies the upgrade. The size is encoded in the usual way. We happen to use MIME content types to name our upgrades because the upgrades we've implemented so far are all preexisting standards.
The receiver indicates its acceptance of an upgrade by sending an upgrade response record. An upgrade response record is the byte 10. When we get to talking about errors, I'll explain what happens if the receiver doesn't accept the upgrade.
After an upgrade is accepted, the upgraded stream wraps all of the protocol transmissions. For example, if the upgrade was to negotiate an additional framing option of SSL communication, at this point an SSL handshake would be exchanged. All future transmissions would be over the SSL connection. Due to the way that upgrades wrap the underlying byte stream to add new protocol options, these are called stream upgrades.
Once the initiator is done sending upgrade requests, the next record is a preamble end record. A preamble end record is the byte 12. We know that the receiver and initiator are synchronized on all of the data that has been transmitted so far when the initiator receives back a preamble acknowledgment record. A preamble acknowledgment record is the byte 11.
The next record at the start of every legal exchange in the framing format is a message encoding record. The message encoding specifies how the message envelope should be translated and processed. There are actually two different ways of expressing the message encoder, each with its own record type.
The message encodings that come with the platform- text, binary, and MTOM- are called the known encodings. A known encoding record starts with the byte 3 followed by a byte for the known encoding. The known encodings are basically an enumeration of encodings that the system knows about by default.
The first six options correspond to the text message encoder together with either SOAP 1.1 or SOAP 1.2. The next option corresponds to the MTOM message encoder. The last two options correspond to the binary message encoder. The dictionary options determine whether the binary encoding is stateful or stateless. Stateful encoders are used with sessions to progressively encode multiple messages.
It's not a problem if the encoding you want to use isn't one of these predefined formats. You can define your own encodings, assuming that both sides of the connection are able to process the format you've come up with. An extensible encoding record starts with the byte 4 followed by the size of the encoding string and followed by the encoding string itself. The encoding string is a MIME content type that you use to distinguish the encoder configuration. The size is encoded in the same way as before.
Although there are a several different legal sequences of records in the framing format, the first few records are always the same after first establishing a connection. The first record describes the version of the framing protocol, the second record describes the mode of the framing protocol, the third record describes the delivery via, and the fourth record describes the message encoding.
A version record starts with the byte 0 followed by a byte for the major version and a byte for the minor version. The difference between a minor version and a major version is that a minor version cannot introduce any new record types. We've only used major version 1, minor version 0 so far.
A mode record starts with the byte 1 followed by a byte for the mode. Mode 1 indicates that the framing protocol is being used to exchange a single message in a request-reply fashion. This is used for streamed TCP connections. Mode 2 indicates that the framing protocol is being used to exchange several duplex messages. This is used for buffered TCP connections. Modes 3 and 4 are used for packaging MSMQ messages. You'll see those modes if you look at the messages in the queue when sending messages using the NetMsmqBinding.
A via record starts with the byte 2 followed by the size of the via string and followed by the via itself. The via is a standard URI and encoded using UTF-8. To prevent a client from tricking the server into reading an excessively long via, there's a default limit of 2 KB on the via length. A server can use a different limit if it likes or not have a limit at all although we recommend picking some reasonable limit based on the length of addresses that you expect.
The sizes in a variable-sized record are encoded to optimize for messages that use smaller sizes. Each byte of the size adds 7 bits to the size field and uses the most significant bit to indicate whether the size has more bytes. When the most significant bit is 1, the next byte in the stream continues the size. When the most significant bit is 0, the size is done. Therefore, a small size, such as 100, can be encoded in a single byte while a larger size can use multiple bytes. This is similar to how the character encoding of UTF-8 works.
Next time I'll continue by talking about the use of message encodings.
Since the last update I did Aaron has put up six more screencasts for you to enjoy.
Configuring WAS for TCP endpoints
Learn how to configure Windows Process Activation Service (WAS) for TCP-based activation, making it possible for you to host your WCF service in IIS with TCP-based endpoints.
Configuring Bindings
Learn how to configure bindings on your WCF endpoints, which will allow you to customize the precise communication details you wish to support on your service.
Configuring services with behaviors
Learn how to configure your WCF services with behaviors, which will allow you to customize different aspects of the runtime execution "behavior".
Configuring MEX endpoints
Learn how to configure your WCF services with Metadata Exchange (MEX) endpoints - both over HTTP and TCP - allowing consumers to automatically retrieve metadata from your services at runtime.
Building RESTful Services with WCF
Building RESTful Services with WCF - Part 2
Learn how to build a RESTful service with WCF, converting a previously created WCF service to support a RESTful interface
Message framing is the breaking up of a stream of data into demarcated units called messages. Some protocols, such as HTTP, natively include a notion of message framing. Other protocols, such as TCP, don't natively include a notion of message framing and need to be augmented with one to be used in a messaging system. WCF includes a message framing protocol called .Net Message Framing for use with transports that don't natively support messaging. This framing protocol is used with the TCP transport to create NetTcp and the MSMQ transport to create NetMsmq. The classes used by the message framing protocol aren't public but after reading this series you should know enough about how the protocol works to put together your own implementation that does most of .Net Message Framing.
The basic operation of .Net Message Framing is to first exchange some metadata about how messages will be exchanged and then to exchange the messages themselves. The metadata includes information such as the version of the framing protocol being used and the algorithm for encoding the messages. The messages can be transmitted in a variety of formats and, if something goes wrong with the exchange, transmission can be aborted to allow the connection to be reused.
The message framing protocol works by sending a series of typed records. Each record is prefixed with a single byte that indicates the record type. There are a few different legal orders of records depending on which mode the message framing protocol is being used in. Here are all of the possible record types along with the type number of each record. Next time, I'll start going into these record types to explain how the message exchange metadata works.
Next week I'll be starting a series talking about the .Net Message Framing protocol. First, some background on what that is.
TCP is a stream-oriented protocol. Although senders and receivers frequently deal with a "packet" of data and although the transmitted data is broken up into packets on the wire, the packet organization is not fundamental to the delivery of the protocol. The boundaries of packets are free to be broken up and moved as data travels throughout the system. Consequently, the received and sent packet structures may be different and there is little value indicating exactly where these boundaries are.
Instead, higher level protocols that are not stream-oriented need to use some other way than packet boundaries to indicate where messages begin and end. This is typically called the framing format of the message.
As you may have guessed, .Net Message Framing is a framing format for transmitting messages used by .Net. This framing format can be used by a variety of different transports and the messages can come in a variety of different formats, but the most common combination is a TCP transport and SOAP messages. These are the defaults of the NetTcp binding. In general, the WCF bindings you see with Net in the name are the ones using this framing format, such as the NetNamedPipe binding and the NetMsmq binding.
When working with a WCF application that has an HTTP binding, it's often useful to be able to see the exact messages that are being transmitted on the wire. You can sometimes achieve that through message logging, but I've found that capturing the HTTP traffic directly is usually both easier and more accurate.
When using HTTP with the text encoding both the SOAP messages and HTTP protocol information are directly readable. Even when using HTTP with the binary encoding, the protocol information is readable though the SOAP messages are not. The protocol information is often sufficient once you've established that message serialization is working correctly.
HTTP applications have some better choices for debugging than the packet capturing tools used with TCP applications. In particular, many HTTP applications work well with proxy servers since they're a common networking technique with the protocol. Fiddler is a debugging tool built as an HTTP proxy server that we've commonly used in the past. Rick Strahl has also written an article about how to use and configure Fiddler when debugging an application.
StackOverflow is a programming question and answer site that Joel Spolsky and Jeff Atwood started a few months ago. I have to admit that I was pretty pessimistic about their success. There are a lot of these types of sites for a lot of different communities and almost none of them have really taken off. One way to tell that a site hasn't taken off is when you land on one of their pages from a search and your question matches someone else's, but invariably they never got a useful answer either. And, it happens again and again to the point where you don’t even bother following the results for that particular site. You already know it's not going to help.
However, I do have one way of seeing the impact of these types of sites. Since I've written a lot of articles about WCF, some fraction of the programming answers in this camp tends to link back to me and I can see the traffic when someone else finds the answer to the question. StackOverflow has been steadily growing in traffic this way and surpassed pretty much every similar site in a few months. This is big because their few months of answers are competing against the long tail of other site's few years worth of answers, and they're still winning. While it's still only fractionally as popular as the MSDN forums for the specific topic of WCF, I'd recommend keeping it in the back of your mind the next time you hit a dead end looking for an answer.
You can get all four of the white papers from the same site.
An Introduction to Microsoft .NET Services for Developers: 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: This whitepaper shows 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: This whitepaper shows developers how to use the .NET Service Bus – part of the Microsoft® .NET Services family – to provide a secure, standards-based messaging fabric to connect applications across the Internet.
A Developer’s Guide to the Microsoft® .NET Workflow Service: This whitepaper provides details about the Microsoft® .NET Workflow Service, its relation to Windows Workflow Foundation, and what developers need to know to begin building workflows for the cloud. It not only explains the current tools and capabilities but also outlines the vision for future releases.
Tess Ferrandez takes a debugging look at what happens when you fail to close client proxies in a timely manner. Given the relatively long default time before the server idles out a client (10 minutes) and given the relatively small default number of connected clients (10), this is probably one of the most frequently encountered issues for new WCF developers. You'll pretty much always want to adjust these settings in a production environment in addition to making clients close their connections more quickly.
The Windows 7 beta should be available later today if you're interested in trying it out. Since this is a platform release rather than a framework release, the number of changes to WCF is small although there will be a few things that we're still working on for the final release. The next major update to WCF is coming in .Net 4.0. One thing that you do get in Windows 7 is the Windows Web Services libraries. WWS is a subset of the functionality of WCF made available to native code applications.
The primary advantage of having a forwarding service that comes with WCF is that it enables you to add a router to your application without having to write any code. I think that many application developers could write the routing logic they need into their applications given enough time spent working on it. However, why spend the time writing code when in almost every case using a canned routing service is going to get the job done faster.
The forwarding service that went out with PDC isn't exactly how I'd expect the configuration of a canned routing service to look, but it's relatively close. All of the major pieces are in place. I'd expect the process of writing the configuration to be more heavily driven by tools though rather than by writing XML.
There is a WCF service type for a routing service that routes messages from one inbound endpoint to one or more outbound endpoints. In the PDC release that service type is Microsoft.ProcessServer.Messaging.ForwardingService. The service can be hosted at an address you choose and with whatever binding you'd like through the standard mechanism of declaring service endpoints. Like any WCF service, you might provide multiple inbound endpoints to allow for different ways of accessing the same service.
We provide the set of contract classes that describes each of the possible shapes your binding might support. This allows us to disambiguate the particular channel shape that you want the endpoint to use since your binding might build different channels depending on the chosen shape. Since these contract classes describe the channel shape rather than the application contract, the contract works regardless of the particular operations or message you use with the destination service.
The outbound endpoints are standard WCF client endpoints. Again, you can choose whatever addresses and bindings you'd like for these client endpoints to point at. By choosing different bindings for the inbound and outbound endpoints, you've built a router that also bridges between different protocols. The outbound contract is a wildcard contract to indicate that you don't care what application contract these messages are for.
Finally, we provide a way to describe the routing table. Each route in the routing table associates a filter with one of the outbound endpoints. You've seen these filters before. The same filters that power content-based correlation also power content-based routing.
Updated versions of the standards for reliable message, message security, and distributed transactions have completed public review and are headed to a final vote. I expect all of these standards updates to be approved and see official publication of the new versions in February.
The product installs in the VPC images of WCF 4 and Dublin should be expiring around now if you've been using them. Since an updated preview isn't available, here's how to keep them going.
Since disabling clock synchronization causes the virtual PC's time to only advance when it is running, a fresh installation should last as long as you need. You can repeat this process as many times as necessary though.
Jeff Beehler has a more detailed explanation.
I saw that Jesus Rodriguez talked about the forwarding service that was included in the Dublin PDC preview so I thought I'd talk a little bit about what motivated the creation of this service and how I think it might be used.
The idea of shipping a general-purpose router with WCF is something that we've tossed around for a long time. It's relatively common when building distributed applications to need application-level routing. Having a router included in WCF would allow people to include a router as a building block in their applications without forcing everyone to write the routing logic themselves. Although a router is conceptually simple, there's some tricky logic needed when routing certain kinds of messages, particularly if you want to support concepts such as sessions. It also takes a certain level of sophistication to build an asynchronous router implementation so that you can use the router in high-scale and high-throughput scenarios.
Putting a router into the product for Indigo ended up not happening. However, we did get to ship a simple router implementation as the intermediary router sample in the SDK. The code for that router sample originally came from a partner demo that Kenny Wolf put together. We later decided to convert the code into a sample and wrote the introductory readme to explain how the router worked.
After Indigo shipped I still wanted to find some way of including a router in the product in the future. There were a few requirements that I had in mind for what it meant to be a high-quality application-level router.
The forwarding service that was included in the PDC preview hasn't met all of these requirements yet but I think it's complete enough that you can get a good sense of how a canned router service might be used. Next time I'll continue describing the capabilities of the forwarding service and what it might look like when it's done.
Here are the stats from the world around us.
Number of posts in 2008: 255, which happens to be the same as last year
Total number of posts: 760, the next milestone prediction will probably be off by two weeks
Most Read Articles During 2008
The list of most frequently read articles was surprisingly stable. No articles written in 2008 made the list for the year. The most frequently read article written in 2008 came in overall at #12.
Most Read Articles Written in 2008