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
(512) 657 8360
--------------------------------------------------------
> -----Original Message-----
> From: Jeff Bohren [mailto:]
> Sent: Monday, February 17, 2003 12:40 PM
> To:
> 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:]
> Sent: Monday, February 17, 2003 1:05 PM
> To:
> 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:]
> Sent: Monday, February 17, 2003 7:43 PM
> To:
> 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: [mailto:]
> Sent: Monday, February 17, 2003 10:55 AM
> To:
> 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>
