Knitting an Integration Solution with BizTalk Services

Woven throughout the fabric of the Web are various protocols, specifications, and public technologies, each solving some particular problem. These common Internet acronyms have become more than simply a name. Often, the name evokes a whole set of patterns for solving a problem. Take for instance FTP, HTML, XML, or SOAP. I’ll add Internet Service Bus (ISB) to this growing list of pattern acronyms.

An ISB is a services “fabric” operating completely in the Internet rather than mostly in the Enterprise like Enterprise Service Buses and other messaging technologies. A few months ago, Microsoft released a Community Technology Preview (CTP) ISB called BizTalk Services. BizTalk Services CTP is to the Enterprise Application Integration (EAI) or Messaging world what Hotmail or GMail is to the email world. So, think of it as a free “as-is” software service for service-based EAI or Messaging solutions.

I’m going to explain all the pieces of BizTalk Services so you can weave your own EAI or Messaging solution into its fabric. Beyond building a messaging solution for today, you will also glimpse the potential future of BizTalk and WCF.

The BizTalk Services Tapestry

BizTalk Services introduces the concept of an Internet Service Bus (ISB). Integration products commonly serve as a Broker or a Message Bus and provide security in many solutions. An ISB serves the same purpose, only it’s provided as a Service across the Internet rather than something you must configure and maintain inside your organization. Like many Integration solutions, BizTalk Services embraces SOA concepts based on WS* (SOAP, WS-Trust, and so forth).

After reviewing the BizTalk Roadmap, it seems clear that WCF and WF will be the common “textile” for future BizTalk Solutions. Less clear is the depth these new solutions will go in solving business problems. Heavy emphasis on “feedback” and “exploring new ideas” gives one the impression that BizTalk Services hopes to open a dialog to answer some of these depth questions and give Microsoft direction on where the first stops are on the road to the future of BizTalk and the .NET Framework.

In its present incarnation, BizTalk Services is a Community Technology Preview (CTP). Reading material on the BizTalk Labs site makes this abundantly clear. Like many CTPs, it is not meant to be a complete solution, for now it seems to be a proving ground for new features in the .NET Framework.

BizTalk Services and the .NET Framework

BizTalk Services is built on top of Windows Communication Foundation (WCF) and Cardspace. A complete review of WCF and Cardspace is beyond the scope of this article. You will find helpful sources listed at the end of this article if these subjects are not familiar to you. The BizTalk Services site completely explains the product’s architecture, so I’ll only summarize here.

BizTalk Services architecture is divided into the following pieces:

  • Connectivity Service serves as a “Relay” for B2B solutions. The Relay servers are hosted by Microsoft. Applications using the Relay Binding send messages to the Relay. Listening applications listen for and retrieve messages from the Relay.
  • Identity Service handles security. Identity Service is a Security Token Service (STS). On the Client side, Identity Service relies on Cardspace.
  • Relay Binding is a main component of the BizTalk Services SDK. As with all WCF solutions, a Binding dictates a Transport, Message Encoders, Message Exchange pattern, and a Channel Stack.
  • Workflow support is hinted at a later date, but as of this article’s publication it is not supported.

Now, you’ll look at each one of these pieces in detail.

BizTalk Services SDK

The BizTalk Services SDK includes the Relay Binding, documentation, and sample code. If you’re familiar with WCF, you’ll have no trouble using BizTalk Services SDK. Sample WCF services are configured using the typical XML configuration. Below is a sample service.

<services>
   <!-- Application Service -->
   <service name="System.ServiceBus.Samples.EchoService">
      <endpoint name="RelayEndpoint"
                contract="System.ServiceBus.Samples.EchoContract"
                binding="relayBinding"
                bindingConfiguration="default"
                address="" />
   </service>
</services>

The most interesting thing about BizTalk Services is that it serves as Message Bus or Broker. Therefore, client and service side of BizTalk Service-based solutions need not interact directly with one another. Though they can use BizTalk Services to locate one another and then talk directly to each other.

BizTalk Services SDK includes all supporting assemblies. System.ServiceBus.dll is the core assembly. One interesting aspect about the assembly is its namespace. I’m accustomed to seeing samples and demos labeled something like Microsost.Sample.ThisDemo. I was surprised to see the namespace labeled like it’s part of the .NET Framework (System.ServiceBus).

SDK samples mostly follow a publish/subscribe exchange pattern, but exchange data in many different formats (images, RSS, Metadata, and so on). Microsoft and non-Microsoft people have created samples supporting other exchange patterns along with some other interesting sample applications. Looking at sample code is the best way to grasp how to interact with the Connectivity and Identity Services.

Connectivity Services

The Echo Service sample in the SDK is a base sample for a number of the other samples. The code below is part of the main client side section of the Echo sample.

Uri clientUri =
   new Uri(String.Format("sb://{0}/services/{1}/EchoClient/",
   RelayBinding.DefaultRelayHostName, userName));
Uri serviceUri =
   new Uri(String.Format("sb://{0}/services/{1}/EchoService/",
   RelayBinding.DefaultRelayHostName, serviceUserName));

ChannelFactory<EchoChannel> channelFactory =
   new ChannelFactory<EchoChannel>("RelayEndpoint",
   new EndpointAddress(serviceUri));
((RelayBinding)channelFactory.Endpoint.Binding).ClientBaseAddress =
   clientUri;
channelFactory.Endpoint.Behaviors.Add(tokenProvider);

EchoChannel channel = channelFactory.CreateChannel();
channel.Open();

One unusual aspect of the code is the URL formatting. Normally, the scheme contains some indication of the transport. So, instead of the “sb” you see in the code above, you normally see something like “http” or “net.tcp”. Translating the URL and contacting the Microsoft hosted servers is handled by the SDK.

Many administration, configuration, and provisioning aspects of BizTalk Services are handled on the BizTalk Services site. BizTalk Services appears to support a Taxonomy-like naming convention. So, services performing different categories or business functions can be compartmentalized or labeled.

As you run the samples, make sure you have an open port 808; many company firewalls block this port for security reasons. I would recommend running the samples from a Sandbox. Also, the URL formatting under Identity Services leads you to believe that the SDK uses the http transport when it fact it’s using net.tcp.

As I said earlier, this is a CTP, so it’s natural to have some missing functionality. Store and forward is something you typically see in a messaging solution. As of article publication, the BizTalk Services CTP does not support store and forward.

An important part of any web-based solution is security. BizTalk Identity Services handles security for BizTalk Services.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read