Introduction to BizTalk.NET Services

Background

BizTalk.NET Services (https://labs.biztalk.net) is a nascent and experiemental project that is all about generic, secure connectivity. Many WCF customers ask us how to notify client applications that something has happened in a service. If the client is addressable and listening, this is a fairly easy question to address. In fact, there is an SDK sample that addresses (pun intended) that exact scenario. However, when one of the clients is not addressable (behind a firewall or NAT), the problem becomes much harder. After all, how can a client receive incoming messages if it's listening address is virtually invisible outside the firewall or NAT?

This problem is not new. Connected applications like Groove, FolderShare, Skype, and all manner of Instant Messenger have had to solve this problem. Each of these applications has solved this problem in their own way, and with their own resources. Even though each of these business had to solve the problem, the physical characteristics of networks and the commonality of the requirement fostered (perhaps) similar design charachteristics. In the cases I am aware of, instances of these connected applications (i.e. clients) call out from behind a firewall or NAT to one or more servers in the internet. For the duration of that established socket, the server is able to send data back to the client. If, during the lifetime of that socket, another instance of the same connected application calls into the server, then the server is able to pass data from one instance of the connected application to another.

Though I don't have much emprical evidence to prove it across the board, my guess is that the connectivity quest undertaken by these development teams was not cheap or easy. Nonetheless, connected application vendors have all incurred this cost, and, in some form or fashion, solved the connected application problem in a proprietary manner. In some cases (like Live Messenger and Yahoo Messenger), some level or interoperability is possible, but they are generally point solutions.

Where does this leave organizations that don't have the budget, expertise, or time to implement a custom connectivity solution? This is the problem space where BizTalk.NET Services thrives. An organization can use BizTalk.NET Services to handle the connectivity, and frees up development resources to focus on the functionality of the application. The hope is that alleviating the connectivity burden allows organizations to deliver better applications faster and cheaper.

State of the Project

As of the date of this post, BizTalk.NET Services is in CTP form, and the team has adopted an Agile mindset. They drop code frequently, and alter the trajectory of the project based on feedback (and other things). As I understand it, the team had not committed to a release date, and there are many discussions internally regarding how these services will be made available to the community and customers.

In my discussions with the team, there is no doubt that they are eager to receive feedback about existing and non-existing features. As an example, the latest drop includes support for username / password security. Before this drop, the product had support for CardSpace security only. The inclusion of username / password security was largely driven by community feedback.

I encourage you to download the BizTalk.NET Services SDK and write some code with it. You can find it here (https://labs.biztalk.net). That site also includes links for how to provide feedback to the team.

How BizTalk.NET Services Surfaces to the Developer

In it's current form, BizTalk.NET Services is visible to developers via a new WCF binding (named the RelayBinding). The RelayBinding type utilizes WCF extensibility points and creates a channel stack that knows how to communicate with the BizTalk.NET Services servers in the cloud. More specifically, the RelayBinding creates a channel stack that includes a new transport channel that can connect with the BizTalk.NET Services servers in the cloud. The URI passed to this channel has a new scheme that helps distinguish it from other transports (sb://). The RelayBinding can be used with the existing ServiceHost implementations for listening, as well as the existing ChannelFactory<T> implementations to send messages to other messaging participants.

The transport channels do the heavy lifting of connecting to the servers in the cloud as well as participating in sending and receiving messages. The servers in the cloud do the heavy lifting of connecting applications. The compostion of the URI and the configuration of the RelayBinding object (and the resultant channel stack) dictate which applications are connected and how they are connected to one another.

Several types of connections are possible, and these will be the subject of another post (or several other posts).

One of the takeaways with this model is that user or applicaiton code is not hosted in the cloud. The services in the cloud broker the connections between instances of a client application.

Futures

As I understand it, the team's work items include furthering the scalability of this system, the inclusion of workflow into the services, and enhancing the security features of the services. Keep in mind that this project is nascent, and the team is intentionally agile. If you have opinions or feedback about any of these features, I encourage you to contact the team via the address shown earlier.

I fully expect to write much more about this cool new project, so stay tuned.