Browse by Tags

• Announcements
• Answers
• Contracts
• Hosting
• Messages
• Queues
• Security
• Service Model

• You Are Here

  Inside of a service method, how do I know where the message was delivered? Without defining what distinguishes a location it's hard to explain where 'here' is. I've got a few guesses though based on the most common variations of this question: OperationContext.Current.IncomingMessageHeaders.To OperationContext.Current.IncomingMessageProperties.Via HostingEnvironment.ApplicationVirtualPath Assembly.GetExecutingAssembly().Location HostingEnvironment.ApplicationPhysicalPath Next time: Serialization Temporary Assemblies Read More... Posted Thursday, June 12, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Messages, Hosting, Addressing

• Mystery of the Disappearing Addressing Headers

  Why do the messages logged by my service show addressing headers but those headers disappear when the message is sent? This is easy to explain once you actually look at the messages. Here's a quick test program that generates some SOAP 1.1 messages with all of the different addressing permutations. using System; using System.Collections.Generic; using System.ServiceModel.Channels; using System.Xml; class MyBodyWriter : BodyWriter { public MyBodyWriter() : base ( true ) { } protected override void OnWriteBodyContents(XmlDictionaryWriter writer) { } } class Program { static IEnumerable<MessageVersion> Versions { get { yield return MessageVersion.Soap11; yield return MessageVersion.Soap11WSAddressing10; yield return MessageVersion.Soap11WSAddressingAugust2004; } } static void Main( string [] args) { foreach (MessageVersion version in Versions) { Message m = Message.CreateMessage(version, "http://MyApplication/Action" , new MyBodyWriter()); m.Headers.To = new Uri( "http://localhost/service" ); Console.WriteLine( "MessageVersion: {0}\n{1}\n" , version, m.ToString()); } Console.ReadLine(); } } That generates the following set of messages: MessageVersion: Soap11 (http://schemas.xmlsoap.org/soap/envelope/) AddressingNone (http://schemas.microsoft.com/ws/2005/05/addressing/none) < s:Envelope xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" > < s:Header > < Action s:mustUnderstand ="1" xmlns ="http://schemas.microsoft.com/ws/2005/05/addressing/none" > http://MyApplication/Action </ Action > < To s:mustUnderstand ="1" xmlns ="http://schemas.microsoft.com/ws/2005/05/addressing/none" > http://localhost/service </ To > </ s:Header > < s:Body /> </ s:Envelope > MessageVersion: Soap11 (http://schemas.xmlsoap.org/soap/envelope/) Addressing10 (http://www.w3.org/2005/08/addressing) < s:Envelope xmlns:a ="http://www.w3.org/2005/08/addressing" xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" > < s:Header > < a:Action s:mustUnderstand ="1" > http://MyApplication/Action </ a:Action > < a:To s:mustUnderstand ="1" > http://localhost/service </ a:To > </ s:Header > < s:Body /> </ s:Envelope > MessageVersion: Soap11 (http://schemas.xmlsoap.org/soap/envelope/) Addressing200408 (http://schemas.xmlsoap.org/ws/2004/08/addressing) < s:Envelope xmlns:a ="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" > < s:Header Read More... Posted Tuesday, March 18, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Addressing

• Setting a User Principal on the Endpoint

  How do I set the user principal name that the client will use when calling the service? The user principal name can be set through either code or configuration, and it's considered a part of the endpoint address used by the client. That means that physically you'll find the user principal name and the description of the endpoint collocated. In configuration that looks like: < client > < endpoint address ="..." binding ="..." bindingConfiguration ="..." contract ="..." name ="..." > < identity > < userPrincipalName value ="name@address.com" /> </ identity > </ endpoint > </ client > And, in code that looks like: EndpointAddress address = new EndpointAddress( "..." , UpnEndpointIdentity.CreateUpnIdentity( "name@address.com" ), null ); Next time: Differences Between WSDL and XSD Read More... Posted Thursday, November 08, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Security, Addressing

