Subject: Re: A proposal for an ebXML Publish Subscribe Service
Krishna: We talked about a security issue for the entire ebXML architecture in San Jose. The Executive team will likely announce the formation of a new Security Team to address ebXML-wide issues. Duane Nickull Krishna Sankar wrote: > > Hi, > > This looks like a basic subscription service over the registry with a store > and forward and/or event notification. This is Ok but will raise security > issues. As I had mentioned earlier, we also need a security model around the > registry. DOes the info model include security and other access primitives ? > > cheers > > -----Original Message----- > From: Nieman, Scott [mailto:Scott.Nieman@NorstanConsulting.com] > Sent: Tuesday, October 31, 2000 3:46 PM > To: 'David RR Webber ' > Cc: ''Philippe DeSmedt ' '; '''Krishna Sankar' ' '; ''Farrukh Najmi ' '; > ''ebxml repository ' ' > 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