RE: [provision] Extended Request/Response Proposal..

["Cohen, Doron" <Doron_Cohen@bmc.com>]

I am attaching the following proposal from Rami as he had some trouble in
posting it to the group. 

Doron

 -----Original Message-----
From: Jeff Bohren [mailto:jbohren@opennetwork.com] 
Sent: Monday, December 30, 2002 5:19 PM
To: provision@lists.oasis-open.org
Subject: [provision] Extended Request/Response Proposal..


In order to move things along, I would like to make a proposal for the
extended request/response operations. I propose that an extended request
contain:
 
An identified operator 
An optional PSO ID
An optional list of attribute value(s) pairs
 
And that the response should contain:
 
An optional PSO ID
An optional list of attribute value(s) pairs
 
The Spml:Identifier could be reused to identify the operation type. I
believe that this will cover the desired functionality we discussed at the
F2F. 
 
Using this model, an example extended request representing an employee
promotion would look like:
 
<spml:extendedRequest>
            <spml:operationIdentifier identifierType =
"urn:oasis:names:tc:SPML:1.0:core#URN">
                        <spml:id>urn:com:acme:operations:promote</spml:id>
            </spml:operationIdentifier>
            <spml:identifier identifierType =
"urn:oasis:names:tc:SPML:1.0:core#EMailAddress">
                        <spml:id>jdoe@acme.com</spml:id>
            </spml:identifier>
            <attr name="title">
                        <value>Manager</value>
            </attr>
</spml:extendedRequest>
 
And the response would look like:
 
</spml:extendedResponse>
            <resultCode code="0" descr="success"/>
            <attr name="title">
                        <value>VP</value>
            </attr>
</spml:extendedResponse>
 
 
The schema for this would be as follows:
 
<xsd:complexType name="ExtendedRequest">
            <xsd:complexContent>
                        <xsd:extension base="spml:SpmlRequest">
                                    <xsd:sequence>
                                                <xsd:element
name="operationIdentifier" type="spml:Identifier" />
                                                <xsd:element
name="identifier" type="spml:Identifier" />
                                                <xsd:element name="attr"
type="dsml:DsmlAttr" minOccurs="0" maxOccurs="unbounded"/>
                                    </xsd:sequence>
                        </xsd:extension>
            </xsd:complexContent>
</xsd:complexType>  
 
<xsd:complexType name="ExtendedResponse">
            <xsd:complexContent>
                        <xsd:extension base="spml:SpmlResponse">
                                    <xsd:sequence>
                                                <xsd:element name="attr"
type="dsml:DsmlAttr" minOccurs="0" maxOccurs="unbounded"/>
                                    </xsd:sequence>
                        </xsd:extension>
            </xsd:complexContent>
</xsd:complexType>
 
Also to better support using the Spml:Identifier to identify operations, I
would like to add OID to our list of supported identifier types.
 
I would like to put this proposal to the list for consideration. I would
welcome others to present other proposals, but one way or the other we
should try to reach a consensus by or at the next telecon. 
 
Jeff Bohren
Product Architect
OpenNetwork Technologies, Inc

--- Begin Message ---

• From: "Elron, Rami" <rami_elron@bmc.com>
• To: provision@lists.oasis-open.org
• Date: Mon, 6 Jan 2003 07:01:55 -0600

I would like to propose the following framework for the SPML Extended
Request. Notwithstanding the fact that it was introduced lately, the
Extended Request's format should address important needs, including the
following:

	1.	Flexibility
	The format should be flexible enough to enable vendors to expose the
functionality their provisioning product supports - and not necessarily PSO
ID-related functions (e.g. reports).
	2.	Extensibility
	The format should allow vendors to support future implemented
functions as well as current feature sets.
	3.	Clarity
	The format should be easy to comprehend and use.
	4.	Interoperability
	Though devised to allow clients to access vendor-native provisioning
services that are not currently supported by the SPML spec, the Extended
Request's format should not necessarily manifest a proprietary schema. By
reflecting a standard framework, the format could alleviate the effort to
access services provided by various vendors.

The simplest effective framework could admittedly consist of just the
following:

	Request:
		1.	ID for the action
		2.	ID for target object
		3.	(Optional) List of attribute-value pairs

	Response:
		1.	(Optional) ID for target object
		2.	(Optional) List of attribute-value pairs

In order to fully address the aforementioned needs, however, I believe that
additional identifiers should be introduced into the framework:

	Request:
		1.	An identifier for the specific vendor-dialect used
in the Extended Request (ProvID). This identifier is a Godsend when
interoperability/migration scenarios are concerned, and may be used
alternatively (or additionally) for filtering/logging/pre&post-processing
purposes, etc.
		2.	An identifier for the object 'logical' type used as
target. This is required to support additional objects not necessarily
identified by PSO IDs (e.g. reports); default could be PSO-ID.
		3.	An optional identifier describing the format of
entry used for the object ID (e.g. (default:) single; comma-delimited list;
n-dimensional array, etc.).

	Response:
		1.	(Optional if no other parameters are sent) An
identifier for the specific vendor-dialect used in the Extended Request
(ProvID). 
		2.	(Optional if no other parameters are sent) An
identifier for the object 'logical' type used as target.
		3.	(Optional - mostly relevant if there are
attribute-value pairs) Response Metacode. Used to specify a selected way to
read the attribute-value pairs; could be used for general responses as well.

The suggested framework thus comprises the following:

	Request:
		1.	provID: An identifier for the specific
vendor-dialect used in the Extended Request. 
		2.	objectTypeID An identifier for the object 'logical'
type used as target 
		3.	(optional) objectFormatID: An identifier describing
the format of entry used for the object.
		4.	actionID: ID for the action
		5.	(Optional) objectID: ID for target object
		6.	(Optional) list of attribute-value pairs

	Response:
	1.	(Optional if no other parameters are sent) provID 
	2.	(Optional if no other parameters are sent) objectTypeID 
	3.	(Optional) objectID
	4.	(Optional) respCode - Response Metacode.
	5.	(Optional) list of attribute-value pairs


Best regards,

		Rami.

----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------------------
Rami Elron
Senior System Architect
Security Business Unit
BMC Software Ltd.

--- End Message ---