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

Inactive hide details for Simon Nash ---04/29/2009 05:12:29 PM---Mike Edwards wrote: >Simon Nash ---04/29/2009 05:12:29 PM---Mike Edwards wrote: >

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:

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

mike...@uk.ibm.com

mean

for

allow

method to

Britain.

with

Hampshire

that

at:_

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: