users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Server sided use of JAX-RS client API: Valid in which server sided components?

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Wed, 27 Jun 2012 16:40:27 +0100

Hi Jan
On 27/06/12 10:10, Jan Algermissen wrote:
>
> On Jun 26, 2012, at 11:57 PM, Bill Burke wrote:
>
>>
>>
>> On 6/26/12 5:41 PM, Jan Algermissen wrote:
>>> Hi Markus,
>>>
>>> On Jun 16, 2012, at 3:50 PM, Markus KARG wrote:
>>>
>>>> Experts,
>>>>
>>>> some weeks ago we discussed server sided use of the new JAX-RS client API, e. g. to pull information from an external RESTful web service.
>>>>
>>>> As I remember, at least for EJBs (SBs, MDBs) it is forbidden to use blocking operations, threading operations, files API and sockets API. All this for the sake of stability and security.
>>>
>>> Yes, this is a good question because it is too easy to assume you could just chunk up a larger system into HTTP services and fire calls between the services all over the place.
>>>
>>> In my opinion, serving an HTTP request must not involve an upstream HTTP call unless in the case of relatively infrequent requests (e.g. order submission) or unless a local cache is very well known to have a sufficient hit ration.
>>>
>>> Turning every user request into a (cascade of) upstream HTTP requests is not really what we want. This statement is not as ridiculous as it sounds because software architects and consulting firms come up with such designs all over the place :-) ... or, well, rather :-(
>>>
>>> I am not sure how a container could 'enforce' anything here, but IMHO HTTP-servers-as-clients is as much a container issue as transactions are.
>>>
>>> Ideas?
>>>
>>
>> So you're saying using the client API within a server should be forbidden? We're talking about distributed systems here, not one-off Web UIs.
>>
>
> Well, it depends :-)
>
> The characteristics of an HTTP request are different from, e.g., a database access. Especially because HTTP communication (if done RESTfully) might involve several requests (redirects, following links etc.).
>
> Encouraging developers to build such an upstream access into their request handing code seems wrong. But forbidding the use does also not quite cut it.
>
Makes sense
> I cannot see a sensible solution at the moment.

Solution for what ? I think supporting the client invocations in the
context of the service request is simply to do with making a tool for
the job available when it is actually needed.

Cheers, Sergey

>
> Jan
>
>
>
>
>
>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>