Release Notes for the Windows Azure AppFabric CTP June Release

Before using the AppFabric CTP release, you must create a service namespace using the portal site. For more information, see Managing a Windows Azure AppFabric CTP June Release Account.

If you used releases of Windows Azure AppFabric CTP prior to the October release, made the recommended configuration file changes, and have been running the Windows Azure AppFabric samples against the earlier AppFabric CTP environment, note that in the AppFabric CTP June release environment the AppFabric samples will no longer run. Windows Azure AppFabric (presented here in the CTP environment) is not backwards-compatible with the AppFabric September release.

Note
If a sample has both a service and a client application, use the credentials from the same service namespace in the both the service and the client.

The AppFabric CTP June release introduces Windows Azure AppFabric applications. For information about this new capability and known issues, see the AppFabric Application Release Notes.

Important
Please note that an updated version of the Windows Azure AppFabric Service Bus has been released to production as part of the Windows Azure AppFabric September 2011 Release, and is no longer available as a CTP release. To install the AppFabric SDK version 1.5, visit the SDK download page. For the Windows Azure AppFabric September 2011 Release documentation, visit the MSDN documentation.

The previous CTP release introduced a set of new features for the Service Bus– most notably load balancing and routing optimization for the relay, durability for message buffers, and a new management model that split the namespace between a runtime view and a management view. The following features have been added in the AppFabric CTP June release

• The “Durable Message Buffer” feature has been renamed to “Queue”. With the features we’ve added over the last several months we now believe we have a capability which we can justifiably call “Queue” in the sense of a Message-Oriented Middleware offering. With that, we’re introducing naming overlap with the Queue capability that exists in Windows Azure storage. Windows Azure wueues are a storage mechanism with a simple REST-style interface, providing reliable, persistent messaging within and between services. Service Bus Queues are one part of a growing suite of Service Bus messaging capabilities including pub/sub and relayed service connectivity. Similar to Windows Azure Queues, Service Bus queues can also be used for asynchronous inter-role communication, and may be a preferred choice if your application is already leveraging the Windows Azure AppFabric for other capabilities, or if your application requires advanced features such as support for arbitrary content types, rich message properties, correlation, or message grouping.
  
  
• The load balancing and traffic optimization features for the relay capability of Service Bus have been postponed and are no longer available in this CTP. We are planning on adding these features back in a future CTP release. We’ve traded these features for capabilities that we expect will be even more important for many customers: Full backwards compatibility between the current production release of Service Bus and the new version we’re presenting in this CTP, even though we have changed a very significant portion of the Service Bus backend. We are committed to providing full backward compatibility for the Service Bus when the capabilities of this CTP go into production, including backward compatibility with the Microsoft.ServiceBus.dll assembly that you may already have deployed.
  
  
• We have retained the existing management model for the Service Bus and allow for entities such as Queues and Topic to be created and managed in the runtime namespace as is the case today – and we will therefore not split off management into a separate namespace. Instead, we will provide a resource-oriented view organized by resource-type much like in the previous CTP as a projection into the existing namespace at the reserved name /$Resources below the service namespace root. For the time being, these views simply provide paged enumeration. We expect to extend those and the hierarchical main namespace navigation pivot with query capabilities over time.
  
  
• The two major new capabilities introduced in this CTP are Topics and Queues. Together, these two new elements form a feature group called “Messaging,” which reflects in the API and also in the assemblies contained in the SDK.
  
  The API for the new messaging capabilities is in the namespace System.ServiceBus.Messaging and you must reference the Microsoft.ServiceBus.Messaging.dll and Microsoft.ServiceBus.dll assemblies in your projects to use the full range of features of Queues and Topics from your applications. The API contains management and runtime classes that interact with Queues and Topics directly and, via the ServiceBusMessagingBinding, a direct integration for WCF services and clients.
  
  Both Queues and Topics support a private, binary protocol based on the WCF net.tcp transport as well as a simple and open REST-style protocol over HTTPS. The REST-style protocol is the same as the one documented for the existing Service Bus message buffer capability.
  
  The current message buffers, including their management protocol, will remain in the system for backward compatibility. The recommendation is that you explicitly change client code to use the new Queue feature. We are exploring whether to explicitly retain the Message Buffer feature as a memory-backed structure trading reliability for higher throughput and lower latency; for this CTP we have not made any comparative analysis in that direction.
  
  We expect the migration of existing Message Buffer client code, including custom implementations to the protocol, to be straightforward and to differ only in how the entity is created on the service namespace.
  
  

