|
|
Browse by Tags
All Tags » Indigo » Documentation (RSS)
-
The Microsoft case study site is a collection of easily-digestible executive-style summaries of people using Microsoft products. While ordinarily this may not sound all that interesting, case studies are good sources of easily stealable material whenever someone asks you to justify why you're using a particular technology. Of course, finding the case studies about WCF in the collection is next to impossible as WCF is not in the case study product list and all of the relevant keyword searches produce either far too few or far too many results to be what you're looking for. Rather than making you search for case studies, I have a selected collection of case studies that deal strongly with WCF. I have filtered these case studies so that they all were published around the time that WCF was finished or later. Obviously though, many of the case studies will be based on prerelease software as it takes a considerable amount of time to complete a project and then complete the case study. Avaya Choicelinx Crutchfield FNAC Kiwibank Nike OPC Foundation OTTO Pfizer Schneider Electric ST Electronics Commonwealth of Massachusetts Thomson Financial Thomson Tax and Accounting Tyco Fire and Security Next time: Channel Factory Behaviors Read More...
|
-
This was a bug that we found a few weeks before V1 shipped but it was not deemed severe enough to fix at the time. I know that one customer has hit this while experimenting and it's pretty easy to understand what's going wrong once you hear the details. The bug affects the use of the reliable messaging channel with different message addressing versions. The reliable messaging channel captures a copy of the first set of headers it sees used for addressing in the application domain. Later, the channel replays those same headers any time it needs to use addressing again. If you have a second endpoint that creates a reliable messaging channel, then that channel will also use the cached headers. However, the other endpoint has a different binding and could be using a different version of message addressing. Having the wrong version of addressing headers typically results in a protocol fault complaining about the version mismatch. It seems unlikely that this would block development of a real application. You have to be using a custom binding to hit this because all of our standard bindings that support reliable messaging use the same addressing version. The workaround is that if you need to have multiple service endpoints that both use reliable messaging but have different message addressing versions, then you should create a new application domain to keep the endpoints separate. Next time: Manually Injecting a ListenUri Read More...
|
-
Fault messages have their own quota sizes, allowing you to limit the amount of data you'll process in response to an error. Existing transport protocols don't know about SOAP fault messages, but some of them have their own error reporting mechanisms that we use for similar purposes. HTTP lets you send back error responses, and there is a similar quota setting for HTTP web requests that let you bound the size of the response. The point of writing this is that the translation doesn't always go smoothly between these quota systems. Our SOAP quotas are measured in bytes while the HTTP quotas need to be rounded up in size to the next largest value measured in kilobytes. Someone recognized that this means that there's a potential for integer overflow in the conversion and so handled that case specially. We take the maximum buffer size and use that to bound your maximum HTTP error size. For buffered transfers, the maximum buffer size is the same thing as the maximum received message size while for streamed transfers, the total message can span many buffered transfers. Unfortunately, the way that overflow is avoided in the computation causes the HTTP quota to not be set in that case. This means that if your maximum buffer size is within 1 KB of Int.MaxValue, the maximum error size doesn't get increased. There's a couple of solutions that you can use here. The default allowed error size is 64 KB so this bug doesn't matter at all if your error messages are smaller than this size. From a practical perspective, there isn't much difference between using Int.MaxValue or a slightly smaller value for the buffer size, so you can avoid the bug by reducing your maximum buffer size by 1025 bytes. It's also possible to directly set the default maximum error size. This is the DefaultMaximumErrorResponseLength setting of HttpWebRequest. Changing this value affects all HTTP traffic in your application, but if you know what your maximum limit is, you can set this and we won't ever use a smaller value. Next time: Reader Mail Read More...
|
-
I'm presenting a small sample I wrote to demonstrate the port sharing feature. The third part is the test client and example usage. I'm looking for feedback to help make the sample better. Right now, the sample configures the endpoints in code rather than configuration because it uses randomly-generated addresses for the server. I may just tack on the configuration details at the end because other port sharing topics already cover that material. You can use the test client to check that messages are correctly routed to services sharing the port. class client { static void Main( string [] args) { Console.Write( "Enter the service number to test: " ); ushort salt = ushort .Parse(Console.ReadLine()); string address = String.Format( "net.tcp://localhost:5555/calculator/{0}" , salt); ChannelFactory<ICalculator> factory = new ChannelFactory<ICalculator>( new NetTcpBinding()); ICalculator proxy = factory.CreateChannel( new EndpointAddress(address)); // Call the Add service operation. double value1 = 100.00D; double value2 = 15.99D; double result = proxy.Add(value1, value2); Console.WriteLine( "Add({0},{1}) = {2}" , value1, value2, result); // Call the Subtract service operation. value1 = 145.00D; value2 = 76.54D; result = proxy.Subtract(value1, value2); Console.WriteLine( "Subtract({0},{1}) = {2}" , value1, value2, result); // Call the Multiply service operation. value1 = 9.00D; value2 = 81.25D; result = proxy.Multiply(value1, value2); Console.WriteLine( "Multiply({0},{1}) = {2}" , value1, value2, result); // Call the Divide service operation. value1 = 22.00D; value2 = 7.00D; result = proxy.Divide(value1, value2); Console.WriteLine( "Divide({0},{1}) = {2}" , value1, value2, result); Console.WriteLine(); Console.WriteLine( "Press <ENTER> to terminate client." ); Console.ReadLine(); factory.Close(); } } Each instance of the service will print out its unique number and address. For instance, you may see the following text when you run service.exe. Service #4381 listening on net.tcp://localhost:5555/calculator/4381. Press <ENTER> to terminate service. Enter the service number you see here when you run client.exe. Enter the service number to test: 4381 Add(100,15.99) = 115.99 Subtract(145,76.54) = 68.46 Multiply(9,81.25) = 731.25 Divide(22,7) = 3.14285714285714 Press <ENTER> to terminate client. Next time: More Binding Polymorphism Read More...
|
-
I'm presenting a small sample I wrote to demonstrate the port sharing feature. The second part is the server application. I'm looking for feedback to help make the sample better. Right now, the sample configures the endpoints in code rather than configuration because it uses randomly-generated addresses for the server. I may just tack on the configuration details at the end because other port sharing topics already cover that material. The following code demonstrates enabling port sharing on the server. It starts an instance of the ICalculator service on a fixed port with a random URI path. Even though two services can share the same port, their overall endpoint addresses still need to be unique so that the Net.Tcp Port Sharing Service can route messages to the correct application. // Define a service contract [ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples" )] public interface ICalculator { [OperationContract] double Add( double n1, double n2); [OperationContract] double Subtract( double n1, double n2); [OperationContract] double Multiply( double n1, double n2); [OperationContract] double Divide( double n1, double n2); } // Service class that implements the service contract public class CalculatorService : ICalculator { public double Add( double n1, double n2) { return n1 + n2; } public double Subtract( double n1, double n2) { return n1 - n2; } public double Multiply( double n1, double n2) { return n1 * n2; } public double Divide( double n1, double n2) { return n1 / n2; } } class service { static void Main( string [] args) { // Configure a binding with TCP port sharing enabled NetTcpBinding binding = new NetTcpBinding(); binding.PortSharingEnabled = true ; // Start a service on a fixed TCP port ServiceHost host = new ServiceHost( typeof (CalculatorService)); ushort salt = ( ushort ) new Random().Next(); string address = String.Format( "net.tcp://localhost:5555/calculator/{0}" , salt); host.AddServiceEndpoint( typeof (ICalculator), binding, address); host.Open(); Console.WriteLine( "Service #{0} listening on {1}." , salt, address); Console.WriteLine( "Press <ENTER> to terminate service." ); Console.ReadLine(); host.Close(); } } With port sharing enabled, you can run the service multiple times without having a conflict over the port number. If you were to change the code to disable port sharing, starting up two copies of the service would result in the second failing with an AddressAlreadyInUseException. Unhandled Exception: System.ServiceModel.AddressAlreadyInUseException: Read More...
|
-
For the next few days I'm going to present a small sample I wrote to demonstrate the port sharing feature. The first part presents background information about the feature. I'm looking for feedback to help make the sample better. Right now, the sample configures the endpoints in code rather than configuration because it uses randomly-generated addresses for the server. I may just tack on the configuration details at the end because other port sharing topics already cover that material. The TCP/IP protocol uses a 16-bit number, called a port, to differentiate connections to multiple network applications running on the same machine. If an application is listening on a port, then all TCP traffic for that port goes to that application. Other applications cannot listen on that port at the same time. Many protocols have a standard or default port number that they use. For example, the HTTP protocol typically uses TCP port 80. Internet Information Services (IIS) has a listener to share a port between multiple HTTP applications. IIS listens on the port directly and forwards messages to the appropriate application based on information inside the message stream. This allows multiple HTTP applications to use the same port number without having to compete to reserve the port for receiving messages. Net.Tcp Port Sharing is a Windows Communication Foundation (WCF) feature that similarly allows multiple network applications to share a single port. The Net.Tcp Port Sharing Service accepts connections using the net.tcp protocol and forwards messages based on their destination address. The Net.Tcp Port Sharing Service is not enabled by default. Before running this sample, you will need to manually enable the service. For more information, see How to: Install and Configure Port Sharing (this is another document in the SDK but it looks like it's still being written so I'm not making this a link). If the service is disabled, an exception will be thrown when the server application is started. Unhandled Exception: System.ServiceModel.CommunicationException: The TransportManager failed to listen on the supplied URI using the NetTcpPortSharing service: failed to start the service because it is disabled. An administrator can enable it by running 'sc.exe config NetTcpPortSharing start= demand'.. ---> System.InvalidOperationException: Cannot start service NetTcpPortSharing on computer '.'. ---> System.ComponentModel.Win32Exception: The service cannot be started, either because it Read More...
|
-
This is the last planned article in a documentation series covering various aspects of Windows Communication Foundation transports. Today's topic covers how to choose a transport and associated encoder. Choosing a Transport The Windows Communication Foundation (WCF) programming model separates the behavior of endpoint operations from the transport mechanism that connects two endpoints. This gives you flexibility when deciding how your services should be exposed to the network. Transports and message encoders are pieces of WCF that sit below a service to provide connectivity. This document discusses some of the characteristics you need to evaluate when choosing a transport and message encoding. In scenarios where you must connect to a preexisting client or server, you may not have a choice about using a particular transport and message encoding. However, WCF services can be made accessible through multiple endpoints, each with a different transport or message encoding. When a single selection does not cover the entire intended audience for your service, you should consider exposing your service over multiple endpoints. Client applications can then choose the endpoint that is most favorable for them. Using multiple endpoints allows you to combine the advantages of different transports and message encoders. Transports and Message Encoders In WCF, the transfer of data across a network requires the joint cooperation of a transport and message encoder. A message encoder converts a System.ServiceModel.Channels.Message to a serialized form. This document covers the Text, Binary, and MTOM message encoders that are included in WCF. The text message encoder supports both a plain XML encoding as well as SOAP encodings. The plain XML encoding mode of the text message encoder is called the POX encoder to distinguish it from the text-based SOAP encoding. A transport sends the serialized form of the message to another application. This document covers the HTTP, TCP, and named pipe transports that are included in WCF. WCF provides several standard bindings that combine a transport, message encoder, and other options. For instance, the BasicHttpBinding binding combines the HTTP transport with a text message encoder. Similarly, the NetTcpBinding binding combines the TCP transports with a binary message encoder. You are not limited to choosing a preset combination given by a standard binding. Decision Points for Choosing a Transport The following table describes several decision Read More...
|
|
|
|