I was looking at adding an operationSelector to use any user-specified "user property" (not just 'scaOperationName') to hold the operation name.
It seems the one oS we currently have, OperationSelectorJMSDefaultServiceInterceptor, has some callback destination stuff in it which should ideally be factored out so each new oS doesn't have to recreate. 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? 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. ---- 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. Thanks, Scott