Queues: Service Bus Queues are based on a new messaging infrastructure backed by a replicated, durable store. Each queue can hold up to 100MB of message content in this CTP, which is a quota we expect to expand by at least an order of magnitude as the service goes into production. Unlike Message Buffers, Queues do not expire once created. Messages can have user-defined time-to-live periods with no enforced maximum lifetime. The size of any individual message is limited to 256KB, but the session feature allows creating unlimited-size sequences of related messages whereby sessions are pinned to particular consumers and therefore enabling chunking of payloads of arbitrary sizes. The session state facility furthermore allows transactional recording of the progress a process makes as it consumes messages from a session. Queues support reliable delivery patterns such as Peek/Lock both on the HTTP API and the .NET API that help ensuring processing integrity across trust boundaries where common mechanisms like distributed 2-phase transactions are challenging.

In addition to a dead-letter facility for messages that cannot be processed or expire, Queues also allow deferring messages for later processing, for instance when messages are received out of the scheduled processing order and need to be safely put on the side while the process waits for a particular message to permit further progress.

Topics: Service Bus Topics provide a set of new publish-and-subscribe capabilities and are based on the same backend infrastructure as Service Bus Queues. A Topic consists of a sequential message store just like a Queue, but allows for many (up to 2000) concurrent and durable Subscriptions that can independently yield copies of the published messages to consumers. Each Subscription can define a set of rules with simple expressions that specify which messages from the published sequence are selected into the Subscription; a Subscription can select all messages or only messages whose user-or system defined properties have certain values or lie within certain value ranges.

The filtered message sequence represented by each Subscription functions like a virtual Queue, with all the features of Queues mentioned earlier. Thus, a Subscription may have a single consumer that gets all messages or a set of competing consumers that fetch messages on a first-come-first-served basis. To name just a few examples, Topics are ideal for decoupled message fan-out to many consumers requiring the same information, can help with distribute work across partitioned pools of workers, and are a great foundation for event-driven architecture implementations.

Topics can always be used just like Queues by setting set up a single, unfiltered subscription and having multiple competing consumers pull messages from the subscription. The great advantage of Topics over Queues is that additional subscriptions can be added at any time to allow for additional taps on the message sequence for any purpose; audit taps that log pre-processing input messages into archives are a great example here.

AppFabric Access Control Integration: This CTP federates with the AppFabric CTP version of the AppFabric Access Control service, which is compatible with the AppFabric Access Control v2.0 service that is available commercially since April. The current commercially available version of Service Bus federates with AppFabric Access Control v1.0.

The Service Bus API that interact with AppFabric Access Control for acquiring access tokens has not changed, but we are considering changes to better leverage the new federation capabilities of AppFabric Access Control v2.0. If you are setting up access control rules for Service Bus programmatically, you will find that there are significant differences between the management APIs of these two versions of the AppFabric Access Control service. The current plan is to provide a staged migration for customers with custom access control rules on their Service Bus namespaces; migration will be an option for some period of time when we will operate the V1 and V2 versions of the AppFabric Access Control service side-by-side. We will publish concrete guidance on this migration over the course of the next few months.

Note that this is a CTP release and while we are doing our best to provide a solid experience, there are no availability guarantees for this CTP. It is possible that we may lose messages or other data due to defects. The release is also equipped with fairly conservative quotas and throttles because we are making the service available at no charge during this testing period. Customers who would normally not choose US South/Central as their preferred Windows Azure datacenter will experience higher latencies and lower throughput than they will in production because we are only making the CTP available in that one location.

The following issues are likely to be experienced by a larger number of customers trying out the respective features:

• Side-By-Side of Production and CTP SDKs: You can run these side-by-side on the same computer. When installing and running the production (V1.0) and CTP (V2.0) version of the SDKs on the same machine concurrently, certain samples from the CTP SDK will not properly function when the production SDK is installed due to conflicting global configuration settings. The following samples are affected:
  
  
  • ExploringFeatures / Bindings / NetOneway
    
    
  • ExploringFeatures / Bindings / NetTcp / MsgSecUserName
    
    
  • ExploringFeatures / Bindings / WebHttp
    
    
  • ExploringFeatures / Bindings / WS2007Http / MsgSecCertificate
    
    
  • ExploringFeatures / Bindings / WS2007Http / Session
    
    
  You must uninstall the CTP v2.0 SDK before installing the production (v1.0) SDK on a computer. You may then reinstall the CTP v2.0 SDK on the same computer.