I interpret this in 3 ways -
First - You have a single message to publish in the publishing service
When you’re executing your flow service via Designer, you are doing it as single client - this is why you see sequential executions. In reality, source systems can post multiple sync/async requests in parallel, unless restricted by design/requirements.
Expose your service as a SOAP/REST API and use SOAP UI or Postman to post multi-threaded requests and you’ll see that IS handles them in parallel.
Second - You have a list of messages to publish within the same publishing service invocation
pub.jms:send is an async API (whereas sendAndWait is the sync one), so you can loop over the list elements and perform multiple sends. The point about using multiple source clients applies here as well, further expanding parallel processing.
Third - Having said the above, implementing multi-threading WITHIN your flow service is also possible, but it’s a rare requirement and the aforesaid options should suffice for most scenarios. See the Java API for the Service class, here (link). The caveat is that you need to know exactly what you’re doing and the limitations of your environment.
Common Element - In all the above cases, you will achieve true end-to-end concurrency only when your subscribing trigger is also set to Concurrent with the desired number of threads (>1).