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) > - 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. > > 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). > What sorts of other criteria would you use, in choosing a solution? > > Speed can be one, EJBd maintains connections in a more performant way than HTTP once configured in this mode. Discovery of servers can be another advantage if needed (multicast/multipoint). > Thanks. >
