NotificationResponse for every Notify request?

[Jonas Buys-2]

Hi,

I have implemented a service that consumes notifications (i.e. NotificationConsumer capability).

But for each <Notify> message I see a <NotifyResponse>:

<soapenv:Envelope
    xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
        <wsa:ReplyTo>
            <wsa:Address>http://www.w3.org/2005/08/addressing/none</wsa:Address>
        </wsa:ReplyTo>
        <wsa:MessageID>urn:uuid:9CAC3C71040F9D76F4123824223414018</wsa:MessageID>
        <wsa:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/NotifyRequest</wsa:Action>
        <wsa:RelatesTo wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply">uuid:138ee423-37af-c545-66bd-6f7cdaaece6a</wsa:RelatesTo>
    </soapenv:Header>
    <soapenv:Body>
        <wsnt:NotifyResponse
            xmlns:tns="http://axis2.platform.core.muse.apache.org" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"/>
    </soapenv:Body>
</soapenv:Envelope>

In WsnConstants.java I found:
// HACK: This is not defined by the standard, but we need something to
//       send back to blocking clients
//
public static final QName NOTIFY_RESPONSE_QNAME =
        new QName(NAMESPACE_URI, "NotifyResponse", PREFIX);

1. Can I disable the submission of these replies in any way?

2. Something else, didn't spot this in WS-BN spec: is there any way to enable assured delivery for notifications?  We are planning to use then for fault-tolerant experiments in our lab.  Suppose WS-RM could come in here?  Any suggestions?

3. I have a service that in its initializeCompleted() starts a thread to send notifications every 10 seconds, but after a while - when the client program (main) stops - messages stop flowing too.  How can I make sure the service will persist in sending messages in time?  Log doesn't give any more info.  Subscription was made with null as time-out, so I should go on forever?


Cheers, Jonas.



     

[Chris Twiner]

On Sat, Mar 28, 2009 at 1:44 PM, Jonas Buys <jonas_buys@...> wrote:

>
> Hi,
>
> I have implemented a service that consumes notifications (i.e. NotificationConsumer capability).
>
> But for each <Notify> message I see a <NotifyResponse>:
>
> <soapenv:Envelope
>    xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing">
>    <soapenv:Header>
>        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
>        <wsa:ReplyTo>
>            <wsa:Address>http://www.w3.org/2005/08/addressing/none</wsa:Address>
>        </wsa:ReplyTo>
>        <wsa:MessageID>urn:uuid:9CAC3C71040F9D76F4123824223414018</wsa:MessageID>
>        <wsa:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/NotifyRequest</wsa:Action>
>        <wsa:RelatesTo wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply">uuid:138ee423-37af-c545-66bd-6f7cdaaece6a</wsa:RelatesTo>
>    </soapenv:Header>
>    <soapenv:Body>
>        <wsnt:NotifyResponse
>            xmlns:tns="http://axis2.platform.core.muse.apache.org" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"/>
>    </soapenv:Body>
> </soapenv:Envelope>
>
> In WsnConstants.java I found:
> // HACK: This is not defined by the standard, but we need something to
> //       send back to blocking clients
> //
> public static final QName NOTIFY_RESPONSE_QNAME =
>        new QName(NAMESPACE_URI, "NotifyResponse", PREFIX);
>
> 1. Can I disable the submission of these replies in any way?

Not that I'm aware of.  What I would like to add is the ability to
return a 204 NO_RESPONSE for http based environments (i.e. all default
Muse isolation layers, not sure how it works with access though). This
would have to wait until 2.3.0 as it breaks compatibility (i.e. we
need to signal that no response is actually intended).

> 2. Something else, didn't spot this in WS-BN spec: is there any way to enable assured delivery for notifications?  We are planning to use then for fault-tolerant experiments in our lab.  Suppose WS-RM could come in here?  Any suggestions?

RM isn't supported by Muse :-<. To be honest if you are after fault
tolerance you will have to add your own protocol on top, RM or
otherwise, including heartbeats etc, the best solutions tend to vary
with each actual use case..

