Re: [sca-assembly] ISSUE 56: Need to clarify definition of BidirectionalInterfaces - Additional Discussion

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

In wstf (http://www.wstf.org) we are working on a purchase order 
scenario that works something like this:
There is a PO service which has submitPO, updatePO, cancelPO methods. 
When a client submits a PO, it has to provide a status update callback 
EPR. As a response to the 'submotPO' operation the client gets a PO 
number back. As the PO moves through various stages (logged, approved, 
back-ordered, shipped etc) the service uses the callback EPR to provide 
updates to the client.
This maps quite well to SCA's bidirectional interface. In this case the 
correlation is provide by the PO number that is part of the application 
message. No infrastructural correlation support is required.

I do think that such cases should be enabled by SCA. I see the 
correlation issue similar to the conversation interface issue that we 
have dealt with. We have said that an interface can be marked 
'conversational' in which case the infrastructure must provide the 
correlation id and manage routing/instances etc. But one can indeed have 
interfaces that are not marked conversational but still provide 
conversational/stateful interactions (it is then the application's 
responsibility). The bi-D case is important even when the infrastructure 
does not provide the correlation. Perhaps we need a separate 
marker/intent that says that the callback correlation is provided by the 
infrastructure (and therefore implies a requirement on the binding).

-Anish
--

Mike Edwards wrote:
> 
> Folks,
> 
> In last weeks' TC conf call, the discussion of Issue 56 was lively and 
> important.
> 
> The discussion closed with the following motion on the table:
> 
> Proposed text for the Assembly specification (CD-01), to be added after 
> line 2333
> 
> "In a bidirectional interface, the service interface can have more than 
> one operation defined, and the callback interface can
> also have more than one operation defined.  A single invocation of an 
> operation on the service interface can cause
> zero, one or many invocations of any of the operations on the callback 
> interface and a single invocation of an operation on
> the callback interface can result from one or from many invocations of 
> any of the operations on the service interface.
> For a given invocation of a service operation, which operations are 
> invoked on the callback interface, the number of operations
>  invoked, how they are correlated, and their sequence are not described 
> by SCA.  It is possible that this metadata about
> the bidirectional interface can be supplied through mechanisms outside 
> SCA. For example, it might be provided as a written
> description attached to the callback interface. "
> 
> 
> I'd like to concentrate on the one aspect of this proposal that I think 
> is not good - the outlawing of means for the correlation
> of callback operations with forward operations.
> 
> First, I'd like to (again) discuss the impact that this has on 
> applications.  If the system (SCA) provides no means for the
> correlation of the callback operations, then it is left to the 
> application writer(s) - in particular to the designer of the forward and
> callback interfaces.  
> 
> Without any system provided correlation, the interface designer has to 
> anticipate the correlation needs of the client (in
> particular) - and must place elements into the business data that 
> provide this correlation capability.  This will often go
> beyond a simple parameter such as (say) "Order ID", since if the forward 
> service interface provides multiple operations
> relating to an order, the callback messages may well have to carry 
> something like a "Request ID" in order to make it
> clear to the client that a given response relates to a particular 
> request that the client made - without this the client may
> have real problems working out the true meaning of the callback operation.
> 
> I note that a single, consistent, system provided means of correlation 
> of this type is preferable to the alternative of every
> designer having to work it out for themselves.
> 
> 
> Second, I note that numerous transport mechanisms including Web services 
> and JMS (and related messaging subsystems)
> provide a capability of marking a response message with an ID which 
> indicates the request message that it relates to.
> It is notable that the designers of these transport mechanisms 
> considered it important to have this function, which has
> the capability of permitting the client to establish which to original 
> message a response relates, without the need to sort
> through the business data.
> 
> I believe that it is reasonable for SCA to provide SCA applications with 
> mechanisms to access this capability of underlying
> transports, without the need for the applications having to resort to 
> transport-specific APIs.
> 
> 
> So, in summary, I continue to support the notion of SCA-provided 
> correlation mechanisms - and that the Assembly specification
> should assert that such mechanisms SHOULD be provided both by Bindings 
> and by Client API specifications.
> 
> 
> 
> Yours,  Mike.
> 
> Strategist - Emerging Technologies, SCA & SDO.
> Co Chair OASIS SCA Assembly TC.
> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
> Email:  mike_edwards@uk.ibm.com
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
> 
> 
> 
> 
> 
>