Simon Nash wrote:
>
> 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.
I'm curious as to how could a SCA runtime prevent such a thing (looking
at it from a testability POV too), unless the SCA runtime prevents the
service from making any calls anywhere, which seems unlikely.
> 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.
>
I'm not sure what's the distinction between the two (MUST and MAY) is.
Is the difference the 'completion' part?
> 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."
>
+1
>
> 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/
>
>
>
>
>
>
