I spent some time today summarising the new features in the Windows Azure AppFabric May CTP for SolidSoft consultants. Microsoft released the CTP a couple of weeks ago and has a second CTP coming out later this month. I might as well publish this here, although it has been widely blogged on already. There is nothing that you can’t glean from reading the release documents, but hopefully it will serve as a shorter summary.
The May CTP is all about the AppFabric Service Bus. The bus has been extended to support ‘Messaging’ using ‘Queues’ and ‘Topics’
‘Queues’ are really the Durable Message Buffers previewed in earlier CTPs. MS has renamed them in this CTP. They are not to be confused with Queues in Windows Azure storage! Think of these as ‘service bus queues’. They support arbitrary content types, rich message properties, correlation and message grouping. They do not expire (unlike in-memory message buffers). They allow user-defined TTLs. Queues are backed by SQL Azure. Messages can be up to 256KB and each buffer has a maximum size of 100 MB (this will be increased to at least 1GB in the release version). To handle messages larger than 256KB, you ‘chunk’ them within a session (rather like BTS large message handling for MSMQ). The CTP currently limits you to 10 queues per service namespace.
Service Bus queues are quite similar to Azure Queues. They support a RESTful API and a .NET API with a slightly different set of verbs – Send (rather than Put), Read and Delete (rather than Get), Peek-Lock (rather than ‘Peek’) and two verbs to act on locked messages – Unlock and Delete. The locking feature is all about implementing reliable messaging patterns while avoiding the use of 2-phase-commit (no DTC!). Queue management is very similar, but configuration is done slightly differently. AppFabric provides dead letter queues and message deferral. The deferral feature is a built-in temporary message store that allows you to resolve out-of-order message sequences. Hey, this stuff is actually beginning to get my attention!
Today’s in-memory message buffers will be retained for the time being. MS is looking at how much advantage they provide as low-latency non-resilient queues before making a decision on their long-term future. This is beginning to sound like the BizTalk Server low-latency debate all over again! Currently, the documented recommendation is that we migrate to queues.
‘Topics’ provide new pub/sub capabilities. A topic is…drum roll please…a queue! The main difference is that it supports subscription. I assume it has the same limitations and capabilities as a normal queue, although I haven’t seen this stated. It is certainly built on the same foundation. You can have up to 2000 subscriptions to any one topic and use them to fan messages out. Subscriptions are defined as simple rules that are evaluated against user and system-define properties of each message. They have a separate identity to topics. A single subscription can feed messages to a single consumer or can be shared between multiple consumers. Unlike Send Port Groups in BizTalk, this multi-consumer model supports an ‘anycast’ model for competing consumers where a single consumer gets a message on a first-come-first-served basis. MS invites us to think of a subscription as a ‘virtual queue’ on top of the actual topic queue. Potential uses for anycasting include basic forms of load balancing and improved resilience.
The CTP supports AppFabric Access Control v2.0. It is fully backward-compatible with the current service bus capabilities in AppFabric.
CTP does not have load balancing and traffic optimization for relay. These were in earlier CTPs, but have been removed for the time being. They may reappear in the future.
The June CTP will introduce CAS (Composite Application Services). CAS is a term used by other vendors (e.g., SAP) for similar features, and has been a long time coming in the Microsoft world. The basic idea is that you build a model of a composite application, the services it contains, its configuration, etc., and then drive a number of tasks from this model such as build and deployment, runtime management and monitoring. Some of us remember an ancient Channel 9 video on a BizTalk-specific CAS-like modelling facility that MS were working on years ago. It was entirely BizTalk-specific and never saw the light of day. However, one connection to make is that CAS will provide capabilities that are conceptually related to the notion of ‘applications’ in BizTalk Server.
We will get a graphical Visual Studio modelling tool to design and manage CAS models. The CAS metamodel is implemented as a .NET library, allowing models to be constructed programmatically. Models are consumed by the AppFabric Application Manager in order to automate deployment, configuration, management and monitoring of composite applications.
So, things are rapidly evolving. However, we won’t see anything on Integration Services until, I suspect, next year. It’s important to remember that the May CTP is all about broadening the existing Service Bus with messaging capabilities, rather than about delivering an integration capability. So, even though we are seeing more BizTalk Server-like features, we are still a long way off having what Burley Kawasaki called a “true integration service” in the cloud. Obviously, Azure Integration Services will exploit and build on the Service Bus, but a lot more needs to be done before we have integration-as-a-service as part of the Azure story.