sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] [ISSUE 33] Updated Proposal for Issue 33
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-assembly@lists.oasis-open.org
- Date: Wed, 19 Nov 2008 12:53:39 +0000
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>
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 - 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]