To Tim's question... Context and scenario.
Project is to utilize QPID to replace a rather interesting yet heavy handed CORBA approach to messaging. A prime example of using a sledgehammer to drive a thumb tack but at the time of original development a good approach (not the best but good). The client, who had a lot of time on their hands, developed their own types and one in particular which they use for formatting messages. The current approach is to 'wrap' the existing message format into the QPID message content which is, at this point, is working well. One of the current 'activities' is to add additional properties to the QPID message to 'promote' specific message content fields from the 'interior' / 'embedded' message to the 'wrapper'. Take the case where we 'emulate' synchronous message processing. At a conceptual level this is simply a requester 'sending' out a request and then 'waiting' for a response. At the same conceptual level a responder 'receives' the requests and 'responds'. At an implementation level there are three distinct message types being processed; 'informational', asynchronous requests and synchronous requests. At this point in time the two request message types share a very basic characteristics and that is that an address is present in a specific message property field that the responder is 'implicitly' asked to send a response too. Case can be made that the only difference between asynchronous and synchronous message processing is in the 'behavior' of the requester; in the synchronous instance the requester 'waits' for a response while in the asynchronous instance the requester continues processing and handles responses at a later time. This puts the distinction and focus on the requester 'relieving' the responder from any additional processing. All seems well at this point. In this case, though, there are existing ABC (audit, balance and control) requirements to 'account' for message received in each of the three 'categories'. One of the audit areas is to insure that each request is matched to it response to be able to measure processing 'responsiveness' to their service level agreements (SLA's). The task at hand is to identify and demonstrate the use of message 'processing type' indicators as part of the 'exterior' QPID message 'wrapper'. It is not as trivial as it may sound /seem. There are touch points that clients reach for to provide them with that 'warm and fuzzy' feeling and this one of them. They are 'letting go' of CORBA and look for assurance at each and every opportunity to assure themselves that the processing approach will still support their existing operational needs. Paul ________________________________________ From: Timothy Bish [[email protected]] Sent: Thursday, April 07, 2016 4:22 PM To: [email protected] Subject: Re: Anyone have an example of using message setProperty()? On 04/07/2016 04:55 PM, Flores, Paul A. wrote: > At client site. > > Need a clear example of the usage of setProperty() Can you provide a bit more context on what code you are referring to and what you want to accomplish? > Thanks for your help it is appreciated! > > Paul > > ________________________________ > > This communication (including any attachments) may contain information that > is proprietary, confidential or exempt from disclosure. If you are not the > intended recipient, please note that further dissemination, distribution, use > or copying of this communication is strictly prohibited. Anyone who received > this message in error should notify the sender immediately by telephone or by > return email and delete it from his or her computer. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Tim Bish twitter: @tabish121 blog: http://timbish.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] ________________________________ This communication (including any attachments) may contain information that is proprietary, confidential or exempt from disclosure. If you are not the intended recipient, please note that further dissemination, distribution, use or copying of this communication is strictly prohibited. Anyone who received this message in error should notify the sender immediately by telephone or by return email and delete it from his or her computer. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
