Jeff
Let me make sure I understand your
proposal. Re 1.1.3 you are making the supported methods query capability
a function on the SOAP/HTTP binding only (implemented via WSDL) and are removing
all notion of that from schema schema. Re 1.1.1 you are adding the
execution type attribute to all operations so they can be sent alone, and
making the Batch operation elements optional to implement…
If this is correct I will add an agenda
item to that effect….
--------------------------------------------------------
Darran Rolls
http://www.waveset.com
Waveset Technologies
Inc
(512) 657
8360
--------------------------------------------------------
-----Original Message-----
From: Jeff Bohren
[mailto:]
Sent: Thursday, March
06, 2003 8:02 AM
To:
Subject: [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
