servicebus

I'm sure I'm not the first to say it, but there's a severe lack of documentation on the finer points of Service Bus 1.0 for Windows Server out there... I'm hoping some of the MS insiders can help clear a few things up... Do services utilizing queues/topics run in an implicit, ambient transaction? For instance consider the following code snippet: [ServiceBehavior] public class MySbService : IDoWork { [OperationBehavior] void DoSomeWork(WorkRequest request) { DoDatabaseWork(); DoMoreDatabaseWork(); } } In the above sample, without creating an explicit TransactionScope , would DoDatabaseWork() be

I have installed Service Bus 1.0 on a server joined to a Domain. From a client app running on a PC joined on the same domain, I am able to create queues, messages, etc. I use a connection string specifying credentials of a user on the same domain. Everything works. From a client app running on a PC outside the domain, nothing works. I was thinking it was related to the fact that it was not possible to use a user from the server domain if the client app was not on the same domain, so I also try to use a connection string containing a SharedSecretIssuer and a ShareSecretValue. With this approach

Yesterday I was able to repeatedly read messages from a subscription of an Azure Service Bus Topic that I created myself. Today, however, whilst using the same code as yesterday, all messages are null despite that the message count of the subscription is well above 0. Let me elaborate: Following the instruction on the MSDN site concerning how to read messages from subscription , I'm using the following to read messages from a subscription client: var tokenProvider = TokenProvider.CreateSharedSecretTokenProvider("MySubscriber","MyKey"); var serviceUri = ServiceBusEnvironment.CreateServiceUri(

I'm having a hard time understanding the RetryExponential class that is used in conjunction with QueueClients (and I assume SubscriptionClients as well). The properties are listed here , but I don't think my interpretation of their descriptions is correct. Here's my interpretation... var minBackoff = TimeSpan.FromMinutes(5); // wait 5 minutes for the first attempt? var maxBackoff = TimeSpan.FromMinutes(15); // all attempts must be done within 15 mins? var deltaBackoff = TimeSpan.FromSeconds(30); // the time between each attempt? var terminationTimeBuffer = TimeSpan.FromSeconds(90); // the

I'm running Service Bus on Azure, pumping about 10-100 messages per second . Recently I've switched to .net 4.5 and all excited refactored all the code to have 'async' and 'await ' at least twice in each line to make sure it's done 'properly' :) Now I'm wondering whether it's actually for better or for worse . If you could have a look at the code snippets and let me know what your thoughts are. I especially worried if the thread context switching is not giving me more grief than benefit, from all the asynchrony... (looking at !dumpheap it's definitely a factor) Just a bit of description - I

I’ve got a WinRT app that I’m using the Windows Azure Toolkit for Windows 8 with. I’ve got a setup where I’d like clients subscribed to ignore messages posted to a ServiceBus Topic if they’re the originator or if the message is older than when their subscription started. In the Properties of my BrokeredMessage, I’ve added 2 items to cover these scenarios: message.Properties["Timestamp"] = DateTime.UtcNow.ToFileTime(); message.Properties["OriginatorId"] = clientId.ToString(); clientId is a Guid. The subscriber side looks like this: // ti is a class that contains a Topic, Subscription and a bool

We all know that BizTalk is an commercial product from Microsoft for ESB (Enterprise Service Bus). What are other ready-made features which BizTalk supports over the AppFabric Service bus. Or in other words what does AppFabric Service Bus doesn't provide to the features of ESB ...? Is the term "Service Bus" misleading as far as the AppFabric Service Bus is concerned with respect to Enterprise Service Bus...? The BizTalk and AppFabric Service Bus teams at Microsoft are actually tightly collaborating and we (I work there) are integrating BizTalk's capabilities with AppFabric and Service Bus over