That is very interesting. Apparently Jersey has a proxy client API as well.
There has to be some sort of state, even if it's as simple as maintaining that your user is authenticated. With this proxy client api, is it possible to have cookies automatically kept, and sent during each request? On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <[email protected]> wrote: > 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <[email protected]>: > > > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau < > [email protected] > > > > > wrote: > > > > > Hello > > > > > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <[email protected] > >: > > > > > > > Good day, > > > > > > > > I've had discussions with people that think JAX-RS should be used as > a > > > > replacement for technologies like EJB, for making n-tier solutions. > > Some > > > > of my main concerns about that would be... > > > > > > > > - JAX-RS is mainly a structured approach to solving the problem, and > > does > > > > not use OOD very well. > > > > > > > > > > Assuming you don't mix local EJB and JAX-RS which are very different > and > > > that EJB means there remote EJB. > > > > > > Since it does serialize the payload it is 1-1 with EJB(d), you have > more > > or > > > less the exact same constraints there. Then you can use different > format > > > over JAX-RS (JSON/XML obviously, but java serialization like EJBd too, > > and > > > more advanced formats too) > > > > > > > Yeah, I'm referring to remotable EJBs. > > > > > > > > > > > > > > - Having stateless remote calls is fine for certain types of data, > but > > > I've > > > > found stateful technologies remove a lot of boilerplate stuff. > > Combined > > > > with good OOD, the savings are even better. JAX-RS is intended to be > > > > stateless, so you'd be required to pass all of the state information > on > > > > each call. That requires a lot more thought, planning, and I think > > it's > > > > more prone to development errors, etc. > > > > > > > > > > Nothing prevents you to have a stateful JAX-RS endpoint, you just need > to > > > ensure your client maintains the session properly. > > > > > > > Yes, I know nothing prevents you, but the whole point of REST, is to be > > stateless, is it not? > > > > > > > Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet layer. > Then you do what you want. Stateless architectures are super nice for a lot > of reasons > but it is not bound to JAX-RS or EJB where the recommanded practise can be > to be stateless as well. > > > > > > > > > > > > > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if > EJB > > is > > > > better for enterprise software, I'd like to be able to articulate it. > > > Or, > > > > perhaps JAX-RS is best, and I'd like to be able to articulate that. > > > > > > > > > > > Technically both (remote EJB and JAX-RS) are globally the same in term > of > > > architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger and > > > more standard (you will find clients for all languages in 5mn, not for > > > EJBd). > > > > > > > I'm curious, how do you see EJB and JAX-RS as being the same > architecture? > > EJB has the capability of maintaining state, and obfuscates the remote > call > > entirely, while JAX-RS does not. As far as I've ever seen, it's up to > you > > to develop the boilerplate code to make the call, even when you're using > > JAX-RS 2 with the client api. I mean you could use something like > retrofit > > to make it sort of like EJB. > > > > > > Use CXF client factory then you will create a proxy from your JAX-RS > contract => you hide the JAX-RS calls behind an interface. It makes it more > or less the same as EJB excepted you replaced EJBException by > WebApplicationException: > > http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI >
