Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement - Simon Nash - org.oasis-open.lists.sca-j

20 messages in org.oasis-open.lists.sca-jRe: [sca-j] [NEW ISSUE] Section 10.13...

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:	Simon Nash (oas...@cjnash.com)
Date:	May 2, 2009 3:41:09 am
List:	org.oasis-open.lists.sca-j

Anish Karmarkar wrote:

Mike Edwards wrote:

Folks,

I think we've lost sight of something here.

If the intention is to use the whole of an implementation class as the definition of a service interface (case of unannotated POJO implementing 0 remotable interfaces), I find it very odd that the client of such a service is not able to use that class as the type of the reference.

It has been stated that this is not possible, but instead the client must obtain or create an */interface class/* that implements "an interface that is compatible with the target implementation class".

If this is the case, then I think the average developer will think we have gone off our heads! They will have a very hard time understanding why they cannot use the POJO class directly - and there are no easy tools that will build the implied interface.

I think that EITHER:

1) We should suppress the ability for an unannotated implementation class to be treated as the definition of a service interface.

2) We should permit the use of an unannotated implementation class as the definition of the interface for a reference.

OR (3) require a clean separate of service interfaces and implementation classes. I.e., all service contracts are specified only with Java interfaces.

-Anish

I recognise that option 2) may give SCA runtime implementations some fun in implementing what is required which may in turn cause there to be restrictions on the form of the unannotated POJO. On the other hand let us remember that this can ONLY apply to local services that are certainly running in the same JVM as the client.

The use of a Java class to define a service contract isn't limited to local services. The resolution to JAVA-134 has made it possible for @Remotable to be applied to a service implementation class that is used as an SCA service contract.

Even if we were to reverse JAVA-134 to prevent @Remotable from being used in this case, I don't see how one-way semantics could be supported for an invocation though a reference whose type is a Java class. The reference would have to contain an instance of the class, and a method call through the reference would execute the implementation method synchronously rather than asynchronously.

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: 30/04/2009 20:29 Subject: Re: [sca-j] [NEW ISSUE] Section 10.13 on @OneWay requires a normative statement

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

Simon Nash wrote:

Dave, Thanks, this is a more useful way to express the issue.

The question is whether one-way invocation is 1) a property of the service, that the reference must obey 2) a property of the service, that the reference can choose whether to use or not 3) a property of the reference, that the service doesn't know is happening

After a little bit of further thought, I think the answer has to be 1). This is because the @OneWay annotation maps to a one-way MEP in the WSDL portType. By the Assembly compatibility rules, if either the reference or the service uses a one-way MEP, then both sides would have to do this.

If we agree on this, the conclusion is that we do need to allow @OneWay on service implementation classes for the case where the service interface is defined using the implementation class. In this case, @OneWay would also need to be specified on the reference interface.

Simon

David Booz wrote:

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:

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.

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:

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.

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

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

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets