You want a side effect which the client won't know about or control the success of? That is asynchronous processing, even if you return an immediate synchronous answer. If the results are observable and of interest to the client, you should have some way for clients and operators to determine whether it succeeded afterwards.
This hinges on how you host your web services (which is orthogonal from WCF providing a communications and activation layer). Normal web service hosting won't allow you process things outside the WS calls, mostly to prevent you from shooting yourself in the foot and eating all server resources.
- Under ASP.NET ASMX hosting, you can enter another task to the thread pool: however, this may be terminated without warning if server loads are excessive. We had to resort to this in a production service recently: luckily, the server host doesn't experience high loads. We're somewhat nervous about the reliability of this solution.
- I haven't worked with Windows Activation Services, but there should be a way of spawning additional work in a separate thread.
- You can always implement your own worker process, e.g. as a Windows Service, and submit work to it as needed. This is not extremely difficult, but requires a bit of work to do reliably and scalably. Not a favourite, and the kind of scenario WAS is intended to address.
Spawning another thread is easy, but isn't something IIS should permit you to do freely, especially if it's running in any sort of multi-application web hotel.