AppFabric Announcements Blog   |   MSDN Dev Center   |   Forums   |   Release Notes   |   Give Feedback

Welcome to MSDN Blogs Sign in | Join | Help

Windows Azure & SQL Azure announce General Availability

Today, Feb 1st 2010, Windows Azure and SQL Azure have announced general availability and have started charging customers. Windows Azure platform AppFabric continues to be free until April 2010. Details available at http://blogs.msdn.com/windowsazure/archive/2010/02/01/windows-azure-platform-now-generally-available-in-21-countries.aspx

 

Windows Azure platform AppFabric Team

Additional Data Centers for Windows Azure platform AppFabric

Window Azure platform AppFabric has now been deployed to more data centers around the world.  Previously, when you provisioned a service namespace, you were asked to select a region from a list that contained only United States (South/Central).  Now, when you provision a service namespace, you have three more regions from which to choose -- United States (North/Central), Europe (North) and Asia (Southeast).  If your firewall configuration restricts outbound traffic, you will need to perform the addition step of opening your outbound TCP port range 9350-9353 to the IP range associated with your selected regional data center.  Those IP ranges are listed at the bottom of this announcement.

 

Note that your existing service namespaces have already been deployed to United States (South/Central) and cannot be relocated to another region.  If you like, you may delete a service namespace, and when recreating it, associate it with another region.  However, if you do so, data associated with your deleted namespace will be lost.

Windows Azure platform AppFabric plans to deploy to more locations in the months ahead.  Further details will be posted as they become available.

 

IP Ranges

United States (North/Central)

65.52.0.0/21, 65.52.8.0/21, 65.52.16.0/21, 65.52.24.0/21, 207.46.203.64/27, 207.46.203.96/27, 207.46.205.0/24

 

Europe (North)

94.245.88.0/21, 94.245.104.0/21, 65.52.64.0/21, 65.52.72.0/21, 94.245.114.0/27, 94.245.114.32/27, 94.245.122.0/24

 

Asia (Southeast)

111.221.80.0/21, 111.221.88.0/21, 207.46.59.64/27, 207.46.59.96/27

 

 

Windows Azure platform AppFabric Team

 

Commercial Offer Availability and Updated AppFabric Pricing

As part of the announcement of the commercial availability of Windows Azure platform offers, we are also introducing updated pricing for the Windows Azure platform AppFabric, which helps developers connect cloud and on-premises applications. Based on discussion and feedback from hundreds of customers during the CTP process, we have made the pricing simpler and more predictable. Service Bus will now be priced at $3.99 per Connection-month, and Access Control will be $1.99 per 100,000 Transactions.

Last November at the 2009 Professional Developers’ Conference, Microsoft announced a new product offering named AppFabric. AppFabric delivers services that enable developers to build and manage composite applications more easily for both server and cloud environments. The server components, known as Windows Server AppFabric, provide caching capabilities and workflow and service management capabilities for applications that run on-premises. The cloud components, known as Windows Azure platform AppFabric  (formerly called “.NET Services”),  include cloud-based services that help developers connect applications and services between Windows Azure, Windows Server and a number of other platforms. Windows Azure platform AppFabric is available as a production ready service today and includes two services: Service Bus, which makes it easier to connect applications and services in the cloud or on-premises, and Access Control, which provides federated authorization as a service.

SERVICE BUS PRICING

For Service Bus, the pricing meter has changed from “Message Operations” to “Connections”. In many cases, each application instance that connects to the Service Bus will require just one Connection, which means that predicting your usage is often as simple as counting the number of application instances or devices that you need to connect. Whether your application requires two-way messaging, event distribution, protocol tunneling, or another architecture, the Connection-based model is designed to suit your business needs. Connections are charged at a rate of $3.99 per Connection per month (plus applicable data transfer charges), and will be billed on a pay-as-you-go, consumptive basis. Alternatively, for customers who are able to forecast their needs in advance, we offer the option to purchase “Packs” of Connections: a pack of 5 Connections for $9.95, a pack of 25 for $49.75, a pack of 100 for $199.00, or a pack of 500 for $995.00 per month (plus data transfer). Connection Packs represent an effective rate of $1.99 per Connection-month. Pack sizes larger than 500 may be available on request. In our FAQ, we provide more details on how Connections are defined, measured, and billed.

