| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Message Sets |
« View previous topic :: View next topic » |
| Author |
Message
|
| jhiemstra |
 Posted: Wed May 01, 2002 3:35 am Post subject: |
 |
|
Newbie
Joined: 27 Mar 2002
Posts: 6
Location: The Economical Insurance Group, Canada
|
We are looking for a company standard when creating new message sets. As it stands now it is left up to each developer. This has led to a number of different ideas:
One message set per project.
One message set per Request/Reply scenario.
One message set per message.
In one of the manuals it states the following:
"Typically, a message set contains a number of related
messages that provide the definitions required for a specific business task or
application suite."
I would appreciate knowing what other developers are doing.
Thanks
Jason |
|
| Back to top |
|
 |
| kirani |
| Posted: Wed May 01, 2002 8:18 am Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Jason,
Here is some info from "Working with Messages" book (Chapter 3: Planning your MRM model).
"You can only import and export message sets, you cannot import or export individual message. Therefore you might want to limit the size of your message sets to ensure the most efficient distribution of the required messages around your enterprise."
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| CodeCraft |
| Posted: Sun May 05, 2002 9:29 am Post subject: |
|
|
Disciple
Joined: 05 Sep 2001
Posts: 195
|
How exactly you do this depends on your distribution of:
a) Actual data
b) Services which access the data
And whether you are driven more by the services/processes or the data which the services/processes act upon.
One message per message set is a bit feeble, unless there is some good design reason for doing so.
If you have multiple services/process, which access the same collection of data, I would recommend putting those messages in one set (unless that set is the whole universe of your data).
If you have certain groups of messages, used by certain processes, you could divide the sets that way.
The key things to remember are:
- A set size manifests itself at build time(including import/export) and runtime.
- There's no point in deploying a set to an execution group if the flows deployed to that group only use a fraction of what's in the set, because the full dictionary for the set is still loaded at runtime.
- Determine what the relationship of the actually messages is, to the actually flows (processes) you have, and thereby you can look at the best distribution of messages within sets.
Ultimately, a set us just a unit of management in the repository.
The distibution of messages within sets, and flows within brokers and execution groups, should be a matter of project policy and not developer discretion. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
