I am working in an enterprise project and my team is responsible for creating front end of the application and there is another team developing webservices and has provided WSDL for all the services that will be available as part of this project. In development phase our local dev environment will point to one of the development box of the team responsible for creating web services. It is quite possible that their dev environment will be shaky in middle of iteration. In order to mitigate that risk, we are using SOAP UI on our local machine and start mocked service and do the development. Whenever we need different flavors of response we modify the local service response XML. This process is running good but i was wondering if there is a way that for each service say i create 10 responses and deploy them as a war on tomcat on one of the machine and my whole development team points to that war which will expose the same service and based on a parameter it can send one response out of the 10 responses bundled in war. i don't want to spend any effort on this. Is there a tool which provides this kind of functionality out of the box.
It would make your life easier if you split up your internal architecture a bit. Instead of inflexibly letting the client code rely on an external SOAP service, it would be beneficial to define an interface for internal use. You could call this IServiceProxy or some such name.
Let the client code talk to that interface and use Dependency Injection (DI) to inject an instance of it into the client. This means that for a lot of development usage, you can simply replace this interface with a Test Double (e.g. a Mock).
If you must also have a SOAP service to verify that your SOAP stack works as intended, watch out for the so-called Shared Fixture test smell. A shared 'test' service on a single server would be a Shared Fixture, and it is likely to give you more trouble than it's worth because developers would be stepping over each other and it would be a bottleneck.
A better alternative is to set up a SOAP service on each developer's machine, or, if that's not possible, a dedicated service for each developer.
You can read more about Shared Fixtures and many other test patterns and anti-patterns in the excellent xUnit Test Patterns.