We implemented a web service from our java application (bottom-up). This worked well and we are able to integrate this web service with front-end client apps.
Now few of the client apps have come up with a new business scenario wherein they would pass multiple requests bundled as a collection in one fat request which effectively means we will have to handle this new request type via a new web service or a new operation within the same web service and trigger the main web service in a for loop (batch mode) for the number of entries in the collection (max=250), collate all the output and send it back to client web apps.
My question here is about calling the web service in batch mode. I tried to find some info on the same but could not find anything remotely close about batch calling of web services. Is it a common (good) practice to trigger web service in a batch type mode.
When you say "batch mode", I suspect you are referring to granularity, i.e. coarse-grained vs. fine-grained services, though I do realize that your new operation will process multiple records in a batch. As you know, this is pretty common. As a set of web services evolves over time, designing with the right granularity becomes more important. So, if I understand your intent, I would say that you are proceeding in the right direction. It is just plain old refactoring, in a different context. Any thoughts on this?
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.
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.