Schema-Oriented Message Destination Author ====== Ricky Ho (rickyphyllis@hotmail.com) 08/28/2001 context ======= When a Message Product (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): unexpected structure If the consumer consumes a message from a queue with an.. At Best, IT Detects The Message IS NOT UNDERSTABLE AND DROPS IT. AT WORST, The Message With Wrong Structure Will Crash The Consumer App. Well-Written Consume . R 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 Verifier The Message. 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 replyschema-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 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 of do the validation for you. Besides, the value 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 replyschema-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 does not 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 consume r. 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 replyschema-Oriented Message Destination
Posted By: Giedrius Trumpickas on August 30, 2001 in response to this message I do not 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 replyschema-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 do not 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 do not 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 is not 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 destinationPosted 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 does not 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 do not know of any organization that does such standardization should not it just be a company internal policy? 1 replies in this thread ReplySchema-oriented message destination
