BINDINGS-93 - alternate proposal....

[Eric Johnson <eric@tibco.com>]

It occurred to me while looking at the proposal for BINDINGS-93, that it might be even clearer to add another predefined @correlationScheme value, specifically that of "sca:uniqueDestination", since that is effectively what we're requiring.

I think this means a revised proposed resolution as follows:

(Section 3, @correlationScheme definition), add the following after "sca:none" sentence:

"If the value of @correlationScheme is "sca:uniqueDestination" the SCA runtime MUST use a unique response destination for each request, and there MUST NOT be a response element specified."

This:
"For an SCA reference with a JMS binding, the SCA runtime MAY choose to receive response messages on the basis of their correlation ID as defined by the binding’s @correlationScheme attribute, or use a unique destination for each response [BJM60006]."

becomes:
"For an SCA reference with a JMS binding, the SCA runtime MUST correlate response messages on the basis of binding’s @correlationScheme attribute [BJM60006]."

(If I've not missed a point here, it would now be possible to not set a "response" element, and use a correlation other than "sca:uniqueDestination".  That should be fine though.  A caller can use a temporary queue multiple times to do some number of request/response exchanges, and use a correlation mechanism other than a unique destination.  BINDINGS-93 seems to imply that this is not a reasonable combination, but I'm unclear on why that would be so.)

---

Oops - typos:
Line 648: <binding.jms correlationScheme=”sca:messageId”>

Should be: <binding.jms correlationScheme=”sca:messageID”>

Likewise line 656 and 799.

I'll file an issue for these.

-Eric.