> 3. I have a service that in its initializeCompleted() starts a thread to send notifications every 10 seconds, but after a while - when the client program (main) stops - messages stop flowing too.  How can I make sure the service will persist in sending messages in time?  Log doesn't give any more info.  Subscription was made with null as time-out, so I should go on forever?

Only if you don't destroy both the actual underlying resource and the
subscription manually.  Also note that you may be falling victim to
Muse 270, which is only in head and the 270 tag, but proving that one
way or the other is tough to do. To test it add extra logging to the
sending thread to see if it at least thinks it should be sending
still.

[Lenni Madsen]

notes inline below

We're the fukarwi

On 28/03/2009, at 17.47, Chris Twiner <chris.twiner@...> wrote:

> On Sat, Mar 28, 2009 at 1:44 PM, Jonas Buys <jonas_buys@...>  
> wrote:
>>
>> Hi,
>>
>> I have implemented a service that consumes notifications (i.e.  
>> NotificationConsumer capability).
>>
>> But for each <Notify> message I see a <NotifyResponse>:
>>
>> <soapenv:Envelope
>>    xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"  
>> xmlns:wsa="http://www.w3.org/2005/08/addressing">
>>    <soapenv:Header>
>>        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</
>> wsa:To>
>>        <wsa:ReplyTo>
>>            <wsa:Address>http://www.w3.org/2005/08/addressing/none</
>> wsa:Address>
>>        </wsa:ReplyTo>
>>        <wsa:MessageID>urn:uuid:9CAC3C71040F9D76F4123824223414018</
>> wsa:MessageID>
>>        <wsa:Action>http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/NotifyRequest 
>> </wsa:Action>
>>        <wsa:RelatesTo wsa:RelationshipType="http://www.w3.org/2005/08/addressing/reply 
>> ">uuid:138ee423-37af-c545-66bd-6f7cdaaece6a</wsa:RelatesTo>
>>    </soapenv:Header>
>>    <soapenv:Body>
>>        <wsnt:NotifyResponse
>>            xmlns:tns="http://axis2.platform.core.muse.apache.org"  
>> xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2"/>
>>    </soapenv:Body>
>> </soapenv:Envelope>
>>
>> In WsnConstants.java I found:
>> // HACK: This is not defined by the standard, but we need something  
>> to
>> //       send back to blocking clients
>> //
>> public static final QName NOTIFY_RESPONSE_QNAME =
>>        new QName(NAMESPACE_URI, "NotifyResponse", PREFIX);
>>
>> 1. Can I disable the submission of these replies in any way?
>
> Not that I'm aware of.  What I would like to add is the ability to
> return a 204 NO_RESPONSE for http based environments (i.e. all default
> Muse isolation layers, not sure how it works with access though). This
> would have to wait until 2.3.0 as it breaks compatibility (i.e. we
> need to signal that no response is actually intended).
>
>> 2. Something else, didn't spot this in WS-BN spec: is there any way  
>> to enable assured delivery for notifications?  We are planning to  
>> use then for fault-tolerant experiments in our lab.  Suppose WS-RM  
>> could come in here?  Any suggestions?
>
> RM isn't supported by Muse :-<. To be honest if you are after fault
> tolerance you will have to add your own protocol on top, RM or
> otherwise, including heartbeats etc, the best solutions tend to vary
> with each actual use case..
>
>> 3. I have a service that in its initializeCompleted() starts a  
>> thread to send notifications every 10 seconds, but after a while -  
>> when the client program (main) stops - messages stop flowing too.  
>> How can I make sure the service will persist in sending messages in  
>> time?  Log doesn't give any more info.  Subscription was made with  
>> null as time-out, so I should go on forever?
>

Please note: to utilize notification in a real world scenario, where  
you don't need a "heart beat", this not the way to implement  
notification. The example is just a proof of concept for notification,  
I don't have to code I supplied last time this subject came up, on the  
handheld but it should be in the Mail Archive.

> Only if you don't destroy both the actual underlying resource and the
> subscription manually.  Also note that you may be falling victim to
> Muse 270, which is only in head and the 270 tag, but proving that one
> way or the other is tough to do. To test it add extra logging to the
> sending thread to see if it at least thinks it should be sending
> still.
>