分享
 
 
 

Schema-oriented message destination

王朝java/jsp·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

Schema-oriented message destination

AUTHOR

======

Ricky Ho (rickyphyllis@hotmail.com)

08/28/2001

CONTEXT

=======

When a message producer send a message to a destination (queue or topic), he wants to make sure that he is sending messages to a destination where the consumers can understand. Similarly, when a message consumer receive a message from a destination, he wants to make sure that he can understand all messages he take from the destination.

PROBLEMS

========

In JMS, the producer and consumer are tightly coupled with the message structure. However, there is no relationship between the destination and the message structure. Therefore, the consumer application and producer application needs to agree upfront (at design time) what message structure will be produced or consumed.

(Problem 1):

There is NO standard way for a new producer app or consumer app to learn what message structure they should be used for a destination. They will try to look for existing design documents to find if they mention anything about the message structure. Nevertheless, the only reliable way is to look at source code from existing producer and consumer app. This process is error-prone.

(Problem 2):

If the consumer consumes a message from a queue with an unexpected structure. At best, it detects the message is not understandable and drops it, in this case the message is lost. At worst, the message with wrong structure will crash the consumer app. Well-written consumer applications will take the burden to code the message structure validation logic, resulting in undesirable complexity. Ideally, the message structure should have been verified before passing to the consumer application.

(Problem 3):

Whenever a change is needed for a message structure (usually initiated from one of the message producer), nightmare start. First, we need to trace all the destination where the new message (with the changed message structure) will go to. Second, for each of the destination, we need to trace all the consumer applications and make sure that they are changed apropriately to deal with the new message structure. This tracing can be very difficult when the consumer application dynamically subscribing and receiving from destinations. If we miss the upgrade for one consuming app, we are introducing problem 2.

SOLUTION

========

A destination should only accept one type of message with a particular message structure. The metadata associated with each destination should include the definition of this ONE message structure that it accepts.

Whenever a message is sent to a destination, the JMS container should verifies the message with the specified structure.

Whenever a change is made to a message structure, a new version of destination (by destination naming convention)is created, at the same time all existing consumer applications will received a callback method "onSchemaChange()". Now this new destination will only accept message with the new (changed) message structure. Old producer app without aware of the message structure change can keep sending message with old structure to the old destination which will be consumed by old consumer apps. Because, existing consumer apps will never receive the new message type until they explicitly change to the new destination, they won't break. This mechanism requires the producer and consumer applications to explicitly move to a new destination and accomodate the message structure changes at the same time.

CONSEQUENCE

===========

By enforcing the association between a destination with a message type. We can standardize the mechanism how the producer app and consumer app discover the correct message schema.

By introducing metadata of the destination, a producer app and consumer app can examine that at run time, and hence reducing design-time assumptions.

The destination versioning helps to prevent incompatibilities problems when schema changes.

4 replies in this thread

Reply

Schema-oriented message destination

Posted By: Gal Binyamini on August 29, 2001 in response to this message.

Some notes:

1. When a schema changes, how do you suppose the clients will start producing new valid versions? New schemas usually mean different data. In order to make clients that can adapt to new schemas on-the-fly you need a lot of technology, and this pattern alone won't help you at that (I belive some work is done in this direction in JXTA).

2. Having a callback to a client is *extremely* undersireable in message-based application. It makes strong coupling between consumers and producers, and should be avoided whenever possible. I think this alone rules out this particular strategy.

3. You have made no proposal as for the schema language to use, and I don't think any one can propose such language. Therefore I don't see a way for the JMS provider to do the validation for you. Besides, the fact is the JMS provider doesn't do the validation, so the current proposal is not a "design pattern" - it can't work with existing specs.

As I see it, this pattern comes down to: define the structure of the message in some language and before you start processing a message make sure it conforms to the definition.

This is generally what people do today, and I think it's more of a "good practice" than a "design pattern".

The parts about making this definition formal and available are again, IMHO, just good practice.

Note that in some areas such as XML messaging defining the input schema using a DTD/XML Schema is possible. Most such systems will support this notion.

Gal

0 replies in this thread

Reply

Schema-oriented message destination

Posted By: Ricky Ho on August 29, 2001 in response to this message.

Of course we verify the message structure using schema validation (in case of XML message) but there is no association between a JMS destination with an XML schema. This pattern suggest to associate the schema definition with the destination so that the validation can be done outside the consumer application (possibly by the JMS container).

My response to your 3 notes

1) The pattern doesn't advocate application (producer or consumer) needs to be adapt to new schema on the fly. Although the metadata of the destination allows this to happen by enabling introspection-style programming, it is not recommended because the code will become less readable (similar to using Java reflection API instead of regular method calls). The pattern actually enable the producer app and consumer app to upgrade their code (design-time, not run-time) in a controllable way so that new producer would never get a chance to talk to an old consumer.

