Implementing Pipes and Filters with BizTalk Server 2004

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Integration Patterns

Contents

Context

Background

Implementation Strategy

Example

Resulting Context

Testing Considerations

Security Considerations

Operational Considerations

Acknowledgments

Context

You are implementing Pipes and Filters by using Microsoft BizTalk Server 2004.

Background

The Global Bank scenario includes the Execute Scheduled Payment use case. This use case permits Global Bank to transfer funds from a customer's account to a specified target account. The target account can reside in one of three systems:

• An internal banking system that uses an internal Global Bank payment channel.
• An external banking system that uses encrypted and signed e-mail messages to transfer funds. One such system is the Society for Worldwide Interbank Financial Telecommunication (SWIFT) payment channel.
• An external banking system that cannot accept an electronic funds transfer and therefore has to receive a paper check. This is an external manual payment channel.

This pattern describes how to implement the Execute Scheduled Payment use case in the Global Bank scenario by using the Pipes and Filters pattern that is described earlier in this guide*.* This implementation uses BizTalk Server 2004 to transform and to route funds to the target accounts by using the correct channel, as shown in Figure 1.

Figure 1. BizTalk Server2004 as Pipes and Filters

Specifically, this pattern focuses on how to implement BizTalk Server 2004 to send payment information to target accounts through channels such as the SWIFT bank payment channel. The communication on the external payment channel sends confidential information across public networks; that information should be protected against unauthorized use. To address this issue, the business requirements require you to encrypt the messages to avoid eavesdropping by third parties. The business requirements also require you to add a certificate to ensure the authenticity of messages. A certificate prevents third parties from generating false messages that are designed to credit bank accounts.

This implementation uses the S/MIME protocol and the Triple Data Encryption Standard (DES3) encryption algorithm. Signing and encrypting the messages for the external payment channel involves applying a pair of transformations to the message data. One transformation digitally signs the message by computing a checksum. Another transformation uses a 168-bit secret key to encrypt the message.

Implementation Strategy

When BizTalk Server 2004 receives a message, the incoming data can be processed by a receive pipeline before it enters the MessageBox database, as shown in Figure 2. The typical functions that are performed in a receive pipeline include the following:

• Decoding and parsing of incoming data such as an XML file or a flat file
• Validation; for example, verifying the incoming data against an XML schema
• Party resolution

Likewise, any message subscriber can configure a send pipeline to preassemble the message data before it is transferred out on the physical send port. Typical functions that are performed in a send pipeline include the following:

• Validation
• Assembly of an XML document
• Encoding
• Digital signing

Figure 2. BizTalk Server 2004 MessageBox database architecture

Even though all the filters (transformation components) in a pipeline have the same interface, some filters function independently and do not depend on other filters. For example, a filter may be used to transform data or to filter for a consuming service. In contrast, some filters inherently depend on other filters. For example, in some cases a message cannot be decoded by a filter until it has been encoded by another filter first. To make it easier to manage the semantic dependencies between filters, BizTalk Server 2004 defines stages for each pipeline. A stage is the portion of a pipeline that is dedicated to a certain type of work. Each available filter is assigned to a specific stage of the pipeline. A receive pipeline consists of the following stages:

• Decode
• Disassemble
• Validate
• Resolve Party

A send pipeline contains the following stages:

• Pre-Assemble
• Assemble
• Encode

Naturally, decoding the message is the first step that is performed in the receive pipeline, and encoding is the last step that is performed in the send pipeline. This design ensures that all other filters in the pipeline can work on messages that are not encoded.

BizTalk Server 2004 supplies default pipelines for frequently recurring needs, such as parsing an incoming XML message. If you need a more tailored functionality, you have the following options:

• You can configure a custom pipeline by using the pipeline components (also known as filters) that are supplied in BizTalk Server 2004.
• You can configure a custom pipeline by writing custom filters in C# or Microsoft Visual Basic .NET.

This pattern focuses on the first option because the standard BizTalk Server 2004 pipeline components provide the functionality that is required for the Global Bank scenario without any custom coding. To assemble a custom pipeline that uses the pipeline components that are included in BizTalk Server 2004, you have to complete the following steps:

