Re: [sca-bindings] Re: [sca-assembly] [ISSUE 33] Updated Proposal for Issue33

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Mike,

Further responses below inline in <sajh>blue</sajh>

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com

Mike Edwards/UK/IBM@IBMGB

19/11/2008 12:53

To	sca-assembly@lists.oasis-open.org
cc	"OASIS Bindings" <sca-bindings@lists.oasis-open.org>
Subject	[sca-bindings] Re: [sca-assembly] [ISSUE 33] Updated Proposal for Issue 33

Folks, 

Comments inline... 

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

From:	Simon Holdsworth/UK/IBM@IBMGB
To:	sca-assembly@lists.oasis-open.org
Date:	19/11/2008 11:09
Subject:	Re: [sca-assembly] [ISSUE 33] Updated Proposal for Issue 33

---

Mike, 

My initial reaction to this is that it conflicts with the existing conversational
support, although I see that there is a new issue to remove that support
from the spec.  If that doesn't get accepted, are you comfortable
with the spec including all of callbacks, conversations and async invocations?

<mje> 
I'm not sure what the conflict is, although as you say, this may be a moot
point.  However, I don't view this "long running" support
as being much different to callbacks.  I think I agree that you can't
really mix callbacks and this new "long running" async style
of service.  Mixing with conversational seems no more complex than
mixing conversations with callbacks (yes, there is complexity there, I
agree). 
</mje> 

<sajh>OK...  However
in theory at least it should be possible for a callback to be made from
such a long-running invocation at any time after the request is received,
including before the response is sent (indeed that should be possible for
any request/response operation, regardless of how long running it is).
 My concern is not so much over the technical possibility as the number
of options and combinations we are presenting.</sajh>

The text says: "the binding must be able to treat the transmission
of the request message separately from the transmission of the response
message, with an arbitrarily large time interval between the two transmissions.".
 Does that leave space for an implementation to include timeouts,
or to hold correlation information non-persistently?  Even for HTTP
some amount of asynchonous invocation is possible, at least from the point
of view of the interacting components, although the connection would be
lost if either party terminates or some comms error occurs.
<mje> 
Not sure I follow your point about HTTP providing "some amount of
asynchronous invocation" unless you mean that HTTP can wait for a
limited time for a response - like a small number of minutes.  What
I am trying to say is that if a service is marked as "long running"
then the binding CANNOT assume that a "small number of minutes"
is going to cut it.  The proposal says that the binding MUST assume
that the response will be a separate transmission at some arbitrarily later
time 
</mje>

<sajh>OK;  I was
saying that from a runtime and programming model point of view, and HTTP
binding could provide the illusion of an asynchronous invocation, however
I agree that it would not be possible to honour the async contract in the
face of a server restart or connection failure.  It sounds like the
expection of this intent would be to survive such events, in which case
for a compliant implementation there would have to be persistent correlation
state stored indefinitely.  My concern was from a practical point
of view, indefinite persistent storage is typically something that is problematic,
and usually has some sort of timeout associated with it, and I was wondering
if there was leeway from a conformance point of view to have some sort
of time limitation, or whether it really did have to be indefinite.</sajh>

I'd note that for the web services example given, the non-anonymous response
URI allows a client of a service to act asynchronously, but it does not
mean that the service itself will dispatch the request on its target component
and handle the response asynchronously. 
<mje> 
Not quite sure what point you're making here.  

As far as the target component is concerned, the whole point of the marking
of the interface is that it indicates that the service operations are going
to be "long running" implying "asynchronous".  For
the service to be able to do this, the implementation type MUST be able
to support such a concept - if it can't then tough, you can't implement
the service in that language.  HOW it is done is up to the implementation
language specs.  In the examples for Java that are in one of the documents
that I sent out, there are examples of two alternatives - one based on
standard Java method calls with responses provided via return values in
the normal way, the other based on using a callback reference to dispatch
the response message.  Frankly, the first of these depends on the
calling thread blocking and waiting at some point which is pretty fragile
and would not be my choice in most cases.  The second way allows for
the callback to be stored into a database and retrieved at some later point
whenever the asynchronous activities complete - much more likely to be
robust.   

Whether other languages can support some style(s) equivalent to these is
up to the relevant implementation TCs to decide.
</mje>

<sajh>OK - so I was
just pointing out that using a non-anonymous URI with WS-A is not itself
sufficient to satisfy the intent - you would also need to have the ability
to dispatch the request on the target component asynchronously from the
returning of the result - which would require the component type to support
such an async dispatch and result passing mechanism. I agree with the point
about persistent request/response correlation state storage as above.</sajh>

Regards, Simon 

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com

Mike Edwards/UK/IBM@IBMGB

19/11/2008 10:51

To	"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
cc
Subject	[sca-assembly] [ISSUE 33] Updated Proposal for Issue 33

Folks, 

Here is an updated version of the proposal for Issue 33 following the discussion
on the call yesterday: 




This is the version that I am sending to the other TCs.

Note that the current Assembly specification does not define the requirements
that bidirectional interfaces place on bindings, so the text in this proposal
is the first place that this is defined for the Assembly specification.


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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

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

[attachment "2008-11-12 - SCA-Assembly Issue 33 - Proposal_2.doc" deleted by Mike Edwards/UK/IBM] [attachment "2008-11-12 - SCA-Assembly Issue 33 - Java Mapping_2.doc" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

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