Also, another aspect to all of this, is that we have a moderately sized application, which uses RMI for the business logic. Converting that to @Stateful EJB, would be a breeze, and we could really be confident it would continue working once we've gone through our testing cycle. I'm guessing that converting it to JAX-RS, could be very painful, error prone, and consume a lot of develop, test, fix, test, fix, test, fix, before we could even go live. Essentially, @Stateful EJB can literally have no code changes to the RMI code, except annotations, and it would work almost identically, except the authentication part of it.
Also, OpenEJB certainly adds some nice multicast distributed server capabilities. On Mon, May 30, 2016 at 2:02 AM, Trenton D. Adams <[email protected] > wrote: > 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 >> > >
