|
|
Browse by Tags
All Tags » Service Model » Indigo (RSS)
-
One concept that sometimes confuses ASP.NET developers when moving to WCF is the notion of session state. In ordinary WCF services, all of the session state is stored in local volatile memory. The application has to choose to copy over a portion of the session state to a durable storage location for that state to be preserved across running instances. WCF doesn't come with a built-in option for enabling persistent storage of session state or enabling access to the session state from other processes. There are a couple ways to make WCF more like ASP.NET. One way to make WCF more like ASP.NET is to make WCF exactly like ASP.NET by turning on ASP.NET compatibility mode. A WCF application that is hosted in IIS and uses HTTP as a transport binding runs together with the ASP.NET pipeline but does not have access to many of the ASP.NET features. Turning on compatibility mode integrates the WCF application with the ASP.NET pipeline and makes many of those features available. Obviously, this approach is only interesting when your WCF service is already very much like an ASP.NET application. Another way to make WCF more like ASP.NET is to change the management of WCF session state to use remote durable storage rather than local volatile memory. This approach is more like the one used by workflow services to create durable applications. The management of service instances and instance contexts is controlled by the IInstanceProvider that creates and destroys service objects, the IInstanceContextProvider that creates and destroys instance contexts, and the IInstanceContextInitializer that sets up newly acquired instance contexts. Although durable services have different semantics than session state, there are common building blocks that can be used for both. Next time: Diagnosing Common Queue Errors Read More...
|
-
I have a schema file that describes a choice between multiple layout formats for a type. How do I build a proxy that matches this schema? The reason that this is probably not working is because DataContractSerializer for the most part does not support ambiguous, optional, or multiply-described sections of types. Using svcutil and specifying the serializer to be XmlSerializer is more likely to generate the expected proxy type. Here's a rough guide to what DataContractSerializer does not support for complex type content. If you're using any of these features in your schema, then it's likely that you'll need to use XmlSerializer instead. Attributes (pretty much everything related to attributes including groups and wildcards) Group, all, or choice selections Extensions or restrictions of simple content (except for restrictions from anySimpleType) Sequences that are optional or repeating (minOccurs or maxOccurs not equal to 1) Sequences that contain other sequences or wildcard content Next time: Using ETW Tracing Read More...
|
-
How do I specify that the client proxy should not have a setter for a particular data member? It doesn't make sense for the service to be able to dictate what the client can do with a piece of data. Once data has been put on the wire, you can't stop the other side that is receiving the message from doing whatever they want with that data. Schema and metadata don't have any notion of access modifiers, but let's say that they did. You might say in the metadata that a certain piece of data has restricted access. First, there's nothing requiring me to use the same metadata and tools that you are, so I may not even know about your access modifiers. The representation that gets written to the wire is the truth about how your service works, not the metadata. Second, even if I am using the same metadata and tools as you are, I can always change the client after it's created because the generated code is something that I own rather than you as the service author. If the client author and the service author are the same person, then there are much more effective ways of providing a preferred programming model than trying to describe those preferences through some aspect of the service description. Instead, just change the client library directly to do what you want and give people that. Next time: Certificate Stores Read More...
|
-
Orcas introduced a new DateTimeOffset class that is easier to use for representing absolute times than the original DateTime class. However, if you run svcutil on a contract that contains a DateTimeOffset, you'll get an ugly generated structure because DateTimeOffset isn’t recognized as a natively supported type by the system. A new class is generated by svcutil to match the schema for DateTimeOffset in the metadata. namespace System { using System.Runtime.Serialization; [DebuggerStepThroughAttribute()] [GeneratedCodeAttribute( "System.Runtime.Serialization" , "3.0.0.0" )] [DataContractAttribute(Name= "DateTimeOffset" , Namespace= "http://schemas.datacontract.org/2004/07/System" )] public partial struct DateTimeOffset : IExtensibleDataObject { private ExtensionDataObject extensionDataField; private DateTime DateTimeField; private short OffsetMinutesField; public ExtensionDataObject ExtensionData { get { return this .extensionDataField; } set { this .extensionDataField = value ; } } [DataMemberAttribute(IsRequired= true )] public DateTime DateTime { get { return this .DateTimeField; } set { this .DateTimeField = value ; } } [DataMemberAttribute(IsRequired= true )] public short OffsetMinutes { get { return this .OffsetMinutesField; } set { this .OffsetMinutesField = value ; } } } } There's a new option on svcutil, /targetClientVersion:Version35, that can be used to indicate that code generation should use new features in Orcas. As far as I know, there are three places where this option makes a difference. DateTimeOffset is automatically added as a known type when referenced Asynchronous methods are generated using the Orcas event-based asynchronous model Additional LINQ types are supported during schema import for XmlSerializer Next time: Read Only Data Members Read More...
|
-
When I create a channel to a service, how do I know when the service is ready to process the data for that channel? A channel doesn't really know what the service is doing. The service might be actively processing the data being sent over the channel. Or, the service might not. There is a constant tension in the system between components that want to push data and components that want to pull data. Components that push data actively work as long as there is data available until a back pressure builds up in the system that resists their ability to push. This back pressure is typically the result of some queue or buffer that has filled up and is no longer able to accept the things being pushed into it. Components that push include several transport and protocol channels, as well as the service dispatcher that pushes messages to the service implementation. Components that pull data remain quiescent even if data is available until there is someone that actually wants to consume some data. Many transport and protocol channels pull messages rather than push. A single implementation may feature both push and pull modes. For example, the TCP channel has a small portion that works in a push mode for connection establishment and transferring some initial data while the application portion of TCP works in a pull mode. Depending on the visibility of these push and pull modes, you might be able to tell from the behavior of a particular protocol what the service is doing. For example, if you're using just TCP, then the initial transmissions needed to open a connection can only be completed once a little bit of pulling has been done on the receiving application side, thus telling you that the service is doing some active processing. On the other hand, if you're using a ReliableMessaging channel or a OneWay channel, then those protocols have a visible running state where they are in push mode. You can't actually tell whether the service is working until you fill up some of the buffers in the protocol stack and start getting push back in the form of rejected messages. That means the service is not working as fast as you're sending data. A queued channel would be an extreme example of push mode. A message queue allows you to push large amounts of data when the service is not even running. Therefore, to know in the general case whether the service is ready to process for you, you need to be able to ask that question to the service rather than to the channel. Next time: Composing Read More...
|
-
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" maxOccurs ="unbounded" name ="CircularList" nillable ="true" type ="tns:CircularList" /> </ xs:sequence > </ xs:complexType > < xs:element name ="CircularList" nillable ="true" type ="tns:CircularList" /> </ xs:schema > When using message contracts I was able to fix the problem by moving the minOccurs and maxOccurs from the element to the containing sequence. This didn't change the meaning of the type when I examined the proxy. With data contracts, trying the same fix caused proxy generation to go into an infinite loop rather than crash, but that's not much of an improvement. The data contract serializer worked best when I defined an intermediate type to represent the sequence rather than directly including the list type in itself. These all look like bugs with schema analysis. Next time: Waiting for Ready Channels Read More...
|
-
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) { } } public static void AddAutoHeader( this IContextChannel proxy, string name, string ns, object value ) { AutoHeaderContextExtension extension = proxy.Extensions.Find<AutoHeaderContextExtension>(); if (extension == null ) { extension = new AutoHeaderContextExtension(); proxy.Extensions.Add(extension); } extension[XName.Get(name, ns)] = MessageHeader.CreateHeader(name, ns, value ); } public static IEnumerable<MessageHeader> GetAutoHeaders( this IContextChannel proxy) { AutoHeaderContextExtension extension = proxy.Extensions.Find<AutoHeaderContextExtension>(); if (extension == null ) { return Enumerable.Empty<MessageHeader>(); } return extension.Values; } public static void RemoveAutoHeader( this IContextChannel proxy, string name, string ns) { AutoHeaderContextExtension extension = proxy.Extensions.Find<AutoHeaderContextExtension>(); if (extension != null ) { extension.Remove(XName.Get(name, ns)); } } } If you combine that with a message inspector that adds the headers on to each message, then you get a collection of headers that are added to every outgoing request. public class AutoHeaderMessageInspectorBehavior : IEndpointBehavior { class AutoHeaderMessageInspector : IClientMessageInspector { public void AfterReceiveReply( ref Message reply, object correlationState) { } public object BeforeSendRequest( ref Message request, IClientChannel channel) { foreach (MessageHeader header in channel.GetAutoHeaders()) { request.Headers.Add(header); } return null ; } } public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { } public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime) { clientRuntime.MessageInspectors.Add( new AutoHeaderMessageInspector()); } public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher) { } public void Validate(ServiceEndpoint endpoint) { } } Here's an example using this extension. [ServiceContract] Read More...
|
-
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 thing you need is the right contract. The initial page load is ordinarily retrieved using the HTTP GET verb rather than the HTTP POST verb assumed by web services. I'll set that up as part of my contract using the WebGet attribute to set the verb and a URI template to set the address. [ServiceContract] public interface IService { [OperationContract] [WebGet(UriTemplate = "/image" )] Stream GetImage(); } The second thing you need is the right content type. Although web browsers can try to autodetect content, you should specify the content type if it is known. This allows the web browser to process the content correctly inline. public class Service : IService { public Stream GetImage() { WebOperationContext.Current.OutgoingResponse.ContentType = "image/jpeg" ; return new FileStream( "c:\\test.jpg" , FileMode.Open, FileAccess.Read); } } Finally, you may notice that while I've done everything needed in the service implementation to enable streaming, content can only be streamed if the binding supports this as well. When using WebServiceHost, the default bindings do not support streamed content. This may be hard to spot because the typical files are small and a test program running on the same machine completes the transfers before streaming would make a difference. I've wrapped the service implementation in this example to intentionally slow down the transfer to make the difference more apparent. The following code demonstrates enabling streaming on the binding. You can change the transfer mode back to Buffered to observe the difference. Streaming requires support in the receiving application as well to make a difference. Using a large, progressive encoded image will demonstrate this. using System; using System.IO; using System.ServiceModel; using System.ServiceModel.Web; using System.Threading; public class SlowStream : Stream { Stream innerStream; public SlowStream(Stream innerStream) { this .innerStream = innerStream; } public override bool CanRead { get { return Read More...
|
-
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 is going to look nothing like the standard application contract. Therefore, there's really no transformation that will take you from the fault message to the same parameterized contract in a way that makes any sense. The response that comes back from the server is unrepresentable using the standard data structure that the application is expecting to receive for an application response. This is why with a typed contract fault messages have to be expressed as an exceptional condition. Exceptions tend to transform the message with a much lower fidelity to the original content. With an untyped contract, incoming messages on the server are not shredded on your behalf but rather preserved in their entirety. You can think about this as performing the transformation between messages and parameters with perfect fidelity since the parameter is equal to the message. Similarly, any message response, whether it's a fault response or a normal application response, is also going to be representable with perfect fidelity. Both types of responses have the same format with an untyped contract so the application can handle them equally well. This is why with an untyped contract fault messages are preserved as messages. One of the major reasons for using untyped contracts is to have great fidelity with the wire. It wouldn't make sense to force the application to lose that fidelity for a certain class of messages. If you choose to in your application though, you can still run the same exception machinery. For details, read some of the past articles on creating and consuming faults . Next time: Streaming Web Content Read More...
|
-
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); } } class Program { static void Main( string [] args) { string address = "http://localhost:8000/" ; WebServiceHost host = new WebServiceHost( typeof (Service), new Uri(address)); host.Open(); ChannelFactory<IService> factory = new ChannelFactory<IService>( new WebHttpBinding()); factory.Open(); IService proxy = factory.CreateChannel( new EndpointAddress(address)); using ( new OperationContextScope((IContextChannel)proxy)) { OperationContext.Current.OutgoingMessageHeaders.To = new Uri(address); proxy.ProcessRequest( "data" ); } factory.Close(); host.Close(); Console.ReadLine(); } } Running the sample reveals that the message wrapper gets an unpleasant namespace instead of the default namespace. < ProcessRequest xmlns ="http://tempuri.org/" > < data > data </ data > </ ProcessRequest > By looking at the metadata, you could figure out where this namespace was coming from using the custom namespace sample I published earlier. In this case the problem is with the operation wrapper, which comes from the service contract. Setting the service contract to have a namespace of "" gets us the desired default namespace. Next time: Using Faults with Untyped Messages Read More...
|
-
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, that reference translates into a significantly sized chunk of metadata for defining the IPAddress type. < xs:schema xmlns:tns ="http://schemas.datacontract.org/2004/07/System.Net" elementFormDefault ="qualified" targetNamespace ="http://schemas.datacontract.org/2004/07/System.Net" xmlns:xs ="http://www.w3.org/2001/XMLSchema" > < xs:import namespace ="http://schemas.datacontract.org/2004/07/System.Net.Sockets" /> < xs:import namespace ="http://schemas.microsoft.com/2003/10/Serialization/Arrays" /> < xs:complexType name ="IPAddress" > < xs:sequence > < xs:element name ="m_Address" type ="xs:long" /> < xs:element xmlns:q1 ="http://schemas.datacontract.org/2004/07/System.Net.Sockets" name ="m_Family" type ="q1:AddressFamily" /> < xs:element name ="m_HashCode" type ="xs:int" /> < xs:element xmlns:q2 ="http://schemas.microsoft.com/2003/10/Serialization/Arrays" name ="m_Numbers" nillable ="true" type ="q2:ArrayOfunsignedShort" /> < xs:element name ="m_ScopeId" type ="xs:long" /> </ xs:sequence > </ xs:complexType > < xs:element name ="IPAddress" nillable ="true" type ="tns:IPAddress" /> </ xs:schema > Notice the inclusion of System.Net.Sockets.AddressFamily. This schema is only the tip of the iceberg. It continues on and becomes much, much worse. Nevertheless, there are times when you can accept putting interoperability aside and have a reason to bind your service to a system type. The metadata still leaves you with the problem of generating a working proxy. Although some system types are recognized and filtered out, other types slip through and will lead to compilation errors due to conflicting type definitions. The standard referencing mechanism of svcutil works with system types as well as your types. You just need to find and point svcutil at the appropriate dll so that it can compute the types to exclude. Since IPAddress is defined in system.dll, if you wanted to resolve a conflict, you Read More...
|
-
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 service implementation with some more semantics filled in for a particular application. All I've done is pick out part of the address space that I want to assign some implementation to. [ServiceContract] public interface IService2 { [OperationContract] [WebGet(UriTemplate = "/resource/{index}" )] string Get( string index); [OperationContract] [WebInvoke(UriTemplate = "/resource" )] void Add( string value ); } public class Service2 : IService2 { public string Get( string index) { Console.WriteLine( "Get {0} {1}" , WebOperationContext.Current.IncomingRequest.Method, OperationContext.Current.IncomingMessageHeaders.To); return null ; } public void Add( string value ) { Console.WriteLine( "Add {0} {1}" , WebOperationContext.Current.IncomingRequest.Method, OperationContext.Current.IncomingMessageHeaders.To); } } Hosting this service is basically the same. I can take out the endpoint definition because that gets inferred automatically. WebServiceHost host = new WebServiceHost( typeof (Service2), new Uri( "http://localhost:8000/" )); host.Open(); Client(); Console.ReadLine(); host.Close(); Finally, I can use the exact same client code as last time even though in the service I've changed my way of writing the service from a centralized approach to an address-based approach. ChannelFactory<IRequestChannel> factory = new ChannelFactory<IRequestChannel>( new WebHttpBinding()); factory.Open(); IRequestChannel proxy = factory.CreateChannel( new EndpointAddress( "http://localhost:8000/" )); using ( new OperationContextScope((IContextChannel)proxy)) { Message request = Message.CreateMessage(MessageVersion.None, string .Empty, "data" ); request.Headers.To = new Uri( "http://localhost:8000/resource" ); WebOperationContext.Current.OutgoingRequest.Method = "POST" ; proxy.Request(request); } using ( new OperationContextScope((IContextChannel)proxy)) { Message request = Message.CreateMessage(MessageVersion.None, string .Empty); request.Headers.To = new Uri( "http://localhost:8000/resource/1" Read More...
|
-
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 null ; } } You might expect to run this service in a straightforward hosting environment. ServiceHost host = new ServiceHost( typeof (Service), new Uri( "http://localhost:8000/" )); host.AddServiceEndpoint( typeof (IService), new WebHttpBinding(), "" ); host.Open(); Console.ReadLine(); host.Close(); And, talk to it with the ordinarily convoluted client programming model. ChannelFactory<IRequestChannel> factory = new ChannelFactory<IRequestChannel>( new WebHttpBinding()); factory.Open(); IRequestChannel proxy = factory.CreateChannel( new EndpointAddress( "http://localhost:8000/" )); using ( new OperationContextScope((IContextChannel)proxy)) { Message request = Message.CreateMessage(MessageVersion.None, string .Empty, "data" ); request.Headers.To = new Uri( "http://localhost:8000/resource" ); WebOperationContext.Current.OutgoingRequest.Method = "POST" ; proxy.Request(request); } using ( new OperationContextScope((IContextChannel)proxy)) { Message request = Message.CreateMessage(MessageVersion.None, string .Empty); request.Headers.To = new Uri( "http://localhost:8000/resource/1" ); WebOperationContext.Current.OutgoingRequest.Method = "GET" ; WebOperationContext.Current.OutgoingRequest.SuppressEntityBody = true ; proxy.Request(request); } However, when you put these pieces together, it fails to work. The client turns out to be fine but there's a problem in the way that the service is hosted. More accurately, there's a problem with the interaction between the way the service is hosted and the way it's defined. By specifying an address for hosting the application, we're claiming all of the messages that go to that address. We're also claiming all of the messages that go to suffixes of that address as long as someone else hasn't claimed them first. Unfortunately, the endpoint doesn't know what to do with these extra messages. It just ignores them. What we want is for the endpoint to just take everything and let the service implementation decide what the addresses 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...
|
-
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...
|
|
|
|