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 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> 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
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

Back to the top