You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2009/03/25 15:05:29 UTC
question on writing a new JMS opSelector
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
Re: question on writing a new JMS opSelector
Posted by Simon Laws <si...@googlemail.com>.
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
>
Re: question on writing a new JMS opSelector
Posted by Scott Kurz <sc...@gmail.com>.
Simon,
Thanks for responding.. replies below...
On Wed, Mar 25, 2009 at 11:09 AM, Simon Laws <si...@googlemail.com> wrote:
> 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.
OK, thanks.
> 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').
>> 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.
Scott
Re: question on writing a new JMS opSelector
Posted by Simon Laws <si...@googlemail.com>.
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
>