BizTalk 2009 : WCF LOB Adapter SDK - WCF LOB Adapters vs. WCF Services

Now imagine a situation when your LOB application is, for example, DBMS-based. Further imagine that as your application evolves, the number of stored procedures (or metadata^[] in terms of ASDK) keeps growing. To expose the new operations to external clients through WCF services, the service provider will either have to update existing contracts or implement new ones by essentially starting the cycle again.

^[] Although metadata is a very broad term and it is hardly possible to give a one-size-fits-all definition, in the context of the WCF LOB Adapter SDK, metadata can be defined as a set of data, operations, and other artifacts determining and constituting functionality of the target LOB system. For example, metadata for a DBMS-based application can be stored procedures and data tables, or it can be assemblies containing classes implementing the application's business objects. It is up to the adapter designer to decide what constitutes metadata for a particular application and how to expose it to the adapter consumers.

1. Dynamic Metadata Discovery and Resolution

The issue is that WCF contracts are static by its nature. If the underlying LOB application changes and you want to make the new functionality available to external clients, the existing contracts also have to change. In contrast, WCF LOB Adapters offer dynamic metadata discovery and resolution at design time. All changes in the underlying LOB system will be available automatically.

Let's look at a concrete example. As you likely know, BizTalk Server 2009 ships with a BizTalk Adapter Pack containing adapters for major LOB systems built using ASDK. Assume you are using the SQL Server Adapter from the pack to communicate with your SQL Server-based LOB application. To generate a proxy file for your .NET application, you will use the Add Adapter Service Reference plug-in, as shown in Figure 1. This plug-in functionally is similar to the Add Service Reference dialog box that you use to generate a proxy for WCF services.

When new stored procedures become available, adapter consumers who want to use those procedures will of course have to regenerate proxies using the Add Adapter Service Reference plug-in. The most important thing is that the new stored procedures will be discovered by the adapter and show up in the plug-in automatically, with no action required from the adapter developers.

Figure 1. Add Adapter Service Reference plug-in

Although the process we've described sounds like magic, of course it is not. It is the sole responsibility of the adapter developer to implement the interfaces to enable adapter metadata capabilities. If that seems confusing, please read on. After completing the walk-through later in the chapter, you'll have a much clearer idea of how this "magic" actually happens.

As a general rule, Microsoft suggests^[] the following guidelines for evaluating whether your organization will benefit from using ASDK.

^[] http://msdn.microsoft.com/en-us/library/bb798089.aspx

You should consider writing adapter when:

• the target system is an existing system that is not enabled for web services;

• the target system is dynamic and can be enhanced with new operations;

• the target system has a large amount of metadata;

• there is a large, diverse number of users for the target system's data; or

• consuming applications need rich application metadata discovery functionality.

You should use the WCF service or channel model to create a service when:

• the target system is static and has a fixed set of operations;

• the target system has little or no metadata;

• service developers have detailed knowledge of the application to be exposed; or

• a new application is being exposed.