|
|
Browse by Tags
All Tags » Channels » Indigo » Channel Dev Tour (RSS)
-
I gave a chalk talk on channel development in the afternoon yesterday. I did a huge experiment for the second-half of the talk, which was to write a custom channel from scratch for the audience. That's the kind of theater that you can pull off in a chalk talk but not a regular breakout session. I started with a completely empty Visual Studio environment, wrote a web service, explained why the web service call crashed due to a protocol issue, and then fixed the crash by writing a custom channel. We had 46 people in the audience at the start. The capacity of the chalk talk theaters is only 32 people, but we secured about a dozen extra chairs from the lounges and people stood along the back. Capacity was an issue for several of the chalk talks yesterday. I saw one chalk talk for BizTalk that had crammed almost 60 people into the room. If you're in the audience, it starts getting quite warm after a while. The breakout session rooms are quite spacious on the other hand so I haven't seen any problems there. The Orlando venue has a tremendous capacity and a generally good layout. The only other difficulty was that the standard equipment was a non-adjustable over-ear headset microphone. In addition to making you look like a cross between a call-center worker and a pop star, that type of mic is pretty uncomfortable to wear for an hour and picks up a lot of extra noise if you move around while talking. I tried a half-dozen ways of putting the headset on to fix the issues before the AV guy offered a standard lapel microphone. They had one sitting in the AV case in the room. I don't know why they didn't make the proper equipment available from the start. I promised at the end of the talk that I'd post some resources. Ed Pinto and Kenny Wolf are giving a talk "Architecture of Microsoft Windows Communication Foundation and Common Extensibility Points" on Thursday at 4:30 PM. Steve Maine is giving the buzzword titled talk "Microsoft Windows Communication Foundation Syndication, AJAX and REST Services in Web 2.0 with .NET Framework 3.5" on Friday at 1 PM. There are six samples that I particularly recommend for channel developers. Chunking channel HttpCookieSession channel UDP transport WSE transport UDP activation Config code generator Finally, here is the code that was written during the talk. The scenario was based on an HTTP problem I described back in August . using System; using System.Collections.Generic; using System.Text; using System.ServiceModel; using System.ServiceModel.Channels; Read More...
|
-
Once you've obtained a channel manager from the binding element, you have the first object that is usable for network communication. Although the two kinds of channel managers, channel factories and channel listeners, share many of the same methods, the use of those methods tends to be quite a bit different. I'm going through just the client-side channel factory in the list, but I'll point out some bits of information that differ between channel factories and channel listeners. To get a minimally working channel factory for a custom channel, you need to think about what you're going to do in five particular methods. The holdover from binding elements to channel managers is GetProperty. The implementation of GetProperty should at a minimum return a response for every interface that you had support for on the binding element. The return value itself should be exactly the same as well, for the values that would have been returned at the moment you created the channel factory. Future changes to the binding element settings should never change the values returned by the channel factory. Open is a hook to let you perform some work prior to making the first service call. This is your chance to do any preconnection work, like looking up credentials, that you want to have costed during startup rather than taking time during a service call. When programming against a service with a client proxy, opening the proxy is an optional step. However, even if the user doesn't open the proxy, your channel factory and channel will get opened prior to the first call taking place. Close is the hook to let you clean up any state left behind that takes time to get rid of, such as open network connections. There is a different meaning for Close between channel factories and channel listeners. Closing a channel factory is supposed to similarly close all of the channels created from that factory. Closing a channel listener doesn't touch the existing channels. Therefore, you're going to have to structure your state differently between the channel factory and channel listener. For the channel listener, you are essentially forced to push more state into the channels so that they can survive the destruction of their channel listener. Abort is a similar idea to Close, but is a part of the ungraceful shutdown process. Rather than nicely cleaning up the state, you are expected to take care of the state problem by blowing it away with abandon. Abort should never do anything with the network or Read More...
|
-
We're back to the channel development series for another pair of days. When I left off, I promised to talk a bit about writing binding elements and channel managers. Today's article is about writing binding elements and tomorrow's article is about writing channel managers. These articles expand on the checklist items for the steps you have to take while writing a custom channel. To keep things simple, I'm only going to talk about the client-side part of the equation. Where needed, I'll point out that there is an equivalent server-side piece that you need to implement as well. To get a minimally working binding element for a client channel, you need to think about what you're going to do in four particular methods. CanBuildChannelFactory is how you plug into the evaluate step of the channel construction process. This method allows consumers of your channel to validate whether construction is going to succeed without actually performing the build process. You should put your validation in a common place rather than duplicating it between the evaluate and build stages. It will save you a lot of trouble whenever you update your channel. There's a corresponding method for the evaluate stage on the server. BuildChannelFactory is how you plug into the build step of the channel construction process. This method produces the channel manager object used by the next layer of the build process. Primarily what you're doing here is copying settings from the binding element to the channel manager so that future changes to the binding element don't affect existing channels. There's a corresponding method for the build stage on the server. GetProperty is a query interface for dynamically discovering information about the channel. Any properties you don't recognize should be passed to the inner binding element so that channels further down in the stack have a chance to respond. I'll have more details about the interfaces you should implement with GetProperty later. Clone produces an exact copy of the binding element. You should implement Clone by creating a copy constructor and doing all of the work in the constructor. Clone will be called many times during the evaluate and build processes. It is essential that modifying the cloned binding element does not affect the original binding element. Next time: Writing Channel Manager Essentials Read More...
|
-
Last time, we left off the channel construction process at the end of the design stage. During the design stage, everything is still in an unmolded and configurable state. At the end of the design stage, the construction process flips from a configuration mode to a runtime mode. The runtime stage has fixed all of the design settings and is in an operational state. Here were the products so far in the construction process starting from the service. Service Service endpoint Service endpoint contract Service endpoint transfer contract (binding) Binding design settings Realization of binding design settings (binding elements) From the binding elements we can produce two objects called channel managers. A channel manager is something that can produce communication channels on demand. One type of channel manager is the channel factory. Channel factories create communication channels that initiate a connection or message send. The other type of channel manager is the channel listener. Channel listeners create communication channels in response to a message or connection attempt. Channel factories generally live in client applications and channel listeners generally live in service applications. The channel manager is the first product in the construction process that performs network operations and can represent a network object. For example, channel managers may contact security servers in preparation for creating communication channels or allocate resources such as a TCP listener socket. The creation of communication channels is controlled by the user for channel factories and essentially controlled by the system for channel listeners. You have to initially start the channel listener but further action is taken in response to messages or connections arriving from other machines. Communication channels are the conduits for sending and receiving messages. The final product of the construction process is one of these channels. For those of your following along, that means to produce a custom channel you will need to write the binding, the binding element, the channel managers, and the channel. All of these were included in the channel writing checklists (the binding was the only one on the optional checklist). When we get to the next two articles in the tour series, the coverage will be on writing the binding element and channel managers. Next time: Responding to GetProperty Read More...
|
-
Let's fill in some of the spaces around yesterday's checklist with a list of additional features for a custom channel. Nothing that's been added to this list is required to actually send or receive messages. By doing the things listed here, you can enable some additional scenarios and make your channel easier to use. However, if you're looking to write a channel as cheaply as possible, then these are the features that you might consider cutting. I'll summarize the previous list using italics and interlace the descriptions of the new checklist items. Understand why you're writing a channel. Identify whether the channel you need is a protocol channel or a transport channel. Identify the channel shapes that your channel needs to be able to surface. Write a binding element so that your channel can plug into the build process. Add configuration support to your binding element. Configuration allows the settings of your binding element to be specified through XML files rather than through imperative code. You implement this configuration support by writing a binding element extension that duplicates the property settings of your binding element in a format that can be picked up by the configuration system. You will quickly grow tired of performing this duplication by hand and start thinking about how this process can be done automatically instead. Write a standard binding that demonstrates the proper usage of your binding element. A standard binding represents the stacks of binding elements for your core scenarios along with the most commonly used configuration settings for those binding elements. Creating a standard binding allows people to frequently make use of your channel without having to write a custom binding of their own. Support generating and consuming policy assertions that describe the capabilities of your binding element. Policy assertions allow you to advertise particular features of your channel so that the two sides can coordinate ahead of time about how the channel stack should be constructed. Policy support is implemented through a pair of interfaces for policy import extensions and policy export extensions. Write a client channel factory that can produce instances of your channel for use by client applications. Write a service channel listener that can produce instances of your channel for use by service applications. Write channel instances to cover each of the supported channel shapes. For transport channels, add a description of your supported Read More...
|
-
This pair of articles marks the checkpoint between the "big picture" introductory segments and the segments where we actually start getting down into the code. The transition is going to be gradual so there's still some philosophy left, particular around the construction of bindings and binding elements. However, the objective of the articles is going to be less about how to think about the system and more about how to think about the code. Here, we get into a checklist of the bare minimum necessary to write a channel. The first few items come from past topics, and you can use the rest as a roadmap of where we're going to go next. Understand why you're writing a channel . Forever more in this series, I'm assuming that you've looked at the other extensibility points and decided that writing a channel is the best way to solve your problem. Identify whether the channel you need is a protocol channel or a transport channel . Identify the channel shapes , one or more, that your channel needs to be able to surface. Write a binding element so that your channel can plug into the build process. The binding element is going to take one of the supported channel shapes and return the factory object that produces channels. Writing a binding is not required as you can always use your binding element in a custom binding. The binding element is also going to hold all of the configurable settings for your channel. Write a client channel factory that can produce instances of your channel for use by client applications. If you have an integration scenario where you're only writing channels for use in a web service, then you can skip this step. For example, if the client is going to be a web browser that doesn't use WCF, then you might not ever have a need to create client channels. Write a service channel listener that can produce instances of your channel for use by service applications. If you have an integration scenario where you're only writing channels for use in a client, then you can skip this step. For example, if you are trying to communicate with an existing mainframe service, then you're only going to produce channels to bridge the connection between WCF and the other system. Write channel instances to cover each of the supported channel shapes. I think it's easier to have separate classes for each channel shape that all use a central communication library. However, you may find it easier to implement multiple channel shapes in a single class. I've put the channel Read More...
|
-
I was looking through the archives the other day and found that the original article on channel shapes is actually still accurate despite having come out a year ago. It's interesting to step forward in time and watch as things become more and more like what actually was released. I've done similar walks through a longer history of the product, although you have to patiently track through whole concepts appearing and disappearing. In celebration of this bit of history, I decided to let last year's article stand. I did have a new picture in the channel dev tour drawing style that I wanted to include though. Update : I'm not sure when the count got off track, but this article turned out to be a day later than one year. Fortunately, now that the product is out, the things that I'm writing about are unlikely to change on a daily basis. Next time: Extracting Content Types Read More...
|
-
In the channel development series last week, we looked at the characteristics of channels (protocol channels, transport channels, and why you would write a channel at all). Let's use a specific example to illustrate those points. Although the protocol for reliable messaging is quite complex, the basic intent of the channel can be described quite simply. We'll keep the discussion simpler by only talking about the send side of the server response. You can map this yourself to the client side or to receiving messages, but this example doesn't need a lot of details to get the point across. Here's a channel stack that contains the reliable messaging channel. When the server sends a message out to the client, that message passes through the upper protocol channels in the channel stack. Those protocol channels can create, alter, or destroy messages along the way, but let's say that the message arrives intact to the reliable messaging channel. The reliable messaging channel first makes a copy of the message just in case delivery fails in the future. The reliable messaging channel then sends the message down through the remaining protocol channels. Again, we'll assume that nothing happens along the way; the message gets to the transport and is sent over the network. Sometimes, despite the best efforts of this process, the client never receives the message. In that case, the reliable messaging channel will produce another copy of the message from its store and send it again. Eventually, the client will either acknowledge receipt of the message or the two sides will decide to give up due to their inability to communicate. When the message is acknowledged, the reliable messaging channel throws its copy away as the message is no longer needed. Let's check against the criteria for writing channels to see if a channel was really needed to perform reliable messaging. Did we need a new component that interfaces with the network? No, there was some other component in the channel stack that handled the network for us. Did we need to establish a pattern of message exchange? Yes, the pattern of retries and acknowledgement is something that's different from the exchange inherent in a service call. Did we need to have a protocol for expressing the messages? Yes, although we didn’t talk about the details of that protocol in this example. We need some way of describing what data is, what acknowledgments are, and when retries are occurring. Did we need something other than a one-to-one Read More...
|
-
Let's shift gears for a bit and talk about transport channels now as opposed to protocol channels. Everything that was said yesterday for channel stacks is still true when we add transport channels to the picture. Everything that was said yesterday for protocol channels is essentially going to be reversed. Here are the essential points that change when we move from protocol channels to transport channels. Protocol channels have two sides: an inner and an outer channel. Transport channels have one side. The inner end of the transport channel connects to the network. Obvious corollary : Protocol channels move messages up and down the channel stack. Transport channels move messages to and from the network. More obvious corollary : Every channel in the channel stack but the bottommost one is a protocol channel. The bottommost channel in the channel stack is a transport channel. Protocol channels work on messages that are XML InfoSets. Transport channels operate on a stream of bytes. As we go through the architecture, you'll notice that transport channels are the only time during messaging that we have actual bytes. This is a necessity as traditional networking interfaces, such as sockets, have no idea how to send an XML message. The only data type that these interfaces rationalize about is byte arrays. The transport channel is the component that is responsible for converting between XML messages and byte streams. There is a standard pattern for delegating this behavior from transports to an external component called a message encoder. A message encoder is an interface that allows third-party developers to plug conversion functionality into a transport. You can choose to either use or ignore this model, although I'd strongly suggest supporting encoders if your transport permits multiple byte encodings for an XML message. The transport channel is also responsible for doing any post-processing on the byte stream. For example, there is a common step called framing in which the payload data is embedded inside a structured format for sending messages. Unlike message encoders, there is no standard interface for applying framing to a byte stream. The current transports that support framing build their framing protocol directly into the transport channel. We're going to take a break from the channel development series for a day tomorrow. When we come back, there will be some catch-up for illustrations and then we go directly into the second topic to overview WCF architecture. Read More...
|
-
There are only two kinds of channels in the world. Today we'll talk about protocol channels. Tomorrow we'll talk about transport channels. Transport channels move data to and from the network Protocol channels move data between the application and transport channel The name "protocol channel" for the second group is a lie. Of the channels we shipped in the product, the most common representative for the second group happens to be protocols. That doesn't mean that every channel in the second group has to an implement a protocol though. The key distinction for the second group is really "moves data between the application and transport channel". In other words, the second group is made up of everything that is not a transport channel. However, if you're following the advice from yesterday about when to write a channel, then I think you'll find that most of the channels that you write are either transport channel or implement some kind of protocol. A channel has two ends to it. The outer end points to the application. The inner end points to the network. If you start stitching together channels end-to-end, you come out with something called the channel stack. The inner end of one channel links to the outer end of another channel. In relative terms, these are the inner and outer channels of the channel that we're looking at. Obviously, we run into a problem if we keep following down the path of inner (or outer) channels. If we follow down the path of inner channels, eventually we'll hit a channel that has no other channel on the inner end to pass data to. That innermost channel is the transport channel that we'll talk about tomorrow. If we follow up the path of outer channels, eventually we'll hit a channel that has no other channel on the outer end to pass data to. Beyond the outermost channel is the application. In between the outermost channel and user code is a large mass called the service model. We'll have a brief look at the architecture of the service model in a few days. Otherwise, there's nothing particular distinctive about the outermost channel. Every channel along the way, except the innermost channel, is a protocol channel. The job of a protocol channel is to pump data between its inner and outer sides. That data is a structure called the XML InfoSet . An infoset is a standardized concept but really you don't have to understand the standard to make use of it. The pump that acts on these infosets is any arbitrary code you care to write. As a channel Read More...
|
|
|
|