RE: A proposal for an ebXML Publish Subscribe Service

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

OK.  Orlando is when we discussed this...when I think we were all snowballed
by the SIZE of this project.  I guess I may have overwhelmed everyone since
I have been thinking about this beast for 4-5 years now.  
BUT...I believe that the work plan is where prioritize this.

Scott 

-----Original Message-----
From: Yutaka Yoshida
To: ebxml-regrep@lists.ebxml.org
Sent: 11/1/00 11:49 AM
Subject: RE: A proposal for an ebXML Publish Subscribe Service

I don't recall that discussion either. I think we should
concentrate the simple set of functionalities good enough
for the acutual use, and if 'fancy' functionality is in the
original document, maybe it's a good time to redefine a
phase delivery matrix.

yutaka yoshida

 > Date: Wed, 01 Nov 2000 08:15:19 -0500
 > From: Lisa Carnahan <lisa.carnahan@nist.gov 
 > 
 > Are you considering making this service mandatory?  I wasn't in all
of the 
 > meetings all of the time, but I don't recall us discussing this as 
 > something that would be mandatory to support.
 > 
 > --lisa
 > 
 > At 05:46 PM 10/31/00 -0600, Nieman, Scott wrote:
 > >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.
 >