Re: [sca-bindings] BINDINGS-93 - alternate proposal....

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Thinking about this some more, the reason it was originally
worded the way it was is that unless the target application uses a specific
response destination, using a unique destination for each response will
always work, regardless of whatever correlation scheme is specified in
the binding. 

So if a fixed response destination is specified, the
runtime has to use that, and has to use the correlation scheme specified
in the binding.  It can't choose to do some arbitrary thing to correlate
because it doesn't know the behaviour of the JMS application at the other
end of the request destination, and we have to assume the person who chose
the correlation scheme does.  It also can't choose to use unique destinations,
because the target application may be coded to send responses to the fixed
destination defined in the binding.

If no fixed response destination is specified, this
implies the target application sends responses to the JMSReplyTo destination,
and so the runtime can choose what it does with destinations.  Depending
on that choice, the runtime may or may not need to pay attention to the
correlation scheme.  It could use one destination per response, and
potentially reuse destinations; it could share a small number of destinations
across responses and use the correlation scheme for messages on each of
those destinations, or it could use a single destination and always use
the correlation scheme.

So while I'd be OK with formalizing the use of a destination
per response - which would be the case where the target application does
nothing to the response message to make it correlate - the use of unique
destinations is also a choice an SCA runtime could make with other correlation
scheme settings, which the original statement was supposed to allow through
the use of MAY.

The two separate conformance statements I proposed
match the above two cases:

For an SCA reference with a JMS binding that has a
destination specified via the response element, the SCA runtime MUST receive
response messages as defined by the binding's @correlationScheme attribute.
[BJM6000X] 

For an SCA reference with a JMS binding that does
not have a destination specified via the response element, the SCA runtime
MUST either receive response messages as defined by the binding's @correlationScheme
attribute, or use a unique destination for each request/response interaction
[BJM60006] 

The combined statement doesn't quite capture the fact
that in the no-response case the runtime can choose which to do - but in
any case I don't think we should leave the door open for the runtime to
make some other choice, it has to be one of the cases above.

I'll admit there's also some ambiguity in "use
a unique destination for each request/response interaction" - really
what's meant there is use a different destination for each pending response
- those destinations could be reused once the response is processed.

Regards, Simon

Simon Holdsworth/UK/IBM@IBMGB wrote on 30/09/2009
10:40:16:

> Re: [sca-bindings] BINDINGS-93 - alternate proposal....
> 
> I'm OK with this alternative proposal, as it does formalise the 
> "unique response destination per request" behaviour. 
> 
> Regards, Simon 
> 
> Simon Holdsworth
> STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings
TC Chair
> MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
> Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
> Internet - Simon_Holdsworth@uk.ibm.com 
> 
> From:  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.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU