RE: A proposal for an ebXML Publish Subscribe Service

[Lisa Carnahan <lisa.carnahan@nist.gov>]

Are you considering making this service mandatory?  I wasn't in all of the 
meetings all of the time, but I don't recall us discussing this as 
something that would be mandatory to support.

--lisa

At 05:46 PM 10/31/00 -0600, Nieman, Scott wrote:
>Yes, but it was in the original architecture, and I think its critical for
>the concept of distributed reg-reps.  I do believe, having slept on it a
>bit, we need another class or two in the information model for subscribing
>to a registered object.
>
>This should not be that difficult.  Here are some potential functional
>requirements:
>1) the ability to specify what "level" of granularity the subscription
>should be.  specifically,  provide the ability to subscribe to one item at a
>time, or a collection of items based on a classification scheme node
>(according to current state of the specification)
>2) The ability to define the event level when I am notified; e.g., the
>registered object is versioned, someone looked at it or downloaded it, etc.
>3) WHO can subscribe is important.  By default the SO, but "Guests" can too,
>specifically if the WHO is another registry.
>4) WHAT is published should only be the metadata, not the object itself.
>
>On a technical note, and to stir debate, perhaps publishing is initiated via
>event trapping instead of (a)synchronous calls by the registry.  that may be
>an implementation issue, but it does affect the proposed client interface.
>I think this could also be modeling by listening to a logging service
>instead of the registry "knowing" that it needs to call the interface.
>Logging is also in the original requirements.
>
>Regards,
>
>Scott
>
>-----Original Message-----
>From: David RR Webber
>To: Nieman, Scott
>Cc: 'Philippe DeSmedt '; ''Krishna Sankar' '; 'Farrukh Najmi '; 'ebxml
>repository '
>Sent: 10/31/00 10:35 AM
>Subject: RE: A proposal for an ebXML Publish Subscribe Service
>
>Message text written by "Nieman, Scott"
> >
>David, this is not rocket science as it is primarily a listening service
>that interacts with the messaging service.  two classes and two
>operations.
>the publish operation of course calls the messaging service.  It should
>be
>considering a shoe-in.
>Scott
><<<<<<<<<<<<<<<<<<<<<<
>
>Scott,
>
>I hear you - and I was seeing the meld too - but you know how those
>gotchas
>come running out just when you thought it was easy.  I'll reserve
>judgement
>
>at this point!   We have to look carefully at the actual business
>functional
>linkages we want to enable - otherwise this could be a runaway train...
>
>Thanks, DW.