2009年5月14日星期四

Introduction to Messaging Channel - EIP

Introduction to Messaging Channels

Pattern Catalog

Previous Previous   Next Next

Site Home • Patterns Home • Table of Contents

In Introduction to Messaging Systems, we discussed Message Channel. 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.

Message Channel Themes

Deciding to use a Message Channel is 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.

Fixed set of channels — One theme in this chapter is that the set of Message Channels 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 Request-Reply. The requestor can create or obtain a new channel the replier knows nothing about, specify it as the Return Address of 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.)

Determining the set of channels — A related issue is: Who decides what Message Channels 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.

Unidirectional channels — Another common source of confusion is whether a Message Channel is 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—while technically possible—makes 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 Request-Reply in the next chapter).

Message Channel Decisions

Now that we understand what Message Channels are, let's consider the decisions involved in using them:

One-to-one or one-to-many — 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 Point-to-Point Channel. 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 Publish-Subscribe Channel. When you send a piece of data this way, the channel effectively copies the data for each of the receivers.

What type of data — Any data in any computer memory has to conform to some sort of type: 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. Datatype Channel is 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.

Invalid and dead messages — 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 Invalid Message Channel, 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 Dead Letter Channel for 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.

Crash proof — 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, Guaranteed Delivery makes 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.

Non-messaging clients — 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—through its user interface, its business services API, its database, or through a network connection such as TCP/IP or HTTP—then a Channel Adapter on 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 Messaging Bridge between the two, effectively connecting them into one composite messaging system.

Communications backbone — 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, 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.

So as you can see, getting applications set up for Messaging involves more than just connecting them to the messaging system so that they can send messages. The messages must have Message Channels 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.

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.


Home • Patterns • Table of Contents Previous Previous   Next Next


没有评论:

发表评论

供稿人

标签