We expect that most customers will find this new meter to be simpler and more predictable. While the former Message Operations meter was well suited for uses such as discrete transactional messaging, it has been more complicated in other cases. For example, what happens if you want to stream a large file, tunnel a protocol persistently, or deploy a lot of devices that all "listen" idly all day? Knowing what gets counted as a message, and predicting usage from day to day, was difficult.

It turns out that our customers have all of those uses in mind, which is a good thing. Customers have asked for simpler pricing, and we are now able to deliver this for a wider range of uses, including streamed data, protocol tunneling, and transactional messaging. This new pricing structure will help make it easier for you to understand and control when and how many Connections are being used. In addition, it provides increased predictability, because under normal circumstances, your total Connection cost will stay the same whether you  generate more or less “message” volume from one month to the next.

ACCESS CONTROL PRICING

For Access Control, the pricing meter has changed from “Message Operations” to “Transactions”. In practice, these meters are the same; only the name has been changed to reflect the Access Control function more accurately. As previously announced, token requests and service management operations will both be counted as Transactions, and charged at a rate of $1.99 per 100,000 Transactions.

AVAILABILITY

The Service Bus and Access Control are available today, however to give customers more time to adjust to the new pricing structure, charges will start to accrue in April, 2010. Usage until that time will be free of charge, so we encourage you to upgrade your account and sign up for an offer today. Starting today, customers can already take advantage of the same support and benefits provided across the Windows Azure platform.  SLAs will take effect when charges begin to accrue in April, 2010.  In order to help customers monitor and predict their usage before charges begin to accrue, Connection and Transaction usage reports will be made available soon on their developer portal at http://appfabric.azure.com.

For more information, please visit our FAQ and pricing pages.

-- Windows Azure platform AppFabric team

The Windows Azure platform AppFabric December 2009 Release is Live

The Windows Azure platform AppFabric December release is live as of December 18th 2009.  This release includes improvements in stability, scale, and performance. Please refer to the release notes for a complete list of the breaking changes in this release. You are encouraged to visit the AppFabric portal to retrieve the latest copy of the SDK.

Windows Azure platform AppFabric Breaking Changes Pre-Announcement

Windows Azure platform AppFabric Breaking Changes Pre-Announcement

In this Windows Azure platform AppFabric release, there are improvements in stability, scale and performance over the previous CTP.  Some of these improvements might require user code modification.  Applications built on or that communicate with AppFabric Service Bus and AppFabric Access Control might be affected and need to change accordingly.  

Access Control

