Re: [jersey-dev] Incoming Coupling and Outgoing Coupling of a Service

[Rupinder Singh <rupi.pal@xxxxxxxxx>]

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

On Tue, Aug 4, 2020 at 5:11 PM Jan Supol <jan.supol@xxxxxxxxxx> wrote:

Hi Rupinder,

This sounds like you have answered your question. But if you have
another query, feel free to ask.

Thanks,

Jan

On 03.08.2020 19:36, Rupinder Singh wrote:
> Hi Jan,
>
> Thanks for taking interest and replying!
>
> I did refer to JAX-RS JSR previously and as and when required,
>
> Bucek, P. & Pericas-Geertsen, S. (eds.), JAX-RS: Java™ API for RESTful
> Web Services, Version 2.1, Final Release, July 13, 2017, Oracle Corp., US
>
> I will reframe my question as follows.
> Ultimately, whenever a user request is received, even if the request
> is for a sub-resource returned by a locator, only a root resource
> class is instantiated and a thread assigned to the request by the
> JAX-RS runtime. The responsibility of instantiating non-root-resource
> classes, including sub-resources returned by a locators, is on this
> thread by class-loading and the corresponding calls are  inlined (as
> Java would do; that is, are not function-calls). In other words, the
> main thread continues. Whatever is inlined is not outgoing coupling.
> All injected dependencies are separate threads and are not inlined and
> thus constitute outgoing coupling of this thread.  The responsibility
> of these threads of execution lies with the respective
> runtimes/containers. From the user viewpoint, a JAX-RS application is
> this single main thread and explicit child thread(s), if any spawned.
> The user invocation is the incoming coupling via service interface.
> This visualization helps me identify incoming and outgoing coupling of
> the service.
> In the case of asynchronous invocation, the method returns immediately
> (e.g., CompletedFuture<T> ) after spawning a thread (implicit) to
> handle asynchronous computation. I have just simply kept out implicit
> threads from my visualization.
>
> I hope I could clarify.
>
> Regards
> Rupinder
>
>
> On Monday, August 3, 2020, Jan Supol <jan.supol@xxxxxxxxxx
> <mailto:jan.supol@xxxxxxxxxx>> wrote:
>
>     Hi Rupinder,
>
>     I do not understand the question, but will try to answer. You can
>     have synchronous and asynchronous services. For synchronous, the
>     thread is provided by the servlet container (if any) and by
>     default, for each http request a new instance of resource class is
>     created, so possibly a new thread can process the new http request.
>
>     For asynchronous services, more threads are involved. The new
>     threads can be spawned by the resource method code (not
>     recommended) or can be provided by ManagedExecutorService and
>     perform some long pending operation in background. You may either
>     return CompletableFuture which will use the executor service
>     (thread) to complete the operation, or you can use @Suspended
>     annotation and resume the provided AsyncResponse in the new thread
>     once the operation is done. See JAX-RS Spec. Section 8.2 for more
>     details.
>
>     Did it answer your question?
>
>     Thanks,
>
>     Jan
>
>     On 03.08.2020 6:20, Rupinder Singh wrote:
>
>         Hi,
>         I am trying to get an answer to a question in relation to my
>         academic research on SOA with JAX-RS as an example
>         implementation technology. Could you help? The question is,
>
>         Can we consider a JAX-RS service as basically the main threads
>         and explicit child thread(s), if any, of the public resource
>         methods of its root resource class with all incoming coupling
>         (dependencies) via service interface and all outgoing coupling
>         emanating from these threads?
>
>         Thanks and regards
>         Rupinder
>
>         _______________________________________________
>         jersey-dev mailing list
>         jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
>         To unsubscribe from this list, visit
>         https://www.eclipse.org/mailman/listinfo/jersey-dev
>         <https://www.eclipse.org/mailman/listinfo/jersey-dev>
>
>     _______________________________________________
>     jersey-dev mailing list
>     jersey-dev@xxxxxxxxxxx <mailto:jersey-dev@xxxxxxxxxxx>
>     To unsubscribe from this list, visit
>     https://www.eclipse.org/mailman/listinfo/jersey-dev
>     <https://www.eclipse.org/mailman/listinfo/jersey-dev>
>
>
> _______________________________________________
> jersey-dev mailing list
> jersey-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev
_______________________________________________
jersey-dev mailing list
jersey-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jersey-dev