Azure: Service Bus 1.0, Workflow 1.0 and SharePoint Workflow Host
This is the first part of my advices and feedbacks to the first Beta of known Azure-Services for on-premises installations. You can find the whole series also in the developers.de blog.
The OnPrem version of Windows Azure Service Bus is probably the first piece of Azure Cloud which can be installed on your laptop. Personally I would call it Enterprise Service Bus, which can and should be used for almost any kind of messaging in enterprise. The good thing on this is that exactly (more or less) the same version is running in the Windows Azure Cloud. The exactly same means in terms of API which developers will use. “More or less” means that there are still few differences.
The first and probably less important difference is Relaying feature. This feature is currently supported in the cloud only (at least for now). Queue and Topic messaging is fully supported.
Windows Token
However from the architecture point of view, it is more important that the On-Premise version (Service Bus Server) additionally to ACS uses Windows Token to access queues and topics. In order to make this work, SB supports internally some kind of Security Token Service, which is able to issue the ACS compatible token on behalf of Windows Token tight in the first message request.
This is all you should know for now about this STS. In fact it is transparent for developers and you shouldn’t even know that it exist. This information is interesting to understand that there is not any magic behind changed security system. Please note that Service Bus Server can also create a namespace in SB which uses ACS just like SB in azure.
Service Bus Configuration in PowerShell
The currently available release supports Power Shell Based configuration only. The RTM version will additionally support a Configuration Wizard.
Note that the Service Bus Explorer supports Service Bus Server (see link below).
Installation via WEB PI 4
Currently you will have to use WEB Platform Installer v4 http://www.microsoft.com/web/downloads/platform.aspx. to install the bits. The setup contains in fact two products: Windows Azure Workflow and Service Bus. Both products are installable on your machine. Yes, that’s right. Windows Azure Workflow is installable on the local machine. Depending on what you want to install, select SB or/and WF and proceed with installation.
Topology Facts
The SB cluster is supported with High Availability feature similar to caching service. That means HA is supported by 3+ nodes in the cluster.
The underlying database can be SQL Express (no joke), SQL 2008 and even SQL 2012.
Workgroups are supported too.
Up to now, bits can be installed on Windows 7 and Windows 8 client OS family. Both are currently supported for development purposes only.
Workflow 1.0
The workflow version installed here needs much more space and time to be explained. For now it is important that you can run your Workflows in Windows Azure. The same version can also be run on-premise. Unfortunately this version cannot use Windows Server AppFabric. The team has internally decided to build the new host for massive scale which activates Workflow Instances from Service Bus topic. At the moment you will have decide whether to use the Windows Server AppFabric host or this one. The new host has been specifically built for SharePoint 15 which is the first Microsoft product which will span its workflows on top of Service Bus on premise.
Note that the same host and workflow will be used by SharePoint Online Version.
With this version SharePoint has finally a serious host for running processes outside of SPS pool. My best wishes.(I was waiting almost 10 years for this). More experienced architects and developers might start to think about SharePoint as a SAP Netweaver. Please just don’t overuse it in this case (as often in the past of SPS).
Authoring of Workflows and SPS13 Workflows is WF 4.5.
NOTE, that not all activities of the common WF 4.5 version are supported. For example messaging activities (i.e. ReceiceMessage) and versioning are not supported. Fortunately there are special activities which can perform activation of workflow by message. In fact this is the only way to start the workflow.
If you want to use custom activities in On-Prem version of workflow, there are a few extra steps which you have to manually (for now) perform.
Following sample illustrate how to receive the message from topic.
using System;
using System.Collections.Generic;
using System.Net;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Description;
using Microsoft.ServiceBus.Messaging;
namespace Daenet.ServiceBus
{
public class Subscriber
private static string ServiceNamespace;
private static string Issuer;
private static string Key;
private static string TopicName = "demotopic";
static void Main(string[] args)
{
ServicePointManager.ServerCertificateValidationCallback = (a, b, c, d) =>
{
return true;
};
Uri rootAddressManagement =
ServiceBusEnvironment.CreatePathBasedServiceUri("https",
"testspace01", string.Format("{0}:{1}", "YOURHOST", 4446));
Uri rootAddressRuntime = ServiceBusEnvironment.CreatePathBasedServiceUri("sb",
"testspace01", string.Format("{0}:{1}", "YOURHOST", 9354));
NamespaceManagerSettings nmSettings = new NamespaceManagerSettings();
nmSettings.TokenProvider = TokenProvider.CreateWindowsTokenProvider(new List<Uri>() { rootAddressManagement });
NamespaceManager namespaceManager = new NamespaceManager(rootAddressManagement, nmSettings);
MessagingFactorySettings mfSettings = new MessagingFactorySettings();
mfSettings.TokenProvider = TokenProvider.CreateWindowsTokenProvider(new List<Uri>() { rootAddressManagement });
MessagingFactory factory = MessagingFactory.Create(rootAddressRuntime, mfSettings);
SubscriptionClient subscriptionClient =
factory.CreateSubscriptionClient(TopicName, "Subscription1", ReceiveMode.PeekLock);
while (true)
{
BrokeredMessage message = subscriptionClient.Receive(TimeSpan.FromSeconds(1500));
if (message == null)
break;
try
{
Console.WriteLine(string.Format("Message received: SEQUENCE = {0}, Id = {1},
Body = {1}", message.Properties["SEQUENCE"], message.MessageId, message.GetBody<string>()));
message.Complete();
}
catch
{
message.Abandon();
}
}
Console.WriteLine("\nEnd of receiving, press any key to exit.");
Console.ReadLine();
subscriptionClient.Close();
}
}
}
It is important in this sample that things like Issuer and Key are not required. The scope used by issuing of the token is like
scope=http%3a%2f%2yourhostname%2ftestspace01%2fdemotopic%2fSubscriptions%2fSubscription1.
The issued token is is private for developers and it will be passed internally to all calls to service bus. On thing of your interest is that this token contains claims which describe users AD membership. Based on this information SB will perform authorization.
Resources:
Service Bus Beta resources:
- Service Bus 1.0 Beta (download)
- Service Bus for Windows Server (Service Bus 1.0 Beta) MSDN documentation
- Service Bus Explorer for Windows Server
Workflow 1.0 Beta resources