Thanks again, Christopher, for a great explanation.
Everything is becoming more and more clear now.
Steve
--- Christopher Frank <[EMAIL PROTECTED]> wrote:
> Steve,
>
> Here are some answers regarding your quest for a
> pub/sub "checklist":
>
> >>>1- Create Publication queue on the broker.
>
> There are actually several queues you may need to
> create.
>
> At a minimum, you are recommended to define
> SYSTEM.BROKER.DEFAULT.STREAM
> (the default publication queue) and
> SYSTEM.BROKER.CONTROL.QUEUE. You also
> need a SYSTEM.BROKER.INTER.BROKER.COMMUNICATIONS
> queue if the WMQI broker
> is to communicate with neighboring MQ base pub/sub
> brokers.
>
> >>>2- RESYSTEM.BROKERINTERBROKER.COMMUNICATIONS
>
> Not sure what you mean by this step.
>
> >>>3-Create a Publish msg flow: It should end with a
> >>>publication node. Someting like:
> >>>InputNode1 (which is the pub queue)--->
> ComputeNode1--a-->
> PublicationNode
> >>>
> --b-->2 OutputNode
>
> You need a message flow to service each publication
> queue. For example, if
> you created the SYSTEM.BROKER.DEFAULT.STREAM (the
> default publication
> queue) you would need to create a message flow to
> service that queue. This
> flow would look something like:
>
> InputNode1--->PublicationNode
>
> SYSTEM.BROKER.DEFAULT.STREAM (or whatever queue you
> are using for your
> publication queue) would be specified on the MQInput
> node. Note that you
> can have many publication queues, as long as each is
> serviced by a message
> flow.
>
> >>>4- Create a topic for the flow
> >>>
> >>>Question: Are "creating a topic for a flow" and
> >>>"ending the flow with a publication node"
> sufficent
> >>>for the publisher to be registered with the
> broker? Is
> >>>there anything else to be done to register the
> topic
> >>>at the broker?
>
> Yes. For the simple flow shown above
> ("InputNode1--->PublicationNode") this
> would be sufficient, as long as the publication
> message was prefixed with
> an RFH or RFH2 header indicating the topic name.
>
> If the inbound message ir not prefixed with an RFH
> or RFH2 header, your
> message flow would require some additional "smarts".
> At a minimum, you must
> specify a topic name property on the Input node. Or,
> in a Compute node, you
> can specify a topic name like so:
>
> SET OutputRoot.Properties.Topic = 'myTopic';
>
> This is a simple, really nice way to make a
> non-pub/sub MQ program a
> publisher. However, there are a frew caveats when
> using this approach
> rather than the RFH/RFH2:
>
> 1) The message is handled as a "local" publication.
> This means that the
> publication will not be forwarded to neighboring
> brokers, even if they have
> subscribers registered on matching topics.
> 2) Response messages will not be sent to publishing
> applications that
> produce messages in this way, even if the MQMD is
> set to imply that
> responses should be sent.
> 3) Existing base MQ pub/sub applications that use
> RFH format subscriptions
> will not receive these messages.
>
> Because of these limitations it is preferable to
> build an RFH2 header in
> your message flow.
>
>
> >>>5- If MQRFH2 Header is not present in the
> incoming msg
> >>>Construct it in the Compute node. If this is a
> >>>request-reply msg, I am thinkin go copying the
> >>>MQMD.ReplytoQ/Qmgr into NameValueData like this:
>
>>><ReplyQ>MY.REPLYQ</ReplyQ><ReplyQmgr>MYQMGR</ReplyQmgr>
> >>>making sure the length is multiple of 4 (may need
> >>>trailing spaces) as specified in the
> NameValueLength.
> >>>Is this correct?
>
> If by request-reply you mean you want a Broker
> response message to be sent
> by the broker to the publisher to indicate the
> success or failure of a
> command message, the broker will use the
> ReplytoQ/Qmgr fields of the MQMD
> directly, so you don't need to do anything.
>
>
> >>>Question: I know it is recommended that we use
> MQRFH2
> >>>header in new apps. But do I really need it? If I
> am
> >>>only interested in ReplyToQ/Qmgr fields I can put
> them
> >>>in a app header before the app. data, right? I
> should
> >>>add that we would be receiving and sending
> messages
> >>>in XML...
>
> Correct, an RFH/RFH2 is not required, but may be
> desirable in some
> situations. The WMQI Programming Guide explains what
> these situations are.
>
>
> >>>6- Persistency (not retantion): Under the
> heading
> >>>of Message Persistency in the Introduction an
> Planning
> >>>book (on the bottom of page 93) it talks about
> >>>options for persistency? What I don't understand
> is,
> >>>shouldn't the persistency of the publication
> (which
> >>>the message actually) be the persistency of the
> >>>message as specified in MQMD? How can I make the
> >>>publisher's persistency dependent on the message
> >>>persistency.
>
> I can't find any heading called "Message
> Persistency" in the WMQI V2.1
> Introduction and Planning Guide. Is this the version
> you are using?
>
> There is a subheading called "Message persistence"
> in Chapter 7 ("Designing
> publish/subscribe applications"). Is this the
> reference you're referring
> to? This is in the section "Subscriptions", and is
> referring to subscribers
> sending their subscription registration messages as
> persistent. I think
> your question, though, is in reference to the
> persistency of a publication,
> correct?
>
> There is also a subheading called "Message
> persistence" in Chapter 6
> ("Application Design") on page 76 (in my version of
> the Introduction and
> Planning Guide). This section discusses
> transactional considerations. With
> pub/sub applications, message persistence can apply
> to the publishers
> messages as well as the message(s) delivered to
> subscribers. In the case of
> the publisher, if the publication message is
> specified as persistent in the
> MQMD, and this property is carried through your
> message flow to the
> Publication node, the broker will treat the
> publication message as
> persistent. However, whether or not the publication
> is delivered to the
> subscriber(s) queue(s) as a persistent message
> depends on whether the
> subscriber has requested persistent message
> delivery, and (if topic
> security is being used) whether the subscriber is
> authorized to request
> persistent delivery. If these conditions are met,
> the broker will put
> publication messages to the subscriber queue(s)
> persistently.
>
> Regards,
>
>
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
