Update on the Next Microsoft .NET Services CTP

It’s been a while since our last update on this blog, hopefully everyone enjoyed a warm, sunny summer break while we continued the march toward the commercial release of Microsoft .NET Services.

 

For those that are new to the conversation .NET Services make it easier to connect applications and services in the cloud and on premises. .NET Services includes access control to help create secure connections between your applications and services, as well as a service bus for communicating across network and organizational boundaries.  In the same way that Microsoft® .NET Framework provides higher-level libraries to make developers more productive, .NET Services help developers focus on their application logic rather than deploying and managing their own cloud-based infrastructure

 

The next Community Technology Preview (CTP) of .NET Services and the supporting Software Development Kit (SDK) is due out in October, and will closely resemble what is planned for our commercial launch. So, what does this mean for capabilities that will comprise of .NET Services when we reach commercial availability? The Microsoft® .NET Service Bus remains largely the same compared to the current CTP, while the Microsoft® .NET Access Control Service will undergo changes in order to bring us closer to locking down the .NET Services launch features.

 

So, let’s dig into it!

What We’ve Heard and Observed Regarding Microsoft .NET Services

 

What’s become a core area of focus for the team, and also a point of discussing during the customer feedback process, is that REST web services are clearly increasing in popularity with both Web and enterprise developers. What is also apparent is a significant gap has emerged in the market place for REST-based identity and access control technologies.

 

Today, developers of REST web services lack an easy, accessible means to secure their services. At MIX09, we exposed some of our thinking about taking a first step toward radically simplifying the REST developer experience, and used this as an opportunity to gauge customer interest and feedback. Your response was overwhelming, positive and confirmed our priorities as we approach the commercial availability of .NET Services.

 

Developers face a lack of consistency and common patterns for managing identity and access control in a way that is compatible with REST.  As developers move towards REST in the enterprise, they will have an increasing need for robust security. They will be required to address the more systematic security concerns of enterprise customers as well as the more complex identity management scenarios that enterprises present. They will need a way to address these requirements in a simple way that integrates well with REST.

 

In speaking with the community in the past several months, it became clear that we all need a better way to control access to REST web services.  We believe that the .NET Access Control Service will address this need and compliment other Microsoft technologies for security and identity management.  The combination of simplicity and support for key enterprise integration scenarios will ensure that .NET Services are useful to enterprise developers as well as the broader developer audience.

What to Expect from Microsoft .NET Services Access Control Services in the October CTP

 

The.NET Access Control Service provides an easy way to control access to web applications and services while integrating with standards-based identity providers, including enterprise directories and web identity systems such as Windows Live ID. Authorization decisions can be pulled out of the application and put into a set of declarative rules that can transform incoming securing claims into claims that applications understand.

October CTP – .NET Access Control Service Capabilities

· Simple Web Trust – Authorization for REST Web Services and the .NET Service Bus

o Two token-exchange endpoints: REST with symmetric key and REST with SAML Extension

§ REST with symmetric key: Makes it easy for developers on any platform to package claims for the .NET Access Control Service

§ REST with SAML Extension will work with tokens issued by ADFS V2

§ Both endpoints will be addressable using standard HTTPs POST requests

o Claims Transformation Engine: Transform input claims to output claims using configurable rules

o Security Token Service: Package and transit output claims using REST tokens

 

While we believe – and have heard clearly – that the changes to the .NET Access Control Service outlined above will bring tremendous benefit to our customers in the near-term, we also recognize these changes will significantly impact any code you are writing today.

 

In concrete terms, this means the WS-* integration features currently supported today will be temporarily unavailable while we focus on delivering a robust infrastructure for REST web services authorization. Once this infrastructure is in place, we will work on future version features of .NET Services, like web single sign-on and rich WS-* support. In future releases, we will reinstate full support for the WS-* protocols, web Single Sign On, and round out the .NET Access Control Service offering in a way that spans the REST/SOAP spectrum. We’ll talk more about these future features at a later date.

What to Expect from Microsoft .NET Services Bus in the October CTP

 

The .NET Service Bus makes it easy to connect applications together over the Internet. Services that register on the Bus can easily be discovered and accessed, across any network topology. The Service Bus provides the familiar Enterprise Service Bus application pattern, while helping to solve some of the hard issues that arise when implementing this pattern across network, security, and organizational boundaries, at Internet-scale.

 

As we work with you to gather feedback on implementations, and work on our future product planning cycles, it is clear developers see great promise for a cloud-based service bus and desire expanded functionality beyond what is available in today’s version .NET Service Bus. Here is what you can expect on this front, from our next CTP…

 

October CTP – .NET Service Bus Capabilities

· Services Naming System and Registry

o Enable tree hierarchical based service naming system

o Service Naming Registry enables opt-in service public discoverability

· Messaging

o Enable one way, request/response and peer-to-peer messaging through NAT and firewall

o NET Service Bus endpoint is secured by .NET Access Control Service

· Message Buffer

o Provide a FIFO data structure within .NET Services namespace and exist independent of any presence of active listeners.

 

In order to facilitate expanded functionality in coming releases and as we approach commercial availability, you will see several key changes relative to the Service Bus available for download today. Specifically, we are making core changes to Routers, Queues, WSHttpRelay Binding, and External Endpoint Registration, as outlined below.

 

· Routers – We are temporarily removing Routers beginning with the next CTP. For developers who architected applications relying on the Router functionality, we will provide a sample to demonstrate a method for implementing Router-like functionality – including multicast, anycast, and push-style message operations – using existing Service Bus features.

 

· Queues -- Queues will be replaced with a simpler offering called Message Buffers. In future releases we will add message buffer durability, delivery guarantees, and other enhanced message delivery semantics.

 

· WSHttpRelay Binding - The WSHttpRelay Binding will no longer be available beginning in the October CTP release.  Customers who were using the WSHttpRelay Binding are advised to consider migrating to the WS2007Relay Binding, which provides support for the updated versions of the Security, ReliableSession, and TransactionFlow binding elements.

 

· External Endpoint Registration - Beginning with the October CTP release, it will no longer be possible to register external (non-Service Bus) endpoints in the Service Registry.  We expect to re-instate this functionality in a future release.

 

Wow, that was a mouthful of an update! We, like many of you, are excited by the fast approaching commercial availability of .NET Services. Continue to let us know what you think about the product, what you are building with the Windows Azure platform, and how we can continue to deliver product improvements that simplify your projects and please our joint customers! If you have any questions or need further information, please visit the .NET Services Technical Discussion Forum.

 

The .NET Services Team