Before running the samples in the SDK, you must create a Windows Azure Services project and one or more service namespaces within the project. To create and manage your project and service namespaces, log in to the Windows Azure platform AppFabric portal and click the service namespace you want to manage.

Note:
Service Namespaces were called solutions in previous releases. There are still some references to solutions in the product (for example, in some error messages). These will be corrected in a future release. Also, some Service Bus samples use the term Service Namespace Domain. Please treat this as a synonym for "service namespace".

Most Service Bus samples contain three prompts:

1. Service Namespace Domain: You can use the service namespace you created in your project on the portal. The Service Namespace Domain is used to construct Service Bus endpoints (for example, sb://<domain>.servicebus.windows.net/Echo/)
   
   
2. Issuer Name: You can use owner, which is an issuer that is created by default for you. To create other issuers, you can use the Acm.exe tool in the SDK.
   
   
3. Issuer Key/Secret: You can use the Default Issuer Key option listed on the Service Namespace management page on the portal.
   
   

The Service Bus and Access Control SDK samples are available as Visual Studio 2008 solutions (C# and Visual Basic), and require Microsoft .NET Framework 3.5 SP1 to run. The SDK is supported on the Windows Server 2008 and Windows Vista operating systems. Some Access Control Service samples require IIS 7.0.

• The AppFabric portal URL has changed from http://portal.ex.azure.microsoft.com to https://netservices.azure.com.
  
  
• The default name of existing subscriptions has changed to projects. You can assign arbitrary names to newly created projects in the November 2009 CTP. Existing subscription names in the July 2009 CTP will be automatically migrated to Project name in the November 2009 CTP.
  
  
• A solution, the basic component of a subscription (now called a project), is now named service namespace. Solutions in the July 2009 CTP will be automatically migrated to service namespaces in the November 2009 CTP.
  
  
• In previous releases, solutions were located in a sub-region within the United States. In the November 20009 CTP, existing service namespaces will be automatically migrated and reassigned to the North Central or South sub-region within the United States.
  
  

• Queues: The AppFabric Service Bus Queues feature has been changed in response to customer feedback and has been renamed to Message Buffers in order to better reflect the associated capabilities. Message Buffers will be introduced with temporary caching functionality in the November 2009 CTP, with the long term goal of providing comparable functionality to queues.
  
  In previous releases, queues provided persistent message storage. The Microsoft.ServicesBus.dll assembly provided APIs such as QueueClient, QueueManagementClient, and QueuePolicy for interaction with queues. In the November 2009 CTP, Message Buffers provide message caching. Queues-related APIs are removed from Microsoft.ServicesBus.dll. MessageBufferClient APIs are now provided in Microsoft.ServicesBus.dll for interaction with the new Message Buffers feature.
  
  You should remove references to queues from applications. For some applications, you can substitute Message Buffers for Queues. Where durability requirements exist, you may prefer service namespaces employing Azure storage features.
  
  
• Routers: The AppFabric Service Bus Routers feature has been removed in the November 2009 CTP. In previous releases, routers pushed messages to a subscription list. Microsoft.ServicesBus.dll provided APIs such as RouterClient, RouterManagementClient, RouterPolicy, and more, for interaction with routers. In this release, these APIs have been removed, and a sample is included that demonstrates how to implement an anycast message distribution model similar to the router’s respective capability.
  
  You should remove calls to the above router APIs from applications. For some applications, the approach suggested in the LoadBalance sample may provide sufficient message routing functionality. Other approaches are possible but are likely to require more client code.
  
  
• RelayBinding Security Default: In the November 2009 CTP, all RelayBindings are secured by default. In previous releases, some RelayBindings have RelaySecurity.Mode set to EndToEndSecurityMode.None. With this release, all RelayBindings have RelaySecurity.Mode set to EndToEndSecurityMode.Transport, which is secured by default.
  
  You should update code that uses RelayBinding to use the HTTPS transport in service and endpoint addresses. As an alternative, you can set the RelayBindingRelaySeucirty.Mode option to EndToEndSecurityMode.None. Note that setting EndToEndSecurityMode.None allows message contents to travel in clear text, which may be a security risk for many applications.
  
  
• TransportClientCredentialType: In the November 20089 CTP, TransportClientCredentialType types such as AutomaticRenewal, CardSpace, ClientCertificate, FederationViaCardSpace, and UserName have been removed. They will be replaced by credential types that are supported by the new Access Control Service. Service Bus authenticated types include SharedSecret, Simple Web Tokens, and Saml, which are reflected in TransportClientCredentialType.
  
  You should change code that uses TransportClientCredentialType in the July 2009 CTP to use the authentication types employed in the November 2009 CTP. The November 2009 CTP provides sample code that illustrates how to use the new authentication type.
  
  
• EndToEndWebHttpSecurityMode.TransportCredentialOnly is removed: The EndToEndWebHttpSecurityMode.TransportCredentialOnly option has been removed as it is no longer supported. You should change code that uses EndToEndWebHttpSecurityMode.TransportCredentialOnly to EndToEndWebHttpSecurityMode.Transport.
  
  
• HttpBufferClient is not public: The Microsoft.ServiceBus.HttpBufferClient type is no longer public. You can replace code that uses HttpBufferClient with MessageBufferClient.
  
  
• TcpRelayConnectionMode.Direct is removed: The Microsoft.ServiceBus.TcpRelayConnectionMode.Direct option is no longer supported; Direct Connection is supported in Hybrid mode only. You can replace code that uses TcpRelayConnectionMode.Direct with TcpRelayConnectionMode.Relayed or TcpRelayConnectionMode.Hybrid.
  
  
• Service publishing feed address aligns with service transport: In previous releases, service publishing feed addresses used HTTP transport; for example, http://<mysolution>.servicebus.windows.net/<mycalculatorservice>, regardless of the transport being used in the service. As an example, previously the service was accessed at sb://<mysolution>.servicebus.windows.net/<mycalculatorservice> when NetTcpRelayBinding was used. With this release, service publishing feed addresses are now aligned with the service transport. For example, you can access the feed at sb://<mysolution>.servicebus.windows.net/<mycalculatorservice> when the service is accessed at sb://<mysolution>.servicebus.windows.net/<mycalculatorservice>. You can change code that references a service publishing feed address to match the service transport.
  
  
• WSHttpRelayBinding is removed: The WSHttpRelayBinding binding is no longer supported. You should change code that uses WSHttpRelayBinding to use another supported binding, such as WS2007HttpRelayBinding or a user-constructed custom binding.
  
  
• WS2007FederationHttpRelayBinding is removed: The WS2007FederationHttpRelayBinding binding is no longer supported. You should change code that uses WS2007FederationHttpRelayBinding to use another supported binding, such as WS2007HttpRelayBinding or a user-constructed custom binding.
  
  

1. WS-Trust and WS-Federation are not supported: The AppFabric Access Control (AC) service no longer supports WS-Trust and WS-Federation. It now supports a REST-based protocol. In previous releases, AC accepted WS-Trust Active and WS-Federation passive token requests. With the November 2009 CTP, AC now accepts REST-based token requests. AC will support WS-* in future releases. If appropriate, you can port your applications to support the new REST-based approach.
   
   
2. Windows Cardspace credential type is not supported: In previous releases, Windows Cardspace was a supported credential for the Service Bus and Access Control portal, Service Bus, and the Access Control service. With this release, it is no longer supported. You should update code or configuration settings that use Windows Cardspace as credentials to applications using the Service Bus or Access Control Service. Such code should use one of the new authentication types, such as Shared Secret, Simple Web Token, or SAML.
   
   
3. Certificate credential type is not supported: Certificate is no longer a supported credential for the Service Bus and Access Control portal, Service Bus, or Access Control service. You should update code or configuration settings that use Certificate as credentials to applications using Service Bus or Access Control Service. Such code should use one of the new authentication types, such as Shared Secret, Simple Web Token, or SAML.
   
   
4. Username and password credential type is not supported: A username and password is no longer a supported credential for the Service Bus and Access Control portal, Service Bus, or Access Control service. You should update code or configuration settings that use a username and password as credentials to applications using Service Bus or Access Control Service. Such code should use one of the new authentication types, such as Shared Secret, Simple Web Token, or SAML.
   
   
5. Access Control Service data will not be migrated: Note that all AC data such as scope, rules, certificate, username and password, and Windows Cardspace will not be migrated to the new release and will not be available for access through public APIs or the Service Bus and Access Control portal. Note that the Service Bus scope and rules will also not be migrated. To facilitate post-release configuration, you may choose to save a copy of existing data through the Access Control management interface. For more information about how to obtain Access Control data through the management interface, see the AC Management AtomClient sample from the .NET Services July 2009 CTP SDK.
   
   At this time, you must recreate Access Control Service data (such as scope, rules, and so on) in order to restore your application using the Service Bus or Access Control Service.
   
   
6. Access Control management portal removal: The Access Control management portal will be removed from the November 2009 CTP Service Bus and Access Control portal. You can no longer access any AC objects through the portal. Instead, you can use a command-line tool, Acm.exe, to manage Access Control Service objects. For more information, see the documentation for the tool.
   
   

• Services using any of the HTTP Relay bindings experience higher memory and CPU load and higher response latencies compared to using NetTcpRelayBinding: In this CTP, 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.
    
    
• SOAP 1.1/HTTP messages sent to one-way listener endpoints: Clients can send messages to NetOnewayRelayBinding and NetEventRelayBinding listeners directly via SOAP/HTTP requests in addition to using the matching .NET bindings. There is a known issue with the November 2009 CTP, in which SOAP 1.1 (not SOAP 1.2) messages may be dropped in transit. It is recommended to use SOAP 1.2 messages for this communication pattern.
  
  
• 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 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 callstack 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 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:
  
  
  <configuration>
         <system.diagnostics>
           <sources>
             <source name="System.ServiceModel" 
                 switchValue="Information, ActivityTracing"
                 propagateActivity="true">

• 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.
  
  
• There are some discrepancies between Web Resource Authentication Protocol (WRAP) and the AC implementation of it. Please refer to the following table.
  
  

   

  Description	WRAP Spec	Access Control Service
  Required auth header format	Authorization: WRAP access_token=”123456789”	Authorization: WRAPv0.8 <token>
  WWW-Authenticate response	WWW-Authenticate: WRAP	None
  Token label	wrap_access_token	wrap_token
  Expires On label	wrap_access_token_expires_in	Wrap_token_expires_in
  Client Requests Access Token Username / password	wrap_client_id	N/A
  Client Requests Access Token Username / password	wrap_username	Wrap_name