Hi Jan,
Thanks for your reply.
I just expanded the original question ( :) ) and my idea remained as was originally: that is, when incoming coupling and outgoing coupling has been diambugated in this manner, would you agree that the service can be basically modeled as all the main threads of execution (each main thread corresponding a public operation) plus any explicit child threads they might spawn. Whereas an asynchronous-operation's main thread returns immediately (e.g., an CompletionStage<T> instance), it would spawn an implicit thread by calling submit() on an executor. Just as a matter of convenience/simplicity, I do not count such a thread as a child thread and rather treat them as outgoing coupling ( submit() call on an executor). Of course, it might be considered as a child thread of the corresponding asynchronous main thread. Needless to say, upon completion, this thread calls complete() on, e.g., CompletionStage<T> instance it had already returned to the corresponding client.
correction: CompletionStage<T> and not CompletedFuture<T> as I wrote earlier :)
regards
Rupinder