[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 16:43:08 -0400

Whether or not you are allowed to open a socket is irrelevant. Servlets
have always been allowed to make remote EJB- RMI, IIOP, or SOAP
invocations. I don't see how an HTTP client API is any different.
JAX-RS *IS* a Java EE specification. And since it is a Java EE
specification the application server can control and manage client HTTP
  connections in a predicable manner just as it does for EJB clients,
jms clients, jdbc clients, ...

On 6/27/12 1:44 PM, Markus KARG wrote:
> Well, in fact nobody says that it should be forbidden. The question was
> whether the spec must explicitly allow it, as opening sockets IS explicitly
> forbidden by the Java EE spec already.
>> -----Original Message-----
>> From: Bill Burke []
>> Sent: Dienstag, 26. Juni 2012 23:57
>> To:
>> Subject: [jsr339-experts] Re: Server sided use of JAX-RS client API:
>> Valid in which server sided components?
>> 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.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat

Bill Burke
JBoss, a division of Red Hat