Dear Dynamics people,
Today we talk about a middle layer of an application.In many projects requirements comes like two or multiple application wants to talk to one application or front end wants to communicate with back end application (Dynamics CRM, Database, Core .net application).
For above requirement, most of the time architecture decide to go with some REST or SOAP design. But the client will face about scale issue always. So an instance of REST/SOAP/XML messaging we can use service bus. And this will be more powerful compared to REST/SOAP/3rd party.
So Here we assume, the front end is the mobile app and wants to communicate with back end application which is Dynamics CRM and visa-verse.
First, we understand about Azure service bus and when using this then we check about Dynamics CRM and Azure Service Bus integration
Azure Messaging Services
Azure Messaging Services communications are three types and as per our requirements, we can select the messaging service.
1 Service Bus
2. Event Hubs
Where can I use Messaging
Where does Service Bus fit?
Features of Azure Service Bus:
Azure Service Bus: Azure Service Bus messaging is an implementation of modern message queuing concepts implemented in the Microsoft Cloud as the platform as a service. Service Bus messaging has two key areas:
Queues offer First In, First Out (FIFO) message delivery to one or more competing consumers. That is, messages are typically expected to be received and processed by the receivers in the order in which they were added to the queue, and each message is received and processed by only one message consumer. A key benefit of using queues is to achieve “temporal decoupling” of application components. In other words, the producers (senders) and consumers (receivers) do not have to be sending and receiving messages at the same time, because messages are stored durably in the queue. Furthermore, the producer does not have to wait for a reply from the consumer in order to continue to process and send messages.
In contrast to queues, in which each message is processed by a single consumer, topics and subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. Useful for scaling to very large numbers of recipients, each published message is made available to each subscription registered with the topic. Messages are sent to a topic and delivered to one or more associated subscriptions, depending on filter rules that can be set on a per-subscription basis. The subscriptions can use additional filters to restrict the messages that they want to receive. Messages are sent to a topic in the same way they are sent to a queue, but messages are not received from the topic directly. Instead, they are received from subscriptions. A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Messages are received from a subscription identically to the way they are received from a queue.
Presentation : AzureServiceBusIntegrationWithDyanmicsCRM