An Overview of Interoperability

One of the key values of SOAP is that it is platform agnostic. Regardless of the platform a system may be on, there is potential to readily interoperate with others.

WS-I Basic Profile

Through the .NET Framework and the SOAP Toolkit, Microsoft provided the capability to create Web services hosted within Internet Information Server (IIS). The more common .NET Web services were stored in files with an extension of .ASMX and are commonly referred to as ASMX Web Services. Other software companies created their own Web service implementations, and subtle differences among the implementations caused some challenges when they attempted to interoperate using other tools, languages, and/or platforms.

The Web Services Interoperability Organization (http://www.ws-i.org) creates, promotes, and supports generic protocols for the interoperable exchange of messages between Web services. The WS-I has published a profile of what must be supported for basic interoperability.

To facilitate interoperability, the WS-I established a working group for a basic profile that could be implemented to support interoperability across implementations and platforms. The Basic Profile 1.1 (BP1.1) consists of implementation guidelines recommending how a set of core Web services specifications should be used together to develop interoperable Web services. The guidelines address technologies that cover the following areas:

• Messaging The exchange of protocol elements, usually over a network, to affect a Web service

• Description The enumeration of the messages associated with a Web service, along with implementation details

• Discovery Metadata that enables the advertisement of a Web service's capabilities

• Security Mechanisms that provide integrity and privacy

BP 1.1 covers the following core Web services standards and provides constraints and clarifications to these base specifications, along with conventions about how to use them together, with the goal of promoting interoperability:

• SOAP 1.1

• WSDL 1.1

• UDDI 2.0

• XML 1.0 (Second Edition)

• XML Schema Part 1: Structures

• XML Schema Part 2: Data types

• RFC2246: The Transport Layer Security Protocol Version 1.0

• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

• RFC2616: Hypertext Transfer Protocol 1.1

• RFC2818: HTTP over TLS Transport Layer Security

• RFC2965: HTTP State Management Mechanism

• The Secure Sockets Layer Protocol Version 3.0

To provide Basic Profile support in WCF is very straightforward, just specify the basicHttpBinding.

WS-*

Although having Basic Profile 1.1 is important, as the name implies, it is for basic interoperability. The functionality provided by the BP 1.1 does not address many of the needs critical to many real-world scenarios, particularly around security and reliability.

Much of what is supported by the Basic Profile is designed for services that have direct connections with their clients. In the emerging world of service-oriented Enterprises, messages no longer go strictly from a service at Point A to a client at Point B; instead a message may make multiple "hops" en route to its destination. This requires involvement not at the transport level, but at the message level.

When examining security in the Basic Profile, the channel between the server and its clients can be secured using SSL. Both server and client authenticity can be validated using certificates. This is typically acceptable when you're interacting in a scenario in which there is a 1:1 connection. But what about when you send a message, that message is then routed, and eventually it reaches its recipient? There could be any number of hops in between client and service, and the path is likely to vary based on various criteria (traffic, SLAs, and so on). Although setting up transport security with BP 1.1 could be done, this process now introduces a number of intermediaries and introduces the potential risk that messages could be modified en route. There was a need for standards around key areas in this space, with major focuses on security, transactions, and reliability. OASIS has been the leader in driving these standards.

OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. Microsoft, IBM, SAP AG, Nokia, Oracle, and BEA Systems are among the 600 organizations that participate in OASIS.

The participants in OASIS have put forward a number of standards for advanced Web services, referred to collectively as the WS-* specifications. In WCF, WS-* interoperability includes platform-agnostic support of reliable sessions, transactions, transport security, and SOAP security.

To provide WS-* support to your services, use the wsHttpBinding.

Custom Bindings

In addition to the bindings provided with Windows Communication Foundation out of the box, WCF provides the capability to create custom bindings in the configuration file. This allows tremendous flexibility when interoperating with business partners, legacy systems, third-party products, and commercial Web services when the standard bindings provided do not meet the requirements of your service. Custom binding elements could be used, for example, to enable the use of new transports or encoders at a service endpoint. Custom bindings are used to define a binding from a set of binding elements.

Creating Proxy Code for Use in Client Applications

To facilitate the creation of client proxies, Windows Communication Foundation includes the Service MetaData Utility tool (SvcUtil.exe). This tool generates service model code from metadata documents and metadata documents from service model code.

In this chapter, we'll use the tool to generate proxy code to be used in interop scenarios. At least up until the February CPT release, it does not automatically map the preconfigured bindings by name. Instead, custom bindings will be created that map to the requirements of the service.

SvcUtil.exe is called using the command line and parameters found in Table 7.1.

Svcutil [options] [metadataPath* | assemblyPath* | metadataUrl*]

Table 7.1. Parameters for SvcUtil.exe

Argument	Description
metadataPath	Path to metadata document that contains the contract to import into code (.wsdl, .xsd, .wspolicy, or .wsmex).
AssemblyPaths	Path to the assembly file that contains service contracts to export to metadata.
metadataUrl	URL to the running Web service that provides metadata for download through WS-Metadata Exchange or Http-Get.
Option	Description.
/directory:< directory>	Directory to create files in. Default: The current directory. Short form: /d.
/out:<file>	File name for the generated code. Default: Derived from the service name or target namespace of the schema document. Short form: /o.
/target:[code | metadata]	Specifies the output to be generated by the tool. Default: Inferred from input. Short form: /t.
/validate	Instructs the tool to validate all service endpoints in associated config files. (A config file is loaded when an exe for the config file is passed to the tool.) Short form: /w.
/config:<file1 [, file2]>	Instructs the tool to generate a configuration file. If only one filename is given, that is the name of the output file. If two filenames are given, the first file is an input configuration file whose contents are merged with the generated configuration and written out into the second file.
/noConfig	Do not create a config file.
/svcutilConfig:<file>	Custom configuration file to use in place of the app config file. Allows the user to change metadata configuration without altering global app config settings.
/language:<language>	Specifies the programming language to use for code generation. Values: c#, cs, csharp, vb, vbs, visualbasic, vbscript, js, jscript, javascript, vj#, vjs, vjsharp, c++, mc, or cpp, or provide a fully qualified name for a class implementing System.CodeDom.Compiler.CodeDomProvider. Default: csharp. Short form: /l.
/compile	Compiles generated code into an assembly. Short form: /c.
/namespace:<"schema	Specifies the CLR namespace to associate with a schema target
namespace", "CLR namespace">	namespace. Default: Derived from the target namespace of the schema document. Short form: /n.
/reference:<file path>	References the specified assembly files. Short form: /r.
/nostdlib	Do not reference standard library (mscorlib.dll).
/referenceCollectionType:<type list>	Fully qualified or assembly-qualified type name to exclude from referenced types. Short form: /rct.
/excludeType:<type>	Fully qualified or assembly-qualified type name to exclude from referenced types. Short form: /et.
/async	Generate asynchronous method signatures. Short form: /a.
/internal	Generate classes marked internal (default: generate public classes). Short form: /i.
/typedMessages	Instructs the tool to generate code that uses typed messages. Short form: /tm.
/useXmlSerializer	Instructs the tool to generate code that uses XmlSerializer. Short form: /uxs.
/importXmlType	Import non-Data Contract types as IXmlSerializable. Short form: /ixt.
/enableDataBinding	Implement INotifyPropertyChanged interface on all XmlFormatter types to enable data binding. Short form: /edb.
/dataContractOnly	Instructs the tool to operate on Data Contract types only. Service Contracts will not be processed. Short form: /dconly.
/noLogo	Suppress the copyright and banner message.
/help	Displays command syntax and options for the tool. Short form: /?.