I depends on the service. Some use MAC addresses, some use customer GUIDs as keys. Typically I cache expensive calls and use the key to retrieve from cache (thus you only pass the key, not everything that goes with it each time). Since the cache is distributed and the VMs are behind a load balancer it's highly available and scalable.
On Mon, May 30, 2016 at 1:46 AM, Trenton D. Adams <[email protected] > wrote: > 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 > > > -- Steven P. Goldsmith
