Comparing Microsoft BizTalk Server and WebSphere Message Broker

This article compares Microsoft BizTalk Server and WebSphere Message Broker by showing you how to implement a common ESB pattern on each system.


Mohab El-Hilaly (, Consulting IT Specialist, IBM

Photo of Mohab El-Hilaly Mohab El-Hilaly has nine years of IT experience and is an IBM Certified Level-2 IT Specialist. His areas of expertise include Business Integration and Connectivity, especially around WebSphere Message Broker and Microsoft BizTalk. Mohab joined IBM Egypt in 2005 and has worked with numerous IBM customers implementing Business Integration and Connectivity solutions. You can contact Mohab at

Mahmoud Galal (, Executive IT Specialist, IBM

Photo of Mahmoud GalalMahmoud Galal has 20 years of IT experience and is an IBM Certified Level-3 IT Specialist. His areas of expertise include Business Integration and Connectivity, focusing on WebSphere Message Broker. Mahmoud joined IBM Egypt with the Holosofx acquisition in 2002 and worked as a Senior Software Engineer on the WebSphere Business Monitor Development team, contributing to several releases of the product. He then moved to IBM Lab Services, where he has worked with numerous IBM customers implementing Business Integration and Connectivity solutions. You can contact Mahmoud at

06 February 2013


Microsoft® BizTalk® Server and IBM® WebSphere® Message Broker are ESB products with comparable functionality, but quite different implementation and internal architecture. This article bridges the conceptual gap between the two products in order to facilitate migration between them. The article provides a common ESB pattern, and shows you how to implement it on Microsoft BizTalk Server 2010 (hereafter called BizTalk) and on WebSphere Message Broker V8 (hereafter called Message Broker).

BizTalk overview

BizTalk is a connectivity and integration solution that facilitates integration between disparate applications and solutions using more than 25 multi-platform adapters. In addition to this integration functionality, BizTalk provides messaging, business activity monitoring, and a rules engine.

Message Broker overview

Message Broker is a comprehensive ESB that delivers a full range of integration capabilities, including content-based message routing and transformation, message enrichment, message logging, and a wide range of message distribution options and protocols to improve the flexibility and performance of services in an SOA. It can integrate a wide variety of applications, networks, and device types using a platform-independent ESB that serves as an ideal SOA platform. Message Broker was introduced about 10 years ago and now has several hundred enterprise-scale implementations in customer shops.

Message Broker uses the WebSphere MQ messaging infrastructure, and has built-in graphical mapping and support for diverse programming languages and environments, including Java, ESQL, and XSL, for customization and other extended functionality. Message Broker helps reduce development costs by separating integration logic from applications, and it provides administration and systems management functionality.

Scenario description

A company has a Customer Complaint Management application that enables customers to report complaints. This legacy application obtains complaint data from a file, processes it, and sends feedback to the customer The company wants to implement a web service interface to enable customers to submit complaints through web clients. The web service interface should receive the complaint using SOAP/HTTP transport protocol, and save the complaint data to a file in a preconfigured location where it can be processed, and then respond back to the customer.

Implementing on BizTalk

BizTalk provides several ways to expose an existing WSDL as a web service. The solution described in this article consists of:

  • Two-way Receive Port – Receives the message
  • Receive Location – Strips the SOAP envelope and routes the message to the message box
  • Orchestration – Receives the message, sends it to the File Send port, transforms it, creates a response, and returns it to the caller
  • File Send Port

The first step is to create the orchestration using the WSDL. After deployment, you create the bindings and send ports.

  1. Open Visual Studio.
  2. Create a new solution and an empty BizTalk project: Create new solution and an empty BizTalk project
  3. Right-click on the newly created project and click Add generated item.
  4. Select Consume WCF service. Even though you are going to consume the WCF service, use the generated artifacts to define the web service request and response. Consume WCF service
  5. A BizTalk WCF Consuming Wizard opens. Click Next.
  6. Select Metadata files (WSDL and XSD) and then click Next: Select metadata files
  7. Click Add, browse to the WSDL on your local hard drive, and then click Next: Browse to WSDL file on your local hard drive
  8. Change the namespace and click Import: Import

    Within the newly created project, you should find artifacts generated from the imported WSDL. What is important are the definitions of the web service request and response messages, as well as the ports. You will use the definitions to create the orchestration logical ports.

  9. Right-click on the project and select Add new item.
  10. Select BizTalk orchestration: BizTalk orchestration
  11. On the newly created orchestration, right-click on the port surface, select New configured port, and then click Next.
  12. Change the name of the port to SubmitComplaint and then click Next.
  13. Select Use an existing port type, select the generated port type, and then click Next: Select generated port type
  14. For Port direction of communication, select I'll be receiving a request and sending a response. For Port binding, select Specify later: Configure port
  15. Click Next and then Finish. You should see the logical port created as shown below: Logical port
  16. Create the Logical Send Port: right-click on the port surface and select New configured port, and then click Next.
  17. Select a Port Name, such as SendRequest, and then click Next.
  18. Select Create new port type, enter a name for the port type, select One-way for the Communication pattern, and then click Next: Create new port type
  19. Select I'll always be sending messages on this port and leave Port binding as Specify later: Port binding

Developing the business logic

Now you are ready to start developing the business logic in the orchestration. This article will not detail how to create the orchestration shapes, but will show what the orchestration should consist of. This table shows the orchestration shapes with the type and function of each shape:

Receive PortReceiveLogical representation of a Receive Port within the orchestration.
Sends copy of request message to Logical Send PortSendSends a copy of the request message to the Logical Send Port.
Construct and TransformConstruct and TransformConstruct Message constructs the response message that will be returned to the caller. Within Construct Message, create a Transform Shape with a map to construct the response message.
Send message back to callerSendSends newly constructed message back to caller.

The full orchestration should look like the image below. Click here to enlarge the image.

Orchestration diagram

Build the project and make sure there are no errors. The next step is to expose the orchestration as a WCF service:

  1. Open the BizTalk WCF Service Publishing Wizard and then click Next.
  2. Select the transport type -- for this example, use WCF-WSHttp. For "Create BizTalk receive locations in the following application," select BizTalk Application 1: Select transport type
  3. Click Next.
  4. Select Publish BizTalk orchestrations as WCF service and then click Next: Publish BizTalk orchestrations as WCF service
  5. Browse to the compiled orchestration .dll file and then click Next: Browse to compiled orchestration .dll file
  6. Select the port that will be exposed and enter the namespace as written in the WSDL file: Select port that will be exposed and enter namespace
  7. Select the location of the service: Select location of service
  8. Click Next and then click Create.

A Receive Location and Receive Port should be created on the BizTalk server. The final series of steps binds the orchestration to the Receive Port and creates a Send Port to write the file that will be bound to the logical Send Port of the orchestration.

Binding the orchestration

  1. After signing the project, deploy the orchestration using Visual Studio.
  2. Right-click on Send port and select Static one-way send port.
  3. Enter a name for the port and select FILE as the type: Select port name and type
  4. Click Configure and select the destination folder: Select destination folder
  5. Locate the orchestration and click Bindings. Bind the logical Receive Port to the generated Receive Port as well as the logical Send Port to the newly created Send Port: Bind ports
  6. Start the orchestration as well as all Send Ports and Receive Ports.

The service is now ready for testing, which you can do using any web service consumer tool. This example uses SOAPUI.

Implementing on Message Broker

  1. Open WebSphere Message Broker toolkit, right click in the Broker development window, and then select New => Application: Create new application
  2. A new window opens for you to enter the Application name. This example uses RegisterComplaintApp: Create new application
  3. Model the web service WSDL interface to be used for the exposed service. In the newly created application, click the twisty next to Application Component, then right-click and select New => Message Model: New message model
  4. Select the first option, SOAP XML: Select model type
  5. Since you already have a WSDL file, select the fifth option as shown below: Select WSDL source
  6. Click Select file from outside workspace and browse to the location where you saved the service WSDL file: Select WSDL
  7. Click Next and then click Finish to completely create a new model for your WSDL file: Select SOAP and HTTP binding
  8. The WSDL is imported and a new model is created as shown below: Imported service WSDL
  9. Create a new message flow to implement the required service: Right-click and select New => Message flow. A dialog window opens as shown below. For Message flow name, enter RegisterComplaint and click Finish. Create message flow
  10. Open the newly created message flow, which will open with an empty canvas. Locate the WSDL interface you imported before and drag it to the empty canvas. A dialog window opens as shown below, to enable you select the creation option. You need to expose the flow as web service, so select the first option. In case the WSDL contains multiple operations, you can select which operations you need to support. Create web service flow
  11. The next step lets you select which types of nodes to use. Message Broker offers two types of nodes -- SOAP and HTTP -- and both can be used to interact with web services. In general, use SOAP nodes when working with SOAP-based web services. Mark the SOAP nodes and then click Finish: Select node type
  12. The toolkit generates the implementation skeleton and one extra subflow to filter for the specified operation. In a later step, you need to add more nodes to implement the service and any required business logic: Toolkit-generated web service flowOperation extract generated subflow
  13. The main flow canvases have the following extra Message Broker nodes to implement the web service:
    • Trace node -- Captures errors
    • Flow Order node -- Enforces order of operations, forcing first path to be processed first and second one second.
    • File Output node -- Saves message into a file as configured for later processing by the legacy application.
    • Mapping node -- Enables graphical mapping from the input message to the output message.
  14. Here are the final flow and the mapping node mapping details: Web service implementation flowMapping node

The flow is now ready, with no need to write any extra code. Message Broker supports several methods of message transformation, including the Mapping node, ESQL code, Java, XSL and more. Choose one based on the complexity of the mapping and the developer skills available.

Deploying and testing the service

  1. Right-click the application name and select Deploy. A dialog window opens to let you select the target broker and target execution group, as shown below: Deploy application
  2. The service is now ready for testing. You can use any web service consumer to test it. This example uses the soapUI tool.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Comparing Microsoft BizTalk Server and WebSphere Message Broker