JBoss EAP 6 Clustering Reference Architecture

JBoss Enterprise Application Platform 6 (EAP 6) is a fast, secure and powerful middleware platform built upon open standards and compliant with the Java
Enterprise Edition 6 (Java EE) specification. It allows horizontal scaling by distributing the load between multiple physical and virtual machines and eliminating a single point of failure.

Want to learn how to stands up two EAP 6 Clusters, each set up as a separate domain, one active and another passive, to eliminate any downtime due to maintenance and upgrades ?

jboss-eap6-clustering-reference-architecture

Red Hat Reference Architecture Series (@RedHatRefArch) announced the availability of a new reference architecture for you!

Download JBoss EAP 6 Clustering reference architecture.

This reference architecture demonstrates EAP 6 Cluster capabilities, including replication of various session types, configuration and setup. Several technologies are covered, including:

  • Red Hat’s JBoss EAP 6.1
  • Apache Web Server
  • HTTP / Stateful session replication
  • JPA 2nd level cache
  • HornetQ cluster and CLI

Automated Java/CLI scripts are used to automatically build out two clusters of three nodes, each as a managed domain. Each node includes one live and two backup HornetQ servers using message replication to provide redundancy. Cache invalidation enables second-level caching of JPA entities, while session replication is used for HTTP and stateful session beans.

In the meanwhile, WildFly 8 is coming along well and will provide full Java EE 7 compliance. It will be released in the next few weeks. Now is a good time to download WildFly and try your applications on it. A subsequent version of WildFly will be the basis for JBoss EAP 7.

Tech Tip #1 shows you how to get started with WildFly. github.com/arun-gupta/javaee7-samples provide a comprehensive set of Java EE 7 samples that run on WildFly. And if you are interested in creating tests for these samples, follow the steps in Devoxx 2013 Hackergarten and send a pull request.

JBoss EAP enables you to consume open source software with comfort. Use open source today with the reliance that a commercial support will be available when you need it!

Be Sociable, Share!
  • Tweet

4 thoughts on “JBoss EAP 6 Clustering Reference Architecture

  1. Thanks for this guide!

    I have a question concerning clustering of stateless EJBs. As far as I gather from a first glance at the guide requests from EJB-Clients are not routed through the load-balancing EAP HTTP-server.
    Is that correct?

    So, how is proper load-balancing for requests to stateless EJBs realized? As far as I know the EJB-Clients are implementing a simple round-robin algorithm to distribute the requests to the different nodes in the cluster.
    Is that correct?
    In this case we would not have proper load-balancing in the sense that requests go to the nodes that have the least load.
    As far as I understood load-balancing for the http-requests would be properly load-balanced through the EAP HTTP-server which knows the load of the EAP cluster nodes through AJP.
    We do not get this advantage for stateless EJBs in this setup. Or I am missing something?

    Thanks for any clarification.

  2. Hi Jonas,

    That’s correct. Clustered remote EJB clients use a client based node selection mechanism to handle distribution, which is unlike a traditional http load balancer that relies on a central redirection point. Remote EJB connections also are multiplexed, and sticky since they are intended to be long lasting.

    However, if you wanted, you can actually provide your own node selector to implement an intelligent connection balancing scheme. Although, if you want server load to be a distribution factor, that requires shipping that data via some custom mechanism to every client (e.g using the custom protocol extension spi). That may or may not be acceptable depending on the number of clients.

    Another option is to expose your EJB using JAX-RS, which allows you to take advantage of HTTP style load balancing. This also has the benefit of supporting non Java clients.

    As to the future, WildFly 8 now uses HTTP as the initial connection point for EJB and other remote protocols. The connection is then converted via HTTP upgrade to the native binary protocol. We plan to expand our revers proxy capabilities to allow you to load balance these upgraded connections via a mod_cluster style mechanism. Finally we have had a few requests for request centric (vs. connection centric) balancing, and will be exploring future enhancements in this area.

  3. @Jason

    Thanks a lot for this clarification.
    The development in WildFly sounds really interesting.
    On the other hand I wondering if EJB-Remoting is rather a dying technology…

  4. Valuable info. Lucky me I discovered your web site accidentally, and I am shocked why this coincidence didn’t happened earlier!
    I bookmarked it.

Leave a Reply

Your email address will not be published. Required fields are marked *