| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Replacing FTP with MQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| pathipati |
 Posted: Sun Jan 14, 2007 9:44 am Post subject: |
 |
|
Master
Joined: 03 Mar 2006
Posts: 296
|
| rtsujimoto wrote: |
| I don't see anything wrong with someone trying to learn something, even if there's a commercial alternative out there. If the person has the time and inclination, then why not? |
I agree.
| Jeff wrote: |
| So you've been constantly improving your initial release for more than 10 years, and you still have things to make better... |
Jeff don't you think this won't happen if we purchase the product. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Sun Jan 14, 2007 12:14 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I've written this by hand. I've also implemented PM4Data.
I'm not actually recommending either approach, or recommending against either approach.
I'm saying that it is more expensive than it looks like at first to write this by hand.
I'm saying that you can't decide whether implementing PM4Data is less expensive than writing it by hand until you know how much it's going to cost to write.
And I'm also saying that a lot of people make an initial estimate based on "Well, it'll take me maybe three days to write some code that I think will be production ready that can read a file and put a message onto a queue." And then it takes them another six months to get all of the actual requirements - like auditing and non-repudiation and security and dealing with a non-transactional file system in a transactional manner - worked out and implemented. It's more expensive than it looks.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Mon Jan 15, 2007 5:22 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
| scottj2512 wrote: |
You can even get more cleverer (poor english intended  ) and have multiple files all streamed together across the same queue if you use something in the correlation ID of your messages/state queue to relate the messages to a file (a separate correl ID for each file). |
Please don't use transport headers to hold business information. |
The file contents are business information, not the file name.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 15, 2007 5:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you have any reason to carry the file name in the message, then it's business information - because you need to make some kind of decision using it!
If you're only carrying the file name through for the simple purpose of "knowing where the message came from" - then in my opinion it's better to log that information in the audit trail, and associate that with the message ID that MQ generates.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Mon Jan 15, 2007 5:54 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
| If you have any reason to carry the file name in the message, then it's business information - because you need to make some kind of decision using it! |
Its only business information if the business care about it. The business may not care that a file is called x.xml or y.xml or z-2007-01-23.xml if it gets loaded behind the scenes and they just see the data in their application.
The manuals say "This [the correlation ID] is a byte string that the application can use to relate one message to another, or to relate the message to other work that the application is performing." Thus it might be appropriate to use the correlation ID to relate the messages to the work of keeping files separate.
That's not to say that one shouldn't take care in one's choice of MQMD fields to use. There are other MQMD fields that may be more appropriate to one's needs, or using an extra header (e.g. RFH2 or custom) may serve one's purposes better.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 15, 2007 6:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the steps that process the file after it's loaded to a queue never care what the filename is, then it doesn't belong in the message. Unless you're defensively coding for unknown future requirements (which isn't a bad thing).
If the steps that process the file after it's loaded to the queue DO care what the file name is, then it's not appropriate to put that information in the MQMD. It's "business" data to the extent that some process needs to make a decision about it.
I'll give you your quibble about "business" information otherwise. A file name is transport information, but should not be kept in the MQMD. There's no appropriate place for it. An MQRFH2 is a much better solution. Or a customer header of some kind.
The MQMD is a very poor place to put any kind of context information that does not directly relate to MQ, and the Message ID and Correlation ID are especially bad, and especially bad for FILE NAMEs for the following several reasons: *) they are never converted between character sets, *) They are almost assuredly going to be too small for some need (24 characters!), *) they are byte strings, and not character strings, *) you have to enforce a contract across your entire MQ network that no application will mangle, update, or fail to pass on the id, even in cases where it might be apprpropriate to generate a new one instead - for example a request/reply scenario.
I guess I need to write up my whole rant about the complexities of file <-> MQ somewhere, so I can link back to it - because it comes up far too often.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Tue Jan 16, 2007 5:24 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
A file name is transport information, but should not be kept in the MQMD. There's no appropriate place for it. An MQRFH2 is a much better solution. Or a customer header of some kind.
The MQMD is a very poor place to put any kind of context information that does not directly relate to MQ, and the Message ID and Correlation ID are especially bad, and especially bad for FILE NAMEs for the following several reasons: *) they are never converted between character sets, *) They are almost assuredly going to be too small for some need (24 characters!), *) they are byte strings, and not character strings, *) you have to enforce a contract across your entire MQ network that no application will mangle, update, or fail to pass on the id, even in cases where it might be apprpropriate to generate a new one instead - for example a request/reply scenario. |
I agree with you on the CorrelID is a bad place to put a file name. However, I never said it had to be the file name. All my original post said was that the correlation ID could be used to keep messages for file 1 separately identifiable from messages for file 2. I never mentioned sending a file name (or if I did it was a slip of the keyboard )
Thus I still maintain that the correlation ID can be used to relate the messages together. As for mangling the ID as its processed by intermediate processes, I would expect any well behaved program to honor the defacto standards laid down in the IBM manuals and follow the report options in a request/reply scenario. If a program that, say reformats messages, encrypts, decrypts, compresses or whatever and is mean't to be "transparent" to the message flow, destroyed this information, I wouldn't consider it well behaved.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
