Andrew Clegg wrote: > > > Well, 'simpler' is pretty subjective. I personally wouldn't design any > of my web services so that only another server could access them -- > which is what your solution implies. But then I'm building services > for public consumption, and the client might be a few lines of Perl or > Python, or a desktop workflow management app like Taverna, for > example. If they can only get the results out of my service by running > another service themselves, well that's most of my users gone. > > But if your usage scenario means that you know exactly who the client > is, and you're using web services primarily for peer-to-peer > communication between server machines anyway, then maybe it is no less > hassle to have a web service on each end. > > Andrew. >
I agree. My web services are not for public consumption. They would be called by clients that register themselves with the messaging gateway. The registration is dynamic though. Hence, there wouldn't a static list of clients. Everytime a new client comes into existence, it would register itself and start calling the web services. The callback would be communicated to the server as part of the registration process and it is a one time thing. From then on, the client side web services would be called everytime a message of interest appears in a JMS destination on the server side. -- View this message in context: http://www.nabble.com/Asynchronous-Web-Services-using-AsyncHandler-tp19520451p19538149.html Sent from the cxf-user mailing list archive at Nabble.com.