• Address Filters that Swallow GET

  Many services consist of more than one message processing strategy. Typically, you think of services as being represented by their application endpoints. When the service receives a message, the decision to route the message to one of those endpoints is done by applying message filters until a winning endpoint is determined. However, services also possess infrastructure endpoints to handle tasks like metadata retrieval. These endpoints are also potential routing targets so the decision from filtering has to span both collections of endpoints. One consequence of having both infrastructure and application endpoints is that it's entirely possible for the defined filter set to be internally consistent for each of the collections but have conflicts when considering the combined set of endpoints. Whenever there is a conflict, some resolution process must take place and pick one of the endpoints to receive the message. Since you primarily think of your application endpoints, you may not consider that you've created a conflict with one of the infrastructure endpoints. Your application endpoints might not win that conflict. The most common symptom of a conflict is that you'll get an exception because the wrong endpoint is trying to process your message. For example, you'll see an address filter mismatch exception that looks like this: The message with To '...' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree. A sometimes surprising source of this conflict is seen when you switch an operation from using the normal POST to use GET. The service help page and metadata endpoint tend to win conflicts directed to their location or any subpath of their location that use a GET request. You can disable or move these infrastructure endpoints to resolve the conflict through the ServiceDebugBehavior or ServiceMetadataBehavior, respectively, in the configuration or through code. Alternatively, you can move your application endpoint to resolve the conflict that way. Next time: Turning Off Principal Handling Read More... Posted Thursday, September 13, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Service Model, Addressing

• WS-Addressing Metadata and WS-Policy Completed

  Two new standards were published yesterday by W3C that cover various aspects of web service metadata. WS-Policy is one of the family of general mechanisms used to describe service requirements and capabilities. Policy attachments supplement the general mechanism to describe how policy is specifically tied to a service description language, such as WSDL. Finally, WS-Addressing Metadata explains how addressing concepts should appear in WSDL, how WSDL should appear in addresses, and how addressing is described through policy. Look for these standards to be supported in the upcoming Orcas release. You can get all of these specifications at the W3C site. Web Services Addressing 1.0 - Metadata Web Services Policy 1.5 - Framework Web Services Policy 1.5 - Attachment Read More... Posted Wednesday, September 05, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Announcements, Contracts, Addressing

• MSMQ Addressing

  Here's a quick guide to how an address that uses the net.msmq scheme in WCF gets turned into an actual MSMQ address. There are three transfer protocols used with MSMQ: native, SRMP (SOAP Reliable Messaging Protocol), and SRMPS (SOAP Reliable Messaging Protocol Secure). Each of the transfer protocols translates addresses slightly differently. For a given net.msmq address, we'll first check the transfer protocol. If the transfer protocol is SRMP or SRMPS, then the MSMQ address is going to be a direct address. The only difference between SRMP and SRMPS is that SRMP uses the http scheme while SRMPS uses the https scheme. The MSMQ address produced from net.msmq://hostname:port/queuename is DIRECT=http://hostname:port/msmq/queuename. Having a port is optional, and this part of the address is omitted if no port is specified. A private queue name is written as private/queuename in net.msmq but translates to private$/queuename in the MSMQ address. It's illegal to include the dollar sign in a net.msmq address. If the transfer protocol is native, then the MSMQ address is either going to be a GUID address or a direct address. A GUID address is created if the binding has been configured with UseActiveDirectory set to true. The GUID uniquely identifies the queue. Otherwise, the MSMQ address produced from net.msmq://hostname/queuename is DIRECT=OS:hostname\queuename. Unlike SRMP, a port is never specified with the native transfer protocol. Again, a private queue name is written as private/queuename in net.msmq but translates to private$\queuename in the MSMQ address. Finally, if the hostname is an IP address, then the resulting MSMQ address instead is DIRECT=TCP:hostname\queuename. Next time: Attribute Driven Transactions Read More... Posted Tuesday, August 28, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Queues, Addressing