[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] missing use cases?
Actually I was suggesting the exact opposite. Using an extended request for an asynchronous notification is not required, will inhibit interoperability, and will be much harder to implement. It's all pain, no gain. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Darran Rolls [mailto:Darran.Rolls@waveset.com] Sent: Tuesday, February 18, 2003 1:31 PM To: provision@lists.oasis-open.org Subject: RE: [provision] missing use cases? In conclusion then, for 1.0 the model for asynchronous notifications from PST to PSP, the committee is going to recommend using custom ExtendedRequest flows? -------------------------------------------------------- Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com (512) 657 8360 -------------------------------------------------------- > -----Original Message----- > From: Jeff Bohren [mailto:jbohren@opennetwork.com] > Sent: Monday, February 17, 2003 12:40 PM > To: provision@lists.oasis-open.org > Subject: RE: [provision] missing use cases? > > > I don't think we need to formalize this, but there are several simple > ways to make this work. All the PSP needs to do is either expose a > different web service URL for PSTs to post updates to, or have one URL > and differentiate between RAs making requests and PSTs posting updates > based on the principle of the web service client. > > Unless you want to support anonymous provisioning request, there should > be no problem differentiating provisioning requests from an RA from > notifications from a PST. > > Jeff Bohren > Product Architect > OpenNetwork Technologies, Inc > > > -----Original Message----- > From: Cohen, Doron [mailto:Doron_Cohen@bmc.com] > Sent: Monday, February 17, 2003 1:05 PM > To: provision@lists.oasis-open.org > Subject: RE: [provision] missing use cases? > > Keep in mind though that a PST that sends a modification as client to > the > PSP will need to be able to indicate (for the PSP sake) that this is a > notification and not and update to the real object at the PST > (otherwise > the PSP may try to provision this update as if it was an RA requesting > it) . > In any case, I would say that this can also be an extended request of > some > kind unless we formalize something more structured in the specs. > > Doron > > Doron Cohen > BMC Software > > -----Original Message----- > From: Jeff Bohren [mailto:jbohren@opennetwork.com] > Sent: Monday, February 17, 2003 7:43 PM > To: provision@lists.oasis-open.org > Subject: RE: [provision] missing use cases? > > > > Looking at the case where there is a local change on a PST that needs to > get > updated in a PSP, there are two solutions, both supportable by our draft > SPML spec: > > 1) The PSP discovers the change using an SPML search (reconciliation). > 2) The PST acts as client to the PSP (which acts as a server) to send > the > change as a modification request (serves as an asynchronous > notification). > > I do not believe that we need to add explicit asynchronous notification > operations at this point. > > Jeff Bohren > Product Architect > OpenNetwork Technologies, Inc > > > -----Original Message----- > From: mpolan@ca.ibm.com [mailto:mpolan@ca.ibm.com] > Sent: Monday, February 17, 2003 10:55 AM > To: provision@lists.oasis-open.org > Subject: [provision] missing use cases? > > We don't have use cases (nor operations obviously) that address > asynchronous > messages from the servers to the clients. For example, a notification > from > a PST or PSP to indicate that a service has been suspended or deleted > for > some reason other than an add/delete/modify request. > > Is this intentional or an oversight on our part? If intentional, how > would > we address this scenario? Discovery by the client? > > Mike Polan > IBM Canada Ltd > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC