Pragmatic BizTalk Services: Introduction

A service bus is an architectural style or a service design pattern that provides a level of indirection between multiple cooperating services.  This indirection alleviates the differences in message exchange patterns, network protocols, authentication and authorization, and multiple other infrastructure mechanisms.  One of the best and shortest descriptions of a service bus is the following:

Once a service gets on the bus, anything else on the bus can connect to it. (Jon Flanders and Aaron Skonnard, June 2008 MSDN Magazine)

An Internet service bus (compared to an enterprise service bus), as the name implies, is a service bus that works on top of the Internet fabric instead of relying on a dedicated inter- or intra-enterprise network.  An Internet service bus is supposed to take care of even more annoying infrastructure details such as firewalls, naming conventions for Internet services, establishing direct channels of communication, and several others.

BizTalk Services is Microsoft's initial implementation of ISB components that are hosted at Microsoft's data center.  The technology is currently in a preview, and more details will certainly be delivered as part of the OSLO sessions during the upcoming PDC'08.

Instead of delving into an even-longer presentation of the various sub-features and sub-services BizTalk Services currently has to offer, I suggest we take a more pragmatic approach.  (Nonetheless, if you're interested in all the architectural details, read the MSDN Magazine article mentioned above, or go directly to the BizTalk Services Labs website and navigate through the documentation and SDK.)

What I would like to create in the first two installments of this open-ended series is a simple application that would allow me to access the files on my home computer from any other machine across the web.  (Yes, I realize that free and commercial solutions exist for this problem.  Yes, I want to roll our own.)

The first thing we're going to need to create a service that can connect to the Internet fabric provided by Microsoft is an account with BizTalk Services.  Opening an account is fairly straightforward - navigate to http://labs.biztalk.net/identity.aspx and choose "Create an Account" from the "Getting Started" section.

You'll be asked for a username, email address and password, and associate a CardSpace Information Card with the account.  If you already have a CardSpace card, a dialog similar to the following will suggest that you choose one of your existing cards:

If you don't have a CardSpace card, you can create one when asked to do so by Windows CardSpace.  You'll also be asked to associate the card with a nickname.  How cute.

Eventually, the account will be created and you'll be asked to sign in.

You can sign in with your information card, but the username and password combination will also work.  You can also manage your account later to associate it with a Windows LiveID.

If you choose "Rules" from the the "Manage Access Control" section you'll see that a set of default claims have already been created for your service operations.

These default claims indicate that the only user allowed to perform the Listen operation on the specified URL is sasha, and that any user (EveryOne) is allowed to perform the Send operation to the specified URL.  In other words, I'm the only one allowed to host the service under that URL, but anyone can talk to my service at that URL.  For the sake of my file sharing application, I will reconfigure the claims and remove the EveryOne part so that I'm the only person allowed at both ends of the pipe.

While creating an account, you can also download the SDK from this direct link or through the "Download the SDK" link in the above screenshot (it's just a tiny 3.24MB installation since it includes the client-side components of the bus - the actual bus implementation is provided by Microsoft and not shared in this SDK).

In the next post, we'll look at the actual service implementation.  Stay tuned!