Module 13: Using WCF Receive Adapters
Time estimated: 90 minutes
Module objective:
In this module, you will learn how to configure BizTalk Server 2010 receive locations to receive messages via the Windows Communication Foundation (WCF) receive adapters.
Introduction
Web services provide industry-standard mechanisms for conducting e-business by communicating across disparate systems. Microsoft BizTalk Server 2010 includes a number of receive adapters that support integration with web services by making use of the Windows Communication Foundation (WCF).
WCF provides support for a wide array of the current web service standards. This support enables developers to both consume a web service as part of a business process and to publish a business process as a web service that can be consumed by external applications.
In this module, you will learn how to configure BizTalk receive locations that accept messages via the BizTalk WCF receive adapters, and to publish BizTalk orchestrations and schemas as WCF web services.
Lesson 1: Introduction to WCF Receive Adapters
Lesson objective:
Describe how the WCF Receive Adapters work in BizTalk Server 2010
Introduction
This lesson provides an overview of Windows Communication Foundation (WCF) and the capabilities that it provides for interacting with web services. This lesson then focuses on the Microsoft BizTalk Server 2010 WCF receive adapters, providing examples for usage, and followed by a discussion of the architecture on which the WCF receive adapters are based.
Windows Communication Foundation (WCF)
Provide an overview of Windows Communication Foundation (WCF)
Introduction
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. WCF is included in the .NET Framework, and it provides a basis for writing code to communicate across components, applications, and systems. A service is a piece of code that clients interact with through messages. Services are passive -- they wait for incoming messages to arrive before starting any work. A client requests a service to perform work by sending a message to it.
Services expose one or more endpoints where messages can be sent. An endpoint consists of an address, a binding, and a contract. The address specifies where to send messages. The binding describes the transport details required. And the contract describes what the messages contain. Clients need to know all of this information before they can access a service.
Services typically offer descriptions of their capabilities and their requirements by using Web Services Description Language (WSDL). Clients can use the service description to generate code within their environment capable of sending and receiving the proper messages.
WCF 4.0 Web Service Standards Support
Explain the features and benefits of using Windows Communication Foundation (WCF).
Introduction
Windows Communication Foundation (WCF) supports a wide array of the web service standards that have been defined since the SOAP specification was first published. WCF enables you to develop secure, interoperable web services based on open industry-standard specifications. In addition to supporting the fundamental standards, such as XML, SOAP and WSDL, WCF includes support for standards covering end-to-end message level security, content-based routing, and web service policies.
WS-* Specification Support in WCF
Following the publication of the SOAP specification, the W3C and a number of industry organizations have continued to pursue the goal of achieving broad-based interoperability between IT systems. As a result, the W3C, OASIS.org, WS-I.org, and ad-hoc industry groups have published a series of specifications, known as “WS-*”, that build on the fundamental standards of web services. WCF 4.0 offers built-in support the following web service standards:
WS-Addressing allows a secured message to be sent over any transport and to also be easily routed.
WS-AtomicTransaction defines an interoperable transaction protocol. It enables you to flow distributed transactions by using web service messages, and coordinate transactions between heterogeneous infrastructures.
WS-Coordination defines a framework that enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment.
WS-MetadataExchange defines how metadata associated with a web service endpoint can be represented and how metadata can be retrieved from a Web service endpoint.
WS-Policy defines an XML syntax that can be used to define policy assertions, which describe constraints and requirements of a web service beyond those listed in a WSDL document.
WS-ReliableMessaging defines a transport-independent protocol that allows messages to be delivered reliably between distributed applications.
WS-Security describes how to secure Web services at the message level instead of at the protocol level or the wire level.
WS-SecureConversation defines extensions that build on WS-Security for establishing and sharing security contexts required for secure communication.
WS-SecurityPolicy describes the policy assertions for use with WS-Policy that apply to WS-Security, WS-Trust, and WS-SecureConversation.
WS-Trust defines extensions that build on WS-Security to request and issue security tokens and to manage trust relationships.
WS-I Profiles
The Web Service Interoperability Organization (WS-I) has published guidelines, sample applications and testing tools to help developers implement web service standards to achieve the best possible levels of interoperability.
A WS-I Profile consists of a set of guidelines, sample applications and testing tools that address a fixed set of web service specifications.
WCF 4.0 provides built-in support for the following WS-I profiles.
· WS-I Basic Profile, Datatypes – XML Schema 1.0 base and complex data types
· WS-I Basic Profile 1.1 – SOAP 1.1, WSDL 1.1
· WS-I Basic Profile 1.2 – SOAP 1.1, WS-Addressing 1.0
· WS-I Basic Profile 2.0 – SOAP 1.2, WS-Addressing 1.0, MTOM
· WS-I Basic Secure Profile 1.1 – WS-Security 1.1
There are asome dditional profiles under development in WS-I working groups that WCF 4.0 does not yet support, including:
Reliable message exchange – WS-ReliableMessaging 1.1
Reliable, secure message exchange – WS-ReliableMessaging 1.1, WS-SecureConversation 1.3
WCF Receive Adapter Scenarios
Describe some common scenarios for using a WCF receive adapter.
Introduction
With the WCF adapters built-in to Microsoft BizTalk Server 2010, developers can expose WCF Web Services to external systems and benefit from the rich integration support offered by WCF. Developers can make use of the WCF native support for the major web service specifications, rather than resort to writing custom code.
Some common integration scenarios in which a developer might want to publish a WCF web service include:
· To enable a BizTalk application to receive messages from an external trading partner’s supply chain system over the internet, making use of digital signatures to ensure that the message has not been tampered with.
· To enable a BizTalk application receive messages from an ERP system, such as SAP, Oracle eBusiness Suite, or Siebel eBusiness Applications.
· To enable a BizTalk application receive messages from a SQL Server or Oracle database, with full support for transactions across disparate systems.
Scenario for Publishing a BizTalk WCF Service
Describe a scenario for publishing a BizTalk orchestration as a WCF service.
Introduction
If your organization requires a specific business process to be accessible via the Web to trading partners, customers, or other applications, you can publish an orchestration or a message schema as a web service. You can do this by running the BizTalk WCF Service Publishing Wizard.
When publishing an orchestration as a web service, each public receive port is presented as a .svc file, which is handled by the Windows Communication Foundation (WCF) framework on a computer running Internet Information Services (IIS) Manager. The web service is called using the SOAP protocol. The data is sent to and from the web service as XML.
WCF Receive Adapter Architecture
Explain the architecture of a WCF receive adapter
Introduction
The BizTalk WCF receive adapters create WCF endpoints to listen for messages. When a message arrives at the endpoint, the WCF adapter receives the message and publishes it to the MessageBox.
BizTalk Server 2010 provides a number of different WCF adapters to meet the requirements of various messaging and transport protocols. The WCF adapters share a common architecture and base implementation. Each WCF adapter, however, requires a different set of configuration data as dictated by its transport, encoding and WS-* protocol support.
When a WCF receive adapter starts running, it creates a BizTalk Service Host, which dynamically builds the WCF runtime components that are required to accept and process messages. When a message arrives, the WCF receive adapter passes it through a series of WCF channel components. A channel consists of one transport component, one message encoder, and zero or more protocol components.
The transport component is responsible for reading in the raw bytes of the message. The encoder component is responsible for converting the raw bytes in to a WCF message. The protocol components are responsible for processing any WS-* protocols that are configured on the adapter.
When the WCF channel components have completed processing, and if they have not rejected the message for security reasons, the message will be passed to the receive location’s pipeline. At this point, the pipeline will process the message in the same manner as it would if the message were received by any other of the built-in BizTalk adapters.
Lesson 2: Configuring a WCF Receive Adapter
Lesson objective:
Learn how to configure a WCF receive adapter
Introduction
To create a receive location that presents a WCF service to external systems, you must determine which WCF adapter best meets the application requirements, and then configure the WCF adapter and BizTalk pipeline in the BizTalk Administration Console.
Steps for Configuring a WCF Receive Adapter
Identify the steps required to consume a Web service from an orchestration.
Introduction
To configure a WCF receive adapter, you must:
- Select a WCF receive adapter that best meets the receive location’s message transport, encoding and WS-* protocol requirements -- each of the WCF adapters is preconfigured with a set of WCF channel components.
- Specify an endpoint address at which the WCF service will be hosted.
- Set the configuration properties for the WCF adapter. Any of the preconfigured WCF adapters will display a set of properties, reflecting the properties of the channel components that it contains.
Types of WCF Adapters
Describe the types of BizTalk WCF adapters, and explain how each one can be used
Introduction
With the wide range of possibilities presented by the BizTalk WCF adapter architecture and the WCF framework, it could become a rather time consuming task to determine which features are required for a given receive location, and to build a corresponding WCF binding each time.
For ease of configuration, BizTalk Server 2010 provides a collection of WCF adapters that are preconfigured with WCF bindings:
The WCF-WSHttp adapter provides the WS-* standards support over the HTTP transport. The WCF-WSHttp adapter implements WS-Transaction for the transactional interactions between external applications and the MessageBox database, and WS-Security for message security and authentication. The transport is HTTP or HTTPS, and message encoding is a Text or Message Transmission Optimization Mechanism (MTOM) encoding.
The WCF-BasicHttp adapter communicates with ASMX-based Web services and clients and other services that conform to the WS-I Basic Profile 1.1. The transport is HTTP or HTTPS, and message encoding is a text encoding.
The WCF-NetTcp adapter provides the WS-* standards support over the TCP transport. The WCF-NetTcp adapter provides efficient communication in a WCF-to-WCF environment. The adapter implements WS-Transaction for the transactional interactions between external applications and the MessageBox database, and WS-Security for message security and authentication. The transport is TCP, and message encoding is binary encoding.
The WCF-NetMsmq adapter provides support for queuing by leveraging Microsoft Message Queuing (MSMQ) as a transport and enables support for loosely coupled applications, failure isolation, load leveling, and disconnected operations.
The WCF-NetNamedPipe adapter provides secure optimization for on-machine cross-process communication. The WCF-NetNamedPipe adapter uses transport security for transfer security, named pipes for message delivery, and binary message encoding.
Custom WCF Adapters
In order to retain the flexibility offered by WCF, BizTalk Server 2010 provides two generic WCF adapters that can be configured to meet requirements that differ from the previously listed WCF adapters.
The WCF-Custom adapter enables the use of WCF extensibility features. It contains no preconfigured channel components. The adapter allows you to select and configure a WCF binding and the behavior information for the receive location and send port.
The WCF-CustomIsolated adapter enables the use of WCF extensibility features over the HTTP transport. It contains no preconfigured channel components. The adapter allows you to select and configure a WCF binding and the behavior information for the receive location running in an isolated host.
WCF Adapter Hosting
Any WCF receive adapter that communicates over the HTTP protocol is hosted in an Internet Information Services (IIS) application pool. A WCF receive adapter that communicates over a protocol other than HTTP is hosted in a BizTalk service process.
Selecting Message Content
Learn how to select the message content that the adapter will publish to the MessageBox.
Introduction
The WCF receive adapters offer the option to configure how much of the content of an inbound SOAP message should be published to the message box. As was the case with the SOAP adapter, the default behavior of a WCF receive adapter is to publish only the message body, and to discard the SOAP envelope.
By configuring a WCF receive adapter to publish the entire SOAP message, including the envelope and headers, it is possible for other components within BizTalk to receive the message with any encryption and digital signatures intact. When selecting this option, you must configure the receive location with a pipeline that does not include the XML disassemble component pipeline, otherwise the SOAP body will automatically be extracted during pipeline processing, and published to the message box.
If your application requires only a subset of the SOAP message body, you can choose the Path option and provide an XPath statement to select a specific node to be published to the message box. This is particularly useful when external systems send large messages, and the receiving application requires only a small subset of the data.