|
|
Browse by Tags
All Tags » Indigo (RSS)
-
How do I find the address of a client connection to make a trust decision? Don't base security decisions on the perceived client address. Any address that we have comes from the underlying socket implementation and could be spoofed. The data that the socket has is sourced by the client. You should be using a source of information that has a verification process that the server trusts, such as a certificate, to distinguish clients. Next time: Reader Trends Read More...
|
-
Looking for a guide to all of the web services protocols implemented by WCF? There's no single document that captures all of the information, but there is a group of documents that talk about the implemented protocols and some of the choices in those implementations. The level of detail varies from document to document as a few are high-level summaries across areas of the product while others are low-level details of a particular protocol. Web Services Protocols Interoperability Guide Web Services Protocols Supported by System-Provided Interoperability Bindings Messaging Protocols Data Contract Schema Reference WSDL and Policy Security Protocols version 1.0 Security Protocols Reliable Messaging Protocol version 1.0 Reliable Messaging Protocol version 1.1 Transaction Protocols version 1.0 Transaction Protocols Context Exchange Protocol Mixing Trust Protocols in Federated Scenarios Next time: Help with Security Programming Read More...
|
-
Where can I get the IContextChannel that OperationContextScope requires? OperationContextScope allows you to create a temporary scope in which context for a service operation can build up before and after the operation is actually called. The constructor for OperationContextScope takes an instance of IContextChannel, which is a type that you've probably never seen before. Why are you expected to have this unknown type? It's because you have instances of it floating around all the time even though there's no particular hint of this. There are different ways to get an IContextChannel depending on whether you're using a proxy generated by svcutil or a proxy generated at runtime. In either case, pretend that I've got service contract called IService with a single method called Foo. When I generate a service client using svcutil, the client object has a member called InnerChannel that works as an IContextChannel. ServiceClient client = new ServiceClient(binding, new EndpointAddress(address)); using ( new OperationContextScope(client.InnerChannel)) { WebOperationContext.Current.OutgoingRequest.Headers[ "X" ] = "from compiled proxy" ; client.Foo(); } client.Close(); Otherwise, if I'm using a ChannelFactory to create the proxy at runtime, the channel that I get back happens to be an IContextChannel as well. ChannelFactory<IService> factory = new ChannelFactory<IService>(binding); factory.Open(); IService proxy = factory.CreateChannel( new EndpointAddress(address)); using ( new OperationContextScope((IContextChannel)proxy)) { WebOperationContext.Current.OutgoingRequest.Headers[ "X" ] = "from runtime proxy" ; proxy.Foo(); } factory.Close(); Next time: Standards Guide Read More...
|
-
Over the past few days Tom Hollander has been posting his experiences hosting a queue-based WCF service in IIS. These posts go into a lot of detail about setting up the machines, configuring the service, and troubleshooting problems. If you're looking for a step-by-step guide, this is a great resource. MSMQ, WCF and IIS: Getting them to play nice (Part 1) MSMQ, WCF and IIS: Getting them to play nice (Part 2) MSMQ, WCF and IIS: Getting them to play nice (Part 3) Read More...
|
-
Some tips for building support for versioning into the naming of data contracts. First, the primary route for versioning should be through the namespace part of the contract rather than the member name part of the contract. Versioning the contract through member names tends to leak across the service boundary more forcefully. The programming experience of the service often makes a member name directly visible while a namespace is more or less invisible. Second, choose a single consistent scheme for identifying the version. Two popular schemes are the date of the contract and a sequential numbering system of major and minor versions. Both schemes provide the basic element required of a versioning identity, which is an unambiguous total order among the different versions. However, multiple schemes should not be mixed together for a single contract and preferably not for a single system as well. The date scheme, http://company.com/year/month/name, has issues around granularity but can be very evocative since you probably already associate dates in your mind with other events. The issue with granularity is that you have to plan ahead for a maximum update frequency. In the previous example, two updates in the same month would collide with the same name, suggesting that a contract that is updated frequently might include additional levels of refinement, such as the day of the month. However, unnecessarily fine granularity makes the name cumbersome. The numbering scheme, http://company.com/major/minor/name, gives less of a clue about what the version corresponds to but has fewer issues with granularity. Updates can happen as frequently as you want since you can just keep picking new numbers. However, you still have to give some thought to granularity when deciding how many numbering components to include. For example, a single version number may be sufficient if no distinction is needed between major and minor updates. Next time: Finding a Client Channel Read More...
|
-
Simplicity is elusive. A few weeks ago I learned that part of transaction flow, propagating information about the source machine between the client and server, is more complicated than I thought. It's not that the details were inherently complicated but rather that they were inconsistent. The information was passed in a certain header of the message, except when using a particular transaction protocol and transport protocol together. Someone noticed that a few bytes could be saved by optimizing this particular combination and in that case put the information in a different header in a different format. Efficiency was achieved at the cost of forcing everyone trying to understand the protocol to think harder about it. Most of the protocols that have stood the test of time on the web have sacrificed efficiency to achieve simplicity. Consider all of the protocols out there that are large, bloated, and redundant but easy to think about and tolerant to misunderstandings. What keeps them alive against their slimmer and more advanced competition other than that they were able to attract many people to speak them? Next time: Naming Contracts for Versioning Read More...
|
-
Host headers in IIS are a way to associate multiple names with a single address. The typical use of host headers is to be able to host more than one web site at a single IP address by giving each of the web sites a distinct DNS name. Host headers also play a role in WCF beyond the definition of a web site. Metadata for a web service, such as that appearing WSDL, uses host headers as a way to pick a preferred name when talking about the service. The user interface for setting host headers is relatively straightforward when the web site is hosted over HTTP but becomes a challenge when the web site is hosted over HTTPS. Here are the command line equivalents that you can use to set HTTPS host headers. On IIS 6, you need to know the id of the web site. Assuming that SSL is taking place on the default port, the command looks like this. cscript.exe adsutil.vbs set w3svc/<id>/SecureBindings ":443:<header>" On IIS 7, the command line looks very different due to the more flexible but complicated support for different web site bindings. You can also use a name that's meaningful for you to distinguish web sites. appcmd set site /site.name:<name> /+bindings.[protocol='https',bindingInformation='*:443:<header>'] To keep the example simple, I'm assuming that you're adding a new binding rather than modifying an existing binding. Next time: Transaction Header Magic Read More...
|
-
Yesterday I talked about adding SOAP headers to an outgoing request using a variety of different methods. The most straightforward method was to create an OperationContextScope in your application code to establish an OutgoingMessageHeaders collection. Although HTTP headers are similar in spirit to SOAP headers, manipulating an HTTP header through code looks a bit different. SOAP headers are elevated to a special significance in the programming model. Everything else, including HTTP headers, is relegated to a general-purpose but distinctly second-class collection of message properties. On the OperationContextScope you'll find a parallel OutgoingMessageProperties collection that can be used for HTTP headers. In Orcas, the plain OperationContext also works as a WebOperationContext that gives the same first-class programming model to HTTP headers as you get with SOAP headers. Here's a comparison of the two approaches. using ( new OperationContextScope((IClientChannel)proxy)) { HttpRequestMessageProperty requestProperty = new HttpRequestMessageProperty(); requestProperty.Headers[ "X-header" ] = "value1" ; OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = requestProperty; proxy.Operation(); } using ( new OperationContextScope((IClientChannel)proxy)) { WebOperationContext.Current.OutgoingRequest.Headers[ "X-header" ] = "value2" ; proxy.Operation(); } Next time: Configuring SSL Host Headers Read More...
|
-
How do I add SOAP headers to an outgoing request? There are a few different ways to add headers to a message depending on how you need to control the header content and where you need to insert the header. I like to think of these methods as being split among the application, the proxy, and the protocol. In your application code you can create an OperationContextScope around the request in order to change some of the request properties. Inside an OperationContextScope, you have a valid instance of OperationContext.Current, which allows manipulation of the message headers through the OutgoingMessageHeaders collection. Use of this method deeply bakes control of the headers into the application code. You would have to be responsible for copying the appropriate code wherever it was needed. Now, assume that you want the header to be present whenever you're talking to a particular service and the header value can be determined consistently. Rather than having to put the same code at each call site, you can centralize the code in the proxy or in a protocol. The simplest way to centralize header manipulation in the proxy is to create an instance of the IClientMessageInspector and attach that to the proxy. This gives you a hook for every message going through the proxy to modify the message headers. An instance of IChannel similarly gives you a hook for every message going through the channel stack to modify the message headers. Using the Message Interceptor sample gives you an extensibility point in the binding that is similar in spirit to the extensibility point provided by a message inspector. The primary difference from your perspective of a message inspector and a channel is a matter of timing. A message inspector always runs before any of the protocols in the binding while a channel can be positioned precisely in the protocol stack. In most cases you don't need precise positioning, so you should go with the simpler approach. Next time: Adding Headers to a Call (HTTP Version) Read More...
|
-
You will sometimes get an error message that mentions a timeout value. You can recognize these error messages by virtue of their containing a long and boring string of text followed by some numbers. The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'. In context, these numbers are exciting. This is primarily due to them being considered in immediate relation to a string of text that, as has previously been mentioned, is long and boring. Numbers are something that you can understand without having to read the rest of the text. Unfortunately, these numbers are most often not particularly helpful and should be ignored. When you see a timeout value in an error message, it is information about one of the call parameters. This isn't a statement that the timeout caused the error. It is a hint to help you think about what might have caused the error. If the timeout value says 1 minute and you see the error after 3 seconds, then the timeout value is probably unrelated to the error. If you find yourself waiting for quite a while and then see a timeout value for a shorter interval than you waited, then the timeout value may have some connection to the error. Often, this connection is that you should go looking for something else that went wrong because the thing that went wrong was supposed to have finished what it was doing before the timeout expired. Next time: Adding Headers to a Call Read More...
|
-
Starting last month, MSDN put together a regular series of webcasts on WCF and WF (focusing on .Net 3.5). Here are the talks being broadcast in July:
July 7th, 10:00AM (PST) Transactional Windows Communication Foundation Services with Juval Lowy
July 9th, 10:00AM (PST) Using Windows Workflow Foundation [...] Read More...
|
-
Four more webcasts are coming this month to talk about some of the new web service features in Orcas. Each webcast is aimed at developers and lasts 60-90 minutes. Transactional Windows Communication Foundation Services with Juval Lowy (Level 200) Monday, July 07, 2008 10:00 AM Pacific Time Transactions are the key to building robust, high quality service-oriented applications. Windows Communication Foundation (WCF) provides a simple, declarative transaction support for service developers, enabling you to configure parameters such as enlistment and voting, all outside the scope of your service. In addition, WCF allows client applications to create transactions and to propagate transactions across service boundaries over a variety of transports. In this webcast, we explain how to configure transaction flow at the binding, contract, and service level, local versus distributed transactions, setting of service transactions, declarative voting, and the available configurations that best fit various application scenarios. Using Windows Workflow Foundation to Build Services with Jon Flanders (Level 300) Wednesday, July 09, 2008 10:00 AM Pacific Time Windows Workflow Foundation (WF) is a programming model, set of tools, and runtime environment which allows you to write declarative and reactive programs for Windows operating systems. WF is part of the Microsoft .NET Runtime, and it first appeared in Microsoft .NET 3.0. Windows Communication Foundation (WCF) is also a programming model, set of tools, and a runtime that first appeared in .NET 3.0. WCF is a framework for building applications that can communicate with each other over varied network protocols. In .NET 3.5, these programming models came closer together to allow easy integration, including allowing WF instances to use WCF to communicate to remote endpoints and allowing WF instances to become the service implementation for WCF endpoints. This is accomplished by two new Activities: ReceiveActivity and SendActivity as well as a new hosting infrastructure for service endpoints. In this webcast, we look at both sides of this integration to give you an overview of how to build WF/WCF applications. WCF Extensibility Deep Dive with Jesus Rodriguez (Level 400) Friday, July 11, 2008 10:00 AM Pacific Time Windows Communication Foundation (WCF) provides a rich messaging framework that extends beyond its capabilities for modeling and implementing services. One of the aspects where WCF really shines when compared with competitive Read More...
|
-
I've been playing with the DataContractJsonSerializer that comes with Orcas recently to produce some JSON-based services. DataContractJsonSerializer works just like any other XmlObjectSerializer, except of course that the serialization output looks nothing like XML when written out. {"content1":"this is content","content2":"this is more content","version":1} If you attempt to push the serialized output through an XML reader or writer and examine it though, that works too through some simple but seemingly magical transformations that happen behind the scenes. < root type ="object" > < content1 > this is content </ content1 > < content2 > this is more content </ content2 > < version type ="number" > 1 </ version > </ root > This transformation trick is one that we've used elsewhere as well to give the appearance of a consistent and highly-structured set of data formats while not actually incurring the costs of that structure. That led me to start trying to observe when the simpler structure of JSON actually provides a performance advantage over the standard DataContractSerializer. I've found that while JSON wins in terms of size, it doesn't always win in terms of serialization speed. Here were the observations that I made. DataContractJsonSerializer tended to be faster for small and simple workloads. When the number of types was small and the types didn't have very many members, DataContractJsonSerializer could beat DataContractSerializer by 25%. This was most often true when the bulk of the object data was string content. On the other hand, DataContractSerializer caught up and then started winning as the types got more complicated. I also noticed that there were some primitive types, such as floating-point numbers, where DataContractSerializer always had a significant advantage. DataContractSerializer could turn a 25% loss into a 25% win just by changing several of the fields of a small type to doubles. This shows that performance is a very hard thing to predict without taking measurements. I would have expected DataContractJsonSerializer to consistently win given the simpler and smaller output format but I was able to find several data contracts taken from popular services for which that wasn't true. Next time: Timeout Error Messages Read More...
|
-
What does the InactivityTimeout on a secure channel do? The inactivity timeout on a message security channel controls how long the channel will allow pending security sessions to linger in its cache before giving up on them. This is completely different from the inactivity timeout on a reliable messaging channel, which controls how long the reliable session will live without an infrastructure message before being torn down, and the inactivity timeout in the application, which controls how long the service instance will live without an application message before being torn down. Next time: JSON Service Speed Read More...
|
-
WebServiceHost is a new feature in Orcas that makes it easy to put up simple web services that are built on HTTP and POX. However, there's no requirement that forces you to build REST and POX services using WebServiceHost. WebServiceHost exists to make a simple case easy, but you're not locked into using that approach if the simple case doesn't apply to you. Here's everything behind WebServiceHost if you want to build your own. WebServiceHostFactory exists to bootstrap WebServiceHost when building a web site in IIS WebServiceHost disables any service metadata or help pages so that they don't steal any part of the URI space under your web site WebServiceHost generates endpoints for all of your contract types with a WebHttpBinding so that you don't have to describe the service endpoints in a configuration file WebServiceHost adds a WebHttpBehavior to all of your service endpoints so that Get and Invoke operations in your service contract work without any additional setup Next time: Security Session Inactivity Read More...
|
|
|
|