[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 56: Need to clarify definition of BidirectionalInterfaces - Additional Discussion
+1 Martin Chapman wrote: > I think the correlation topic should be separated out into a separate > issue as it warrants much deeper thought. > My view on the topic is that we need to distinguish between SCA runtime > provided correlation, and application correlation based on content of > application data in messages. > An SCA service/callback should be able to mark its interface as > requiring SCA Runtime correlation, which requires support in its bindings. > I am very scared of SCA saying anything about application correlation, > which to me includes c+i specs. The reason for this is that one must not > assume that both parties are in the same language and understand the > correlation mechanism without some extra meta-data. > > Martin. > > > > -----Original Message----- > *From:* Simon Nash [mailto:NASH@uk.ibm.com] > *Sent:* 07 July 2008 12:31 > *To:* OASIS Assembly > *Subject:* Re: [sca-assembly] ISSUE 56: Need to clarify definition > of Bidirectional Interfaces - Additional Discussion > > > I believe we were moving towards an emerging consensus on last > week's call that the question of whether the Assembly spec should > mandate, prohibit or permit per-message correlation IDs should be > the subject of another issue, and that the resolution to issue 56 > should focus on normative rules for how SCA runtimes should support > callbacks. > > Here's my attempt at the latter: > > "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. SCA runtimes MUST allow a single > invocation of an operation on the service interface to make zero, > one or many invocations of any of the operations on the callback > interface. SCA runtimes MAY also allow operations to be invoked on > the callback interface following completion of an invocation of an > operation on the service interface. > > For a given invocation of a service operation, which operations are > invoked on the callback interface, when these are invoked, the > number of operations invoked, 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." > > > Regarding correlations, I don't think it would be proper for the > Assembly spec to direct other SCA specs using RFC2119 language of > the form "....such mechanisms SHOULD be provided both by Bindings > and by Client API specifications". This is a misuse of RFC2119, and > it is also loose enough that it could cause serious problems if > these other specs were to define such facilities with inconsistent > or incompatible semantics. If an SCA correlation mechanism is > required (as opposed to allowing use of transport-level correlation > facilities), the Assembly spec should define its semantics and > conformance points, and leave other specs to indicate how it is > supported by specific bindings and implementation types. > > Simon > > Simon C. Nash, IBM Distinguished Engineer > Member of the IBM Academy of Technology > Tel. +44-1962-815156 Fax +44-1962-818999 > > > *Mike Edwards/UK/IBM@IBMGB* > > 07/07/2008 10:17 > > > To > "OASIS Assembly" <sca-assembly@lists.oasis-open.org> > cc > > Subject > [sca-assembly] ISSUE 56: Need to clarify definition of > Bidirectional Interfaces - Additional Discussion > > > > > > > > > > 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/ > > > > > > > > > > ------------------------------------------------------------------------ > > / > / > > /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/ > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]