Re: Use case 3

Anish Karmarkar wrote:
> Roberto Chinnici wrote:
> 
>>
>> * Description of the scenario
>>
>> In this use case, a client contacts a server using transport T1. The
>> response is sent back asynchronously using a callback made over a
>> potentially different transport T2. Even if the transports are the 
>> same, the request and response messages could use different connections,
>> making this case different from #6.
>>
>> As a working example, let's use Kevin's "submitExpenseReport" operation
>> (see [1]). Its request and response messages are defined as follows:
>> (I made a few edits to make the naming more consistent)
>>
>>     <xs:schema ...>
>>
>>        <xs:element name="submitExpenseRequest" >
>>             <xs:complexType ...> ...    </xs:complexType>
>>       </xs:element>
>>
>>       <xs:element name = "submitExpenseResponse">
>>           <xs:complexType>
>>                 <xs:choice>
>>                         <xs:element ref = "tns:ApprovalConfirmation"/>
>>                             <!-- an immediate approval message for
>>                                  amount under $100 -->
>>                         <xs:element ref = "tns:ManagerDecision"/>
>>                             <!-- manager decision is required for amount
>>                                  above $100 -->
>>             <xs:choice>
>>           </xs:complexType>
>>        </xs:element>
>>             ...
>>     </xs:schema>
>>
>> This example highlights some variations on this use case:
>>
>>   3a. The response always uses transport T2.
>>   3b. The response uses sometimes T2a, sometimes T2b. Both are
>>       statically described.
>>   3c. The response may use any transport T2, independently from
>>       what the service description says.
>>
>> In Kevin's description of the sample service, the response would be
>> sent over HTTP when it's immediately available ("ApprovalConfirmation"
>> case) and over SMTP when it's not ("ManagerDecision"), thus providing
>> an example of (3b).
>>
>> * Can we achieve this case now with the current specs?  With how much
>> "squinting"?
>>
>> Almost. At the price of giving up on the idea of having a single
>> sumitExpenseReport operation. One can define two interfaces, each
>> carrying half of the whole interaction modelled as an in-only operation.
>> E.g.
>>
>>   <interface  name = "expenseReportingService" >
>>     <operation name="submitExpenseReport"
>>             pattern="http://www.w3.org/2004/03/WSDL/in-only" >
>>         <input messageLabel="In"
>>               element="tns:expenseRequest" />
>>     </operation>
>>   </interface>
>>
>>   <interface  name = "expenseReportingCallback" >
>>     <operation name="submitExpenseReportCallback"
>>             pattern="http://www.w3.org/2004/03/WSDL/in-only" >
>>         <input messageLabel="In"
>>               element="tns:expenseResponse" />
>>     </operation>
>>   </interface>
>>
> 
> I interpreted this to mean that usecase 3 (as expressed above) is 
> reduced to usecase 5 (correlated 2 one-way messages). Is that correct 
> interpretation?

At the description level, yes. There was quite a bit of overlap between
the use cases. Perhaps I should have described use case #3 the way you
described #4, e.g. in terms of the messages exchanged on the wire.
Based on them, the two formulations I described are both valid.

Roberto

Received on Wednesday, 16 February 2005 20:03:44 UTC