We want Content Based Routing in Azure App Fabric. How can you take it out of it? A service Bus is not complete without one. I suggest we have it for XML/JSON type messaging, and it must be durable!

I mentioned to customer that we can host their services in App Fabric, and we can leverage Content Based Routing. I am somewhat dissapointed when I worked on the SDK, that this is not their! So what do I do? I do not think using BizTalk just for the routing capabilties is suffucient, App Fabric MUST have this built in, if it is to surivive and beat the competitors. It is application driven and shouls therefore be able to intrinsically route certain message types based on type or content!

I think it's great that we finally have support for Flash/Silverlight on the ACS. However, I think the support is poorly implemented.

The current policy is expressed as

<cross-domain-policy>
<allow-access-from domain="*" secure="true" />
<allow-access-from domain="*" secure="false" />
<allow-http-request-headers-from domain="*" headers="*" secure="true" />
<allow-http-request-headers-from domain="*" headers="*" secure="false" />
</cross-domain-policy>

I'd prefer to be able to add the domains that can access the service from Flash/SL via the administrative UI since my use cases for ACS are for single applications, not for the world at large.

Currently, I guess there is no WS-* support in ACS for us to do multi-tenant federation from Web role.
I have seen examples for REST services but how about web role?
We can do this on premise by ADFS adding whr parameters to the querystring etc.. but how to do it on azure using ACS and web role.

This is must for any SaaS application

I'd like to see a single Issuer store for both ACS configuration and the service bus configuration. SInce you already have to grant issuers specific rights for the service bus I don't see why I need to maintain two stores of issuers for both access to the service bus AND for my own services. I should be able to define an issuer once, then grant them rights to my service bus and/or ACS from there.

Hi,
Cloud Drive is very helpful for those who are using standard NTFS APIs like us.

Actually we are working on application which will run both on cloud and on local machine. We need to store and use our large amount of data which will be used by our application to azure storage. and both local and cloud running application have to save and retrieve data from one location. Initially we are concentrated on blobs but looking at cloud drive we want to shift on to it.

In terms of Cloud Drive and our application running in cloud its awesome.
But But the application running in local environment have no access to cloud drive.

So Cloud Drive functionality shoud be available Locally in future ??

Managed Services Engine is a wonderful capability that allows MS stack to have a native SOA intermediary. What is great about it built up on WCF, it does work with the AppFabric and more importantly allows non WCF applications to be integrated to AppFabric out of the box.
Microsoft is really bad in promoting it and very few people know about it.
Please add one or two labs to the SDK how to expose an existing endpoint via AppFabric + MSE (cut and paste Arron’s article if you wish) and start promoting it! It is very useful (and missing block) that you need to promote more!

Provide native security services in AppFabric such as XML firewalling (structure, grammar, semantics, algorithms, injections, etc), similarly like other XML virtual appliances .
Ideally, it would great if interception can be implemented between client and the end service by calling Worker / Web Role on Azure to perform this functionality (an possibly policy enforcement) – Customer may or may not to choose to deploy this solution at their own cost. The firewall can be reference implementation on codeplex and / or fully managed service provided by Microsoft.

Currently ServiceBus is billed monthly per connection, with prices that can go lower with packs, but nevertheless far too expensive for some low traffic/usage scenario.
In my scenario the connection is between client applications and the Azure services, must be active all the time the application is working (normally 8 hours a day) and "real" communication between the two, interaction and data transfer, happens unfrequently and move little data.
In this scenario the current pricing strongly limit the chance to use the ServiceBus, even if it is an enabling feature.
A pricing model more proportional to time and usage would really help