|
|
Browse by Tags
All Tags » Encoders (RSS)
-
Why doesn't a message start with an XML declaration? The XML declaration is a processing instruction at the beginning of an XML document that gives information about the format and logical structure of the document. You've probably seen the most commonly used XML declaration on many documents. <? xml version ="1.0" encoding ="UTF-8" ? > Both the version and the encoding in this example declaration are the default values. XML documents aren't required to start with a declaration because default values are assumed. Processors that are sensitive to the size of the produced document omit the declaration to avoid transmitting redundant information. The text encoder is an example of an XML processor that can recognize when the default values are being used and omit the declaration to save space. In some cases you want the XML declaration even when it's unnecessary because the receiver is expecting the document to start with a particular sequence of characters. Since the optimization in the text encoder isn't the result of a configuration setting, some amount of manual work is required to produce messages that contain unnecessary processing instructions. You can recreate this effect using a custom message encoder that is even simpler than the sample custom text encoder . You don't need to support a custom content type or to do any special processing when reading a message. You do need the shell for a message encoder and message encoder factory plus the logic in WriteMessage to insert the processing instruction. The sample writes the processing instruction using XmlWriterSettings although you can choose any method you wish. Next time: Flowing Additional Identity Information Read More...
|
-
I have an operation contract that uses untyped messages. When using the message, I get an error telling me to change the quota settings on the XmlReader. Where are these quotas located? I'm not using an XmlReader. A message represents an XML InfoSet. While there are many different ways to access the content of a Message, in a standard implementation, all of these methods are wrappers around the core XmlReader and XmlWriter infrastructure. If there is no obvious XmlReader, then that means that the XmlReader is being used by the internal implementation of the message. Therefore, whoever created the Message must have been the one that knew about the XmlReader and its quotas. Since most of the messages that you deal with inside of a service operation were created by the message encoder of the binding, the first place to look for the quota settings are either on the binding or the binding element. Next time: Sticky Sessions Read More...
|
-
Why doesn't anything happen when I try to add HTTP headers from a message encoder? The problem here is a basic issue of timing. Recall the interface contract that a message encoder has with its transport. The transport receives a message from the next channel up in the channel stack, does some processing on the message, and calls WriteMessage on the message encoder when it wants to write out the message body. The message encoder does not necessarily see all of the message content. Some message content, such as framing, is independent of the message encoding and directly handled by the transport. In fact, the message encoder may not be called at all if there is no content for it to write. HTTP headers are an example of content that is handled by the transport rather than the message encoder. The message encoding transforms the body of the message, but HTTP headers are always sent as text. In the call to WriteMessage, the message encoder does get a Message object, which has a handle to the HTTP headers. However, if you look at the format of a raw HTTP message, then you would see that the HTTP headers are completely written out before the message body is written out. When streaming an HTTP message, the headers may even be transmitted before the message body is written out. Therefore, you should guess that it's unlikely that the message encoder can do anything with the HTTP header collection because the HTTP headers may already have been transmitted. If you want to change the HTTP headers, then you should make sure that all of the changes are made before the transport is given the message. Next time: WCF Case Studies Read More...
|
-
There are three types of message encodings that come with WCF: text, binary, and MTOM. Text is the traditional way of encoding an XML document; MTOM is an interoperable way to create messages with attachments; and binary is an optimized format. The binary message encoder requires you to use SOAP 1.2 and any version of message addressing. Validation for the message encoder checks that you are using SOAP 1.2. The validation doesn't check to make sure that you have some kind of message addressing, so if you are using AddressingVersion.None, then that won't show up as an error until you try to send a message. It may be difficult to figure out the cause of the error because the resulting message looks invalid and the connection just gets refused. If you are capturing all of the exceptions that occur though, you should see something that looks like one of these stack traces when you have an invalid configuration. The stack trace when using HTTP is going to look like: System.ServiceModel.Channels.BinaryMessageEncoderFactory.BinaryMessageEncoder.ReadMessage + 0x299 bytes System.ServiceModel.Channels.HttpInput.DecodeBufferedMessage + 0x56 bytes System.ServiceModel.Channels.HttpInput.ReadBufferedMessage + 0x7e bytes System.ServiceModel.Channels.HttpInput.ParseIncomingMessage + 0x9e bytes System.ServiceModel.Channels.HttpRequestContext.CreateMessage + 0x2e bytes System.ServiceModel.Channels.HttpChannelListener.HttpContextReceived + 0x99 bytes System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContextCore + 0x231 bytes System.ServiceModel.Channels.SharedHttpTransportManager.OnGetContext + 0x1e bytes System.ServiceModel.Diagnostics.Utility.AsyncThunk.UnhandledExceptionFrame + 0x28 bytes System.Net.LazyAsyncResult.Complete + 0x7f bytes System.Net.LazyAsyncResult.ProtectedInvokeCallback + 0x8b bytes System.Net.ListenerAsyncResult.WaitCallback + 0x22a bytes System.Threading._IOCompletionCallback.PerformIOCompletionCallback + 0x68 bytes The stack trace when using TCP or named pipes is going to look like: System.ServiceModel.Channels.TransportOutputChannel.TransportOutputChannel + 0x8b bytes System.ServiceModel.Channels.FramingDuplexSessionChannel.FramingDuplexSessionChannel + 0x4f bytes System.ServiceModel.Channels.FramingDuplexSessionChannel.FramingDuplexSessionChannel + 0x38 bytes System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.ServerFramingDuplexSessionChannel.ServerFramingDuplexSessionChannel + 0x29 bytes System.ServiceModel.Channels.TcpDuplexChannelListener.System.ServiceModel.Channels.ISessionPreambleHandler.HandleServerSessionPreamble Read More...
|
-
There has always been some confusion about what it means to use a "binary encoding" with your web service. The word encoding is used in a very specific sense here, which should also help you figure out the implications of choosing an encoder in the future. There are two words, encoding and formatting, that I use a lot to keep the concepts clear. When we talk about an in-memory message, an instance of a message that your service can interact with, that message is always an XML Infoset. There is no physical representation associated with the Infoset, although you can manipulate it using XML readers and writers. On the wire, there is something physical and totally different from the Infoset, typically a stream of bytes. A formatter translates between typed objects and an XML Infoset. An encoder translates between an XML Infoset and the wire representation. You're probably familiar with XML representations that write out the document using text phrases to express the tags inside the document. A binary encoder is just a particular encoder implementation that uses an alternative way of representing the XML Infoset. A binary XML representation replaces the textual tags with opaque binary tokens. Different representations of XML are better at certain tasks, but they result in the construction of the same Infoset after the message is transmitted. Nothing about the encoder implies what can go into the Infoset. In particular, you can have a formatter that puts binary content into the Infoset regardless of whatever kind of encoder you want to use with that Infoset later. Next time: Interfaces for GetProperty Read More...
|
-
This time it's two questions that have the same answer. What contract does the message encoder have for producing a message from ReadMessage? What should the transport do if the message encoder doesn't produce a message from the buffer you give it? The contract of the message encoder is that it will always either throw an exception or produce exactly one message each time ReadMessage is called. This means that a properly-written message encoder will never fail to produce a message without throwing an exception out of ReadMessage for the transport to handle. As you might recall, the contract that the transport must abide by is that operations should only throw exceptions that are subtypes of CommunicationException, TimeoutException, or some fatal exception type (such as OutOfMemoryException). The transport should catch all exception types that it knows the message encoder will produce, such as XmlException, and wrap those in some instance of CommunicationException. A good choice would be ProtocolException. However, the transport should not just eat all types of exceptions. It's best to let a stray exception through unless it is a specific, known type because you run the risk of trapping a fatal exception. What happens to the message after the transport gets it back from the message encoder is no longer constrained by the contract of the message encoder. Next time: How to Configure MaxItemsInObjectGraph Read More...
|
-
I drew this picture for myself while working on the guidelines for implementing GetProperty . I figured that other people might find it useful as well. One of the guidelines is that queryable properties on design time objects should flow to the corresponding run time objects. The black boxes show the classes that support GetProperty and the black arcs show the anticipated flow of properties. The red boxes show the classes that don't support GetProperty today but might make sense to have support in the future. Read More...
|
-
This post is just some quick thinking about guidelines for implementing the GetProperty method. These guidelines are still in development so think of this as a draft rather than real guidance at this time. Background: We provide an extensibility point called GetProperty on many of the components you can build using the channel model. The exact list of components that support GetProperty are bindings, binding elements, channel factories, channel listeners, channels, and message encoders. GetProperty allows someone to execute a strongly-typed query against your component to inspect its configuration settings. GetProperty takes a type parameter T and either returns some instance of T or returns default(T) to indicate that the type is unknown. DO expose configurable settings for your component using GetProperty. GetProperty should be used in preference to ad-hoc methods for searching through a stack of components. DO NOT require the use of GetProperty to access mandatory or intrinsic configuration settings. The types supported by GetProperty are not discoverable and any setting that your component considers mandatory should be accessible through the object model. GetProperty can be used as an alternative way of accessing the same value. DO support in your runtime objects every property that was available on your design time objects. If a channel factory exposes a setting, then every channel produced by that factory should expose a corresponsing setting that tells you what the value was when the channel was created. DO create specialized interfaces that capture each class of information that you want people to query on. Specialized interfaces promote the reuse of a particular type for semantically identical settings. DO reuse existing interfaces if your information has exactly the same semantics as the previous use. Conversely, if your settings don't have the same semantics, don't reuse a type just because it's more convenient to do so. DO NOT key properties off of commonly used types with a generic meaning. Types that appear frequently, such as IDisposable, will not have consistent semantics for all of their potential uses. DO NOT key properties off of value or enumerated types. We enforce this by placing a restriction on the generic type parameter. DO delegate down to inner channels, channel factories, and channel listeners when they exist and your component does not know about the requested type. We have a pipeline model that supports the composition of many Read More...
|
|
|
|