[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [provision] missing use cases?
I would say that although this approach is possible but since it may not be applicable to all binding types, I recommend to allow for both extended request or the PST acting as RA to be valid and leave it for the implementation. If down the road we would like to include a specific definition for 2.0 , we can do it by creating the appropriate use cases and protocol definitions. Doron -----Original Message----- From: Darran Rolls [mailto:Darran.Rolls@waveset.com] Sent: Tuesday, February 18, 2003 10:15 PM To: Jeff Bohren; provision@lists.oasis-open.org Subject: RE: [provision] missing use cases? So in conclusion (and for the 1.0 record) The current specification does allow for an asynchronous notification "upstream" between a PST and a PSP. This protocol flow is not called out in the 1.0 use cases nor is it reflected in new or specific operations. The recommended implementation for this model would be for the PST to function as an RA and make an independent Add/Modify/Delete request back to the PSP, requesting change (aka notification) to a "service" schema that is in effect "change notification". -------------------------------------------------------- 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: Tuesday, February 18, 2003 12:36 PM > To: provision@lists.oasis-open.org > 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> > > ---------------------------------------------------------------- > 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