+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:]
> *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" <>
> 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:
>
>
> ------------------------------------------------------------------------
> /
> /
>
> /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/
>
>
>
>
>
>
