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.
>