[provision] Proposal for issues 1.1.1 and 1.1.3...

[Jeff Bohren <jbohren@opennetwork.com>]

Two of the current open issues are 1.1.1 and 1.1.3, which are:

 

1.1.1.    Batch Requests (Open)

Champion: Conrad Agramont, Microsoft

Description: SPML should not use batch requests. Only single operations should be supported. This affects both the SPML SOAP/HTTP and File Bindings.

 

1.1.3.    Need Supported Operations Mechanism (Open)

Champion: Jeff Bohren, OpenNetwork Technologies

Description: There is no mechanism in the current specification that allows for a SPML client to query a service for what operations it supports. This only affects the SPML SOAP/HTTP Binding.

 

I have a proposal that addresses both of these issues. My proposal is:

1) add top-level request elements for all of the SPML operations defined in the core schema to the request schema

2) change batchStatusRequest and batchCancelRequest to statusRequest and cancelRequest, respectively

3) remove the schemeRequest and searchRequest element from the batch request

 

That would make the total list of requests:

 

batchRequest

addRequest

modifyRequest

deleteRequest

searchRequest

schemaRequest

statusRequest

cancelRequest

 

By making this change, we can partly satisfy issue 1.1.1, since batch requests are not optional and not required for conformance. It will also satisfy issue 1.1.3 because the supported requests would now be defined in the WSDL for each web service. Additionally removing search and schema requests from the batch requests makes more sense because they are really not appropriate for batch type operations.

 

To make this change, all that need to be done is to add request element types in the request schema that add the synchronous/asynchronous attribute. For instance to define this for add requests, the following would be added to the request schema:

 

            <xsd:complexType name="AddRequest">

                        <xsd:complexContent>

                                    <xsd:extension base="spml:AddRequest">

                                                <xsd:attribute name="execution" type="ExecutionType" use="optional" default="urn:oasis:names:tc:SPML:1.0:req#synchronous" />

                                    </xsd:extension>

                        </xsd:complexContent>

            </xsd:complexType> 

 

            <xsd:element name="addRequest" type="AddRequest" />

 

            <xsd:element name="addResponse" type="spml:AddResponse" />

 

Then the WSDL for a web service that supported this type of add request would be modified as:

 

                        <wsdl:operation name="SPMLAddRequest">

                                    <wsdl:input name="SPMLAddInput" message="tns:SPMLAddRequestMessage"/>

                                    <wsdl:output name="SPMLAddOutput" message="tns:SPMLAddResponseMessage"/>

                        </wsdl:operation>

 

and

 

                        <wsdl:operation name="SPMLAddRequest">

                                    <soap:operation style="document"

                                                soapAction="urn:oasis:names:tc:SPML:1:0:req/AddRequest" />

                                    <wsdl:input name="SPMLAddInput" >

                                                <soap:body use="literal" />

                                    </wsdl:input>

                                    <wsdl:output name="SPMLAddOutput" >

                                                <soap:body use="literal" />

                                    </wsdl:output>

                        </wsdl:operation>

 

The only other change I would make is around conformance. I would specify that if a SPML web service supports batch, it should support add, modify, and delete operations within the batch. By making this change we would completely satisfy issues 1.1.3.

 

Any thoughts on this?

 

Darran, could you add a motion for this to the agenda for Monday’s call? Thanks.

 

 

Jeff Bohren

Product Architect

OpenNetwork Technologies, Inc