OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[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



Folks,

There are several bones in here that I'd like to pick out, marked inline as

<mje> ... </mje>


A suggested revision of the wording I previously proposed follows - removing anything about correlation and
adding in words about timing and lack of constraints....


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, their sequence and their timing are not constrained by SCA and 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. "




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



Simon Nash/UK/IBM@IBMGB

07/07/2008 12:31

To
"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
cc
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.
  <mje> Agree </mje>

Here's my attempt at the latter:


<mje>
Not sure where to put this comment - so up front seemed as bad a place as any ;-)  I'm OK with having RFC2119 language, but I think I'd prefer a style where we say something like "an SCA runtime MAY support bidirectional interfaces" and then go on to describe the characteristics of bidirectional interfaces without RFC2119 language embedded.  The runtime then does not get to pick and choose - implement all that is required or none.  The problem with the language as below is that the application programmer is left uncertain as to what they can rely on,  It is much easier to understand that you get all or nothing.
</mje>

"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.

<mje>
OK, my first surprise when reading this carefully is the interpretation or meaning given to the term "invocation".

The way it is used here is to imply that "invocation" is being used in the sense of "the time span of the call made to the service implementation code when the initial service operation is invoked"  (in Java terms, the span of the method call which implements the service operation).

This was a surprise to me.  I can see how such a meaning then gives rise to the second sentence above.

However, this was never my understanding of how async, callback-based services were intended to work.  For me, the initial forward service request is merely the initiator of some sequence that is potentially long drawn-out in time.  It is my expectation that 99% of the time, the initial forward service call is done and dusted before the first of any callback operations gets invoked.  If it were likely that the response messages could be produced during the life of the forward service invocation call, then I don't know why I would use an asynchonous pattern at all.  The whole point of the async pattern is that the responses are likely to take a while - and it does not seem reasonable to keep the initial invocation "alive" for this period.

For me, if we really want to get into specifying the detail, the timing of the response messages relative to the forward invocation MUST also be completely free.  I would require an SCA runtime that supports callbacks to permit the callback operations to occur at any time after the initial invocation - and that the runtime MUST permit callback messages to be returned aftern the initial invocation is "complete" (we'd have to define that term - at the very least it would mean the release of the binding and underlying transport resources for the forward call).

I'm OK for some runtime not to support callbacks at all, but if they are going to be supported, then the time sequencing must be free, decided by the application code and any services that it might depend on.
</mje>

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."

<mje>
I agree with this - but I have this previously unstated view that not only are the operations, timing, sequence not described by SCA - they are also NOT CONSTRAINED by SCA, which is what is behind my comment on the previous paragraph.
</mje>


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.

<mje> I agree that we should move the discussion of correlations elsewhere</mje>

   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












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]