2) Callback function is used extensively in JMS. Whenever a subscriber subscribe to a topic, it register a callback function "onMessage()" which will be called whether a message is delivered to that topic. Same for MessageDrivenBean, "callback" almost becomes a dominant case. Would you mind to elaborate more detail about the tight coupling scenario you mentioned.

3) For XML message, the Schema language will be XML Schema. For Map message, the Schema language will specify the list of key names. For Object message, the Schema language will specify the class name of the Java Object.

Best regards,

Ricky

2 replies in this thread

Reply

Schema-oriented message destination

Posted By: Giedrius Trumpickas on August 30, 2001 in response to this message.

I don't think that this design suggestion can be treated as pattern. It just design suggestion for MOM API.

In simple terms it sounds: messages version support in MOM and message routing to consumers depending on version.

0 replies in this thread

Reply

Schema-oriented message destination

Posted By: Gal Binyamini on August 30, 2001 in response to this message.

As you said, the association of schema definition with a destination is important at design time, not run time. I don't see a reason for letting the clients know about new schemas as they arrive unless they can adapt to them.

If you want a seperate service of notifying clients as new versions of the service get released, you can use a callback (with a topic) as you described. I don't see how this is specifically relevant to this pattern.

If choosing a schema language was that simple, JMS would have incorporated it. However, JMS is designed to be used in a variety of different ways, and validation may mean different things to differet people. When I validate a Map, I usually need to check the actual mapped values, not only that *some* value exists for them. I see no special reason why JMS should support your specific schemas rather than others. If you need these particular types of schemas, you can extend JMS (for instance, by providing a common base class for listeners).

If JMS will be extended to support XML messaging in specific (which isn't obvious), it may support XML Schemas.

Anyway, my point is not that what's described here is not a good design approach. It's simply not a design pattern, IMHO.

Regards

Gal

0 replies in this thread

Reply

Schema-oriented message destination

Posted By: Polina Alber on September 12, 2001 in response to this message.

Introduction of "schema-oriented message destination" comes against loosely coupled system approach. In addition a number of destinations can be limited per system. I think the easiest way to enforce message delivery to appropriate consumer is to use a message selector option and custom message properties settings ( like: proprietary message format type).

1 replies in this thread

Reply

Schema-oriented message destination

Posted By: Ricky Ho on September 13, 2001 in response to this message.

The unfortunate fact is, in current JMS, the producer and consumer code are "tightly coupled" with the message structure. Message selector doesn't help in this case because there is nothing preventing the producer code putting the right message properties but the wrong message type and crash the consumer code.

The solution is some schema checking needs to be done before the message get dispatched to the consumer. Therefore, we need to associate some schema information with the destination (queue/topic) to enable this kind of checking.

Ricky

0 replies in this thread

Reply

Schema-oriented message destination

Posted By: Peter Donald on September 16, 2001 in response to this message.

I am not sure this is strictly needed as part of the API or even the infrastructure. Names in JMS roughly corespond to ports in TCP/IP world.

The TCP/IP world has several "schemas" and generally they are associated with a port (though not necessarily). For instance the HTTP "schema" is associated with port 80, 8080 and a few others ontop of SSL.

If there was well known and published schemas then I think they could have well known and published names. However as I don't know of any organization that does such standardization shouldn't it just be a company internal policy?

1 replies in this thread

Reply

Schema-oriented message destination

Posted By: Ricky Ho on September 16, 2001 in response to this message.

Peter,

There are some interesting difference ...

1) Port 80 is well-known, but not any JMS destination.

2) HTTP parameters has a well-published encoding standard, but JMS doesn't.

In fact, HTTP suffer from a similar problem, but to a lesser degree, because ...

a) HTTP has a different programming model. Typically the Servlet will extract only the parameters it expect, so whatever it doesn't expect will simply be ignored. For those it expects, the Servlet code will check if they are "null" or any application specific test. Of course in JMS, such checking responsibility can be put into the receiver code also, but having another layer to enforce this is cleaner, because the checking is declared externally, rather than buried into the Java code.

b) HTTP is a sync protocol, so whatever the sender immediately aware of any problem that has occured and deal with it immediately. However, exception handling in an async protocol is very clumsy. The default exception handling is just abort the receiving side transaction and keep re-dispatching the wrong message. Usually the solution requires some more complex async notification and sometime manual intervention. It will be much better if the checking can be done by the message broker when the sender sends the message. (the interaction between the sender and message broker is usually sync).

Best regards,

Ricky

0 replies in this thread

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有