snip.. > >> What does "MyOperationProperty" refer to? Are you really saying it would >> be... >> >> <tuscany:operationSelector.jmsUser propertyName="MyOperationProperty" >> operationName="MyChosenOperation"/> > > I'm saying that my operation selector will expect to find the > operation name as the value of the user property identified by > @propertyName, (a lot like the JMS default oS will key off of JMS user > property 'scaOperationName').
OK, got you. > > >>> 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? > > Yes and yes.. that's how I read the OASIS spec, and I'm further > assuming that this happens on top (after) any potential specific JMS > oS, default or otherwise. Yes, I think it would have to come after operation selection. So maybe on both these counts we need to instigate a service side header processor. We only have reference side support at the moment. > > Scott >
