Hi Scott Comments in line.
snip... > Realizing that we had needed to wait until operation selection took > place to run this logic, I was thinking about moving this to > TransportServiceInterceptor.invokeResponse(). I would assume it's > reasonable to assume that the app did not modify the original request > JMS msg in the meantime (e.g. in the case the app gets the message > "as-is"), but I'm not sure if these messages are explicity read-only > typically or not. > > Or would it be better to add another "callbackProcessingInterceptor" > or something like that after operation selection? This logic seems to be setting callback destination information into the forward message. So that the invoker code can handle callbacks properly. The URI from this callback reference will be copied back into the callback jms binding when the callback wire is cloned. If it's deferred to the transport service interceptor response processing I think that will be too late. So a new interceptor would seem to be the way to go. > > Some other notes on this ... I'm thinking of SCDL syntax like: > > <tuscany:operationSelector.jmsUser propertyName="MyOperationProperty"/> > > I don't think this has any bearing on the reference side, i.e. we > still set property 'scaOperationName' into the message we create, > never this new property. What does "MyOperationProperty" refer to? Are you really saying it would be... <tuscany:operationSelector.jmsUser propertyName="MyOperationProperty" operationName="MyChosenOperation"/> > > ---- > > As a separate but related issue, it appears from looking at the OASIS > spec that we interpreted the OSOA attr: > /binding.jms/operationProperties/@nativeOperation incorrectly. We > currently make use of this on a request from the reference side in > HeaderReferenceInterceptor. When looking at the OASIS spec, where > @nativeOperation has been replaced by @selectedOperation, it's clear > that this is supposed to be a service side thing, which provides > another layer of metadata-based override to whatever oS has been > configured by the runtime. (The only use on the reference side seems > to be wrt receiving callbacks). > > I'm thinking this should also be factored out so that every specific > oS implementation does not have to do this. Do you mean disable the reference side use of this for forward messages? Then we would need to instigate some service side processing to map selected operations to native operations? > > Thanks, > Scott >
