Subject: RE: A proposal for an ebXML Publish Subscribe Service
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.
eList eXpress LLC