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

Anish,

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:  

From:
Anish Karmarkar <>

To:
Mike Edwards/UK/IBM@IBMGB

Cc:
, OASIS
Bindings <>

Date:
25/11/2008 06:55

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

Mike,

 >I think I agree that you can't really mix

 > callbacks and this new "long running" async style of service.

Why not? 

<mje> Because it
is £*&$^%"* complicated, that's why.  </mje>

I think it should be possible. 

<mje> Why?  What's
the use case?  Just because we COULD do the combination of

function doesn't mean that
we should do so - especially if it complicates matters </mje>

asyncInvocation is just a 

req-res where the response is sent over a separate connection. This is

independent of callbacks. Yes, it is possible to do a asyncInvocation 

using callbacks and one-way operations. But the critical difference here

is that the asyncInvocation consists of only one reply/response.

<mje> I agree.  But
why would you want to mix the two mechanisms in one service interface?
</mje>

-Anish

--

Mike Edwards wrote:

> 

> 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:  

> 

> 

> From:                
 Simon Holdsworth/UK/IBM@IBMGB

> To:                
 

> 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>*

> 

> 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>*

> 

> 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>*

> 

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

> 

> *Mike Edwards/UK/IBM@IBMGB*

> 

> 19/11/2008 10:51

> 

>                  

> To

>                  "OASIS
Assembly" <>

> 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:  

> 

> 

> ------------------------------------------------------------------------

> 

> /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/

> 

> 

> 

> 

> 

> 

---------------------------------------------------------------------

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