On Jun 27, 2012, at 10:43 PM, Bill Burke wrote:
> 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, ...
+1
Marek
>
> 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 [mailto:bburke_at_redhat.com]
>>> Sent: Dienstag, 26. Juni 2012 23:57
>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>> 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
>>> http://bill.burkecentral.com
>>>
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>