Hello, everyone! .
AppFabric Service Bus. In my previous posts, I casually mentioned the technology and gave her definition ( for example, here.
Introduction to the integration infrastructure. ). Today we have a closer look at the mechanism, the main scenarios of bus service, and look to begin work, and how to create your first namespaces.
So, let's imagine that we are building an application that needs to interact with other applications. Something like compounds.
peer-to-peer. The biggest problem that usually arises in the design - a large number of constraints on the process of communication ( firewalls, NAT- T and translators. Dr.. ) Typically allow network devices to initiate outgoing connections, but all members are discarded immediately for safety reasons. Therefore, we always have with you wildly perverted to circumvent these limitations of network equipment, while coming up with a pretty complex functionality. And since the network topologies, there are countless, then change the ... It is to solve such problems and the technology was invented.
Service Bus. Which makes it relatively easy to organize a connection between different applications. The mechanism supports a large number of patterns of interaction, including such as bi-directional connection.
peer-to-peer. - Connection scenario.
publish / subscribe. , Scenarios that involve the preservation and forwarding messages, etc.
Some facts about technology:.
The tire is based on technology. Windows Communication Foundation. and uses standard Internet protocols.
Service is hosted in the cloud. The technical side of the mechanism of interaction involves simplifying services and applications, even if they are for ...
Building applications using the bus, does not require significant changes to source code.
As part of the integration infrastructure. Service Bus. reduces the cost of construction, deployment and support systems in comparison with all existing analogues present.
What are the main usage scenarios.
Service Bus. ? In my understanding of the diversity can be identified 4 main.
The first option - is the one to which I have often remembered today, namely, relaying messages. Very handy for those situations where we need to access a remote service, and thus it is necessary to overcome many barriers, including NAT- translators and firewalls (very often for such a situation use the term Service Remoting). For such situations, service bus will be extremely useful.
Service Bus can also be used as a convenient and efficient delivery method according to the scenario of events. publish / subscribe. This is a very common scenario, under which we have certain events that may generate one or more sources, and there are subscribers who need to be compulsorily notified of the event has occurred. That's just the mechanism of distribution facilities and events, as well as subscription and connection / disconnection from the bus takes the Service Bus, which greatly facilitates the life of a developer.
Above all, the bus can be used as a mechanism for message queuing. This is somewhat similar to an event-driven model, except for some fundamental differences. First in the case of tires as a queue storing messages is guaranteed up to the point of delivery to the Subscriber. For example, if the system receives events in the queue, and an endless stream handlers simply do not have time to deal with the coming challenges, the queue will store all the events until they are processed. The second stage is usually used in very different scenarios - for the organization of loosely coupled systems in order to build a more scalable applications.
The latest version of the application, which I would like to tell - an enhanced event model that allows you to customize a flexible routing of messages. This thing called. Service Bus Topics. In this system, the developer can create topics and set up rules filtering messages based on selected criteria. The figure below shows an example of topics.
Suppose we have a regular online store, allowing customers to buy books and CD-ROMs. Once the client has issued an order, we need to notify the background subsystem responsible for the further processing of the order. The first subsystem can only handle orders of books. Second - can only handle orders discs. The third subsystem is designed to log any order. In such circumstances, the ideal solution would be to use topics. In the above scenario will create a topic, and it rules that determine what books should be directed orders processing subsystem and the subsystem audit the books and orders drives - disk subsystems processing and auditing. All we need - is to specify a set of rules according to which the message will be routed, the rest of us do.
Service Bus Topic. So you need to do to get started with Service Bus? . Namespaces serves as a container for an application that contains all points of access to bus service. To do this, the portal developer to go to the section.
... and click to create new namespaces.
After that, we will open an interesting window in which to choose as a services -enabled Service Bus, will determine the name ( it must be unique because it will be used to uniquely identify the tires on the Internet), the target region, as well as the maximum number of connections. In my case turned out the following situation:.
After pressing the buttons Create Namespace will have a little bit to wait until it is activated. As soon as it happens in front of namespaces will be the status of Activated, that would indicate it was fully alert.
At that, the technology can be considered complete. In subsequent articles we will delve into the details of the organization and functioning of the Service Bus on a real example.
