On Fri, Aug 26, 2011 at 9:13 AM, Simon Laws <[email protected]> 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 <[email protected]> >> 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
