Ive already touched on the fact a couple of times in the documentation that you can use clients in other technologies, but if your client is a .net client then you can use the AppFx.ServiceBus.Client assembly which contains some features to make things easier for you.

The old way the first version of the framework used to implement the client class is listed at the bottom of the page. The newer way uses a class called SimpleServiceBusClient which implements an interface called ISimpleServiceBusClient.

SimpleServiceBusClient

The SimpleServiceBusClient is the main class to use when sending messages to service bus. It will encapsulate some of the complexity required to implement the different message exchange patterns and give you a nice easy and obvious interface to program against.

There are 4 methods:
  • Send which is used to send a message which you are not waiting for a response for
  • SendForDeliveryLater send a message in a one way pattern but for which you want to delay the processing
  • SendAndWaitForResponse is used to implement the RPC pattern
  • SendAndWaitForLotsOfResponses is used to implement the scatter gather pattern

Send

The below is an example of the one way send of a message

            var client = new SimpleServiceBusClient("OneWay-TestQueue");
            client.Send<PingRequest>(request);

SendAndWaitForResponse

The below is an example of the client side implementation of the RPC pattern

            var client = new SimpleServiceBusClient("RPC-Client");
            var response = client.SendAndWaitForResponse<PingRequest, PingResponse>(request);

Custom Message Properties

There is also a properties dictionary which you can set properties for the message client on. These will be set as metadata on the brokered message sent to azure service bus. The below code demonstrates setting these properties.

            var client = new SimpleServiceBusClient("OneWay-MessageTypeRoutingKey-Topic");            
            client.Properties.Add("MyProperty", propertyValue);
            client.Send<Message2>(message);

Identity Properties

Mike recently produced a whitepaper which describes how to flow identity details along with a message to implement an identity flow solution. This paper is linked from the following blog post:
http://geekswithblogs.net/michaelstephenson/archive/2014/01/24/155271.aspx

The SimpleServiceBusClient contains some properties which allow you to implement this pattern if you wish. An example of this is shown below:

            var client = new SimpleServiceBusClient("RPC-Client");
            client.Username = WindowsIdentity.GetCurrent().Name;
            client.IdentityType = table.Rows[0]["Identity Type"];
            client.IdentityActAs = table.Rows[0]["Act As"];
            var response = client.SendAndWaitForResponse<IdentityFlowTestRequest, IdentityFlowTestResponse>(request);

Legacy Messaging Clients

The SimpleMessagingClient was recently introduced to make the message client experience a little simpler, however the old classes are still there incase anyone was using those. They are:
  • MessagingClient
  • SessionRequestResponseMessagingClient
  • SessionScatterGatherMessagingClient

MessagingClient

This class is intended to be used if your implementing a one way messaging pattern where you will push your message to the service bus and let it be processed later. Your not waiting for any kind of response.

An example of using this client is below:


            var properties = new Dictionary<string, object>();
            properties.Add("SENDER", "ACME");

            var messagingClient =
                new AppFx.ServiceBus.Client.MessagingClient<Contracts.Types.MemberUpdatedEvent>("EventClient");
            messagingClient.Send(_memberUpdateEvent, properties);
            MessageBox.Show(@"Event submitted");


As you can see this class is a generic class where I have specified the type generated from my schema as to type the class for use at runtime. This will then take care of serialization and other such things.

In the above example I want to use a topic so I am populating a dictionary with some settings which will be set as message properties to aid with subscription on the Azure Service Bus.

When I construct the instance of my messaging client I provide a string which will relate to one of the clients I have configured in the application configuration file. This is similar to the WCF endpoint configuration technique.

SessionRequestResponseMessagingClient

This class is used to implement a two way messaging pattern. When you send your message the class will setup a listener which will poll the response queue using the session you have provided to watch for the response message coming back.

An example of the use of this class is below:

                const string appFxClient = "AcmeRpcClient";
                var client =
                    new AppFx.ServiceBus.Client.SessionRequestResponseMessagingClient
                        <Contracts.Types.GetMemberDetailsRequest, Contracts.Types.GetMemberDetailsResponse>(appFxClient);
                var response = client.SendRequestResponse(request);
                resultsTextBox.Text = resultsTextBox.Text + @"\r\n" + response.Name;


SessionScatterGatherMessagingClient

This class is very similar to the SessionRequestResponseMessagingClient in that it will implement a 2 way messaging pattern however in this case this client will wait for a number of responses to return before returning to the caller.

An example of the use of this class is below.


                const string appFxClient = "ScatterGatherClient";
                var client =
                    new AppFx.ServiceBus.Client.SessionScatterGatherMessagingClient
                        <Contracts.Types.MemberSearchRequest, Contracts.Types.MemberSearchResponse>(appFxClient);
                var responses = client.SendScatterGather(request, 2);
                foreach (var response in responses)
                {
                    resultsTextBox.Text = resultsTextBox.Text + @"\r\n" + response.MemberId;
                }

Last edited Mar 25, 2014 at 1:17 PM by michaelstephenson, version 4

Comments

No comments yet.