Q1: Should I use WS-Policy to create requirements that state element A is required when consuming ServiceFoo? I don't want developers to call without the element, get a fault, and then have to retry. I want to declare a predefined agreement between the endpoints.
If you want to avoid {try, fault, revise, retry}* message exchanges then consider service metadata. Think of metadata as enabling compile-time checking which minimizes but doesn’t eliminate run-time errors.
To describe the structure of the XML content within the SOAP Body (or an application SOAP Header block), XML Schema (within WSDL) is your first option.
To describe required infrastructure messages or headers, WS-Policy (within WSDL) is your first option. For instance, WS-RM Policy defines an assertion to indicate that a service requires WS-ReliableMessaging. WS-Policy is also a reasonable option to describe that a particular service requires an optional feature within a standard specification. For instance, the Devices Profile (Lines 845+) defines assertions to indicate that the service (device) requires WS-Eventing messages with duration and “push” subscriptions.
Q2: Any links on how to implement/use WS-Policy* with Visual Studio 2005?
When metadata is embedded within WSDL, you can retrieve it by retrieving the WSDL. Visual Studio 2005’s Add Web Reference (and wsdl.exe) knows how to process embedded XML Schema, but to process embedded WS-Policy you’d probably use System.Web.Services.Description. Indigo’s Windows Communication Foundation’s svcutil.exe knows how to process both.
Posted
Sep 01 2005, 09:10 PM
by
jeffrey-schlimmer