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 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. ...ant
