ant elder wrote:
On Thu, Jun 25, 2009 at 5:12 PM, Raymond Feng<[email protected]> wrote:
I don't think adding the callback pattern to SCAClient is good idea. IMO,
the client should be really lightweight and supporting incoming connections
is too much in such environment.
Sure, it wouldn't be appropriate for all environments, but the client
factory is plugable so if supporting a listener really causes issues
then its easy to also have a simpler factory that doesn't support
callbacks. But its not necessarily going to add much weight, the
client is remote from the domain so it already needs code to handle
the communication protocol, the callback listener wont add much more
over that. If its an http protocol and jdk6 then that already comes
with a built in mini http server.
Why don't you use an SCA composite/component if callback is required?
and you could go further on that path and say why have the SCAClient
at all and everything could be an SCA composite/component ;) Not
everyone and everything is SCA yet, the async programing model is one
of the interesting features of SCA and IMHO having things like this
client being able to support that would help people see the utility of
SCA before they've adopted it wholesale.
...ant
There is (now) another way for non-SCA code to receive callbacks
from SCA code. The public review draft of the WS Binding spec
defines a WS Binding Callback Protocol for which support is optional.
Any web service client could use this protocol to call an SCA
service and receive callbacks, as long as the service has a WS binding
and the SCA runtime supports this optional protocol. IMO this is a
better way to meet this requirement than making the SCAClient API
more complex by adding an optional callback listener.
Simon
