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

From: Bill Burke <>
Date: Wed, 27 Jun 2012 12:08:24 -0400

On 6/27/12 11:40 AM, Sergey Beryozkin wrote:
> 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.

Ya, I don't get it. Since when is nesting distributed calls an

Bill Burke
JBoss, a division of Red Hat