You can use Lingo to cluster your POJO services across a number of different JVMs. Lingo will then provide

  • load balancing across each server
  • High Availability; if a server fails for whatever reason the pending requests are automatically dispatched to another server.
  • loose coupling between clients and services in terms of location and time
    • you can send one-way requests which can be persisted until the back end services are available
  • traffic shaping - you can use JMS wildcards and selectors to shape the traffic
    • e.g. have a rack of servers which only process gold customers using a JMS selector to filter them out

How it works

Lingo relies on the underlying JMS provider to implement the load balancing and HA. So you can use all the benefits of the JMS provider like wildcards and selectors with the message exchanges.

Typically Lingo uses JMS Queues; the servers consume request messages from queues. Typically clients use temporary queues, sending on the server queue and setting the JMSReplyTo destination to allow the server to reply.

Multiple servers can consume messages on the queue concurrently in different threads and JVMs; so the JMS provider can provide load balancing across the server instances.

ActiveMQ specific configurations

If you are using ActiveMQ as your JMS provider there are a few extensions you can use...

Sticky load balancing

ActiveMQ supports Message Groups which basically provides a form of stick load balancing and auto-failover for consumers of a queue. The standard JMS header JMSXGroupID is used to group messages together that should be processed by the same service instance (i.e. POJO).

If a service is marked as being conversational using annotations then Lingo can automatically generate a JMSXGroupID header so that ActiveMQ can perform sticky load balancing.

Peer transport and/or embedded brokers

Using the peer transport or deploying embedded brokers inside servers means that there is no extra network hop when using Lingo do implement remoting. Normally there would be 2 extra network hops for a request-reply message exchange if the JMS broker is deployed in a different JVM to the client and server.

Powered by Atlassian Confluence