i think there is already a JIRA issue open for this
Key: TUSCANY-1208
URL:
https://issues.apache.org/jira/browse/TUSCANY-1208
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding
Reporter: Lou Amodeo
--- Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
> Comments inline.
>
> muhwas wrote:
> > I thought Callback is actually asynchronous method
> > call. because client call the method and then
> continue
> > and then server does some processing then using
> the
> > callback interface notify client that processing
> is
> > complete.
> >
>
> It really depends on what you mean by asynchronous
> method call. My
> understanding of the SCA specification is that a
> Callback does not imply
> a non-blocking call (this is the terminology used in
> the SCA spec) or
> dispatching to a different thread.
>
> However IMO the spec is not really clear on this as
> I found references
> to asynchronous interactions in the callback
> sections:
>
> Assembly spec v1.0, lines 739-746:
> Bidirectional Interfaces
> The relationship of a business service to another
> business service is
> often peer-to-peer, requiring a two-way dependency
> at the service level.
> In other words, a business service represents both a
> consumer of a
> service provided by a partner business service and a
> provider of a
> service to the
> partner business service.This is especially the case
> when the
> interactions are based on asynchronous messaging
> rather than on remote
> procedure calls. The notion of bidirectional
> interfaces is used in SCA
> to directly model peer-to-peer bidirectional
> business service relationships.
>
> Java Annotations and API spec, lines 528-530:
> Callbacks
> A callback service is a service that is used for
> asynchronous
> communication from a service provider back to its
> client in contrast to
> the communication through return values from
> synchronous operations.
>
> But these two statements still do not mean that a
> Callback implies an
> asynchronous / non-blocking call.
>
> Let's take an example (adapted from the Java
> Annotations and API spec
> sample lines 545 to 600) to illustrate this:
>
> // A service interface and the corresponding
> callback interface
> @Callback(MyServiceCallback.class)
> public interface MyService {
> public void someMethod(String arg);
> }
>
> public interface MyServiceCallback {
> public void receiveResult(String result);
> }
>
> // The service implementation
> public class MyServiceImpl implements MyService {
> @Callback
> protected MyServiceCallback callback;
>
> public void someMethod(String arg) {
> callback.receiveResult(result);
> }
> }
>
> // The client implementation
> public class ClientImpl implements MyServiceCallback
> {
> @Reference
> protected MyService myService;
>
> public void aClientMethod() {
> myService.someMethod(arg);
> }
>
> public void receiveResult(String result) {
> // code to process the result
> }
> }
>
> In the above example, my assumption is that
> ClientImpl.receiveResult()
> can execute in the same thread as
> ClientImpl.aClientMethod().
> MyServiceImpl.someMethod() will not return until
> ClientImpl.receiveResult() returns.
> ClientImpl.aClientMethod() will not
> return until MyServiceImpl.someMethod() returns. All
> calls can be
> synchronous (although they don't have to) without
> violating the spec,
> but you still get a sense of asynchrony here as from
> the perspective of
> ClientImpl, as receiveResult is invoked
> "asynchronously" before
> MyServiceImpl.someMethod() returns. Note that I'm
> saying that all calls
> can be synchronous but don't have to, in some cases
> the runtime may
> choose to execute callbacks on a different thread,
> still without
> violating the SCA spec if I understand it correctly,
> and this may very
> well be what we'll have to do in some cases
> involving remote
> communications to avoid deadlocks.
>
> If you add @OneWay annotations to some of these
> methods then it's a
> different story, as each method annotated with
> @OneWay will get
> dispatched to a different thread of execution and/or
> use a binding that
> buffers requests, allowing the caller to proceed
> without having to wait
> for the service method to return.
>
> So, to get back to the asynchronous pattern that you
> were describing,
> you'll need to annotate your service methods with
> @OneWay if you want
> the client to continue with other work while the
> server is executing a
> request.
>
> > I am having problem when i include both callback
> and
> > synchronous method in the same bussiness
> interface. My
> > callback method call works fine but somehow
> > synchronous method also expect a call back from
> server
> > and hang and eventually throw time out exceptions.
> >
> >
>
> This is probably a bug. Thanks for reporting it.
> Could you please open a
> JIRA issue with a test case and/or a description of
> the steps allowing
> us to reproduce the bug, and we'll investigate. If
> you find a solution
> to fix it then that's even better, just attach a
> patch to the JIRA :)
> Thanks.
>
> > --- Jean-Sebastien Delfino <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> >> muhwas wrote:
> >>
> >>> Hi guys,
> >>>
> >>> I have a quick question. If i put a
> >>> @Callback(CallBackInterface.class) on my
> bussiness
> >>> interface then all method in that interface has
> to
> >>>
> >> be
> >>
> >>> asynchronous or i can use synchronous method
> too?
> >>>
> >>> thanks,
> >>> muhwas
> >>>
> >>>
> >>>
> >
>
---------------------------------------------------------------------
> >
> >>> To unsubscribe, e-mail:
> >>>
> >> [EMAIL PROTECTED]
> >>
> >>> For additional commands, e-mail:
> >>>
> >> [EMAIL PROTECTED]
> >>
> >>>
>
=== message truncated ===
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
