Re: A proposal for an ebXML Publish Subscribe Service

[duane <duane@xmlglobal.com>]

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.