In the course of learning to share sharp distinctions, let us look at the messaging patterns, such as data type channel, the message is not valid and invalid messages, crashes verification and guaranteed delivery and non-messaging client.
Foreword
When two or more applications to exchange data, it is connected to the passage to exchange the data transmission by other applications through. Application sends data may not know which application receives the data, but to send data by selecting a specific channel, the sender knows the recipient will be to find such data by looking up data on its receiver channels.
When designing an application, developers must know what type of data is placed to share the data with other applications, the same should also find out what types of data from other applications where to where. These communication paths can not be dynamically created and discovered at runtime. They need to reach a consensus in the design, so the application knows which data from where and where the data will arrive. One exception is a request - reply channel in reply. The requestor may be created or acquired responder does not know the new channel, which is designated as the return address of the request message, then the response can use it. Another exception is the mail system support barker channel implementation. Recipients can subscribe to the parent object hierarchy, then the sender can publish the recipient does not know the contents of the new sub-channel, subscribers will still receive messages.
First, the application determines the channel messaging system will need to provide. Subsequent application will attempt to design around the communication channel is available, but if impractical, will need to add additional channels. When a set of application already uses a specific set of channels, and the new application wishes to join, it will use the existing set of channels. When an existing application to add new features, they may need new channels.
Another common cause of confusion is the message channel is unidirectional or bidirectional. Technically, neither; channel more like some applications to add data to other applications wherein the bucket from which to obtain data. However, because the data is propagated in a message from one application to another application, the given direction of the channel, making it unidirectional. If a channel is bidirectional, it means that an application can only send messages to the same channel, will receive messages from the same channel, because the application tends to continue to consume its own message, and the message is supposed to be sent to other application. Thus, for all practical purposes, channels are unidirectional. As a result, two applications for two-way dialogue, they will need two channels, one for each direction.
Thus, using different types of channels in a messaging system. Message mode channel is a basic architecture of the messaging system, for exchanging data between applications fundamentally.
1, one to one or one to many
When an application to share data with one of the other applications or any other application of the data of interest only. Then you can use Point to Point Tunneling. This can not guarantee that each of the data transmitted on the channel are bound to the same receiver as the channel may have multiple receivers. But it does ensure that only one application can receive any piece of data.
If all recipients are required to receive data, use the publish - subscribe to the channel. Then, the data channel is effectively copied, and transmitted to each receiver. The sender simply an event broadcast to all interested receivers.
2, the data type (data type channel)
Message content must conform to a certain type, so that the recipient understand the structure of the data. Data type of channel is a principle, all of the data on the channel must have the same type. This is the main reason messaging system requires a lot of channels. If the data can be of any type, the messaging system between any two applications require only one channel (in each direction).
3, invalid and ineffective messages
Messaging system can ensure the correct pass messages, but can not guarantee that the recipient knows how to handle. There are expectations of the recipient type and meaning of the data. However, it can do is strange message in specially designated the "Invalid Message Channel" in the hope of some utility to monitor the channel can extract the message and how to figure out the process.
Many messaging system having a similar built-in functionality, i.e. dead letter channels, but ultimately not used to successfully send messages successfully delivered. Again, hope that some monitors that channel utility will know how to handle undeliverable messages.
4, crash proof
If the messaging system down for maintenance or crash. Back up and running, the message will remain in the channel thereof. By default, no; channel to which the message is stored in memory. However, `` guaranteed delivery '' so that the channel remains persistent state, so that its message is stored on the disk. This affects performance, but makes messaging more reliable.
5, non-mail client
If the application can not connect to the messaging system, but still want to participate messaging. However, if the messaging system through its user interface, business services which the API, a database or over a network connection (e.g., TCP / IP or HTTP) connected in some way to the application, can be used on the `` channel messaging system adapter '' of the channel (or group of channels) connected to the application, without having to modify the application, a messaging client need not run on the same computer application resides.
Sometimes, the "non-messaging client" is actually a messaging client, only for other messaging systems. In this case, as a client application on both messaging system can be established in a messaging bridge therebetween, thereby effectively connected to a messaging system complex thereof.
to sum up
Articles I write to you, I believe we now have a simple description of the. If deficiencies are welcome to add comments.