Online casino Philippines using gcash {"id":451,"date":"2009-05-14T19:19:00","date_gmt":"2009-05-14T11:19:00","guid":{"rendered":"http:\/\/wp.imkylin.cn\/?p=451"},"modified":"2009-05-14T19:19:00","modified_gmt":"2009-05-14T11:19:00","slug":"introduction-to-messaging-channel-eip","status":"publish","type":"post","link":"http:\/\/wp.imkylin.cn\/archives\/451","title":{"rendered":"Introduction to Messaging Channel – EIP"},"content":{"rendered":"

<\/p>\n

\n\n\n\n\n

<\/td>\n

Introduction to Messaging Channels<\/td>\n

\n

Pattern Catalog<\/p>\n

$\"Previous\"$ <\/a>\u00a0 Previous<\/a>\u00a0\u00a0\u00a0 Next<\/a>\u00a0 $\"Next\"$ <\/a><\/p>\n<\/td>\n

<\/a><\/td>\n<\/tr>\n

Site Home<\/a>\u00a0\u2022\u00a0 Patterns Home<\/a>\u00a0\u2022\u00a0 Table of Contents<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

In\u00a0 Introduction to Messaging Systems<\/i><\/a>, we discussed\u00a0Message Channel<\/i><\/a>. When two applications wish to exchange data, they do so by sending the data through a channel that connects the two. The application sending the data may not know which application will receive the data, but by selecting a particular channel to send the data on, the sender knows that the receiver will be one that is looking for that sort of data by looking for it on that channel. In this way, the applications that produce shared data have a way to communicate with those that wish to consume it.<\/p>\n

Message Channel Themes<\/h2>\n Deciding to use a\u00a0 Message Channel<\/i><\/a>\u00a0is the simple part; if an application has data to transmit or data it wishes to receive, it will have to use a channel. The challenge is knowing what channels your applications will need and what to use them for.<\/p>\n
Fixed set of channels<\/b>\u00a0\u2014 One theme in this chapter is that the set of\u00a0Message Channel<\/i><\/a>s available to an application tends to be static. When designing an application, a developer has to know where to put what types of data to share that data with other applications, and likewise where to look for what types of data coming from other applications. These paths of communication cannot be dynamically created and discovered at runtime; they need to be agreed upon at design time so that the application knows where its data is coming from and where the data is going to. (While it is true that most channels must be staticly defined, there are exceptions to this theme, cases where dynamic channels are practical and useful. One exception is the reply channel in\u00a0Request-Reply<\/i><\/a>. The requestor can create or obtain a new channel the replier knows nothing about, specify it as the\u00a0Return Address<\/i><\/a>\u00a0of a request message, and then the replier can make use of it. Another exception is messaging system implementations that support hierarchical channels. A receiver can subscribe to a parent in the hierarchy, then a sender can publish to a new child channel the receiver knows nothing about, and the subscriber will still receive the message. These relatively unusual cases notwithstanding, channels are usually defined at deployment-time and applications are designed around a known set of channels.)<\/p>\n
Determining the set of channels<\/b>\u00a0\u2014 A related issue is: Who decides what\u00a0Message Channel<\/i><\/a>s are available, the messaging system or the applications? That is to say: Does the messaging system define certain channels and require the applications to make due with those? Or do the applications determine what channels they need and require the messaging system to provide them? There is no simple answer; designing the needed set of channels is iterative. First the applications determine the channels the messaging system will need to provide. Subsequent applications will try to design their communication around the channels that are available, but when this is not practical, they will require that additional channels be added. When a set of applications already use a certain set of channels, and new applications wish to join in, they too will use the existing set of channels. When existing applications add new functionality, they may require new channels.<\/p>\n
Unidirectional channels<\/b>\u00a0\u2014 Another common source of confusion is whether a\u00a0Message Channel<\/i><\/a>\u00a0is unidirectional or bidirectional. Technically, it’s neither; a channel is more like a bucket that some applications add data to and other applications take data from (albeit a bucket that is distributed across multiple computers in some coordinated fashion). But because the data is in messages that travel from one application to another, that gives the channel direction, making it unidirectional. If a channel were bidirectional, that would mean that an application would both send messages to and receive messages from the same channel, which\u2014while technically possible\u2014makes little sense because the application would tend to keep consuming its own messages, the messages it’s supposed to be sending to other applications. So for all practical purposes, channels are unidirectional. As a consequence, for two applications to have a two-way conversation, they will need two channels, one in each direction (see\u00a0Request-Reply<\/i><\/a>\u00a0in the next chapter).<\/p>\n
Message Channel Decisions<\/h2>\n Now that we understand what\u00a0 Message Channel<\/i><\/a>s are, let’s consider the decisions involved in using them:<\/p>\n
One-to-one or one-to-many<\/b>\u00a0\u2014 When your application shares a piece of data, do you want to share it with just one other application or with any other application that is interested? To send the data to a single application, use a\u00a0Point-to-Point Channel<\/i><\/a>. This does not guarantee that every piece of data sent on that channel will necessarily go to the same receiver, because the channel might have multiple receivers; but it does ensure that any one piece of data will only be received by one of the applications. If you want all of the receiver applications to be able to receive the data, use a\u00a0Publish-Subscribe Channel<\/i><\/a>. When you send a piece of data this way, the channel effectively copies the data for each of the receivers.<\/p>\n
What type of data<\/b>\u00a0\u2014 Any data in any computer memory has to conform to some sort of\u00a0type<\/i>: a known format or expected structure with an agreed upon meaning. Otherwise, all data would just be a bunch of bytes and there would be no way to make any sense of it. Messaging systems work much the same way; the message contents must conform to some type so that the receiver understands the data’s structure.\u00a0Datatype Channel<\/i><\/a>\u00a0is the principle that all of the data on a channel has to be of the same type. This is the main reason why messaging systems need lots of channels; if the data could be of any type, the messaging system would only need one channel (in each direction) between any two applications.<\/p>\n
Invalid and dead messages<\/b>\u00a0\u2014 The message system can ensure that a message is delivered properly, but it cannot guarantee that the receiver will know what to do with it. The receiver has expectations about the data’s type and meaning; when it receives a message that doesn’t meet these expectations, there’s not much it can do. What it can do, though, is put the strange message on a specially designated\u00a0Invalid Message Channel<\/i><\/a>, in hopes that some utility monitoring the channel will pick up the message and figure out what to do with it. Many messaging systems have a similar built-in feature, a\u00a0Dead Letter Channel<\/i><\/a>\u00a0for messages which are successfully sent but ultimately cannot be successfully delivered. Again, hopefully some utility monitoring the channel will know what to do with the messages that could not be delivered.<\/p>\n
Crash proof<\/b>\u00a0\u2014 If the messaging system crashes or is shut down for maintence, what happens to its messages? When it is back up and running, will its messages still be in its channels? By default, no; channels store their messages in memory. However,\u00a0Guaranteed Delivery<\/i><\/a>\u00a0makes channels persistent so that their messages are stored on disk. This hurts performance but makes messaging more reliable, even when the messaging system isn’t.<\/p>\n
Non-messaging clients<\/b>\u00a0\u2014 What if an application cannot connect to a messaging system but still wants to participate in messaging? Normally it would be out of luck; but if the messaging system can connect to the application somehow\u2014through its user interface, its business services API, its database, or through a network connection such as TCP\/IP or HTTP\u2014then a\u00a0Channel Adapter<\/i><\/a>\u00a0on the messaging system can be used to connect a channel (or set of channels) to the application without having to modify the application and perhaps without having to have a messaging client running on the same machine as the application. Sometimes the "non-messaging client" really is a messaging client, just for a different messaging system. In that case, an application that is a client on both messaging systems can build a\u00a0Messaging Bridge<\/i><\/a>\u00a0between the two, effectively connecting them into one composite messaging system.<\/p>\n
Communications backbone<\/b>\u00a0\u2014 As more and more of an enterprise’s applications connect to the messaging system and make their functionality available through messaging, the messaging system becomes a centeralized point of one-stop-shopping for functionality in the enterprise. A new application simply needs to know which channels to use to request functionality and which others to listen on for the results. The messaging system itself essentially becomes aMessage Bus<\/i><\/a>, a backbone providing access to all of the enterprise’s various and ever-changing applications and functionality. You can achieve this integration nirvana more quickly and easily by specifically designing for it from the beginning.<\/p>\n
*So as you can see, getting applications set up for\u00a0**Messaging<\/i><\/a>\u00a0involves more than just connecting them to the messaging system so that they can send messages. The messages must have\u00a0*Message Channel<\/i><\/a>s to transmit on. Slapping in some channels doesn’t get the job done either. They have to be designed with a purpose, based on the data type being shared, the sort of application making the data available, and the sort of application receiving the data. This chapter will explain the decisions that go into designing these channels.<\/p>\n
To help illustrate the patterns, each one has an example from a ficticious, simplified "stock trading" domain. While none of these examples should be used as the basis for implementing a real trading system, they do serve as quick and specific examples of how the patterns can be used.<\/p>\n
\n\n\n\n
Home<\/a>\u00a0\u2022\u00a0 Patterns<\/a>\u00a0\u2022\u00a0 Table of Contents<\/a><\/td>\n $\"Previous\"$ <\/a>\u00a0 Previous<\/a>\u00a0\u00a0\u00a0 Next<\/a>\u00a0 $\"Next\"$ <\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\n\n\n
<\/td>\n \u00a9 2003\u00a0Gregor Hohpe<\/a>\u00a0\u2022\u00a0 Bobby Woolf<\/a>\u00a0\u2022 All rights reserved.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n<\/div>\n
<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction to Messaging Channels Pattern Catalog \u00a0Pre … \u7ee7\u7eed\u9605\u8bfbIntroduction to Messaging Channel – EIP<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/posts\/451"}],"collection":[{"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/comments?post=451"}],"version-history":[{"count":0,"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/posts\/451\/revisions"}],"wp:attachment":[{"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/media?parent=451"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/categories?post=451"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/wp.imkylin.cn\/wp-json\/wp\/v2\/tags?post=451"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}