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
>