WRAP version updated.  AppFabric Access Control has been updated to support version 0.9 of the Web Resource Authorization Protocol (WRAP).  Support for version WRAP v0.8 has been removed.  See the OAuth WRAP WG document for WRAPv0.9.7.2 for full details on this version of WRAP (located at http://oauth-wrap-wg.googlegroups.com/web/WRAP-v0.9.7.2.pdf?gda=dLqVw0QAAABFB7PFAFiVedPtjcqT8uuI_dtfzzpm2dFi8PLv_8ljHRidFvlYqd_ZjmG9h9kh5-pV6u9SiETdg0Q2ffAyHU-dzc4BZkLnSFWX59nr5BxGqA).  In addition, the WRAP endpoint name has changed from https://servicenamespace.accesscontrol.windows.net/WRAPv0.8/ to https://servicenamespace.accesscontrol.windows.net/WRAPv0.9/.  The WRAPv0.8 endpoint has been removed. 

WRAP Request changes

Token type field.  In WRAPv0.8, the requester specified the type of token by providing “wrap_swt=[token]” or “wrap_saml=[token]” in the request.  In WRAPv0.9, the user now provides a separate parameter specifying the token type: “wrap_assertion_format=[SWT, SAML]”.  See Section 5.2 of the WRAPv0.9.7.2 document referenced above for more details.

Token field.  In WRAPv0.9, since the token type is a separate parameter (see above item), the token is provided using the “wrap_assertion=[token]” parameter.  See Section 5.2 of the WRAPv0.9.7.2 document for details.

Scope field.  In WRAPv0.9, the “applies_to” field name has been changed to “wrap_scope”.  See Section 5 of the WRAPv0.9.7.2 document for more details.

WRAP Response changes

Expiration field.  In the WRAPv0.9 token, the “wrap_token_expires_in” field name has been changed to “wrap_access_token_expires_in”.  See section 5 of the WRAPv0.9.7.2 document.

Body field.  In the body of the response from ACS upon a token request, the body was previously “wrap_token=[token body]”.  The name has been changed such that the body is now “wrap_access_token=[token body]”.  See Section 5 of the WRAPv0.9.7.2 document.

Issuer in the returned token.  In the November 2009 CTP, the issuer in the token response was the URI of the endpoint that issued the token.  For example, in the November 2009 CTP, if you requested a token from https://servicenamespace.accesscontrol.windows.net/WRAPv0.8/, the issuer in the returned token was https://servicenamespace.accesscontrol.windows.net/WRAPv0.8/.  In this release, the issuer in the returned token is not tied to a specific endpoint (in preparation for future support of multiple-endpoint-issuing tokens), so the response returns https://servicenamespace.accesscontrol.windows.net/.

Authorization (auth) header.  In WRAPv0.8, the auth header appeared as:  Authorization: WRAPv0.8 [token].  In WRAPv0.9, the auth header format is now:  Authorization: WRAP access_token=”[token]”.  See section 4.2 of the WRAPv0.9.7.2 document.

 

Service Bus

Message Buffers

PeekLock expiration.  The determination for when message buffer PeekLocks expire was incorrectly computed.  In this release, the PeekLock respects the user configurable timeout value and uses the operation timeout to determine when the PeekLock should expire.

URI in Atom feed.  The response to the HTTP request to create a message buffer contains an Atom feed identifying the URI for the buffer head.  That URI had contained extra slashes.  The response has been corrected in this release and now identifies the buffer head with the correct URI.

Allowing “/” in Delete requests.  Attempts to delete a message buffer where the buffer URI was incorrectly specified used to return a 500 error.  In this release, such Delete requests will return a 400 Bad Request error.

Creation Errors returned.  Message buffer creation sometimes failed silently.  In this release, creation errors are returned.

Status code change.  Invalid message buffer operations had returned an HTTP status code 500.  In this release, status codes in the 400-range (4xx) are returned.

Relay Bindings

Port change.  Customers communicating with previous versions of the AppFabric Service Bus through firewalls that restrict outbound traffic had to open ports 808 and 828 for NetOnewayRelayBinding and NetEventRelayBinding communication and 818 and 819 for the other bindings.  In this release, the range is specified at 9350-9353 where 9350 and 9351 are used for NetOnewayRelayBinding and NetEventRelayBinding communication and 9352 and 9353 are used for the other bindings.

Oneway errors returned.  Initiators (clients) using NetOnewayRelayBinding and NetEventRelayBinding were unable to receive error information in previous CTP releases.  In this release, failed channel creation or failed message delivery will return the cause of the error, such as quota exceeded and authorization failure.

Unneeded security mode eliminated.  The EndToEndWebHttpSecurityMode had an acceptable value of “TransportCredentialOnly” whose behavior was indistinguishable from the value “None”.  In this release, “TransportCredentialOnly” is no longer an allowed value.

URIs and Headers

Case sensitivity introduced.  Case insensitive comparisons had been made with SOAP headers, HTTP methods (GET, POST, PUT, etc.) and Access Control claim tokens.  In this release, such comparisons are now case sensitive in order to comply with these standards.

ASCII required in URI paths.  Users had been allowed to include non-ASCII characters in URI names.  In this release, URI path names are restricted to the ASCII character set.  The ASCII character limitation does not extent to fragments and query strings, which often represent application-domain-specific information.

Token URI validation.  When granting permission to access a URI, comparison between the endpoint URI and the URI specified in the token did not distinguish URI segments.  Thus, a token issued for abc/def was held to be valid for abc/def/g (which is correct) as well as abc/defg (which is unwanted behavior).  In this release, tokens are valid for child segments of the URI.

Using Access Control

Secure channel required for tokens.  Customers had been allowed to transmit messages that contained Access Control tokens in clear text.  In this release, attempts to send messages that contain Access Control tokens over non-secure transport channels will fail with an error “Transport security is required to protect the token.”

Token tag change.  The previous CTP SDK used <BinarySecret> to wrap the Access Control Simple Web Token.  This tag is reserved in WS-Trust for carrying key material.  In this release, the tag used to wrap SWT tokens is <BinarySecurityToken>. 

Windows Azure platform AppFabric Team

A New Community Protocol and Token Format Supported by the Access Control Service

The November 2009 CTP release of the Access Control Service includes support for a new community protocol and token format. Their names are Web Resource Authorization Protocol (WRAP) and Simple Web Tokens (SWT). See here for specifications, community discussion, and more information.

 

 

 

Upcoming Important Changes to Microsoft .NET Workflow Service

The team is excitedly preparing the next milestone of the Microsoft .NET Services Community Technology Preview (CTP). Once the .NET Services CTP becomes available, we’ll post the details via this blog, including a download link.

 

The next release of the .NET Services CTP will be the sixth version released since the initial CTP became public last year. The rapid iterative development cycle required for cloud offerings is driving an equally interesting and rapidly iterating feedback loop with customers and partners. Keep sending us your feedback!

 

Incorporating community feedback is the cornerstone of each and every development milestone. Talking to current and potential CTP users, listening to the community’s needs, and responding accordingly is essential to delivering .NET Services in a way that “just works” to address your business and development needs.

 

An area of consistent discussion is the Microsoft .NET Workflow Service delivered via .NET Services, and how it relates to the Windows Workflow Foundation (WF) in the .NET Framework. One of the comments that we’ve consistently heard about the .NET Workflow Service is that you want the Workflow Service to be built on .NET Framework 4‘s workflow engine. This is currently not the case, since we are prior to the release date of .NET Framework 4.

 

As the direct result of user feedback, we will hold off further releases of the Workflow Service until after .NET Framework 4 ships. Since there will be important changes to the Workflow Service before it goes to full production, we are planning to take down the existing Workflow Service as part of service improvements in the month of July. This means any solutions that currently rely on the Workflow Service will have to be modified on or before July 1 in order to continue functioning smoothly.

 

We understand this decision will cause disruption, yet we’ve consistently heard from customers “it is the right move” to ultimately deliver a better product and a better experience. The sixth iteration of Microsoft’s .NET Services will still include the Microsoft .NET Access Control Service and the Microsoft .NET Service Bus. The team will continue to deliver a number of requested improvements that make .NET Services more reliable, secure, and robust. Details will follow in due course.

 

Please be sure to check back frequently for updates and visit our forum if you have any questions.

 

.NET Services Team

Welcome to .NET Services!

Today we released the Community Technology Preview of the first three .NET Services: Access Control, Service Bus and Workflow Service. You can find out more about .NET Services on the .NET Services Developer Center, or ask questions about the services at our discussion forum!

This blog will keep you informed about updates to the .NET Services, including any scheduled service maintenance or operational issues with the services.

The .NET Services Team blog will provide you with news from the .NET Services team including new sample applications, feature highlights, whitepapers etc.

 
Page view tracker