Web Service vs Web Application
If we think the terminology, which I think is the main question here.
Web service refers to software, that serves data in any format (XML/JSON etc.) through some kind of web interface. That interface can be called API (Application Programming Interface). REST and SOAP are ways to design the API.
Application is the software that is using this API provided by the web service.
In the other words, web service is "server" and application is "client". Usually server serves machines and clients serve the user.
So in any way you choose to build your system, I would call the part that serves the data as "Web service" and the part that utilizes the data as "application" (or "web application" if such).
Sounds like in your case, you are building a web service that provides XML-formatted data for multiple applications. So my answer is: build the thing you are already building and call it web service.
My question is that same can be achieved by a simple web app accepting the request in XML format and responding with an XML response.
That is a web service. I think this is an issue of terminology. You have no way of solving this other than to use a web service, whether it is restful or SOAP based is up to you but if you are passing data to clients in XML format, in response to XML requests, that is a web service.
I suspect what you mean to ask is whether or not you should be using a RESTful webservice or a complicated SOAP based approach. For me the answer depends on how many functions are needed in your 'Service'.
SOAP
If your service has lots of functions than users of java and/or visual studio would prefer to import your WSDL file and use your service as an object with all of the XML parsing done for them, so SOAP would be the answer.
REST
If you only have a few functions, with very basic input parameters and response data, then SOAP might be overkill.
MySite.com/Add/5/3
or
MySite.com/GetStockSymbol/Facebook
or
MySite.com/GetWeather/Paris/France
If your application doesn't need a user interface, then make it a web service. If it needs a user interface, then use a web application.
At a low level web applications and web services are kinda the same thing. They both operatate over http(s). SOAP is just a well defined version of XML. REST is kinda just HTTP. If you wanted to, you could make a web application look like web services and visa versa.
The main difference would be internal development options based on the platform you are using. If, for example, you are using Visual Studio then adding a WCF Service Application will give you a project which is by default geared towards WCF. But choosing any other application type won't stop you from adding Web Services.
Using SOAP is generally a better option than plain old xml for these reasons:
Your users will be expecting it, and are likely to know how to read it already.
Your users' development environments will likely know all about SOAP and be able to interpret it out of the box. (If you provide a WSDL file then many users will be able to use a script to generate your classes in seconds.)
Your messages are more likely to be well defined. I am working on a project at the moment where the other side have defined their own random XML structure and it is a nightmare to work with. I never really know what to expect, and there is little consistency between their different message types. At least if they had agreed to conform to SOAP then I might have had a much easier time interpreting their messages.