Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jersey-dev] Incoming Coupling and Outgoing Coupling of a Service 
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

Back to the top