Windows Azure platform AppFabric

Announcements

• Windows Azure platform AppFabric December 2009 release known issues

  Jeanne Baker, AppFabric Service BusMSFTFriday, December 18, 2009 9:36 PM

  This list of known issues appears in the December 2009 release notes.
  
  
  AppFabric Service Bus

  • Services using any of the HTTP Relay bindings experience higher memory and CPU load and higher response latencies compared to using NetTcpRelayBinding: In this release, the WS2007/Basic/WebHttpRelayBindings bindings may require two network roundtrips, including establishing a new socket connection from the listener to the Service Bus infrastructure, for most incoming requests. Due to the stateless nature of HTTP, each request must also be separately authorized which requires the client to send a security token along with the request. This will generally increase the protocol overhead incurred for each message. Thus, applications will commonly experience higher latency and additional communication overhead when using the HTTP modes compared to the NetTcpRelayBinding binding. The recommendation is to use the NetTcpRelayBinding binding for all communication paths that do not require HTTP interoperability or reach.
  • HTTP response codes and SOAP faults:

  ·        In some cases, HTTP response codes and SOAP faults immediately returned by the AppFabric Service Bus infrastructure (Service Registry, HTTP polling protocols) may indicate a "500" server error instead of more specific error codes.

  ·        Some SOAP faults may not be correctly wrapped in a SOAP 1.1/1.2 envelope when they are returned.

  • Because of a bug in Windows Communication Foundation (WCF), when WCF activity tracing is on, a call to Channel.Open when using the NetTcpRelayBinding binding generates a NullReferenceException. This bug has been fixed in WCF 4.0.
  • ATOM feed always comes back empty when a GET request is made against an HTTP URI unless the Cache-Control max-age=0 header is set. A GET against HTTPS URIs works fine without the need for this header.
  • In tests of the Ws2007HttpRelayBinding binding protocol, it has been observed that it often times out during periods of moderate to high system load. Because of this behavior, we recommend that for solutions requiring a high degree of reliability, you use the WebHttpRelayBinding binding instead.
  • The AppFabric Service Bus times out after several hours with an "endpoint not found" error: After approximately 8 hours of successful client and listener interaction, the client may receive the error "Unhandled Exception: System.ServiceModel.EndpointNotFoundException: The endpoint was not found." After the error is generated, the name of the endpoint for the listener no longer appears in the Service Registry (even if the DiscoveryMode property for the endpoint is set to Public). If tracing is enabled for the listener, you will see the exception and call stack in the trace logs.
    
    This error is caused by a known issue in WCF. The WCF issue occurs when ActivityTracing is enabled for the listener. When the AppFabric Service Bus authenticates listeners, it provides the listener with a token that is valid for 8 hours. At the end of 8 hours, the listener must acquire a new token. Because of the WCF issue, when ActivityTracing is enabled, this token re-acquisition process fails and the listener expires. As a result, the listener disappears from the Service Registry.
    
    The workaround is to remove the ActivityTracing value from the application configuration file on the listener side, as in the following example:

  Copy Code

  <configuration>

         <system.diagnostics>

           <sources>

             <source name="System.ServiceModel" 

                 switchValue="Information, ActivityTracing"

                 propagateActivity="true">

  • Sending HTTPS messages with tokens: If you use the BasicHttpRelayBinding or WS2007HttpRelayBinding bindings with the EndToEnd.Message security mode and HTTPS scheme, and send a message with a RelayAccessToken, the operation will fail with an Internal Server Error. The workaround is to set the security mode to EndToEnd.TransportWithMessageCredential instead.

  Access Control

  • You must specify service namespace names in lowercase letters when creating Access Control resources through the management service API. However, the Acm.exe tool does not have this requirement. This restriction may be removed in future releases.
  • Windows Identity Foundation (WIF) is required for Active Directory Federation Services V2 (ADFS) integration. For WIF system requirements, click here.

  Quotas

  Please note the following quotas for the AppFabric Service Bus and AppFabric Access Control, listed by property:

  Service Bus

   

  Quota Name	Quota Value
  Number of simultaneous connections (senders) open per service namespace	100
  Number of simultaneous listeners per service namespace	25
  Number of operations per second (does not apply to NetTcp bindings)	10000
  Number of message buffers per solution namespace	1000
  Maximum message (in a message buffer) size	64KB
  Total capacity of a single message buffer	3MB

  Access Control

   

  Quota Name	Quota Value
  Management reads	20 operations per second per service namespace
  Management writes	20 operations per second per service namespace
  Token requests claim types per scope	20 requests per second per service namespace
  Token size	2048 bytes
  Input claims	32 claims
  Output claims	32 claims
  Rule chaining depth	10 rules
  Rule processing timeout	10 seconds
  Number of segments in appliesTo	32 segments
  Number of characters in appliesTo	256 characters

   

  -- The Windows Azure platform AppFabric Team
  

• Additional Data Centers for Windows Azure platform AppFabric

  Jeanne Baker, AppFabric Service BusMSFTFriday, January 29, 2010 1:11 AM
  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

• Windows Azure platform AppFabric Breaking Changes

  Mujtaba Syed - MSFT Monday, December 14, 2009 8:05 PM

  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

   

• Reminder: the SDK has changed

  Jeanne Baker, AppFabric Service BusMSFTFriday, December 18, 2009 10:37 PM
  The December release includes updates to the SDK.  You are encouraged to visit the AppFabric portal at https://netservices.azure.com to retrieve the latest SDK, version 1.0.
  
  The Windows Azure platform AppFabric team
  
  
  

• Commercial Offer Availability and Updated AppFabric Pricing

  Jeanne Baker, AppFabric Service BusMSFTTuesday, January 05, 2010 1:22 AM

  As part of today’s announcement about 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.

• The Windows Azure platform AppFabric December 2009 Release is Live

  Jeanne Baker, AppFabric Service BusMSFTFriday, December 18, 2009 9:31 PM

  The Windows Azure platform AppFabric December release is now live.  In posts that follow will appear the breaking changes associated with the release as well as its list of known issues.  You are encouraged to visit the AppFabric portal at https://netservices.azure.com to retrieve the latest SDK.
  
  The Windows Azure platform AppFabric Team