| From | Sent On | Attachments |
|---|---|---|
| Mike Edwards | Apr 28, 2009 12:37 am | |
| Simon Nash | Apr 28, 2009 4:39 am | |
| David Booz | Apr 28, 2009 4:52 am | .gif, .gif |
| Mike Edwards | Apr 28, 2009 5:58 am | |
| David Booz | Apr 28, 2009 6:10 am | .gif, .gif |
| Simon Nash | Apr 28, 2009 6:34 am | |
| David Booz | Apr 28, 2009 1:10 pm | .gif, .gif |
| Mike Edwards | Apr 28, 2009 2:44 pm | |
| Simon Nash | Apr 29, 2009 2:11 pm | |
| Simon Nash | Apr 29, 2009 2:15 pm | |
| David Booz | Apr 30, 2009 10:49 am | .gif, .gif |
| Simon Nash | Apr 30, 2009 11:09 am | |
| Simon Nash | Apr 30, 2009 12:28 pm | |
| Mike Edwards | May 1, 2009 1:13 am | |
| Anish Karmarkar | May 1, 2009 4:23 pm | |
| Anish Karmarkar | May 1, 2009 4:28 pm | |
| Simon Nash | May 2, 2009 3:41 am | |
| Mike Edwards | May 7, 2009 7:31 am | |
| Mike Edwards | May 7, 2009 7:35 am | |
| Mike Edwards | May 7, 2009 7:48 am |
| Subject: | Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement | |
|---|---|---|
| From: | David Booz (bo...@us.ibm.com) | |
| Date: | Apr 30, 2009 10:49:23 am | |
| List: | org.oasis-open.lists.sca-j | |
| Attachments: | ||
Thanks for clarifying. I see that you're questioning the validity of specifying @OneWay methods on service interfaces.
I was a bit surprised to find that the Assemlby spec doesn't say anything about one-way/non-blocking behavior. There's a hole here in that another CI spec could define it as a service runtime behavior, resulting in no one performing the asynchronous dispatch. Is this a discussion we've had before?
Java CAA certainly hints that it's the client runtime (probably the binding) which implements the behavior but we could definitely make this more explicit with RFC2119 words.
Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC and SCA-J TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:bo...@us.ibm.com
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Simon Nash <oas...@cjnash.com>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|OASIS Java <sca...@lists.oasis-open.org>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|04/29/2009 05:12 PM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative
statement |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Mike Edwards wrote:
Simon,
So, if an unannotated Java POJO implements only local interfaces and is introspected as a single local service typed by the POJO class itself, as described in JAVA CI spec sections 2.3 and 8, what does the componentType of that service look like and how would a <reference/> element be configured in order to invoke the service offered by a component using the unannotated POJO as an implementation?
The componentType of the service component would have a <service> element with <interface.java interface="name-of-the-impl-class"/>
So far, so good. On the reference side, things get more tricky. For example, if the reference is an injected field, the type of this field can't be declared in Java code with a type of "name-of-the-impl-class". In order for the SCA runtime to successfully inject a reference proxy, the type of the field would need to be an interface type that is compatible (in the SCA sense) with the class that is used for the service's interface.
For any one-way methods that are part of the service contract, the @OneWay annotation would need to appear on that method in the reference's interface, so that the reference side SCA runtime would know that a non-blocking invocation is required.
It is an interesting question whether or not @OneWay would also need to appear on the corresponding method of the service's interface (aka impl-class). The non-blocking invocation is performed on the reference side, so from that perspective it would make no difference whether or not @OneWay appears on the service side. If the Assembly compatibility rules required matching one-way annotations on methods, this would require @OneWay to appear on the service side as well. However, the interface compatibility rules as currently written don't require this, so the following would be legal:
(on service side)
public class MyServiceImpl { public void myAsyncMethod() { ... } }
(on reference side)
public interface MyService { @OneWay public void myAsyncMethod(); }
public class MyClientImpl {
@Reference protected MyService ref;
... ref.myAsyncMethod(); // non-blocking invocation ... }
In this example, it makes no difference whether or not the method myAsyncMethod() of MyServiceImpl has a @OneWay annotation.
Simon
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...@uk.ibm.com
From: Simon Nash <oas...@cjnash.com> To: sca...@lists.oasis-open.org Date: 28/04/2009 14:38 Subject: Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement
------------------------------------------------------------------------
The problem with this interpretation is that @OneWay would need to appear on the reference side, and a reference must use a Java interface and not a Java class.
Simon
David Booz wrote:
+1
Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC and SCA-J TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:bo...@us.ibm.com
Inactive hide details for Mike Edwards ---04/28/2009 08:59:22 AM---Simon, I don't think it was the intention of the original woMike Edwards ---04/28/2009 08:59:22 AM---Simon, I don't think it was the intention of the original wording of the spec to
From: Mike Edwards <mike...@uk.ibm.com>
To: OASIS Java <sca...@lists.oasis-open.org>
Date: 04/28/2009 08:59 AM
Subject: Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement
------------------------------------------------------------------------
Simon,
I don't think it was the intention of the original wording of the spec to permit the implementation pattern that you describe below.
I think that the case of class methods being annotated was there to cover the case where the whole class defines the interface - as occurs for unannotated classes with purely local interfaces.
Maybe I have this wrong, but that is how I understand it.
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...@uk.ibm.com
From: Simon Nash <oas...@cjnash.com> To: OASIS Java <sca...@lists.oasis-open.org> Date: 28/04/2009 12:43 Subject: Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement
------------------------------------------------------------------------
Mike, I agree that this needs to be made normative.
I had always thought that @OneWay applied only to interface methods. The reference to class methods (in the original text and your proposal) surprises and intrigues me, because this suggests that @OneWay could be applied to a service implementation method without being applied to the corresponding interface method. If this is legal, it would mean that the client invokes the service synchronously, and the service returns back to the client immediately and dispatches the method for subsequent execution.
Do we want to allow this interaction pattern? If we do want to allow it, then I think we need to make this more explicit in the text.
Simon
Mike Edwards wrote:
*** NB I am happy for this new issue to be treated as a comment on the Public Review draft - I just don't want this item lost ***
Raiser: Mike Edwards
Target: sca-javacaa-1.1-spec-cd02-rev6.doc
Description:
There is a sentence in section 10.13 about @OneWay which in effect describes a normative requirement but is not in the form of a normative statement:
Lines 1923 - 1925:
"The @OneWay annotation is used on a Java interface or class method to indicate that invocations will be dispatched in a non-blocking fashion as described in the section on Asynchronous Programming."
This must be recast into the form of a normative statement
Proposal:
Replace lines 1923 - 1925 with the following normative statement:
When a Java interface method or a Java class method is annotated with @OneWay, the SCA runtime MUST ensure that all invocations of that method are executed in a non-blocking fashion, as described in the section on Asynchonous Programming. [JCA90052]
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...@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/
--------------------------------------------------------------------- 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






.gif, .gif