Introduction to Messaging Channels	Pattern Catalog  Previous   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   Next

2009/05/10 – By 数位之墙 – 关键字／标签：电子商务 搜索引擎 门户网站 网络广告 B2C 品牌

》高阶工作机会《 – 年薪100万台币及15万人民币以上的工作
供应链经理级　Sales/Account Manager (苏州)　电子商务/客户服务主管　电源研发工程师/经理/处长　客服资材主管　客户服务主管(处长级以上)　设备及自动化设计高阶主管 (桃园)　机构技术主管	更多

◎开设分店成本低廉

由于电子商务是「电子」加「商务」，也因此有很多传统商务的运作方式被使用到互联网来。例如我们常听到的直营分店，加盟连锁，代理经销等。这些模式的原理不论在线或线下都一样，但在在线的部分，实际做法则会因互联网擅长处理信息流的特性而有所不同。

建立一个电子商务网站独立经营，基本上就算是直营店模式。看似简单，但是却也面临了「店要开在哪里」的问题。大部分网上直营店面临的困扰是，不做推广就没人潮流量，一旦做推广，购买网络广告的效果很差，成本高又吃不消。

把店面开在深山里，然后到大都市的市中心去发传单，希望消费者到店里购物，这难道不是大部分初创电子商务公司在干的事情吗？如果把「到大型网站购买网络广告」当成销售渠道来看，这种渠道的销售效率是非常低落的。

对比到实体世界的商务，大家都知道开店要开在人潮聚集处，要开在市中心而不是深山里。而「网上的市中心」在哪里？这就难怪有些电子商务网站选择到淘宝去开分店了。在实体世界，开分店的成本很高，而在虚拟的世界里，开分店无非就是另外建立一套系统而已。

这就是直营分店模式搬到网上的差别：你可用低廉成本在网上建立无数分店。然而，人潮聚集处并非只有淘宝。新浪搜狐等门户网站以及百度谷歌等搜索引擎，校内网开心网等社交网络，都可能摇身一变成为新的开店平台，吸引大量B2C 业者来开分店，或乾脆在此开直营店。

◎虚拟加盟的运作方式

在实体世界里，除了直营分店之外尚有加盟模式。由加盟者出资获得 品牌与经营授权，甚至负担店租与店内硬件设施成本，开设与直营店相类似的店面。因为在实体世界里开设分店的成本太高，所以经营者才需要透过加盟模式将这个成本转嫁给加盟者，达到快速展店目的。

由于在网上开分店的成本太低，这种模式在网上比较少见。然而，因为互联网擅长处理信息流的特性，却诞生出新的「虚拟加盟」方式。电子商务经营者与加盟者之间采用销售后分成的方式合作，而加盟者则获得一个自己的授权网店的网址，可用于推广。

例如，网上超市「一号店」（http://www.yihaodian.com）就采取这种方法，开设了「天涯一号店」（yihaodian.tianya.cn ）以及「新浪乐居一号店」（http://yihaodian.house.sina.com ）。这种类似于开设分店的方式，最大的不同在于与合作方采取售后分成的方式。

此外，从加盟店网址来看，加盟者似乎有一个自己的店面。但其实不论开设多少加盟店，最终交易都是发生在原来的直营店，加盟者根本没有自己的系统。当新浪用户来到一号店时，一号店就换上新浪招牌；当天涯用户来到一号店时，一号店就换上天涯招牌，如此而已。

不论交易是怎么发生的，背后的客户服务，物流，金流，其实都是由原来的直营店面完成，加盟者仅需专心在想办法导入人潮流量到加盟店网址去进行消费。这种加盟系统可以再扩大到个人，最终行成加盟体系（Affiliate Program） ，让即使是博客的经营者也可加盟。

◎销售后分成将成主流

Affiliate Program 可以翻译成「夥伴计画」，这个由Amazon发扬光大的推广模式，在西方世界已经行之有年非常成熟，可视为是完全看透了互联网擅长处理信息流特性的典范。在中国，知名的网上男性衬衣销售商Vancl 的发迹部分原因就是靠著Affiliate Program 。

在2005年的时候，有些台湾的电子商务公司到大陆来开疆辟土。当时大陆的电子商务环境还不太成熟，对方很惊讶的跟我说，大陆的网际网络流量很不值钱，流量很大，但是对电子商务公司来说，要的不是流量而是销售，而大陆的互联网流量大部分无法转换成销售。

这个问题相信是目前大部分电子商务公司的问题。你可以花大钱到新浪去买广告，但是新浪的广告所带来的流量最终转化成销售的比例却很低。而，新浪理所当然的不保证效果，他甚至不保证广告有人点击。在这种情况下，依照销售后付款的广告型态，将在中国逐渐兴起。

这种业界称为CPS （Cost Per Sale ，销售后分成）的广告型态，逐渐出现在中国大陆的广告市场，类似的广告联盟也不断冒出。由于广告曝光（CPM ）与广告点击（CPC ）对电子商务公司来讲，如果没有转化成销售都没用的，在B2C 大潮来袭之下，CPS 广告将成一大主流。

有了分店与加盟，还需要网上代理商与经销商吗？由于网上销售等于直接面对终端客户，传统经销代理制度对网上商城来说似乎不再必要。然而，传统行业在开设自己的网上商店时还是引入了这种体系，例如李宁的网上销售战略。这更多是出于价格／品牌／渠道管制的考虑。 （文：数位之墙）