Welcome to Windows Communication Foundation (WCF)
Top Tasks :

Browse by Tags

All Tags » Service Model   (RSS)
Showing page 1 of 7 (69 total posts)
  • Avoiding Infinite Schema Chains

    I was working on some services with recursive data structures when I noticed that there were a few cases where I would get crashes while trying to generate proxy classes. The problems seemed to be around types that were a sequence of instances of themselves. That looks like this: < xs:schema xmlns:tns ="http://test" targetNamespace ="http://test" xmlns:xs ="http://www.w3.org/2001/XMLSchema" > < xs:complexType name ="CircularList" > < xs:sequence > < xs:element minOccurs ="0"
    Posted to WCF Team Bloggers (Weblog) by Anonymous on August 27, 2008
    Filed under: Indigo, Service Model, Proxies, Serialization
  • AutoHeader Extension

    I frequently get asked how to add a header to every outgoing request so I wrote up a quick reusable approach. This adds some extension methods to the IContextChannel class for working with auto-added headers. The headers are stored between calls in an IExtension. public static class AutoHeaderExtension { class AutoHeaderContextExtension : Dictionary<XName, MessageHeader>, IExtension<IContextChannel> { public void Attach(IContextChannel owner) { } public void Detach(IContextChannel owner)
    Posted to WCF Team Bloggers (Weblog) by Anonymous on August 22, 2008
    Filed under: Indigo, Samples, Service Model
  • Streaming Web Content

    How do I deliver content from a WCF service as part of a web page? Web page content in this case typically refers to HTML, images, or other data that is directly consumed by the web browser rather than an application running in the web browser. There are a few things you need to do to make your web service serve up content in a way that's indistinguishable from an ordinary web server. I'll serve up a static image at a fixed location for this example but you can get as fancy as you'd like. The first
    Posted to WCF Team Bloggers (Weblog) by Anonymous on August 18, 2008
    Filed under: Indigo, HTTP, Answers, Service Model, Orcas
  • Using Faults with Untyped Messages

    When using a typed contract, incoming messages on the server are shredded on your behalf to be turned into method calls and parameters. Ordinarily, the particular method call selected for an application messages will have the same parameterized contract as the message. This allows the transformation between messages and parameters to be made with a high degree of fidelity. However, operations also permit fault responses in addition to the normal application response. The parameterized fault contract
    Posted to WCF Team Bloggers (Weblog) by Anonymous on August 15, 2008
    Filed under: Indigo, Messages, Faults, Service Model, Contracts
  • Getting Rid of Namespaces

    How do I write a contract for a wrapped message in the default namespace? I've written a quick sample to demonstrate what happens when you write the contract without taking any namespaces into account. [ServiceContract] public interface IService { [OperationContract] [WebInvoke(BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "/" )] void ProcessRequest( string data); } public class Service : IService { public void ProcessRequest( string data) { Console.WriteLine(OperationContext.Current.RequestContext.RequestMessage);
    Posted to WCF Team Bloggers (Weblog) by Anonymous on August 11, 2008
    Filed under: Indigo, Answers, Service Model, Contracts
  • System Types in Metadata

    It's bad practice to use system types when defining an operation contract. A system type is often a complex composition of primitive types that has no direct analog in other implementations. By using a system type, you bind your service to the particular implementation used by that type, which effectively ends any chance of having an easily interoperable service. For example, a contract containing an IPAddress seems innocuous. [OperationContract] string LookupHostName(IPAddress address); However,
    Posted to WCF Team Bloggers (Weblog) by Anonymous on August 5, 2008
    Filed under: Indigo, Service Model, Contracts, Proxies
  • Avoiding Address Filters

    The address filter mode that we looked at last time solved the problem of funneling all of the messages with a given prefix address to our service instance. Changing the filter mode still left us with the problem of dispatching from that universal contract to all of the logical operations that live inside the address space. This is exactly the problem that UriTemplate solves. By combining templates and WebServiceHost, both of the problems get taken care of for us. Here is an equivalent contract and
    Posted to WCF Team Bloggers (Weblog) by Anonymous on July 30, 2008
    Filed under: Indigo, HTTP, Service Model, Contracts, Orcas
  • Web Address Filters

    Here is a basic service that defines a universal contract to program against for building a simple HTTP application. The service doesn't do anything, but you can ignore that in this example. [ServiceContract] public interface IService { [OperationContract(Action = "*" , ReplyAction = "*" )] Message Request(Message msg); } public class Service : IService { public Message Request(Message msg) { Console.WriteLine( "{0} {1}" , WebOperationContext.Current.IncomingRequest.Method, msg.Headers.To); return
    Posted to WCF Team Bloggers (Weblog) by Anonymous on July 29, 2008
    Filed under: Indigo, HTTP, Service Model, Behaviors, Orcas
  • Finding a Client Channel

    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
    Posted to WCF Team Bloggers (Weblog) by Anonymous on July 18, 2008
    Filed under: Service Model, Indigo, Proxies, Answers
  • Naming Contracts for Versioning

    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
    Posted to WCF Team Bloggers (Weblog) by Anonymous on July 11, 2008
    Filed under: Service Architecture, Service Model, Indigo, Contracts
1 2 3 4 5 Next > ... Last »

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us