Share via

Design Considerations for Using WCF in Complex Business Communications, Part 2

  • Article

Applies to: Windows Communication Foundation

Published: June 2011

Author: Alex Culp

Referenced Image

This topic contains the following sections.

  • Interacting with Nonstandard Clients
  • Using an Enterprise Service Bus to Solve Integration Woes
  • Integration Scenarios
  • Conclusion
  • Additional Resources

Interacting with Nonstandard Clients

Another common integration challenge is how to communicate with nonstandard clients. A nonstandard client is any client application that cannot natively consume web services, or that cannot easily integrate with services that are exposed by WCF. Some clients that fall into this category are legacy Visual Basic 6 applications, mainframe applications, and old versions of Web Sphere. There are basically two approaches possible when there are integration problems between the client and the services. The first approach is to create an adapter on each client that will translate data to and from the service to something that the client understands. This is known as a client adapter. The second approach is to adapt the service to meet the needs of the client.

Client Adapters

The following figure illustrates how a client adapter mediates between a nonstandard client and a business service.

Referenced Image

A client adapter's design depends on the type of client. For example, a solution that integrates a legacy Microsoft® Visual Basic® 6 application with business services is completely different from one that integrates a mainframe application with business services. Because of this variability, a discussion of client adapters is beyond the scope of this article.

Adapter Service

The following figure illustrates how an adapter service mediates between nonstandard clients and a business service.

Referenced Image

As with client adapters, the design of service adapters varies with the client. Some examples of a service adapter include:

  • A hosting service that uses REST.

  • An adapter that exposes COM+ components that call the service on behalf of the client.

  • A Windows service that handles custom-formatted TCP socket connections.

Contract-First Development

A client may be considered nonstandard because it has very specific requirements that the service must meet. In other words, the service must meet a particular Web Services Description Language (WSDL) specification. If you must create a service that conforms to a WSDL file and its associated schemas, you must use the contracts to develop your code. This is known as contract-first development. Fortunately, WCF supports this. There is also a set of tools available named WCSF.blue that helps you to develop web services through a contract first approach. The tool set includes wizards and a tutorial. For more information, go to the WSCF.blue page on CodePlex at http://wscfblue.codeplex.com/.

Using an Enterprise Service Bus to Solve Integration Woes

Another way to solve integration problems is to use an Enterprise Service Bus (Enterprise Service Bus). An Enterprise Service Bus is messaging middleware that provides rules-based routing and enterprise integration. Many Enterprise Service Bus products support, to some degree or another, interaction with a number of nonstandard hosts and clients. An Enterprise Service Bus can often solve integration problems either by providing an adapter for the nonstandard hosts or clients, or by providing a framework that helps you create those adapters as plugins to the Enterprise Service Bus.

BizTalk and the Enterprise Service Bus Toolkit

It is impossible to talk about integration with nonstandard hosts without discussing Microsoft BizTalk Server, and the Enterprise Service Bus Toolkit. BizTalk is Microsoft's premier enterprise application integration (EAI) server. The BizTalk Enterprise Service Bus Toolkit 2.1 is a collection of tools and libraries that extend BizTalk Server 2010 capabilities. It functions as middleware that mediates between services and their consumers. Enabling maximum flexibility at run time, the BizTalk Enterprise Service Bus Toolkit 2.1 simplifies loosely coupled composition of service endpoints, and management of service interactions. For more information, go the Microsoft BizTalk Server page at https://msdn.microsoft.com/en-us/biztalk/dd876606

When to Use BizTalk

Here are some questions that will help you to determine if BizTalk is the right solution for integration with a nonstandard host or client.

  • Do I already have a BizTalk installation?

  • Do my BizTalk servers have the capacity to handle the extra load? If not, what is the cost to upgrade them?

  • Do I have other integration concerns that can be addressed by BizTalk?

  • Do I have the expertise in house, or do I need to hire a specialist?

  • Is my nonstandard host one that BizTalk can natively talk to?

When Not to Use BizTalk

BizTalk is a sizeable investment in terms of licenses, hardware, and often, consulting fees, so cost is probably the biggest factor to consider. Also, because of the performance considerations that are discussed in the next section, BizTalk might not be an appropriate solution for scenarios where there are a very high number of transactions per second, and where low latency is critical. Finally, BizTalk might not be the correct choice if there is a single integration problem. Custom development might be considerably cheaper, particularly if the application is one with a limited lifetime.

Performance Considerations

Because of BizTalk's architecture, all messages must go through the message box. This means that there will be at least one read and write from SQL Server. Often, there are multiple reads and writes. When using BizTalk for synchronous web service calls, there will always be a performance penalty. This penalty varies, depending on the hardware, the configuration, throttling, the architecture, and the level of orchestration. The BizTalk architecture makes it very important to consider the additional load on BizTalk. You may need to scale out the message box, and the underlying SQL Server instances.

Integration Scenarios

The following sections describe three different integration scenarios.

Visual Basic 6 (Nonstandard Client) Client Communicating with Web Services

In this scenario, a Visual Basic 6 client must consume web services. However, there is no support for this in Visual Basic 6. There are three ways to solve this problem.

Approach #1: Build a Client Adapter with Com Interop

Use the .NET COM Interop to build an adapter to communicate with the web service on behalf of the client. For more information on this approach, see "Using the WCF Moniker with COM Clients" on MSDN at https://msdn.microsoft.com/en-us/library/ms752245.aspx.

If the legacy Visual Basic 6 application runs on Windows Server 2000, you must use the 2.0 version of the framework. To write this adapter, you can use WSDL.exe to create the proxy that you will enable over the COM Interop.

Approach #2: Use Web Client to Open the Web Service

This approach opens an XML stream and uses an XML reader to parse through the results. For more information, see "Calling Web Services from Visual Basic 6, the Easy Way" on MSDN at https://msdn.microsoft.com/en-us/library/aa730836(v=vs.80).aspx.

Approach #3: Making the service look like COM+ component

This approach takes advantage of RegSvcs.exe to register types that are exported from SvcUtil. For more information, see "Integrating WCF Services with COM+" on MSDN at https://msdn.microsoft.com/en-us/library/bb735856.aspx#_Toc156817373.

Note

This approach requires .NET Framework 3.0 or greater.

Consuming SAP Data from SharePoint 2010

If you must consume data from SAP from the Business Connectivity Services (BCS) in SharePoint, then the best solution is to use the BizTalk Adapter Pack. The BCS can consume WCF services directly, so there is no reason to write custom code to consume the SAP data. For more information about the BCS, see https://msdn.microsoft.com/en-us/magazine/ee819133.aspx.

Communicating with a Legacy COBOL Mainframe Application

Typically, you must create an adapter in either C or C++ that will consume the services and deliver them to the COBOL application. If you want to consume data from a legacy COBOL application, you may need to create an adapter service that interacts with a green screen.

Conclusion

It is critical to identify interactions with nonstandard hosts and clients early in the development life cycle. When possible, use existing code or third-party adapters to integrate the nonstandard components into the system. When you must write custom code, the best practices that are discussed in this article should make the development process smoother.

Additional Resources

For more information, see the following resources:

Previous article: Design Considerations for Using WCF in Complex Business Communications, Part 1

Continue on to the next article: Authentication Boundaries with Unsecured Services