April 5, 2011, 4:46 a.m.
posted by optimum
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:
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:
To provide Basic Profile support in WCF is very straightforward, just specify the basicHttpBinding.
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.
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 Figure.
Svcutil [options] [metadataPath* | assemblyPath* | metadataUrl*]