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]
Hi,
There is no relationship at all between callbacks
and the asynchronous
(non-blocking) programming model. So mixing these
two aspects should
work. Are you running into a problem when you mix
@Callback and @Oneway?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
