The transition / staging phase of a web service application's life-cycle usually involves tests of the endpoints.
Depending on the reason why a web service application is in a staging environment, different kinds of tests are performed. This might also vary according to the enterprise testing practice, however it should be stressed that the purpose of this phase's tests usually goes beyond that of the development phase (i.e. having a running application according to the given requirements). That's because it involves quality of data, integration with customers' remote systems and so on.
The way QA tests are performed changes according to the project scope and domain. Given that a web service application is running fine from a developer point of view, large projects usually require QA testers and business analysts to check whether the system behaves correctly from a quality of data point of view. This include testing endpoints with boundary condition input data that business analysts only know.
Developers might feel comfortable with Java test cases or IDE tools; unfortunately those means of testing might be too difficult to be used by non-technical guys like QA testers. Allowing them to perform web service invocations on their own without support from developers may help performing the whole test process more quickly.
Generic web service invocation tools should be used for this; for example WISE is an open source JBoss Seam application that leverages JBossWS tools. It allows users to dynamically invoke services using a web interface without even having to deal with XML. QA testers just need to feed Wise with the URL to the wsdl file, then the web interface will guide them through the operation and parameter selection. Requests and responses are shown in a graphical way so that no web service related technology is required to get and check data.
Another reason that usually brings web service applications to the staging environment is the need for integration and interoperability tests. When dealing with issues emerging only during communication with customers' remote endpoints, being able to re-invoke our own service with the request that caused the problem (perhaps after some small changes) might be extremely handful. This speeds up the resolution of integration issues since it decreases the required cooperation between remote development teams.
Eviware's soapUI is a great testing tool allowing users to do a lot of interesting stuff with web services; in particular it is possible to easily send custom SOAP messages to endpoints and check the resulting message. SoapUI is a standalone desktop application and has a free and open source version.