The simple answer is No. (At least not if it is exposed as a SOAP web service)
SOAP web services were never designed to be directly accessed via a browser. There always has been the expectation that the client application would build a SOAP request and place that request inside of an HTTP request - browsers were never designed to do that, they simply issue HTTP requests.
Originally posted by Ulf Dittmer: IF the WS is written in a RESTful style, and recognizes HTTP parameters.
Even that is debatable with the example given. In the Richardson/Ruby philosophy the HTTP parameters are part of the URI that names a linkable resource. Now that does work if a response is returned pretty snappily from the URI - even if it is sooooo RPC. However if a response can be so quickly "calculated" (rather than retrieved) then there must be some question whether this functionality actually classifies (in terms of granularity) as a service. A more general REST implementation might have you
POST the parameter data to http://www.example.com/user/myusername/processname and return a URI for your results (a new resource).
GET the result at (e.g.) http://www.example.com/user/myusername/processname/results/12345678. You would then get a 204 ("No Content") code if processing wasn't yet complete or a 200 ("OK") with the result representation.
Also a RESTful web service may use the full range of HTTP methods including PUT and DELETE which aren't usually supported by browsers. So to support manipulation-by-browser a properly designed RESTful web service may have to support a URI kludge (HTTP method tunneling in the query string or entity body):
When the browser issues: POST /user/myusername/processname/results/12345678?_method=delete
The service interprets it as: DELETE /user/myusername/processname/results/12345678
The good news it that a RESTful web service can be designed to serve multiple representations of the same resource. A browser might request:
and then get a nice human readable html page of the result. An application on the other hand could request:
and an XML version of the same results is returned in the HTTP response.
Properly designed RESTful web services use a broader range of HTTP protocol features than most browsers and for the time being the RESTful developer has to have a pretty good understanding of the HTTP protocol even more so than what would be expected of a competent web component developer (as web components serve their results only to browsers).
If you are interested in implementing a RESTful web service then I would recommend that you set JAX-WS aside for the moment and that you have a look at Restlet. JAX-WS focuses primarily on SOAP web services - REST web services were only of secondary importance when JAX-WS was defined. So it wouldn't surprise me at all if it would be simpler to build a proper RESTful web service (along the lines of RESTful Web Services (amazon US)) with Restlet which is dedicated to implementing RESTful web services rather than JAX-WS.