Browse by Tags

• Answers
• Contracts
• Service Model

• Working with XElement Names

  XElement has a slightly different way of talking about XML than what WCF uses. This can lead to subtle bugs if you're not careful. Everywhere you see XML used in WCF, it is processed using an XmlReader and XmlWriter. These classes allow you to work with XML with extremely high performance but the classes themselves are not particularly easy to use. For someone who hasn't used this particular model before, it is surprisingly difficult to create and build up XML documents. XElement is the center of a newer and much easier library of classes for working with XML although it doesn't get quite the same performance as XmlReader and XmlWriter, particularly when doing stream processing. When working with WCF you'll frequently see a Name and Namespace pair of parameters. These parameters are both string types. The name is the common name and the namespace qualifies the common name so that many people can choose names without having to worry about conflicts. Since the namespace is primarily for avoiding conflicts, some people like to cheat a bit and just use the name in comparisons when conflicts are unlikely. XElement also has a Name. However, rather than being a string, this name is actually the XName type, which contains both the common name and the namespace. Some people who are used to using the Name in WCF translate that to the Name in XElement, which represents a change in behavior. The correct parallel would be element.Name.LocalName instead of element.Name. This difference can be hard to spot because it frequently just happens to work if you change both sides of the comparison in the same way at the same time. Additionally, your choice of serializer and contract definition may affect the default namespace. A lot of the older mechanisms and tools used an empty default namespace so again many things will happen to work. Other serializer and contract mechanisms, such as with data contracts, generate temporary namespace, which is much more likely to mysteriously stop working due to failed matches when you change the comparison behavior. Next time: Examining Header Values Read More... Posted Friday, October 17, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Messages, Service Model, Serialization

• Producing Typed Messages

  How do typed messages get created from an object that has a message contract? There seem to be a lot of examples that talk about how messages get produced when they're described by data contracts but relatively few descriptions of the equivalent process for message contracts. There's really nothing complicated or magical here so let's go through it. I'll start with a message that I want to describe with a message contract and then build the contract class. < s:Envelope xmlns:s ="http://www.w3.org/2003/05/soap-envelope" > < s:Header > < h:version xmlns:h ="http://mycorp.com" > 1 </ h:version > </ s:Header > < s:Body > < name xmlns ="http://mycorp.com" > Microsoft </ name > < address xmlns ="http://mycorp.com" > 1 Microsoft Way </ address > </ s:Body > </ s:Envelope > There's a message header whose type is an integer and two body members whose types are strings. This is a pretty easy message to describe although I have to change the settings for the wrapper and namespaces to get the structure to match. I apply an order to the body members because the default would reverse them. [MessageContract(IsWrapped= false )] class MyMessage { [MessageHeader(Namespace = "http://mycorp.com" )] public int version { get; set; } [MessageBodyMember(Namespace = "http://mycorp.com" , Order = 1)] public string name { get; set; } [MessageBodyMember(Namespace = "http://mycorp.com" , Order = 2)] public string address { get; set; } } Now I can use the TypedMessageConverter class to go between the message contract and a Message object. MyMessage record = new MyMessage(); record.version = 1; record.name = "Microsoft" ; record.address = "1 Microsoft Way" ; TypedMessageConverter converter = TypedMessageConverter.Create( typeof (MyMessage), null ); Message message = converter.ToMessage(record, MessageVersion.Soap12); Console.WriteLine(message.ToString()); message.Headers.Clear(); message.Headers.Add(MessageHeader.CreateHeader( "version" , "http://mycorp.com" , 2)); MyMessage record2 = (MyMessage)converter.FromMessage(message); Console.WriteLine(record2.version); Console.WriteLine(record2.name); Console.WriteLine(record2.address); I changed the version header for the return trip just to prove that there's no cheating going on. I gave an explicit message version when creating the message because otherwise I would have gotten SOAP 1.2 with WS-Addressing 1.0. My sample message didn't have any addressing information so I Read More... Posted Friday, February 08, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Messages, Service Model, Serialization

• Data Contract and Message Contract

  I have an existing web service that I need to replace with a WCF web service. How do I choose between using a data contract and a message contract? There are actually three choices to consider for describing the messages that your service uses: data contracts, message contracts, and XML serialization. You will be forced to use XML serialization in some cases because you have an existing message format with precise specification of XML elements and attributes that you need to replicate. In these cases, it may simply be impossible to duplicate this exact XML schema with a message or data contract-based description, forcing you to use XML serialization to describe the messages. However, let's assume that the existing message format is not so unreasonable and you have a choice between the various options for describing messages with contracts. How do you choose between data contracts and message contracts? The choice may not always seem clear if both types of contracts are capable of describing your messages. A rule of thumb though is that data contracts are generally portable between different kinds of XML encodings, making this option preferable if you might choose to project the Infoset differently in the future. Message contracts are more limited in the projections that they can support but are reasonably adept at mimicking the most common types of XML messages produced today. Therefore, there is a preference to use data contract, followed by message contract and XML serialization. However, the ability to adapt to a preset form is ranked in the reverse order. When you're required to conform to an existing message layout, you are more likely to be forced to use message contracts. When you are designing new message layouts, you almost always want to use data contracts. Next time: Message Disposal Read More... Posted Wednesday, July 25, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Messages, Service Model, Contracts, Serialization