ant elder wrote:
On Fri, Jun 26, 2009 at 11:36 AM, Simon Nash<[email protected]> wrote:
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
Isn't saying the service could just use a WS binding similar to the
other suggestion of just using a SCA composite/component, in that you
could add a WS binding to any service and then use any regular WS
client so why then have the SCAClient at all?
>
I don't think it's the same at all. The WS Callback Protocol allows
any code that uses Web Services to interact with SCA callbacks.
There's no need for this code to run within an SCA runtime, as a
composite/component would have to do.
The SCAClient API is intended to provide a simple way of accessing
SCA services from outside an SCA domain. The important word is
"simple", which is why it doesn't handle things like policies,
binding selection, and callbacks. I think that's a reasonable
trade-off.
> I didn't really expect
this to get into the spec at this late stage, but i do still think it
would be a useful thing to support, so how about we use Tuscany as a
testing ground for it and try adding a TuscanySCAClient interface that
supports callbacks to try it out, you'd get a regular SCAClient and if
you want to do callbacks cast it to a TuscanySCAClient. If we can get
it to work and try it out for a while to see if it makes things
complicated or heavy weight, and if it works ok get it added to a
letter spec release.
I think we would be better spending our efforts on supporting all the
things that are in the OASIS specs, and getting Tuscany to pass the
OASIS compliance tests.
Simon
...ant
