ebxml-regrep message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: A proposal for an ebXML Publish Subscribe Service


	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 ?


-----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
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.



-----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
the publish operation of course calls the messaging service.  It should
considering a shoe-in.


I hear you - and I was seeing the meld too - but you know how those
come running out just when you thought it was easy.  I'll reserve

at this point!   We have to look carefully at the actual business
linkages we want to enable - otherwise this could be a runaway train...

Thanks, DW.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC