Hi Steve, Is that all stateless then? You just pass your state each call?
On Sun, May 29, 2016 at 7:11 PM, Steve Goldsmith <[email protected]> wrote: > 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 >
