Announcing the Microsoft Code-Name “BizTalk Services” R12 Release
We’re thrilled to announce that the BizTalk Services “R12” Community Technology Preview (CTP) is now available for general use.
“BizTalk Services” is the code-name for a platform-in-the-cloud offering from Microsoft. Currently in active development, BizTalk Services provides Messaging, Workflow, and Identity functionality to enable disparate applications to connect quickly and easily.
Combined together in an integrated offering, these capabilities deliver a Service Bus architectural pattern that is immediately usable by applications that need to connect across the Internet.
Many enterprises employ the ‘Enterprise Service Bus’ pattern to interconnect disparate systems within an organizational domain. Built on Microsoft platform technology, an ESB might include building blocks such as Windows Server, Active Directory, BizTalk Server, as well as the Windows Communication Foundation and Windows Workflow Foundation technologies included in the .NET Framework. “BizTalk Services” extends the concept of an ESB to truly exploit the Internet, for instance by exposing individual service endpoints in a secure fashion or by selectively federating elements of distinct identity systems to facilitate cross-company collaboration.
For ISVs and Solution Providers creating specialized business solutions that enable collaboration and information exchange across increasingly mobile and distributed work-forces, “BizTalk Services” provides the cloud-based platform building blocks to create sophisticated (Internet-) Service Bus solutions with broad reach that could otherwise only be realized by operating dedicated Data Centers of significant complexity – which is often out of reach for both, ISVs and their customers.
Major Changes
With the release of BizTalk Services “R12”, developers must update all clients and SDK installations to the new release.
New in R12 - Workflow
The most exciting new capability we’ve added in the “R12” CTP is Workflow. These new cloud-based Workflow capabilities enable ‘service orchestration’ from the cloud. This specialized cloud-based, or hosted, Windows Workflow Foundation runtime can orchestrate services that connect to systems in your enterprise, or to systems running anywhere on the Internet via Web services messages. This new power and capability will enable an entirely new set of application scenarios, and we’re very excited to see what people will do with it.
In the SDK you will find samples showing how to create and control Workflow instances hosted on the BizTalk Services cloud, including a sample Workflow implementation that monitors the availability of a website and fires multicast events into the service bus indicating the state.
New in R12 - Identity
For R12, the BizTalk Services Identity Service has been expanded and enhanced to enable more flexibility for scenarios demanded by our customers. R12 introduces a new approach for creating, viewing, and managing access control rules. This approach relies on a few key principles outlined below:
• Every Identity Service account owns a Security Token Service (STS).
• An STS is composed of one or more scopes.
• A scope contains zero or more access control rules.
• An STS owner can grant another Identity Service account permission to edit the access control rules in a scope
A practical illustration to clarify:. The Messaging Service owns an STS whose root scope is http://connect.biztalk.net/services/. When you create a new account (newaccount) in the Identity Service, the messaging service creates a new scope http://connect.biztalk.net/services/newaccount. The Messaging Service then grants (newaccount) the permission to create access control rules in that scope. Any communication endpoints hosted there can thus be secured by the owner of the scope. Rules from R11 accounts have been migrated to the “root” scope of the new account.
On the protocols front, we’ve added several new capabilities for ‘REST’ services. We now support integration with Windows Live ID and have added RFC2617 Basic and HTTPS/Client Certificate support for acquiring security tokens using simple HTTP GET requests.
New in R12 - Messaging
Connectivity Modes
The most fundamental new feature area in the Messaging service are the new ‘connectivity mode’ settings on the RelayBinding. Before this release, BizTalk Services clients and listeners always required outbound TCP ports 808 and 818 to be available for connecting to the BizTalk Services cloud for all connection modes except the clients of a listener running with ConnectionMode.RelayedHttp.
In this release we are introducing three different connectivity modes: Tcp, Http, and AutoDetect. The connectivity mode can be set on a static property of the RelayBinding. The Communication\ExploringFeatures\ConnectionModes\Multicast sample shows how. For clarity: ‘Connection Mode’ defines the type of end-to-end connection that is to be established through the Relay. ‘Connectivity Mode’ defines how a particular endpoint connects up to the Relay.
The ‘Tcp’ connectivity mode is the most efficient one and works as in previous releases. The ‘Http’ mode is new. It creates a volatile FIFO buffer for messages in the BizTalk Services cloud and polls for messages using HTTP ‘parked requests’. The Http model exhibits delivery latency characteristics similar to Tcp mode, albeit with slightly higher bandwidth consumption on idle connections. The ‘AutoDetect’ mode will check whether TCP connectivity is available and will choose ‘Tcp’ if that’s the case and ‘Http’ otherwise.
The new HTTP-based connectivity option is only effective for the RelayedOneway, RelayedMulticast and RelayedDuplex connection modes. RelayedDuplexSession, HybridDuplexSession, and RelayedHttp (listener only) still require TCP connectivity at this time.
Transport Credentials and Unauthenticated Access
Also, in the “R12” release, the model for specifying the client credentials for the Relay has now been closely aligned with the standard WCF client credentials model. Instead of picking and instantiating token providers, there is now a TransportClientEndpointBehavior that holds all credential information and credential types. The samples in the Communication\ExploringFeatures\RelayAuthentication of the SDK download clarify the use of this new behavior.
We have added a pair of ‘WebNoAuth’ samples which introduce a new capability that we had a lot of requests for: Unauthenticated client access. When registering a service listener you can now explicitly waive the authentication requirement for clients connecting to your service. This is very useful in Web scenarios where you want to enable any HTTP client to connect to your service and don’t want them to authenticate in any way. For the time being we suggest that you always use this new unauthenticated access mode for RelayedHttp services until we release the update for the ‘Web’ client authentication capability.
For R12, we have omitted the ‘Web’ (REST) samples for Relay authentication since that area is undergoing some substantial protocol changes. The update for this will be released soon. In the interim, existing applications that were built on a prior release of the BizTalk Services SDK to use the authentication technique shown in the R11 ‘Web’ sample must be modified to use unauthenticated access as shown in the new ‘WebNoAuth’ sample.
Give it a try
The new BizTalk Services “R12” CTP is online and available now for your use. The SDK is available at http://labs.biztalk.net. If you already have an account for BizTalk Services, your accounts and settings have been migrated to the new environment. If you don’t have an account yet, just sign up, download the SDK, and get started creating the new generation of connected applications.