You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2011/08/25 15:49:13 UTC
What should the Tuscany generated WSDL contract look like for an
async service?
Looking to fix TUSCANY-3931 about the clients not working with the
wsdl in the domain registry for async services and i wonder what the
wsdl should really look like. For example with the service interface:
@AsyncInvocation
public interface Service1AsyncServer {
@AsyncFault( {BusinessFault1.class, BusinessFault2.class} )
public void operation1Async( String input, ResponseDispatch<String> handler );
}
would we expect the generated wsdl that goes in the domain registry be
that or the equivalent synchronous version, so with an operation1
instead of operation1Async?
...ant
Re: What should the Tuscany generated WSDL contract look like for
an async service?
Posted by Mike Edwards <mi...@gmail.com>.
On 25/08/2011 20:53, Greg Dritschler wrote:
> I agree that the DomainRegistry should have the equivalent synchronous version.
>
> While we're on this subject, I happened to be wondering today whether @AsyncInvocation obligates the
> service implementation to use the async service interface? Obviously it makes the most sense to use
> them together, but is that required? As a service implementer, could I use @AsyncInvocation with
> the normal synchronous interface? This would mean the service implementation completes "inline" so
> to speak and has no need for a ResponseDispatch object. Since @AsyncInvocation is used, the SCA
> runtime is obligated to provide a suitable thread for a long-running request, and the binding still
> must support an asynchronous response. Effectively, it means the SCA runtime would do the
> ResponseDispatch call on behalf of the implementation at the completion of the method.
>
> I'm not terribly excited about supporting such a thing, but I didn't see anything in the spec that
> suggests either way whether it's allowed or disallowed.
>
> Greg
>
Greg,
Yuk, pretty ugly.
I'd be happy if the SCA runtime barfed if it saw @AsyncInvocation being used like that.
It isn't a good pattern to encourage since it consumes server resources and is susceptible to failures.
As for fixing the spec to disallow this usage - maybe V1.2 could address that.
Yours, Mike.
Re: What should the Tuscany generated WSDL contract look like for an
async service?
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Aug 26, 2011 at 10:46 AM, ant elder <an...@gmail.com> wrote:
> On Fri, Aug 26, 2011 at 9:13 AM, Simon Laws <si...@googlemail.com> wrote:
>> snip...
>>> While we're on this subject, I happened to be wondering today whether
>>> @AsyncInvocation obligates the service implementation to use the async
>>> service interface? Obviously it makes the most sense to use them together,
>>> but is that required? As a service implementer, could I use
>>> @AsyncInvocation with the normal synchronous interface? This would mean the
>>> service implementation completes "inline" so to speak and has no need for a
>>> ResponseDispatch object. Since @AsyncInvocation is used, the SCA runtime is
>>> obligated to provide a suitable thread for a long-running request, and the
>>> binding still must support an asynchronous response. Effectively, it means
>>> the SCA runtime would do the ResponseDispatch call on behalf of the
>>> implementation at the completion of the method.
>>> I'm not terribly excited about supporting such a thing, but I didn't see
>>> anything in the spec that suggests either way whether it's allowed or
>>> disallowed.
>>> Greg
>>> On Thu, Aug 25, 2011 at 1:03 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>>
>>
>> I agree Greg that the spec doesn't seem to outlaw it. It talks about
>> the mapping but doesn't seem to make it mandatory. I would suggest
>> that it's up to us to decide. My opening gambit would be to say we
>> don't support it in the first instance on the basis that if the user
>> went to the trouble to annotate a service with the asynInvocation
>> intent then presumably their intention was to exploit an async
>> invocation pattern. Just my 2c.
>>
>
> Section 6.4.3 in the assembly spec says "It is also possible for a
> service to set the asyncInvocation. intent when using an interface
> which is not marked with the asyncInvocation. intent. This can be
> useful when reusing an existing interface definition that does not
> contain SCA information." Its not terribly clear to me what that
> really implies but it does sound like it might be saying you can do
> what Greg is suggesting.
>
> ...ant
>
Good spot Ant but not sure what it means precisely in the context of
this question. I think you mean it's saying you can do either:
@AsyncInvocation
@Remotable
public interface HelloWorld {
public void helloAsync( String input, ResponseDispatch<String> handler );
}
OR
@Remotable
public interface HelloWorld {
public String hello( String input);
}
<service name="HelloWorld" requires="asyncInvocation"/>
Although it's not explicit that the interface has to have any explicit
form. I can't see anything in JCAA about it.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: What should the Tuscany generated WSDL contract look like for an
async service?
Posted by ant elder <an...@gmail.com>.
On Fri, Aug 26, 2011 at 9:13 AM, Simon Laws <si...@googlemail.com> wrote:
> snip...
>> While we're on this subject, I happened to be wondering today whether
>> @AsyncInvocation obligates the service implementation to use the async
>> service interface? Obviously it makes the most sense to use them together,
>> but is that required? As a service implementer, could I use
>> @AsyncInvocation with the normal synchronous interface? This would mean the
>> service implementation completes "inline" so to speak and has no need for a
>> ResponseDispatch object. Since @AsyncInvocation is used, the SCA runtime is
>> obligated to provide a suitable thread for a long-running request, and the
>> binding still must support an asynchronous response. Effectively, it means
>> the SCA runtime would do the ResponseDispatch call on behalf of the
>> implementation at the completion of the method.
>> I'm not terribly excited about supporting such a thing, but I didn't see
>> anything in the spec that suggests either way whether it's allowed or
>> disallowed.
>> Greg
>> On Thu, Aug 25, 2011 at 1:03 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>
> I agree Greg that the spec doesn't seem to outlaw it. It talks about
> the mapping but doesn't seem to make it mandatory. I would suggest
> that it's up to us to decide. My opening gambit would be to say we
> don't support it in the first instance on the basis that if the user
> went to the trouble to annotate a service with the asynInvocation
> intent then presumably their intention was to exploit an async
> invocation pattern. Just my 2c.
>
Section 6.4.3 in the assembly spec says "It is also possible for a
service to set the asyncInvocation. intent when using an interface
which is not marked with the asyncInvocation. intent. This can be
useful when reusing an existing interface definition that does not
contain SCA information." Its not terribly clear to me what that
really implies but it does sound like it might be saying you can do
what Greg is suggesting.
...ant
Re: What should the Tuscany generated WSDL contract look like for an
async service?
Posted by Simon Laws <si...@googlemail.com>.
snip...
> While we're on this subject, I happened to be wondering today whether
> @AsyncInvocation obligates the service implementation to use the async
> service interface? Obviously it makes the most sense to use them together,
> but is that required? As a service implementer, could I use
> @AsyncInvocation with the normal synchronous interface? This would mean the
> service implementation completes "inline" so to speak and has no need for a
> ResponseDispatch object. Since @AsyncInvocation is used, the SCA runtime is
> obligated to provide a suitable thread for a long-running request, and the
> binding still must support an asynchronous response. Effectively, it means
> the SCA runtime would do the ResponseDispatch call on behalf of the
> implementation at the completion of the method.
> I'm not terribly excited about supporting such a thing, but I didn't see
> anything in the spec that suggests either way whether it's allowed or
> disallowed.
> Greg
> On Thu, Aug 25, 2011 at 1:03 PM, Simon Laws <si...@googlemail.com>
> wrote:
>>
I agree Greg that the spec doesn't seem to outlaw it. It talks about
the mapping but doesn't seem to make it mandatory. I would suggest
that it's up to us to decide. My opening gambit would be to say we
don't support it in the first instance on the basis that if the user
went to the trouble to annotate a service with the asynInvocation
intent then presumably their intention was to exploit an async
invocation pattern. Just my 2c.
Regards
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: What should the Tuscany generated WSDL contract look like for an
async service?
Posted by Greg Dritschler <gr...@gmail.com>.
I agree that the DomainRegistry should have the equivalent synchronous
version.
While we're on this subject, I happened to be wondering today whether
@AsyncInvocation obligates the service implementation to use the async
service interface? Obviously it makes the most sense to use them together,
but is that required? As a service implementer, could I use
@AsyncInvocation with the normal synchronous interface? This would mean the
service implementation completes "inline" so to speak and has no need for a
ResponseDispatch object. Since @AsyncInvocation is used, the SCA runtime is
obligated to provide a suitable thread for a long-running request, and the
binding still must support an asynchronous response. Effectively, it means
the SCA runtime would do the ResponseDispatch call on behalf of the
implementation at the completion of the method.
I'm not terribly excited about supporting such a thing, but I didn't see
anything in the spec that suggests either way whether it's allowed or
disallowed.
Greg
On Thu, Aug 25, 2011 at 1:03 PM, Simon Laws <si...@googlemail.com>wrote:
> On Thu, Aug 25, 2011 at 2:49 PM, ant elder <an...@gmail.com> wrote:
> > Looking to fix TUSCANY-3931 about the clients not working with the
> > wsdl in the domain registry for async services and i wonder what the
> > wsdl should really look like. For example with the service interface:
> >
> > @AsyncInvocation
> > public interface Service1AsyncServer {
> > @AsyncFault( {BusinessFault1.class, BusinessFault2.class} )
> > public void operation1Async( String input,
> ResponseDispatch<String> handler );
> > }
> >
> > would we expect the generated wsdl that goes in the domain registry be
> > that or the equivalent synchronous version, so with an operation1
> > instead of operation1Async?
> >
> > ...ant
> >
>
> My immediate answer would be that it should look like the synchronous
> version with the asyncInvocation intent attached.
>
> When we are matching interfaces we are comparing the synchronous
> version because that's what the statement of the service interface
> looks like.
>
> Bindings have to decide how to support async invocations. We current
> support two models which allow native and non-native support. Our web
> services binding doesn't support async natively so I would guess that
> ?wsdl to the async endpoint results in the synch WSDL (don't know if
> it's appropriately decorated). If it did provide native support would
> we expect it to represent the async flow explicitly. No sure but we
> can look to see it Axis says anything about what it does in the async
> case.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
Re: What should the Tuscany generated WSDL contract look like for
an async service?
Posted by Mike Edwards <mi...@gmail.com>.
On 25/08/2011 18:03, Simon Laws wrote:
> On Thu, Aug 25, 2011 at 2:49 PM, ant elder<an...@gmail.com> wrote:
>> Looking to fix TUSCANY-3931 about the clients not working with the
>> wsdl in the domain registry for async services and i wonder what the
>> wsdl should really look like. For example with the service interface:
>>
>> @AsyncInvocation
>> public interface Service1AsyncServer {
>> @AsyncFault( {BusinessFault1.class, BusinessFault2.class} )
>> public void operation1Async( String input, ResponseDispatch<String> handler );
>> }
>>
>> would we expect the generated wsdl that goes in the domain registry be
>> that or the equivalent synchronous version, so with an operation1
>> instead of operation1Async?
>>
>> ...ant
>>
>
> My immediate answer would be that it should look like the synchronous
> version with the asyncInvocation intent attached.
>
> When we are matching interfaces we are comparing the synchronous
> version because that's what the statement of the service interface
> looks like.
>
> Bindings have to decide how to support async invocations. We current
> support two models which allow native and non-native support. Our web
> services binding doesn't support async natively so I would guess that
> ?wsdl to the async endpoint results in the synch WSDL (don't know if
> it's appropriately decorated). If it did provide native support would
> we expect it to represent the async flow explicitly. No sure but we
> can look to see it Axis says anything about what it does in the async
> case.
>
> Simon
>
+1
WSDL simply has the AsyncInvocation intent added to it. How that gets interpreted by the binding is
the big thing. The idea is that the binding should really split the request and response handling.
But note that in principle, a non-aware binding could try to treat the operation as synchronous -
it would simply time out in most cases.
Yours, Mike.
Re: What should the Tuscany generated WSDL contract look like for an
async service?
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Aug 25, 2011 at 2:49 PM, ant elder <an...@gmail.com> wrote:
> Looking to fix TUSCANY-3931 about the clients not working with the
> wsdl in the domain registry for async services and i wonder what the
> wsdl should really look like. For example with the service interface:
>
> @AsyncInvocation
> public interface Service1AsyncServer {
> @AsyncFault( {BusinessFault1.class, BusinessFault2.class} )
> public void operation1Async( String input, ResponseDispatch<String> handler );
> }
>
> would we expect the generated wsdl that goes in the domain registry be
> that or the equivalent synchronous version, so with an operation1
> instead of operation1Async?
>
> ...ant
>
My immediate answer would be that it should look like the synchronous
version with the asyncInvocation intent attached.
When we are matching interfaces we are comparing the synchronous
version because that's what the statement of the service interface
looks like.
Bindings have to decide how to support async invocations. We current
support two models which allow native and non-native support. Our web
services binding doesn't support async natively so I would guess that
?wsdl to the async endpoint results in the synch WSDL (don't know if
it's appropriately decorated). If it did provide native support would
we expect it to represent the async flow explicitly. No sure but we
can look to see it Axis says anything about what it does in the async
case.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com