<?xml version="1.0" encoding="UTF-8"?>
<section version="5.0" xml:lang="en" xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:xi="http://www.w3.org/2001/XInclude"
         xmlns:svg="http://www.w3.org/2000/svg"
         xmlns:mml="http://www.w3.org/1998/Math/MathML"
         xmlns:html="http://www.w3.org/1999/xhtml"
         xmlns:db="http://docbook.org/ns/docbook">
  <info>
    <title>Load-balancing and high availability</title>
  </info>

  <section xml:id="principles.farming.scalability">
    <info>
      <title>Farming for scalability</title>
    </info>

    <para>The scalability of a system lies in its capacity to evolve in power by adding or removing software and
    hardware elements without impact on its architecture.</para>

    <para>The scalability aims at adjusting the system bandwidth to fit with the performance needs of the service.
    It is achieved by replicating the resources within a farm according to the input requests load.</para>

  </section>

  <section xml:id="principles.farming.availability">
    <info>
      <title>Farming for availability</title>
    </info>

    <para>Farming provides a first level of availability: when a resource failure occurs, the request will be
    submitted again (fail-over mechanism) and will be routed towards another resource. In this case, the failure is not transparent to
    the user whose request is processed by the failed resource. But the service is not interrupted as
    the user can restart its operation. For the users whose requests are processed by other resources within the farm,
    the failure will be transparent and the only impact will be the response time due to load distributing
    among a smaller number of resources.</para>

  </section>

  <section xml:id="principles.clustering">
    <info>
      <title>Clustering for high availability</title>
    </info>

    <para>The high availability of a system lies in its capacity to serve requests under heavy load and despite
    any component failure.</para>

    <para>A highly available architecture contains some replicated elements. The number of replicas determines
    the number of simultaneous failures the system is able to tolerate without interruption of service. According
    to the fail over implementation, the service may be damaged during a short period. This service malfunction
    may impact users at different levels.</para>

  <para>Replication mechanisms contribute to the continuity of service and enable to mask the resources failures to the users
   (or at least to minimize their visibility). Such mechanisms do impact the system sizing as they consume more resources
   or for a same sizing do impact the global performance.</para>

  </section>

  <section xml:id="principles.web.farm">
    <info>
      <title>HTTP/WEB farm</title>
    </info>

    <section>
      <info>
        <title>Rationale</title>
      </info>

      <itemizedlist>
        <listitem><para>Ensuring the scalability of a web application</para></listitem>
        <listitem><para>Improving the availability of a web application (without session replication)</para></listitem>
      </itemizedlist>

      <para>HTTP farming consists in distributing the processing load across <emphasis>N</emphasis> JOnAS instances.
            The same application is deployed all over the cluster and a request may be processed by any instance.</para>

    </section>
    <section>
      <info>
        <title>Principle</title>
      </info>
      <para>A load-balancer is setup in front of the JOnAS instances. The intermediate device
            handles the site url in order to mask the JOnAS instances multiplicity to the users. The load-balancer
            supports the HTTP session affinity in order to route a client towards the server hosting its session.</para>

      <para>A load-balancer may be a software or a hardware device or a mix of two. The application server instances
            may be collocated on a same machine or may be distributed across several machines.</para>

      <para>The intermediate device may be duplicated for avoiding a SPOF.</para>

      <para>Hereinafter the figure illustrates a HTTP farm composed of a L4 switch, 2 Apache servers and <emphasis>N</emphasis> JOnAS instances.
        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/httpfarm.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
      </para>
      <para>
        The Apache server is configured with the mod_jk plugin for ensuring the load-balancing between the JOnAS instances
        and the session affinity through the AJP protocol. Furthermore mod_jk supports the failover when a server crashes. The Apache server may be
        used for caching the static pages, performing compression or encryption and, thus, can reduce the application servers
        load.
      </para>
      <note><para>
        From Apache 2.2, mod_proxy_balancer is alternative to the mod_jk plugin. It supports AJP protocol but also HTTP and FTP.</para>
      </note>
      <para>
        The number of JOnAS instances must be determined according to the expected performance.
        The Apache server being a SPOF, it should be duplicated and a network device distributes the load at the TCP level
        between them. Of course the network device should be replicated as well (primary/backup mode).
      </para>

    </section>
    <section>
      <info>
        <title>Use case</title>
      </info>
      <para>HTTP farming is very common and widespread. It fits well with the more frequent requirements in terms
      of scalability and availability. Furthermore, this architecture pattern can be used for implementing a
      cluster of web service providing that the web service is standard and is stateless.</para>

      <para>When the application server tier gets a bottleneck, this architecture enables to improve the performance
            by adding some JOnAS instances.</para>

     <para>The application server may be unstable, in particular under heavy load. This architecture enables to
           improve the availability by reducing the impact of failures. However the failures are not transparent
           to the users who are connected to the in-fault server since they lose theirs sessions. To be note that
           after a crash, the load is distributed between the survivors servers what may impact the performance.</para>

    </section>

  </section>

  <section xml:id="principles.web.cluster">
    <info>
      <title>HTTP/WEB cluster</title>
    </info>

    <section>
      <info>
        <title>Rationale</title>
      </info>

      <para>HTTP clustering is used when service continuity of web application is expected and when failures must be
      transparent for the users. It consists in replicating the HTTP sessions on <emphasis>P</emphasis> JOnAS instances
      among <emphasis>N</emphasis>.</para>

    </section>
    <section>
      <info>
        <title>Principle</title>
      </info>
      <para>The session context is replicated across a replication domain. Domain members are met through a multicast based protocol.
      The session replication takes place through point to point protocol (TCP based) and the replication mode can be synchronous
      (the user response is sent after the replication) or asynchronous (the user response is immediate and the replication is delayed).</para>

      <para>Hereinafter the figure illustrates cluster with 4 JOnAS instances behind an Apache server. Requests are load-balanced across the 4
      instances . The jk connector handles the session affinity and ensures that all the requests related to one session are routed towards the same
      instance. 2 replication domain are defined and each session is replicated on 2 JOnAS instances hosting by 2 different nodes for ensuring
      not to lose a session when a crash node occurs.
        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/httpcluster.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
      </para>
      <para>
        The Apache server can be duplicated for avoiding a SPOF.
      </para>
      <para>
        Such a configuration lies both in the Apache/jk elements (related to the load-balancing) and in the JOnAS instances (related to
        the session replication).
        <itemizedlist>
          <listitem><para>At the jk level, a load-balancer worker is defined with 4 AJP workers. Session affinity is set and two domains are configured.</para></listitem>
          <listitem><para>At the JOnAS level, the <filename>tomcat6-server.xml</filename> file defines an AJP connector, a jvmRoute attribute set to a hosting domain and
          a cluster element for the replication. To be noted that the web application meta-data must be defined as distributable through the <literal>distributable</literal>
            element.</para></listitem>
        </itemizedlist>
      </para>
      <note><para>
        From Apache 2.2, mod_proxy_balancer is alternative to the mod_jk plugin. It supports AJP protocol but also HTTP and FTP.</para>
      </note>

    </section>
    <section>
      <info>
        <title>Use case</title>
      </info>
      <para>HTTP clustering must be used only when the HTTP session loss is not acceptable. A server failure is visible only for the connected users who have an on-going request processed by the failed instance.
      The fault will be transient, the request will be sent towards another server which hosts a backup of the session.</para>

      <para>The HTTP session replication impacts the performance and causes an overhead on the system resources consumption (memory. network, cpu). Moreover, the replication
      in a synchronous mode induces an extra latency.</para>

      <para>For reducing the performance impact, it is recommended to use a dedicated network interface for the HTTP session replication (separated from the AJP requests) and to limitate
      the replication across 2 JOnAS instances (replication domain).</para>

    </section>
  </section>

  <section xml:id="principles.ejb.farm">
    <info>
      <title>EJB farm</title>
    </info>

    <section>
      <info>
        <title>Rationale</title>
      </info>

      <para>EJB farming aims at providing:</para>

      <itemizedlist>
        <listitem><para>scalability of the EJB tier</para></listitem>
        <listitem><para>availability of the EJB tier (without session replication)</para></listitem>
      </itemizedlist>

      <para>EJB2 and EJB3 farming are supported by JOnAS.</para>

      <para>The EJB tier duplication is not visible for the client.</para>

    </section>
    <section>
      <info>
        <title>Principle</title>
      </info>
      <para>EJB farming relies on the CMI component which enables clustering on top of different RMI protocols such as
            <emphasis>jrmp</emphasis>, <emphasis>iiop</emphasis> or <emphasis>irmi</emphasis>.</para>

      <para>When a client program intends to access an EJB, it invokes a JNDI registry lookup for getting an EJB home or EJB remote proxy.
      In an EJB farm, the CMI registry is replicated in order to provide a cluster view to the client. The cluster view represents a
      a list of JOnAS nodes hosting the EJB with additional clustering meta-datas. The replication and the
      group membership rely on the JGroups's group communication protocol. The cluster view is updated dynamically
      through a control channel and a dedicated control thread in the client JVM. The CMI client proxy ensures the load-balancing and the
      fail-over of the EJB invocations.</para>

      <para>In the clustering meta-datas, the cluster logic defines both the load-balancing and fail-over algorithms.
      The cluster logic can be customized. A set of default policies
      are provided with CMI: round-robin, first available, random, etc... For each one, a strategy can be added, for example,
      local preference (for dealing with the collocated mode)
      or weighted round-robin (for adding a weighting).</para>

      <para>Hereinafter the figure illustrates a EJB farm in a 2 tier architecture with both web client and java client.
        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/ejbfarm.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
      </para>
      <para>
        The Apache server is configured with the mod_jk plugin for ensuring the load-balancing between the JOnAS instances
        and the session affinity. Two JOnAS instances (1-2) host the presentation layer and are configured with a servlet
        container. Two JOnAS instances (3-4) host the business layer and are configured with an ejb container. The CMI registry
        is replicated across the cluster members in order to share informations about EJBs deployment and topology. Both servlet
        and java clients do access to EJB and do benefit from load-balancing and availability. In the case of a SFSB (stateful session bean),
        the EJB is created only in one instance and the state is lost if the JOnAS instance crashes, state replication is addressed in
        <xref linkend="principles.ejb.cluster" />.
      </para>
      <para>
        The JOnAS instances number must be determined according to the expected performance.
      </para>

    </section>
    <section>
      <info>
        <title>Use case</title>
      </info>

      <para>This architecture pattern is used either when the ejb tier is separated from the web tier and/or when ejb client are fat java programs.</para>
      
    </section>
  </section>
  
  <section xml:id="principles.ejb.distrib">
    <title>EJB distribution</title>
    
    <section>
      <title>Rationale</title>
      
      <para>EJB distribution aims at deploy a JavaEE application which is distributed on many JOnAS instances.</para>
    </section>
    
    <section>
      <info>
        <title>Principle</title>
      </info>
      
      <para>EJB distribution also relies on the CMI component.</para>
      <para>
        Without CMI, EJB needs to be modified to allow invocations on the remote EJBs, for example by setting the Context.PROVIDER_URL
        of the remote registries or by using the specific features of the IIOP protocol. With CMI, EJB can continue to access to the remote EJBs
        as if they were locally deployed.
      </para>
    </section>
    
    <section>
      <info>
        <title>Use case</title>
      </info>
      
      <para>
        This architecture pattern is used on the EJB tier.
      </para>
      
    </section>
  </section>

  <section xml:id="principles.ejb.cluster">
    <info>
      <title>EJB cluster</title>
    </info>

    <section>
      <info>
        <title>Rationale</title>
      </info>

      <para>EJB clustering is used when service continuity of ejb application is required and when any failure must be
      transparent for the users. It relies on the stateful EJB replication and manages the transaction in order to:

        <itemizedlist>
          <listitem><para>ensure that the replicated system do have a similar behavior of the not replicated one,</para></listitem>
          <listitem><para>in case the client doesn't abort, the transaction is executed exactly once, and no more than once otherwise.</para></listitem>
        </itemizedlist>
      </para>
    </section>
    <section>
      <info>
        <title>Principle</title>
      </info>
      <para>The EJB replication relies on
        <itemizedlist>
          <listitem><para>a mechanism for replicating the state of the EJBs and the business methods invocation return values. This mechanism
            is provided by the HA service and different implementations do exist (JGroups) or are under development (Terracotta, Pair replication);</para>
           </listitem>
          <listitem><para>a mechanism for marking the transaction in a persistent database. The information is used at the fail-over time to determine
            whether the transaction was aborted and whether the request must be replayed.</para></listitem>
          <listitem><para>a smart proxy in charge of redirecting the client calls towards another replica when a failure occurs.</para></listitem>
        </itemizedlist>
      </para>
      <para>An EJB is replicated only if it is specified as replicated in the component meta-datas (annotation and/or deployment descriptor).</para>

      <para>A stateful ejb is created on a JOnAS instance selected according to a load-balancing algorithm (default is round-robin). After the creation
      all the business methods invocations are routed to this JOnAS instance unless a failure occurs.</para>

      <para>Hereinafter the figure illustrates a EJB cluster.
        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/ejbcluster.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
      </para>
      <para>
        Each JOnAS instance of the EJB tier is configured with the HA service in charge of the session replication. CMI client API supports
        fail-over for both EJB2 and EJB3.
      </para>
     </section>
    <section>
      <info>
        <title>Use case</title>
      </info>
      <para>This architecture pattern is recommended when the application contains some stateful EJB and doesn't tolerate
      any session loss and any interruption of service. However the user must be aware that this kind of setting does impact
      highly the performance as the session is replicated between the JOnAS server at each method call.</para>

    </section>

  </section>

  <section xml:id="principles.jms.farm">
    <info>
      <title>JMS farm</title>
    </info>

    <section>
      <info>
        <title>Rationale</title>
      </info>

	  <para>
	  JMS Farming aims at:
	  </para>
      <itemizedlist>
        <listitem><para>ensuring the scalability of asynchonous applications,</para></listitem>
        <listitem><para>improving the availability of asynchonous applications.</para></listitem>
      </itemizedlist>

      <para>JMS farming consists in distributing the messages load across <emphasis>N</emphasis> JOnAS instances.
            The same application is deployed all over the cluster and a message may be processed by any instances.</para>

    </section>
    <section>
      <info>
        <title>Principle</title>
      </info>
      <para>JMS farming relies on the distribution capabilities of the JORAM product. Load-balancing can take place both
      at the server side or at the client side. When a server crashes, pending messages are lost unless a specific mechanism
      is set up at the disk level (such mechanisms are addressed in <xref linkend="principles.jms.cluster" />).</para>

      <para>At the server side, messages can be redirected towards other JOnAS instances when the load reaches a threshold.</para>

      <para>Hereinafter the figure illustrates a JMS farming with a distribution control at the server side.
        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/jmsfarm_a.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
      </para>

      <para>At the client side, messages can be distributed across a set of JOnAS instances according to a load-balancing algorithm (default is random).</para>


      <para>Hereinafter the figure illustrates a JMS farming with a distribution control at the client side.
        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/jmsfarm_b.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
      </para>

    </section>
    <section>
      <info>
        <title>Use case</title>
      </info>
      <para>JMS farming fits well with the need of scalability and availability of the EDA (Event Driven Architecture) applications. When
      the application provides a JMS based asynchronous interface, the JORAM's clustering capabilities do enable to equilibrate the load
      either from the client side or from the server side. JMS farming is recommended when the message loss is acceptable and constitutes
      a good compromise in terms of performance and flexibility.</para>

    </section>
  </section>

  <section xml:id="principles.jms.cluster">
    <info>
      <title>JMS cluster</title>
    </info>

    <section>
      <info>
        <title>Rationale</title>
      </info>

       <para>JMS cluster is used when the messages loss is not acceptable and when the interruption of service is not permitted.</para>

    </section>
    <section>
      <info>
        <title>Principle</title>
      </info>
      <para>Two solutions are available for ensuring the messaging high availability with JOnAS:</para>

      <itemizedlist>
        <listitem><para>through the persistent mode of JORAM combined with some cluster features at the operating system level (NFS, HA/CMP product, Veritas product, ...).
        The HA OS must provide a HA network address (virtual ip address) which can be reallocated dynamically when a node failure occurs. JMS objects, topics
        and queues, must be stored on a shared disk space (external disk array or shared disk space as NFS). JORAM supports 2 storage types : file and database.
        When a JOnAS instance fails, the on-going messages are retrieved by a backup instance in the persistent storage, the virtual IP address
        is bound to the backup node and the messages are processed.</para>

        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/jmscluster_a.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>
        </listitem>

        <listitem><para>through JORAM HA concept delivered with the JORAM project. The mechanism relies on a Master/Slaves approach. At one point, only the master instance
          is active and all the JMS requests are replicated towards the slaves instances. The JMS replication is synchronous and implemented with JGroups.</para>

        <mediaobject>
          <imageobject role="html">
            <imagedata align="center"
                       fileref="../../../../resources/images/clustering/jmscluster_b.png"
                       width="60%" scalefit="1">
            </imagedata>
          </imageobject>
        </mediaobject>

        </listitem>
      </itemizedlist>
    </section>
    <section>
      <info>
        <title>Use case</title>
      </info>
      <para>This architecture pattern is recommended when the application doesn't tolerate any message loss and any interruption of service.
      Two mechanisms are available: the first one relies on operating system HA features and the JORAM's persistent mode whereas the second one
      relies on the native JORAM capabilities and a replication of the JMS requests.
      In case of the underlying OS provides HA features, the first solution is simpler in term of configuration and provides better performance.
      Otherwise JORAM HA solution can be considered and the user must pay attention to the performance impact.</para>
    </section>

  </section>

</section>
