Yesterday's post covered most of the big new features that were added in the latest release. Today I'll go through the rest of the new features that are smaller in scope although no less exciting.
We also changed a few interfaces into abstract base classes although we didn't add any new functionality to those classes at this time. The IRequestContext interface is now the RequestContext class and the IStreamUpgradeBindingElement interface is now the StreamUpgradeBindingElement class.
I had a list of changes that I was hoping to get through during this week. However, the first two days ran a little bit long so there are still a few more items to cover. I'll run one more installment of this series on Monday and the next set of topics will start after the 4th of July holiday.
Next time: Some Changes for Channels and Transports in the June CTP, Part 5
Back in March, I talked about the POX support we added for the February CTP and a bug we found in our implementation of HttpMappingMode. There were two problems in that release. The first problem was the unfortunate functional bug that made it far too easy to shoot yourself in the foot when building an application. The second problem was that the multi-state mapping mode setting was a confusing and clunky way of enabling this architectural style. It was better than having to install an unsupported POX encoder sample on your production machine, but it still was not good.
In June, you can now see our new approach to solving this problem. Support for POX is built into the normal text encoder. Fundamentally, using the POX style means that you want our messaging layer to not add the SOAP and addressing goop that it normally sticks into every outgoing message for you and not require that goop on every incoming message. We already had knobs for controlling how to format the goop in the encoder. Our solution was to add a "none of the above" option to these knobs. Setting MessageVersion to None means taking the "none of the above" option for every part of the message, or equivalently, it means "no goop please".
The two major kinds of routers are circuit-based routers and packet-based routers. A circuit-based router affinitizes the incoming and outgoing connections. This makes the router almost transparent to the way we think about connectivity (the router is still not transparent to the way we think about message passing though, for instance transport security is point-to-point). A packet-based router treats everything like a datagram and doesn't care about connections.
Packet routers work well with fire-and-forget messaging. Transports that are inherently request-reply, such as HTTP, don't work so well with packet routers when they need to send back failure notifications. When an HTTP message arrives at a packet router, the router needs to make the reply immediately. Once the message moves on to the next hop, the router forgets everything about the reply connection so there's only one opportunity to send the reply message. Typically, the router just sends back an acknowledgment that the packet was received. However, if an error occurs several hops later, there's no way to route that error notification back to the originator. The router can't make a reply back without a new request.
To solve this problem, we introduced a one-way binding element that tags messages with an indication that they are safe for packet routing. Packet routers can look for this tagging and reject connections that are unsafe rather than mysteriously losing data at some point in the future. A consequence of this is that we removed the "native" one-way support in our HTTP transport and now require you to explicitly put in this binding element when you want one-way HTTP. I've only talked about HTTP in this discussion but the same binding element works with all of our transports to provide shape changing to the one-way messaging pattern.
Next time: Some Changes for Channels and Transports in the June CTP, Part 4
One of the biggest changes, although hard to recognize as such, is that we had to change the behavior of the Close method of ICommunicationObject to fix a bug. This was a particularly difficult fix to make because changing how ICommunicationObject works has such a broad impact across the entire product. The problem was that Close automatically downgrades itself to Abort when the communication object is faulted. How is this a problem? Well, the notification of the communication object faulting comes from the Faulted event being raised. If you call Close at almost the same time as the communication object is faulting, your Close may actually be an Abort but you won't know that because the Faulted event hasn't gone out yet.
This makes it impossible to know if your call to Close successfully completed. If you have some coordinating operation, such as a transaction or durable message, then you need to know whether the Close was successful so that you can either commit or roll back as appropriate. Our solution, after looking at a lot of proposals, was to make Close throw an exception after it downgrades to Abort due to a fault. That way, you always know whether the call to Close was successful. However, this change breaks code that calls Close without handling this exception. That can happen if you call Close in the cleanup of a catch block for instance. Although Close always could have thrown an exception at this time, many people were not handling that case. The solution is to call Abort yourself rather than calling Close and relying on it to downgrade to Abort for you.
The pattern for this that we expect to be commonly used looks something like this:
try { communicationObject.SomeOperation(); communicationObject.AnotherOperation(); ... communicationObject.Close(); } catch (...){ communicationObject.Abort();}
A smaller change to CommunicationObject that happened earlier is that we removed the base class implementation of several of the callback methods for state changes. CommunicationObject implements the state machine for you and calls into your code when an Open, Close, or Abort happens to actually do the work. The default implementation for these callback methods did nothing, but there was a lot of confusion over whether these methods should be overridden and whether the subclass should chain back to the method in the base class. Changing these methods to be abstract makes what you need to do in a subclass very clear.
Unfortunately, it's hard to achieve that same kind of clarity when making behavioral changes because we don't have validation in the compiler to tell you whether you're using an object correctly.
Next time: Some Changes for Channels and Transports in the June CTP, Part 3
The binding context stores all of the dynamic information needed when the construction of the channel stack is in progress. When we go to build a channel stack from a binding, we first need to stamp out a set of binding elements. Think of this as constructing a custom binding from the instantaneous settings of the binding you're building it from. If we change the original binding in the future, that doesn't affect the binding elements we created. The same is true in reverse. If we change the binding elements, it doesn't affect the original binding or any other binding elements created from that binding.
The other piece we need is a bag to hold all of the miscellaneous settings we encounter. That bag is the binding parameter collection. You'll initially populate the bag through design-time configuration of the binding and contract. More likely though, you'll use someone else's code that will populate the bag by examining your service description and pulling interesting bits off to place into the collection. Then, any settings that need to be pushed down the channel stack during creation are put into the collection until a channel lower in the stack needs them. This replaces the old method of stashing any extra binding elements in the UnhandledBindingElements collection.
public class BindingContext{ public BindingContext(CustomBinding binding, BindingParameterCollection parameters); public BindingContext(CustomBinding binding, BindingParameterCollection parameters, Uri listenUriBaseAddress, string listenUriRelativeAddress, ListenUriMode listenUriMode); public CustomBinding Binding { get; } public BindingParameterCollection BindingParameters { get; } public Uri ListenUriBaseAddress { get; set; } public ListenUriMode ListenUriMode { get; set; } public string ListenUriRelativeAddress { get; set; } public BindingElementCollection RemainingBindingElements { get; } public IChannelFactory<TChannel> BuildInnerChannelFactory<TChannel>(); public bool CanBuildInnerChannelFactory<TChannel>(); public BindingContext Clone(); public T GetInnerProperty<T>() where T : class;}
The listen address mostly does what it says and provides the server side of a connection with an indication of the address to listen on. There is some magic that goes on when you only specify part of the listen address and rely on us to generate the rest for you automatically. For some particularly clever transports, you can get away with specifying nothing at all for the listen address. If the ListenUriBaseAddress is null and the ListenUriMode is set to Unique, it means that the transport should generate the entire base address from scratch including details like the hostname and port.
The remaining methods are straightforward for delegating to from your channel implementation. Rather than directly using the inner channel underlying your channel to chain the construction process, you delegate the building or querying operation to the inner channel through the binding context. You have access to the binding elements that go into making the inner channel for examination, but you don't have to worry about the actual instance.
Next time: Some Changes for Channels and Transports in the June CTP, Part 2
At this point in the product cycle for WCF, how do we decide what disruptive changes to make? The changes that we're making now typically happen for one of four reasons:
I'm going to go over some of the more noticeable changes that we made between the February and June CTP releases. Not all of these are breaking changes for earlier code. In some cases we added significant new functionality without affecting the existing code. Most of these changes do have an impact on earlier versions though.
I'll run the article on binding contexts tomorrow, then continue with this series for the remainer of the week.
Two announcements coming out today.
The first announcement is that the slides from the chalk talks at Tech Ed are now available. You can get the slides for the WCF presentations from the community site and I'll let you explore to find the slides for the WF presentations (hint: it only requires changing one letter in the URL).
The second announcement is that the newly renamed .NET Framework 3.0 has a CTP release out. The June CTP is the first with the .NET 3.0 name instead of WinFX. This link is just for the runtime. I haven't seen a link to the SDK yet for this CTP but I expect it will be available soon. My blog is now three name changes out of date.
Index for bindings in this series:
The final HTTP binding that I'm covering in this series is WSFederationHttp. Federation is the ability to share identities across multiple systems for authentication and authorization. These identities could either be for users or machines. This binding is intended for the very specific scenario of federated security.
Standard disclaimer:
I've cut down on the number of properties presented by eliminating duplicates between the binding settings and binding element settings. For instance, the XML reader quotas can be set on either the binding or the message encoder binding element, but I'm only going to show them on the message encoder. I've also omitted most of the security credential settings because they're very messy and you hopefully won't need to change them much.
Federated HTTP supports SOAP security as well as mixed-mode security, but it doesn't support exclusively using transport security. I'll begin with the usual pattern of first presenting the binding with security disabled.
TransactionProtocol: WSAtomicTransactions
AddressingVersion: Addressing10 (http://www.w3.org/2005/08/addressing)MaxReadPoolSize: 64MaxWritePoolSize: 16ReaderQuotas: MaxArrayLength: 16384 MaxBytesPerRead: 4096 MaxDepth: 32 MaxNameTableCharCount: 16384 MaxStringContentLength: 8192
AllowCookies: FalseAuthenticationScheme: AnonymousBypassProxyOnLocal: FalseHostNameComparisonMode: StrongWildcardManualAddressing: FalseMappingMode: SoapWithWSAddressingMaxBufferPoolSize: 524288MaxBufferSize: 65536MaxReceivedMessageSize: 65536ProxyAddress: ProxyAuthenticationScheme: AnonymousRealm: Scheme: httpTransferMode: BufferedUnsafeConnectionNtlmAuthentication: FalseUseDefaultWebProxy: True
There's nothing unusual about these settings compared to any of the other HTTP bindings. However, if you look at the top-level settings on the binding, there are two new components. The first is an address for a privacy notice. The second is buried inside the security settings. If you drill down to the settings for message security (not pictured here) there's now more than a dozen settings instead of the normal two or three.
CloseTimeout: 00:01:00EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)Namespace: http://tempuri.org/OpenTimeout: 00:01:00PrivacyNoticeAt: ReceiveTimeout: 00:01:00ReliableSession: Enabled: False InactivityTimeout: 00:10:00 Ordered: TrueSendTimeout: 00:01:00TextEncoding: System.Text.UTF8EncodingTransactionFlow: False
The channel stack is identical to the WSHttp binding when Security.Mode is set to Message.
However, setting Security.Mode to TransportWithMessageCredential results in something of a hybrid between the WSHttp and BasicHttp bindings.
RequireClientCertificate: FalseScheme: https
Finally, using the MTOM encoder looks exactly the same as for WSHttp.
Next time: It's All in the BindingContext
After a few days break, the series on standard bindings continues. This week will take care of the remainder of the HTTP bindings, leaving only the MSMQ and PeerChannel bindings to talk about. WSDualHttp features the same support for Web Service protocols as the WSHttp binding, but is designed for use with duplex contracts.
Unlike WSHttp, WSDualHttp only supports SOAP security. I'll start off with the settings when no security is being used. The other two big differences you'll see between WSHttp and WSDualHttp is that the dual variety makes Reliable Messaging mandatory and adds a CompositeDuplex binding element to provide the duplex shape.
AcknowledgementInterval: 00:00:00.2000000EnableFlowControl: TrueInactivityTimeout: 00:10:00MaxPendingChannels: 128MaxRetryCount: 8MaxTransferWindowSize: 32Ordered: True
ClientBaseAddress:
The CompositeDuplex element creates the back channel from the server to the client using the base address setting. Most configuration settings are unchanged from the ones used with the WSHttp binding except that there is no longer a switch to disable reliable sessions.
CloseTimeout: 00:01:00EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)Namespace: http://tempuri.org/OpenTimeout: 00:01:00ReceiveTimeout: 00:01:00SendTimeout: 00:01:00TextEncoding: System.Text.UTF8EncodingTransactionFlow: False
Setting the Security.Mode to Message makes exactly the same transformation as we've seen with the other standard bindings.
The same holds true for changing the message encoding to use MTOM.
Next time: Inside the Standard Bindings: WSFederationHttp
When you build a channel factory or listener, you have to specify a TChannel parameter that describes the shape of the channel you want to build. In most cases, you don't have a lot of choices for the channel shape, although conceivably any subset of the possible channel shapes might be available depending on how you've configured your factory or listener.
That's not very helpful, so let's be specific and look at what our built-in channels support. I'll deviate a bit from usual by covering how the final release is expected to behave rather than how the latest public release does behave. This topic isn't meaty enough to be worthwhile revisiting in the future.
The NamedPipeTransportBindingElement and TcpTransportBindingElement change shape depending on whether the transfer mode is buffered or streamed. When buffered, both the factory and listener for these transports requires the IDuplexSessionChannel channel shape. When streamed, the factory requires the IRequestChannel channel shape and the listener requires the IReplyChannel channel shape.
The HttpTransportBindingElement doesn't change with the transfer mode. The factory always requires the IRequestChannel channel shape and the listener always requires the IReplyChannel channel shape. Previously, the HTTP transport cheated a bit by offering an IInputChannel and IOutputChannel option even though HTTP is inherently request-reply. Read on to find out what to do if you were using this feature.
The OneWayBindingElement is used to change one of the bidirectional channel shapes into a one-way channel shape (the naming is very clever). The factory feeding into the OneWay factory must provide either the IDuplexSessionChannel or IRequestChannel channel shape. The OneWay factory always requires the IOutputChannel channel shape. The listener feeding into the OneWay listener must provide either the IDuplexSessionChannel or IReplyChannel channel shape. The OneWay listener always requires the IInputChannel channel shape.
Finally, the CompositeDuplexBindingElement is used to logically associate an IInputChannel and IOutputChannel. On the factory side, both the CompositeDuplex factory and the underlying factory require the IOutputChannel channel shape. On the listener side, both the CompositeDuplex listener and the underlying listener require the IInputChannel channel shape. You'll notice that none of the transports mentioned above offer up an IInputChannel or IOutputChannel, so you'll need to make use of a one-way conversion at some point to build the composite duplex.
Next time: Inside the Standard Bindings: WSDualHttp
I've talked about the framing that goes on in the network stack before, but today's topic is a case where the framing actually affects what your application can do. Inside the WCF transport, essentially the uppermost level of the WCF network stack that actually has a byte stream, we need to make a decision about how that stream of bytes will get pushed onto the wire. A WCF message has an almost unlimited size. You can of course constrain the size of messages that you'll deign to receive, but in theory it's possible to create really, really big messages and there might be someone actually willing to receive a message that big.
Network messages almost never have an unlimited size. Some network transports (the layer below WCF transports) cap out at hundreds of bytes, while others cap out at millions of bytes (queues, but I haven't talked about those yet), but nearly all have a cap that is less than the quadrillions or quintillions of bytes you can stuff into a WCF message. How is it possible to actually send a WCF message over a size-constrained network transport?
The solution is message framing. Surrounding each message is contextual information that allows the receiver to reassemble fragments into the original WCF message. Each transport is responsible for splitting the byte stream, applying its own framing format, and performing the reassembly.
At the beginning of the message are two pieces that could conceivably be quite large, the via for message delivery and the content type of the message. Now, these pieces are constrained by your maximum message size, but you have to know where the message is going before you can do things like perform user authentication. This is a sticky point because while you might be ok with authorized users sending you millions of bytes, you probably don't want unauthorized users to do the same.
This was a somewhat long digression to motivate a problem you might encounter with our TCP and named pipe transports. The framing format for these transports specifies that the receiver may, if they want to, cap the maximum size of the message via and content type. That's the Via property on your IOutputChannel and the ContentType property on your MessageEncoder. We do in fact want to do this. There are even specific faults to send back in the event that the limits are reached. What you probably want to know though is: what are those limits? 2048 bytes for the message via and 256 bytes for the content type.
Next time: Mapping Channels to Shapes
Friday was pretty much uneventful since the conference was in the process of shutting down. Instead, I'm pulling out some pictures I took earlier to show you what the exhibition floor was like.
Coming in to the big room, there were three color-coded Technical Learning Center areas and the vendor area, which took up the majority of the space. All of the breakout sessions and stores were located on three levels higher up in the convention center.
The vendors had about a dozen aisles, with about two score booths in each aisle. This area was only open about half the time each day so it invoked a mad rush whenever the barriers were lowered.
There's no way to look into each of the four corners of the floor, except when in the glass walkway you can see in the upper-right corner of the picture. I went up there to get a view of each quadrant. When you're in the walkway, the view is across the aisles instead of down them.
Turning to the right, you can see the red Technical Learning Center, which had the Windows Client, Management, Security, and Server groups.
Turning right again, you can see the green Technical Learning Center, which had the Office and Mobility groups. There was a little pod right by the entrance that had all of the mobile device samples. At the end of each day, they just wrapped the pod up in plastic and tape so that no one could steal the devices.
Turning right one last time, you can see the blue Technical Learning Center, which is where the Connected Systems Division was located. In this center there was also the Architecture group and the Development group for Visual Studio.
That's all from this year's Tech Ed. See you next time, unless Sara kills me for posting this picture of her with two of the MSDN mascots.
Starting tomorrow, we'll be back on the usual technical posting schedule.
Thursday was the last day for the exhibition booths so it was everyone's final chance to grab free items. Personally, I don't take home a lot of stuff when I travel because of the hassle of getting it on a plane and home. There are some people that do not see this as an obstacle. In the exhibition area, there were beanbag lounges set up for relaxing and using the wireless network. At the end of the show, the organizers gave away the beanbag chairs. If you're flying next to someone who is trying to put a beanbag in the overhead bin of the plane, ask if they got it at Tech Ed.
I realized that I mentioned the demo stations yesterday without showing what those looked like.
The kiosks are basically a computer, monitor, and whiteboard assembled together that lets the team show off some demo application. This one shows Elliot Waingold demonstrating the IndiEnterprise demo for WCF. IndiEnterprise is a collection of web services for an order processing system that uses a variety of bindings and WCF features. There's an animated frontend just so that you can see something happening when messages are sent. The number one question that I got about IndiEnterprise is whether WCF automatically visualizes your network infrastructure and message tracking. Um, sorry, it's just a demo.
More great chalks including these two on BizTalk adapters and Workflow extensibility.
I'm going to tally all the estimates I made, but it looks like the Workflow talks were the best attended of all of our chalk talks. They had a lot of sessions that were packed out of the theater area and into the discussion area.
In the afternoon, I went out to some of the breakout sessions. Clemens Vasters had one on the selection of WCF bindings for different architectures. The gimmick that he used was to present a particular application and then use his tablet to draw an architecture and talk about which bindings you should think about using. It was an interesting idea but the handwriting was hard to read from the back of the room.
By this point in the conference, everyone has got the routine down for what they're doing either manning a booth or wandering around the show floor. Some of the vendors that misestimated their swag budget have started running out of free gifts to give away. The goal for those in the booths is to completely run out of items as the last person leaves so that they don't have to turn anyone away and they don't have to take anything home. The goal for those wandering the floors is to collect enough free t-shirts to avoid doing laundry next year but not to collect so much that the airline makes them buy another ticket.
There were more great chalk talks throughout the day. We've basically been running sessions all day in both theaters, with 30 minute breaks in between. One of the best attended talks that I spotted was Shy Cohen's one on service-oriented design patterns. People were packed into the theater and out into the booth area until you reached the point where you couldn't hear Shy speaking from any further back.
Another great talk was a joint talk on interoperability given by Kirill Gavrylyuk of Microsoft and Gerry Beuchelt of Sun Microsystems. Kirill has been giving a lot of these talks recently, including at JavaOne a few weeks ago.
Besides the chalk talks, demo kiosks, and discussion area, we also have a set of hands-on labs for people to work on. The hands-on lab is a self-directed activity that take people through a series of activities for getting started with the NetFX products. Our hands-on lab area is a large triangular array of computer stations for people to work at, with the other half of the triangle filled in by the Architecture track.
Normally the room is packed, but I managed to wander over there when it was competing with the most popular session of the day, and every other day as well, lunch. There is an absolutely mammoth lunch area for the 12,000 attendees and other personnel wandering around Tech Ed. This shot doesn't even cover a quarter of the area. Even still, they're relying on people wandering in and out over 90 minutes in order to fit everyone through.
Now that we've had a chance to get a second round through the system, it's possible to start notice the patterns of what people are really interested in learning about. One of the hot topics that was surprising to me is about building security infrastructure. I've gotten a lot of questions about building your own secure token service for use in federated systems. I have no idea how to do this, but I bet Jan Alexander, who gave two chalk talks today about security, could explain it.
This is from the earlier talk on the Web Service series of standards for security: WS-Security, WS-SecureConversation, WS-Trust, and WS-SecurityPolicy. Actually, if you're interested in learning about building an STS, I've gotten a recommendation for Pablo Cibraro's blog entry on doing exactly this.
My favorite session of the conference so far was this one by Scott Hanselman of Corillian.
ARC310 Dirty SOAP: A Dynamic Endpoint without ASMX - How and Why?
Not every large system in the wild can use .NET 2.0, ASMX and "Indigo". Often the real world isn't very pretty, or formal use of .NET ASMX Web Services doesn't lend itself to a particular solution. Corillian's software handles a quarter of the nation's retail banking online population with .NET. The system is built with a contract-first approach using WSDL and a custom binding to generate in-process service proxies. When it came time for Corillian to present their Operations as SOAP, we created a dynamic endpoint - WITHOUT ASMX. We then extended it to support POX (Plain Old XML). In this session, we discuss the architectural and design ramifications of managing a dynamic endpoint and how this decision will positively or negatively affect our move to WCF.
Scott gave a great history about how they ended up building a service architecture that was almost identical to the WCF model, and how they'll replace that infrastructure with WCF when it comes out.
One hundred posts and a few hundred thousand article reads since starting this blog on February 6th, the Tech Ed summary post this morning marked the 100th article posted. There's still a few days left until the 100th daily article because I've had some multi-post days and a Memorial Day holiday without a post.
Monday was a long day on the show floor at the Connected Systems track. I spent most of the day in the Technical Learning Center where I was able to catch some of the Chalk Talks we had going on.
I got to listen to a general talk on WCF in the early afternoon by Steve Maine. Steve started about a half-hour early by giving a small group an overview about the work we're doing with POX and RSS. As additional people kept coming to the talk, the subject changed to a series of short talks.
I also got to listen to some talks in the area by the Biztalk and Windows Workflow teams. The post yesterday was a picture from the Workflow talk. Both of those talks ended up continuing long after the talk was actually over. People stuck around to interact with the team and chat in a freeform session.
At 5 PM, I went upstairs to listen to the WCF overview talk by John Justice. John gave a basic foundation for thinking about connected systems and did three demos for using WCF. After John's talk was over, the WCF team members that had later sessions came up on stage to plug their upcoming talks. The audience then got an impromptu question and answer session with the team answering as a tag-team. From left-to-right, that's John Justice, Shy Cohen, Steve Maine, Kirill Gavrylyuk, Clemens Vasters, and Mark Fussell on stage. I believe Steve's answering a question about IIS scalability and its interaction with WCF in the picture.
This is a talk that is going on behind me at the moment. The shot was taken during the setup before the talk started. We continued moving a bunch of chairs over to accomodate extra people but these sessions are fairly intimate and it's hard to comfortably fit more than about 30 people. This session basically maxed out the space after a few minutes.
[blogging live from Tech Ed]
Check out the new WCF community site that just went live with the even newer NetFx 3.0 naming.
Sunday was a day of travel and key notes. Although many people flew out on Saturday, Sea-Tac airport was packed with Microsoft employees going to Boston on Sunday morning. You could spot the people with backup laptops going over their presentations one more time to make sure that everything was in order. It was strange to hear the buzz for Tech Ed spontaneously circulate around the airport at seven in the morning.
Having booked my travel plans well in advance, I was able to get a direct flight from Seattle to Boston. That's about 2,496 miles and five and a half hours on Alaska Airline. Those less fortunate had a much more treacherous time coming here. I spent a number of years flying out of small airports so I know the pain of traveling all day just to get to an event. It's tough to keep your energy up after a long trip, but I'm sure everyone will be energized again tomorrow.
The schedule this year is for all of the keynotes to go on Sunday night, with talks starting first thing on Monday. I like this approach as I've never been a big keynote person. Coming out of a keynote though, the first talk you see afterwards just cannot compare with the quality and polish of the opening addresses. Hopefully, everyone will be able to reset themselves with the extra time.
What I'm really looking forward to is some of the great WCF talks this week as well as having some good conversations with customers. I'll be in the Technical Learning Center all day Monday so I'll have to catch those talks during a repeat performance or watch the presentations after the show.
The WsHttp binding is a lot like the BasicHttp binding with the Web Services knob turned up a little higher. Where BasicHttp stops with message security, WsHttp continues with transactions, reliable messaging, and WS-Addressing either enabled by default or available through a single control setting. Otherwise, the HTTP-ness of the two bindings is the same and all of the binding elements being used have appeared in previous bindings.
I'll start with my usual approach of presenting the channel stack and baseline settings with the Security.Mode property set to SecurityMode.None. The important points to note here are that we've got a binding element for transactions (with the transaction protocol set to the WS standard rather than OLE transactions) and the mapping mode is now SoapWithWSAddressing.
CloseTimeout: 00:01:00EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)Namespace: http://tempuri.org/OpenTimeout: 00:01:00ReceiveTimeout: 00:01:00ReliableSession: Enabled: FalseSendTimeout: 00:01:00TextEncoding: System.Text.UTF8EncodingTransactionFlow: False
Except for the differences in addressing, all of the features that are on by default in the WsHttp binding match the BasicHttp binding. This is still true when we set the SecurityMode to Transport, although you have to pretend like that transaction binding element isn't there.
However, when we switch to Message security, a slight divergence begins to appear. The message security implementation is more like the one we saw with the NetTcp binding.
Moving to the TransportWithMessageCredential security mode brings us back into line with the BasicHttp binding though.
To finish things up, I tried bindings with the security mode again set to None and enabling either the reliable message or MTOM features.
There's nothing special going on here that we haven't seen before.
Next week is going to be TechEd in Boston. There's no planned schedule of topics although I'll continue to try to write a new entry each day. After TechEd, I have some short topics about our transports before we get back into the series on the standard bindings.
Some time in the future: Framing Size Limits for the Tcp and Named Pipe Transports
I've talked about the request-reply message exchange pattern that HTTP uses, but we've never looked at what those messages translate into during transmission. Unlike TCP, which is sometimes used with the request-reply style but is inherently uncorrelated, the idea of requests and responses is built into HTTP.
After a connection is made to the server, the basic request message looks like
VERB URL VERSIONHEADERSBODY
The verb is the action that is being requested. The most common HTTP verb is GET, which simply retrieves the resource at the location specified by the URL. The version describes the message format being used and has a format of HTTP/1.0, where the first digit '1' is the major version number and the second digit '0' is the minor version number.
The headers and body specify data for the request. Headers consist of a name, followed by a colon, and then a value. A carriage-return line-feed pair terminates each header and the list of headers ends with a blank line. You can make up your own headers and the ones that the other side doesn't understand will just be ignored. The body is then totally arbitrary data.
Here's an example of a request I tried out when connected to port 80 of www.microsoft.com.
GET / HTTP/1.1Accept: text/*Host: www.microsoft.com
The verb is GET, the location is the root of the server, the HTTP version is 1.1, and I've specified two headers with no body. In response, I got
HTTP/1.1 200 OKDate: Thu, 01 Jun 2006 06:34:41 GMTServer: Microsoft-IIS/6.0P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"X-Powered-By: ASP.NETX-AspNet-Version: 2.0.50727Cache-Control: privateContent-Type: text/html; charset=utf-8Content-Length: 30430
followed by a whole bunch of text for the response body. The format of a response message is
VERSION STATUS REASONHEADERSBODY
The status is a machine-readable code that explains how the server is reacting in response to the request while the reason is a human-readable version of the same information. I'll talk about the parts of an HTTP message and how they relate to WCF more in the future, but for now I need to wrap up some of the other series that I have going.
Next time: Inside the Standard Bindings: WSHttp
A uniform resource locator (URL) is a standardized pointer to a resource. URLs not only tell you where information is located, they also tell you how to interact with that information. A cousin of the URL is the URN (the N stands for Name). URNs identify a resource by name without regard to the resource location. URLs are the opposite. They identify the location of a resource without regard to what that resource is actually called.
URLs don't have an overly rigid syntax, although most URL schemes follow the same general form.
scheme://username:password@host:port/path?query#fragment
There are other pieces that can go into URLs although these are seen less frequently in WCF applications. Usernames, passwords, and fragments are rare enough that I'm not going to talk about them here. These are primarily used in the HTTP and FTP schemes with an interactive client, rather than against a web service.
The most easily recognizable portion of a URL is the scheme. A scheme indicates the protocol that is needed to access a resource. Our standard transports come with the schemes "http", "https", "net.tcp", and "net.pipe". You'll sometimes see other schemes for transports and you can pick your own scheme when you're writing a channel and make the binding element.
The host and port specify where connections should be established to access a resource. If you're using a hosting environment, like IIS, or discovery then the location of the server is generally determined by configuration information outside the service. Someone then has to tell the client where the server is located. In some cases, particularly when you've got a transport that's purely on-machine, neither the client nor server cares about the actual connection location.
The path has traditionally indicated where a resource resides on the machine, using a hierarchical notation very similar to a file path. There's no requirement to actually map paths to files. When you're using the net.tcp scheme, the path really is just the name of a service without regard to where the files for that service are located. Automatically generated client-side paths for net.tcp services are even less connected to the concept of a file because they contain a random GUID to make each conversation have a unique address.
The query string is used by some schemes to pass parameters to the service. There's no standard for formatting a query and there are very few restrictions on what can go in the query string. Servers that process a query string should make sure that the string does not contain tainted data before doing something with the query. An example is if the query is supposed to contain a local file name, then the server should make sure that the name doesn't specify a network path or contain path symbols that give access to resources outside of those that the server is expected to provide.
Next time: HTTP Request and Response Messages
Part 3 of the series detailing the standard bindings (Part 1 was on BasicHttp and Part 2 was on NetTcp). The standard binding for named pipes is very similar to the standard binding for TCP. Named pipes are simpler because the WCF implementation is only meant for on-machine use and consequently there are fewer exposed features. The most notable difference is that the Security.Mode setting only offers the None and Transport options. SOAP security support is not an included option.
Like TCP, there's three binding elements in the channel stack when Security.Mode is set to None.
TransactionProtocol: OleTransactions
AddressingVersion: Addressing10 (http://www.w3.org/2005/08/addressing)MaxReadPoolSize: 64MaxSessionSize: 2048MaxWritePoolSize: 16ReaderQuotas: MaxArrayLength: 16384 MaxBytesPerRead: 4096 MaxDepth: 32 MaxNameTableCharCount: 16384 MaxStringContentLength: 8192
ConnectionBufferSize: 8192ConnectionPoolGroupName: defaultHostNameComparisonMode: StrongWildcardIdleTimeout: 00:02:00ManualAddressing: FalseMaxBufferPoolSize: 524288MaxBufferSize: 65536MaxInboundConnections: 10MaxOutboundConnectionsPerEndpoint: 10MaxOutputDelay: 00:00:00.2000000MaxPendingAccepts: 1MaxReceivedMessageSize: 65536Scheme: net.pipeTransferMode: Buffered
Along with the usual collection of settings that are only available through the binding itself.
CloseTimeout: 00:01:00EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)MaxConnections: 10Namespace: http://tempuri.org/OpenTimeout: 00:01:00ReceiveTimeout: 00:01:00SendTimeout: 00:01:00TransactionFlow: False
Switching the security mode setting to Transport does the same transformation for named pipes as it did for TCP. A new binding element is inserted to supply transport security, with no changes to either the binding element for the transport or the scheme of the binding.
ProtectionLevel: EncryptAndSign
Next time: Understanding the Syntax for URLs
Today continues the series I started last week about the standard bindings. The previous article covered the BasicHttp binding. Today's article covers the NetTcp binding, which is going to be the popular out-of-the-box choice for communicating over an Intranet. The default configuration for TCP is faster than the configuration for HTTP, but intended only for WCF-to-WCF communication. You can open that up with a cost to speed, and you can add some WS-* specification features again at a cost to speed. There's more about this in the article I did for choosing transports and message encoders. Whereas the HTTP bindings tend to turn things on by default, the TCP binding tends to turn things off by default so that you have to opt-in.
I'm again going to use the Security.Mode settings on the binding as my primary pivot for talking about the binding elements that are produced by the binding. The available settings are no security, TCP/SSL security, SOAP security, and TCP/SSL security with SOAP credentials. Let me repeat the presentation disclaimer I used previously because it applies just the same this time.
When Security.Mode is set to None, there are three binding elements in the channel stack.
ConnectionBufferSize: 8192ConnectionLeaseTimeout: 00:05:00ConnectionPoolGroupName: defaultHostNameComparisonMode: StrongWildcardIdleTimeout: 00:02:00ListenBacklog: 10ManualAddressing: FalseMaxBufferPoolSize: 524288MaxBufferSize: 65536MaxInboundConnections: 10MaxOutboundConnectionsPerEndpoint: 10MaxOutputDelay: 00:00:00.2000000MaxPendingAccepts: 1MaxReceivedMessageSize: 65536PortSharingEnabled: FalseScheme: net.tcpTeredoEnabled: FalseTransferMode: Buffered
And there are a number of loose settings on the binding not otherwise covered by these elements.
CloseTimeout: 00:01:00EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)MaxConnections: 10Namespace: http://tempuri.org/OpenTimeout: 00:01:00ReceiveTimeout: 00:01:00ReliableSession: Enabled: FalseSendTimeout: 00:01:00TransactionFlow: False
These are the baseline settings and all of the variations are very similar so I'm not going to repeat the properties unless they're new or different.
Enabling Transport security adds a new binding element to perform the transform on the data stream. Note that unlike HTTP, the transport itself does not change and we do not integrate the transport security binding element with the transport binding element.
Setting Security.Mode to either Message or TransportWithMessageCredentials works almost the same as it did for HTTP. We take the channel stack corresponding to a Security.Mode of either None or Transport and add an additional binding element to perform SOAP security. The specific binding element used for security varies depending on both the Security.Mode setting and the security options that are being used.
Here's an example with Security.Mode set to Message:
And here's an example with Security.Mode set to TransportWithMessageCredentials:
RequireClientCertificate: False
Note that in all of these channel stacks, the transactions binding element was included even though transactions are disabled by default. The same is not true for reliable messaging. A binding element only appears for reliable messaging if you specifically enable that feature by setting the ReliableSession property to true.
I used Security.Mode set to None for this example, but reliable messaging works with other security modes as well.
Next time: Inside the Standard Bindings: NetNamedPipe
During TechEd, the Connected Systems track (that's the WCF, Workflow, Infocard, and Biztalk teams) is going to include dozens of bonus talks for your enjoyment. Each of these mini-talks is going to be a little more than an hour long and drill into a particular topic. These talks are going to be held in small rooms so attendance is limited. There are hopefully enough activities going on at once that there won't be too much of a rush and you'll get to see everything you want. Check the Connected Systems area of the conference for locations and updates when you arrive.
Applying the Security Development Lifecycle to the Windows Communication Foundation (100)by Maciej Skierkowski6/12/2006 10:45AM-12:00PM
This talk will describe how we applied the Trustworthy Computing Security Development Lifecycle to the WCF infrastructure. I will elaborate on the processes we followed for design reviews, threat modeling, and security testing. I will also describe how these processes (and lessons) can apply to securing your WCF applications.
Using Windows Communication Foundation diagnostics to debug your distributed applications (100)by Vadim Meleshuk6/12/2006 9:00AM-10:15AM
This talk will show you how you can use WCF diagnostic features (such as correlated tracing) to troubleshoot your WCF and even non-WCF web services and clients
Service Oriented Design Patterns (100)by Shy Cohen6/14/2006 2:00PM-3:15PM
Design pattern are a general, repeatable solution to commonly-occurring problems in software design. In this talk, we will review several common SOA patterns related to the space between the services, examine the pros and cons, describe some of the complications they entail, provide practical advice on how to best implement the patterns, and when applicable use some code and demos to illustrate some points.
Programming Transactions: Past, Present and the Ubiquitous Future (200)by John Doty6/15/2006 2:45PM-4:00PM
This talk will provide an overview and a hands-on demo of transactional programming. We will take a brief look at where we've been with Enterprise Services, where we are now with the simplicity and performance of System.Transactions and a look into the near future with WCF's web service transaction support. We will also look at enhancements in the transaction system in Windows Vista and Longhorn Server such as the transacted registry and file support and improved cluster support.
WS-* security specifications (200)by Jan Alexander6/13/2006 10:15AM-11:30AM
This talk will give an overview of WS-* specifications that relate to the security (WS-Security, WS-SecureConversation, WS-Trust, WS-SecurityPolicy). It will describe how these standards are implemented in WCF and what they are used for. We will mainly focus on the WS-SecurityPolicy specification and how it relates to the WCF generated message formats and security configuration.
Introduction to the Service Factory (200)by Shy Cohen; Don Smith6/16/2006 9:00AM-10:15AM
The Service Factory is a cohesive collection of various forms of guidance that have been built with the primary goal of helping you build high quality connected solutions in a more consistent way with less effort. In addition to the forms of guidance you may have already seen from the Patterns & Practices team, a new form of guidance called a Guidance Package is used to allow guidance to be automated from inside Visual Studio 2005 through the use of a wizard-based dialogs. This guidance can also be modified to fit the needs of a specific solution. In this session we will present the Service Factory, walk you through some common usage patterns, and discuss the development process and future of the Service Factory. This is a joint talk by Shy Cohen, and Don Smith (Product Manager, Patterns and Practices)
Testing Custom Channels built with Windows Communication Foundation (200)by Kavita Kamani6/13/2006 2:45PM-4:00PM
This talk will focus on why you need custom channels, and when you do have them, what are the interesting test considerations. At the end, I will demo a basic tool we've built to test custom channels
Exposing your custom channels built with Windows Communication Foundation to the configuration system (200)by Kavita Kamani6/15/2006 8:00AM-9:15AM
This talk will focus on things you need to understand to expose any Custom Channel you have so that it is configurable via app.config or web.config. Again, the talk will conclude with a tool we've developed to make it seemingly easy for you.
Windows Communication Foundation: A model-based approach in testing your custom ICommunicationObject (200)by Sara Wong6/13/2006 8:30AM-9:45AM
If you are looking into implementing your own or extending existing WCF ICommunicationObjects, what can you do to ensure your new objects obey the existing ICommunicationObject contract? In this talk, not only will you learn the latest model-based testing approach, you will also see how you can apply it to achieve your goal via this easy and fun method.
Extending Windows Communication Foundation diagnostics (200)by Vadim Meleshuk6/14/2006 10:15AM-11:30AM
What can you do if you want to extend WCF's tracing, logging and inspection functionality? This talk applies to both custom channel writers and developers implementing or consuming services.
Hosting a web application business logic in Windows Workflow Foundation (200)by Matthew Winkler6/12/2006 3:15PM-4:30PM
In this chalk talk we'll look at ways to leverage WF to handle the business logic in your web application. First, we'll look at hosting options (in process, exposed via WCF) and then move into a few different patterns for workflow. These will include using WF to manage short lived business logic (from postback to render), participating in long running business process managed by WF, and using the Rules Engine to drive validation and other rules based scenarios. We'll also discuss security considerations in these approaches as well as listen to how you're planning on using WF in your web applications.
Windows Communication Foundation Security Architecture (200)by Jan Alexander6/13/2006 4:30PM-5:45PM
The aim of this talk is to give people insight into our security architecture and how it fits in the overall WCF architecture. It covers the architecture of security binding element and channels, the relation between transport and message security and how they fit in the WCF channel stack, security credentials and service authorization, integration with existing authorization frameworks (MembershipProvider, PrincipalPermission), and introduction to claims and XSI
Customer Scenario: Use of Windows Workflow Foundation Credit Suisse (200)by Leslie Muller6/15/2006 9:45AM-11:00AM
Credit Suisse Group is a leading global financial services company, providing clients with investment banking, private banking and asset management services worldwide. Like in most enterprises, Credit Suisse provided their developers with physical machines for development. Issues such as combination of authorization, physical delivery times and compliance-related workflows led to slow development timeframes. Their R&D group built an extremely extensible self-service virtual-machine provisioning system that enables software developers in a fraction of the time to easily, securely and rapidly provision on-demand disposable workstations, servers, and multi-tier environments. Credit Suisse will exponentially increase software developer productivity, drastically lower IT costs and ensure compliancy with continuously stringent regulatory requirements. The solution uses Windows Workflow Foundation, Windows Communication Foundation, and Virtual Server. This talk will be presented by Leslie Muller, an Architect at Credit Suisse.
Windows Communication Foundation Authorization with Claims (300)by Tomasz Janczuk6/14/2006 8:30AM-9:45AM
The goal of this talk is to help people leverage the new claim-based authorization mechanism in WCF. The talk introduces the new WCF claim-based authorization model and explains the concepts of claim, claim set, authorization policy, authorization manager, and claim normalization. The talk further goes into exploring the role of the Security Token Service, the service, and the client with the help of a sample.
UI Page Flow by hosting Windows Workflow Foundation in ASP.NET (300)by Israel Hilerio6/15/2006 1:00PM-2:15PM
In a web application the transitions between multiple web pages is often written in code. The business logic deciding which page to send the user to next gets hidden in with the procedural code in the page. User interface page flow is a concept to allow the declarative modeling of page transitions and this can be implemented using Windows Workflow Foundation. This talk will describe the concept in more detail and give you a sneak peak at the advances that Microsoft is planning in this area
Rehosting of the Windows Workflow Foundation Designer (300)by Devinder Singh6/14/2006 3:45PM-5:00PM
Windows Workflow Foundation comes with a workflow designer which you normally use in Visual Studio 2005. The workflow designer component is allowed to be rehosted in your application. This talk will describe how you can add the workflow designer into your application so that your application can create and edit sequential and state machine workflow models. We will cover workflow designer feature integration of activity property binding, the rules editor and using code handlers with your designed workflow models.
Understanding Exceptions, Transactions and Compensation in Windows Workflow Foundation (300)by Gerald Walsh6/16/2006 10:45AM-12:00PM
Windows Workflow Foundation provides a rich set of features to support powerful fault handling, robust Atomic and long-running transactions, and flexible compensation support for failed transactions. This session will examine how to manage exceptions within a workflow, how to use the System.Transactions namespace, how to implement both atomic and long-running transactions, and how to utilize compensation and the compensate activity to recover from faults occurring during a transaction's execution. Demonstrations will be provided to highlight the features and techniques developers need to know to build resilient and reliable workflow applications.
Monitoring Running Workflows Using the Tracking Service (300)by Moustafa Ahmed; Joel West6/12/2006 5:00PM-6:15PM
In Windows Workflow Foundation, the tracking service keeps log information about workflow events and activity execution statuses. The workflow runtime automatically identifies events related to executing workflow instances and outputs them to a tracking service. This chalk talk will cover the capabilities of the out of box SQL-based tracking service as well as how and why you would build a custom tracking service.
Windows Workflow Foundation - Rules Engine Extensibility (300)by Jurgen Willis6/15/2006 9:45AM-11:00AM
The breakout session "Windows Workflow Foundation: Building Rules-Based Workflows" gave an introduction to the rules engine capabilities provided in Windows Workflow Foundation (WF). In this chalk talk, learn more about the WF Rules extensibility mechanisms, which support more advanced scenarios. See an example of how to externalize rules so that they can be maintained separately from the workflow assembly. In addition, learn how to author and execute rules outside of a workflow. Also, see how you can create custom expression and action types that can be used directly in your rules.
Enterprise WebServices interoperability between .Net and Java using WCF and Sun's GlassFish (300)by Kirill Gavrylyuk; Gerald Beuchelt6/14/2006 2:00PM-3:15PM
Web Services matured to address enterprise needs. Interoperability between Java and .Net on Secure, Reliable and Binary messaging is a reality. Come and see .Net and Java interoperating in a real world enterprise scenario using Microsoft's Windows Communication Foundation and Sun's GlassFish web services stacks. Gerald Beuchelt is a Web Services Architect in the Chief Technologist's Office at Sun Microsystems, Inc. He is focusing on advanced web services and security technology and their application, with an in-depth focus on standards and Microsoft interoperability.
Custom Security Tokens in Windows Communication Foundation (400)by Tomasz Janczuk6/16/2006 10:45AM-12:00PM
The goal of this talk is to help people understand the steps necessary to create and use custom security tokens in WCF. The talk explains the concepts of security token, token provider, token authenticator, and token serializer. It introduces the steps necessary to introduce a custom token on the client or the service. The talk then walks through a sample showing the use of a custom hardware-based security token.
Building Federated Clients and Services using Windows Communication Foundation (400)by Todd West6/13/2006 1:00PM-2:15PM
Windows Communication Foundation supports the active client federation profile by way of federated bindings and issued token authentication credentials. Publishing of service issuer information, construction of client binding stacks, use of X509 certificates in federation, and local issuer (home realm) federation are discussed.
Provisioning of X509 Certificates and X509 Trust Models (300)by Todd West6/15/2006 4:30PM-5:45PM
X509 certificate chains can be generated using certificate autoenrollment, makecert, or other tooling. WCF transport, mixed mode, and message security can be configured to use certificates in various ways, notably the peer trust and chain trust models. This talk demonstrates certificate creation, shows how WCF works with certificate chains and chain trust, how peer trust and custom X509 certificate validation is configured, and looks at the special role of machine certificates
Windows Communication Foundation: More than just SOAP (400)by Steve Maine6/12/2006 1:30PM-2:45PM
WCF loves SOAP, but it's rich extensibility allows it to be much more than "just" a SOAP messaging stack. Take a tour through the Indigo extensibility points used to serve up a variety of non-SOAP formats including XML-RPC, RSS, ATOM, JSON, and more
The Windows Workflow Foundation Scheduler Service and Transactions (400)by Israel Hilerio6/14/2006 5:30PM-6:45PM
The WorkflowSchedulerService defines how CPU threads can be used by the workflow runtime. Standard ACID transactions are supported in Windows Workflow Foundation through the TransactionScope composite activity. Long running processes that require some compensatory action when an exception occurs are also supported through the CompensatableTransactionScope. This talk will discuss these interesting areas of Windows Workflow Foundation.
Inside the Windows Workflow Foundation runtime (400)by Bob Schmidt6/16/2006 2:45PM-4:00PM
The WorkflowRuntime is the engine that manages executing workflow instances in Windows Workflow Foundation. It handles events for workflow instances, interacts with services that the host application adds and manages workflow persistence. This talk will drill down into the workflow runtime and give you some insight as to how it works. This will be an advanced talk and you should have some prior exposure to Windows Workflow Foundation prior to attending.
Next time: Inside the Standard Bindings: NetTcp