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

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