I've built a scalable solution using EJB/JAX-RS/JAX-WS. I put the business logic in EJBs that are called from JAX-RS services. The EJBs are JAX-WS and JAX-RS clients. I use JMS for asynchronous operations and the rest of the services are synchronous. It performs very well in the 100K+ to 1M+ transactions a day with a couple VMs. Depends on the latency of the business logic.
I also use JCache to persist user data for fast access. I maintain state in a distributed cache, so no dealing with sticky sessions behind a load balancer. I can take a node down, do a deploy and the cache will sync before I deploy the next node. On Sun, May 29, 2016 at 2:57 PM, Trenton D. Adams <[email protected] > wrote: > 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. > - 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. > > 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. > > What sorts of other criteria would you use, in choosing a solution? > > Thanks. > -- Steven P. Goldsmith
