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


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.


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

Powered by eList eXpress LLC