1. Create a custom send pipeline.

   First, you have to define a new pipeline. A pipeline definition is stored as a separate project file in Microsoft Visual Studio .NET.

2. Assign and configure the filters.

   The Pipeline Designer in BizTalk Server 2004 enables you to drag filters into the new pipeline. You can configure each filter by using the properties editor.

3. Build and deploy the pipeline.

   Pipeline definitions are compiled into a .NET Framework assembly. Before you can configure a send port or a receive port by using the custom pipeline definition, you have to deploy the assembly.

4. Assign a certificate to BizTalk Server 2004.

   This step is needed because the business requirement includes signing the outbound message with a certificate. Such a certificate is usually obtained from an outside certificate authority and is loaded into the certificate store of the local operating system. After the certificate is loaded, the certificate thumbprint has to be entered into the BizTalk Administration console. The thumbprint is a unique identifier.

   For a detailed description of certificates, see "Certificate Stores" in Windows XP Professional Product Documentation [Microsoft04].

5. Configure the send port to use the custom pipeline.

   After the custom pipeline is deployed, you can reference the custom pipeline in the configuration settings of a send port.

Example

To make the communication on Global Bank's external payment channel secure, you must create a custom send pipeline that signs and encrypts the outbound messages. This pipeline is used in conjunction with the Message Broker described in Implementing Message Broker with BizTalk Server 2004.

Based on the implementation strategy, you have to complete the following steps to implement the new custom pipeline by using BizTalk Server 2004.

Step 1: Create a Custom Send Pipeline

Pipeline definitions are created in Visual Studio .NET and are compiled into a.NET Framework assembly by using the Pipeline Designer. First, create a new BizTalk Server 2004 solution in Visual Studio .NET. Next, select Send Pipeline in the item list, and then add it to the solution. This opens the Pipeline Designer.

Step 2: Assign and Configure the Filters

In this step, you use the Pipeline Designer to drag predefined filter components from the Toolbox into the pipeline, as shown in Figure 3.

Figure 3. BizTalk Server 2004 Pipeline Designer and Toolbox

A send pipeline has three predefined stages: Pre-Assemble, Assemble, and Encode. The Global Bank solution requires only the Assemble and Encode stages, so leave the Pre-Assemble stage empty. The Assemble stage contains filters that convert message data from the BizTalk Server 2004 internal format to an external format, such as a flat file structure or an XML document. Because you want to send XML messages to the external bank payment system, add the XML assembler filter to this stage. You can use the default configuration for this filter.

The encryption and signing occurs in the Encode stage. This stage is the last stage. Add a MIME/SMIME encoder filter to this stage so that you can configure the encryption properties. Configure the properties as shown in Table 1.

Table 1: Properties for the MIME/SMIME Encoder Filter

Property	Value
Enable encryption	True
Encryption algorithm	DES3
Add signing certification to message	True
Signature type	BlobSign

The filter has built-in capability for DES3 and enables you to sign the message simply by selecting True for the Add signing certification to message property. The BlobSign value means that a signature is appended to the message and that the signature is encoded. When a message passes through this pipeline, the MIME/SMIME encoder uses the certificate to sign the message.

Step 3: Build and Deploy the Pipeline

Save the pipeline definition. Then, build and deploy the project from Visual Studio .NET to make the pipeline definition available for port configuration.

Step 4: Assign Certificates to BizTalk Server 2004

BizTalk Server 2004 uses two distinct certificate stores in this scenario. A certificate store is the system area where certificates are stored. To sign outgoing documents, BizTalk Server 2004 uses certificates from the Personal certificate store. For a detailed description of how to import certificates, see "Certificate Stores" in Windows XP Professional Product Documentation [Microsoft04]. Each certificate has a thumbprint that is generated by running a hash algorithm across the public key portion of the certificate.

First, view the thumbprint on the Details tab in the Certificate dialog box for the certificate, as shown in Figure 4.

Figure 4. A certificate thumbprint

Next, configure the server running BizTalk Server 2004 with the certificate thumbprint. To do so, start the BizTalk Administration console. Then, configure the signing certificate thumbprint on the General tab in the Microsoft BizTalk Server 2004 (Local) Properties dialog box, as shown in Figure 5.

