A test creates some inputs, supplies them to a function, retrieves the results, and finally consults an oracle to determine whether the results are correct. Depending on the function, any of those actions may be easy or difficult. You could argue that the design you described is simply a way to distribute the oracle between the test client and the parallel application. If you need to calculate expected results somewhere, why not in parallel application?
For a QA person who wants to be a developer job someday, it may be more interesting and fun to code the oracle as a web application. The design will give the QA person the opportunity to practice their coding and design skills, and perhaps even to prove their coding abilities to a development manager.
Nonetheless, I wonder about the wisdom of what you described. Your parallel application does more than just compute a correct answer; it must also behave like a web service. For example, before your parallel application computes a correct answer, it must listen for requests, parse a request, and perhaps fetch additional data from other sources like a relational database. And after computing a correct answer, the parallel application must encode the answer in a response and send it back to the client. If you really want to test the application, you must use entirely different software for all these operations; otherwise may miss bugs because your parallel application will have the same bug as your real application.
I suspect that the alternative -- to embed the oracle in the test client -- will be simpler. Simpler software is usually easier to understand and maintain and is less likely to have bugs. Perhaps you should consider that type of design instead.