Hi!
Strictly speaking, it would be enough with a web service operation that takes a list of parameter entries, that in turn returns another list with responses.
This covers the special case of one single parameter entry as well as the "batch mode" in which the service is to process more than one single entry.
I think UDDI uses a similar strategy in certain operations on registries.
Regarding implementation:
It depends on the original web service and, to some extent, on the container in which the web service runs.
The simplest scenario is to use a loop that iterates over the parameter entries received and, for each of them, calls the original service implementation using a plain method call.
This has the drawback that all the processing will be done in one single
thread and may be unnecessarily slow.
If you are running in an application server or if your web service endpoint is an
EJB, then creating your own threads is not a good idea.
In such scenarios, you may want to implement the original service as a stateless EJB and the new service that accepts many parameter entries as another EJB.
The new EJB will call instances of the old EJB, of which there will be multiple instances and thus processing will be done in parallel.
Finally, if you are deploying your web service in a web container or a standalone server, then you may want to use a theadpool holding some number of worker threads.
For each of the parameter entries, you create a job (implementing Runnable) and place it in the queue of the threadpool.
There are other approaches related to this that does not use a threadpool, but some similar concept of having a number of workers that share the processing of the entire request.
Hope this is of any help!
Best wishes!
