Re: [wsn] Chained Notifications

[David Snelling <David.Snelling@UK.Fujitsu.com>]

Don,

My first cut on this would be that if this level of QoS is provided by 
the Broker, the the Broker retains that information if it is needed.

On 19 Sep 2005, at 17:04, <marchadr@wellsfargo.com> wrote:

>
> I was going through the specifications again I was thinking if we are 
> starting to broker and provide pulling mechanisms it would be nice to 
> have some sort of chaining on the way notifications can be associated 
> with each other.
>
> In some ways this can be achieved with the producer and consumer 
> elements within a notification, but when another notification is 
> created as a result of a notification it would be good to track that.
>
> Here is a scenario:
>
> 1. Service X processes an operation request and decides an event needs 
> to be triggered.
> 2. Service X creates a notification X.1 to be send to its notification 
> producer Y
> 3. Notification Producer Y sends it to the Broker B that is subscribed 
> to the particular event
> 4. Broker B creates a new notification B.2 that is based on 
> information from X.1 to send to its subscribers
>
> B.2 notification should have a source/parent element referring to a 
> X.1 notification for trackback purposes.
> Would be required for regulated systems that need some sort of audit 
> event.
>
> Any thoughts?
>
> Thanks,
>
> Dan
>
>
-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)