Google (6) 船坚炮利 (5) Blogger (4) GHS (3) Salesforce (3) C.M.O. (2) GFW (2) Google Analytics (2) Google Apps (2) PR (2) Twitter (2) baidu (2) dns.com.cn (2) keso (2) kylin (2) python (2) 中国 (2) 新互 (2) .ru (1) 10-08-23 (1) 1960 (1) 2008 (1) 2012 (1) 3g (1) 404 (1) 502 (1) 71-81 (1) AFE (1) Adobe开源 (1) Banned (1) Basic English (1) Blogspot (1) CPI (1) CUIL (1) Character Entities (1) Checkout (1) Cloud Computing (1) D-Dos (1) Delphic oracle (1) Domain (1) Essential English (1) FRID (1) FTP (1) FeedBuner (1) Flash (1) Flex+Firefox (1) Flickr (1) Foolish Games (1) Force.com (1) GMAIL (1) Gmail Offline (1) Googe Site (1) Google Docs (1) Google Spreadsheet (1) IBM (1) IE+SilverLight (1) IPV9 (1) Jewel (1) Open Social (1) OpenID (1) PageRank (1) PigeonRank (1) QQ,IP隐私 (1) Redirect (1) Rich Memdia (1) SFTP (1) Secularism (1) Simplified Technical English (1) Sitemap (1) Spam (1) Special English (1) TV (1) Tracker (1) UI (1) aa (1) addOrganic (1) beyond (1) blog (1) blogbus (1) com (1) cyberWar (1) daas (1) dnspod (1) draft (1) earthquake (1) ebank (1) event track (1) fisher (1) git (1) google_prc (1) huang qi (1) iamfisher (1) iamfisher.net (1) ipai (1) linkedin (1) mayumusic (1) netsh (1) ning (1) paas (1) pk (1) planet-lab (1) ppc (1) qunar (1) roscosmos (1) saas (1) sars (1) serp (1) sohu (1) urchin (1) wealink (1) web analytics (1) wiki (1) zh_CN (1) 一本万利 (1) 三峡 (1) 上海人 (1) 下雨 (1) 世俗 (1) 世纪墙 (1) 中化网 (1) 中印 (1) 中欧 (1) 临终一课 (1) 乡下人 (1) 云之南 (1) 云计算 (1) 井真成 (1) 亨廷顿 (1) 人寿 (1) 人际 (1) 代价 (1) 传统 (1) 低腰裤 (1) 佛教 (1) 依赖症 (1) 偷懒 (1) 傲慢 (1) 儿时梦想 (1) 先进 (1) 公共品 (1) 六六 (1) 养廉 (1) 再融资 (1) 凤凰卫视 (1) 出版 (1) 刘仰 (1) 创新 (1) 删IE8 (1) 判例法 (1) 制高点 (1) 剩者为王 (1) 剽窃 (1) 北极 (1) 博客 (1) 危害健康 (1) 厚黑 (1) 原创 (1) 去哪儿 (1) 双面胶 (1) 发展 (1) 变暖 (1) 司法解释 (1) 合法外衣 (1) 吉尼斯 (1) 品牌 (1) 唐老鸭 (1) 嘿嘿 (1) 噩梦 (1) 国务院 (1) 土鳖 (1) 坚船利炮 (1) 域名被锁定 (1) 域名诉讼 (1) 基因 (1) 墓志铭 (1) 壳牌 (1) 奥运 (1) 妓女 (1) 威权 (1) 媒体 (1) 孙德良 (1) 孩子 (1) 定罪 (1) 宝洁 (1) 宣传 (1) 家庭税负不高 (1) 寻找好友 (1) 崩溃 (1) 巫咸 (1) 年代 (1) 开封犹太人 (1) 开放 (1) 张掖 (1) 弥勒 (1) 强烈 (1) 彩信 (1) 征召 (1) 很开放 (1) 很被守法 (1) 徐荣祥 (1) 微博 (1) 微软 (1) 微软收购雅虎 (1) 急死你 (1) 愚蠢 (1) 愤怒 (1) 愿望 (1) 我很抱歉 (1) 手机 (1) 执着 (1) 改版 (1) 改进 (1) 散乱 (1) 敦煌 (1) 文化入侵 (1) 文核 (1) 新加坡 (1) 方舟子 (1) 无标题 (1) 无语 (1) 日历 (1) 早报 (1) 暴力拆迁 (1) 最在邊外 (1) 月映天江 (1) 有趣 (1) 有限公司 (1) 朝贡 (1) 杀伐决断 (1) 标题党 (1) 梁山强盗 (1) 武威 (1) 比基尼 (1) 民族主义 (1) 水师 (1) 江姐 (1) 沉迷 (1) 泡沫 (1) 洁空 (1) 洋品牌 (1) 海归 (1) 海禁 (1) 海航 (1) 消费升级 (1) 温室 (1) 滕鸡 (1) 点出统计 (1) (1) 物权 (1) 犹豫 (1) 狗屁CPI指数 (1) 独角兽 (1) 玄幻 (1) 王彩玲 (1) 用Firefox (1) 电脑 (1) (1) 瘦身 (1) 百年积弱 (1) 知识产权 (1) 码字 (1) 砖窑 (1) 破坏力 (1) 硬道理 (1) 礼仪 (1) 祝福北京奥运 (1) 禽流感 (1) 科学网 (1) 稳定压倒一切 (1) 空降 (1) 穿越 (1) 童奴 (1) 第二人生 (1) 繁荣 (1) 红土高原 (1) 织壮锦 (1) 终身教授 (1) 统一 (1) 绿色 (1) 缓刑 (1) 缘起 (1) 缙云山 (1) 缺乏自信 (1) 网摘 (1) 网易新闻评论 (1) 网瘾症 (1) 网盛科技 (1) 网站分析在中国 (1) 网络游戏 (1) 网络犯罪 (1) 网鸟 (1) 美孚 (1) 老外 (1) 职业打假 (1) 联手制造 (1) 自卑感 (1) 自定义域名绑定 (1) 船坚器利 (1) 芙蓉姐姐 (1) 苏北人 (1) 草稿帖 (1) 草药 (1) 蒋雯丽 (1) 薄纳厚赠 (1) 虚拟财产 (1) 被误解 (1) 装傻 (1) 西南 (1) 论坛 (1) 谶语 (1) 货币 (1) 贴标签 (1) 赤蛇 (1) 转基因 (1) 软件C2C (1) 迁海令 (1) 过度依赖 (1) 进口关税 (1) 迪斯尼 (1) 道德传统 (1) 道德缺陷 (1) 道长 (1) 邓公 (1) 酒泉 (1) 金融时报 (1) 长短 (1) 闲逛 (1) 闹晕 (1) 闹晕经济 (1) 阿里软件 (1) 难过 (1) 青蛇 (1) 非洲 (1) 风力 (1) 食品 (1) 首席营销官 (1) 高鑫养廉 (1) 鸦片战争史 (1) 黄芪 (1) 龙象 (1)