Figure 5. BizTalk Server 2004 properties

Use the same certificate to sign outgoing messages for all servers in the BizTalk Server 2004 group.

To encrypt outgoing messages, BizTalk Server 2004 uses the Local Machine\Other People certificate store. This certificate store holds public key certificates. Multiple certificates can be stored and then used to encrypt messages to specific parties. The certificate used to encrypt the message is specified in the send port configuration.

Step 5: Configure the Send Port to Use the Custom Pipeline

Now that the custom pipeline definition is deployed in a global assembly, you can use it in the configuration of the send port, as shown in Figure 6.

Figure 6. BizTalk Server 2004 send port properties

You can now connect the new send port to the MessageBox database as described in Implementing Message Broker with BizTalk Server 2004.

Resulting Context

Using Pipes and Filters with BizTalk Server 2004 results in the following benefits and liabilities:

Benefits

• Filter reuse. BizTalk Server 2004 users can reuse both the pipeline definitions and the set of pipeline filters across different ports. For example, the MIME/SMIME encoder filter is suitable for any application that needs to send MIME or S/MIME messages.
• Amenable for graphical tools. Programming the pipeline involves connecting and configuring filters by dragging components rather than by writing source code.
• Developer specialization. Pipes and Filters fosters the division of labor between different types of users. For example, C# developers build filters by using the Microsoft Small Business Customer Manager Filter SDK. Business users and developers who use BizTalk Server 2004 can assemble them without any programming.

Liabilities

• Restricts the filter types. BizTalk Server 2004 pipelines use filters that have a single input and a single output. This implementation of Pipes and Filters cannot accommodate filters that do not fit within this constraint.
• Overhead cost. BizTalk Server 2004 pipelines are very powerful when there are business rules and other types of processes on the data. However, the business rules and processes on the data are overhead if all that is required is a simple pipe between applications.

Testing Considerations

There are two main test scenarios when you use BizTalk Server 2004 to implement Pipes and Filters. The test scenario that applies to you depends on the customization option that you choose as your implementation strategy:

• Configure a custom pipeline by using the filters that are supplied with BizTalk Server 2004. In this case, you build the custom pipeline and configure the filters by using the Pipeline Designer. You then create a test configuration that uses this custom pipeline in either a receive port or a send port. You can then submit test messages and validate the resulting output.
• Configure a custom pipeline by writing custom filters in C# or Visual Basic .NET. In this case, you can test the pipeline component by creating a test configuration that uses the component in a custom pipeline as described earlier. You can also use Microsoft Visual Studio .NET to review the pipeline component code.

Security Considerations

In addition to security features that are provided by the transports, such as encryption when using HTTPS, BizTalk Server 2004 provides security at the message level. BizTalk Server 2004 can receive decrypted messages and validate digital signatures that are attached to these messages. Similarly, BizTalk Server 2004 can encrypt messages and attach digital signatures to messages before sending them. You can also purchase or develop custom security components as required.

Note   The BizTalk Server 2004 host instance runs the send pipelines and the receive pipelines within a specific security context. Therefore, any processing that the pipeline components perform operates within this security context. This security context may impose constraints on the way that the custom component accesses a database. The security context may also impose constraints on the location in the certificate store that the component can access a digital signature from.

Operational Considerations

BizTalk Server 2004 provides extensive support for application monitoring. Users can monitor the messages that are going through each pipeline. Users can therefore also monitor the ports the pipeline uses. BizTalk Server 2004 users can configure each send port or receive port to track messages, as shown in Figure 7.

Figure 7. BizTalk Server 2004 port-level tracking

The Health and Activity Tracker (HAT) tool in BizTalk Server 2004 provides access to port-level tracking information that allows you to see what is happening in the system. It also allows you to examine archived data for patterns or trends.

Acknowledgments

[Microsoft04] Microsoft Corporation. "Certificate Stores." Windows XP Professional Product Documentation. Available from Microsoft.com at https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_cmuncertstor.mspx.

Start | Previous | Next

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.