FAS Architecture Guide

FAS Architecture Guide
YRP1-508, 3-4 Hikari-no-Oka Yokosuka-Shi, Kanagawa, 239-0847, Japan

tel.: + 81-(0) 46-821-3362 | cba-japan.com
This document contains confidential information that is proprietary to CBA. No part of its contents
may be used, disclosed or conveyed to any party, in any manner whatsoever, without prior
written permission from CBA.
© Copyright 2023 CBA
All rights reserved.
Updated: 2022-06-22
Document version: 2.6
Contact Information
For technical support or other queries, contact CBA Support at:
support@cbaliveassist.com
For our worldwide corporate office address, see:
https://www.cba-japan.com (Japanese) https://www.cba-gbl.com (English)
© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 2

Documentation in this Release
The following user documentation is provided in this release
Fusion Application Server Architecture Guide
Fusion Application Server Installation Guide
Fusion Application Server Administration Guide

Contents
Introduction
What is Fusion Application Server?
Cluster Components
FAS Processes
Masters and Slaves
SNMP Agent
FAS Startup Process
Communication between ASs and LBs
Server Groups, Profiles, and Domains
Default Server Groups and Profiles
Deployment Options
Single Box Installation
High Availability Installations
Two-box HA Installation
Up to Ten-box HA Installation
HA Installation with Separate Load Balancers
High Availability
SIP and HA
Segments
Replication
SIP Failover
Load Balancer Failure
SIP External Address Mode
Handling ‘Split-brain’
Session Targeting Features
HTTP Session Targeting
Application Architecture
Application Router Registry
Application Router Selection
SNMP Architecture
Glossary

Introduction
This guide is aimed at those with no knowledge of Fusion Application Server, as it introduces
the terminology and concepts used in Fusion Application Server. This section and the
Deployment Options section on page 10 will be of use to most people using or installing Fusion
Application Server. The later sections describe more in-depth concepts, and will be of more
use to those responsible for planning installations.
What is Fusion Application Server?
The Fusion Application Server (FAS) is a combined SIP and HTTP application development
and delivery platform that can be used in multiple network architectures, ranging from the
smallest enterprise applications to large scale IMS environments using SIP and HTTP.
The Fusion Application Server is optimized for applications conforming to the SIP Servlet 1.1
(JSR 289) API, and operates as a clustered software solution comprising of a number of
components that serve distinct roles within the cluster. These components can be distributed
over several machines, or they can all be installed on a single host. When used as a cluster of
FAS nodes (several host machines, all running FAS, of which one is the master node, with the
others linked to it as slaves), FAS provides applications that are deployed on the platform with
high availability and scalability. For example, it supports deployment of complex applications like
the CBA Fusion Client SDK.
Cluster Components
Fusion Application Server consists of two main components, which run as server processes
inside a FAS node:
Application Server (AS)
The AS is the server process that runs the applications.
Load Balancer (LB)
The LB is the outward-facing component of a cluster. It receives SIP and HTTP messages, and
sends them to the correct AS node for processing. New SIP and HTTP requests are balanced
across the AS nodes in the cluster.

Each cluster must contain at least one AS and one LB node (in a single box installation, the
single node is both an AS and an LB node). Each host or virtual machine can run at most one AS
and one LB; however, you can run both an AS and an LB on each host.
FAS Processes
Each FAS node has a number of processes:
Process Controller
Manages the lifecycle of the other processes; it starts, stops, and restarts them, as appropriate.
Host Controller
Provides the management interfaces, and an SNMP Agent.
Plus one or more of:
AS
A JSR 289 compliant Application Server. Applications are deployed to the AS, and it executes the
application logic.
LB
The entry point to the cluster, which directs SIP and HTTP traffic to the appropriate AS process.
The LB is largely a stateless proxy for both SIP and HTTP. It is aware of the ASs, and routes new
requests to a randomly selected AS. If there is a failure on an AS, the LB routes the requests to
an alternative AS.
Management
Performs management tasks such as licensing and trust management. The process only runs on
the master node (see the Masters and Slaves section on page 5).
Masters and Slaves
During installation, you choose one node to be the master; other FAS nodes are slaves. The
master FAS node differs from the slave nodes in that:
The host controller on the master node is known as the Domain Host Controller (DHC). All
changes to the configuration for the cluster occur on the DHC. The host controllers on the
slave FAS nodes receive their configuration changes from the DHC. Configuration can be

read from any host controller, but updates to the configuration can only happen through the
DHC.
The master FAS node runs the management server process; the slaves do not.
Therefore, a master node will run the following processes:
Process controller
Domain Host Controller
Management
one or both of AS and LB
A slave node will run:
Process Controller
Host Controller
one or both of AS and LB
The FAS on the master node must be installed first. The installer configures the FAS on each
slave node with the connection details of the master node; when the slave node starts, it tries to
connect to the master. If the connection is successful, the master synchronizes configuration,
applications, and so on, with the slave. If the connection fails, the slave starts up with a
previously-cached configuration, but will periodically try to reconnect to, and synchronize its
configuration with, the master.
SNMP Agent
An SNMP Agent process runs in the host controller on each node. The SNMP Agent collects
information from the FAS platform, and applications hosted on FAS , and exposes it to an
external Network Management System. This information can be used to monitor the platform and
applications, and to notify administrators when important management events occur.
FAS Startup Process

The following steps occur when a FAS node starts:
1. The fas service starts, either automatically following installation, or manually (using service
fas start). Both approaches use boot configuration in the <install dir>/bin/domain.conf file,

and use the fas.sh script to start FAS in managed domain mode.
2. The process controller is the first process to start. The process controller is responsible for
starting and restarting other processes on that host. It then starts the host controller.
3. The host controller process first determines its host and server name, and whether it is the
DHC or a slave.
If it is a slave, it tries to fetch domain configuration from the DHC. If after about 30 seconds it is
unable to connect to the DHC, it starts up in cached mode, using the configuration that it had
when it last had contact with the DHC. The slave tries periodically (around every six seconds) to
reconnect with the DHC, to get the latest configuration. (A reconnected slave might need to be
restarted to become fully synchronized with the DHC).
4. The host controller reads the local configuration of the FAS:
The host controller determines the list of local server processes (Management, LB, and
AS).
For each local server process, it asks the process controller to start it.
5. Each server process that starts gets the profile configuration appropriate to the server group
it is part of (see the Server Groups, Profiles, and Domains section on page 7).
The server process starts each subsystem in the profile.
If the host controller fails unexpectedly, the process controller restarts it.
If a server process fails, the host controller detects the failure. By default, the host controller asks
the process controller to restart the process.
Communication between ASs and LBs

The nodes discover each other using an Infinispan cache (see www.jboss.org/infinispan/). After
fully starting, an AS server process adds some information to this shared Infinispan cache, which
allows the LBs to route traffic to it. When an AS stops, the LBs receive a notification from the
Infinispan cache that the AS has left the cluster, and react by sending traffic to another AS.
Server Groups, Profiles, and Domains

Server processes across one or more FAS nodes are grouped into server groups. An
application is deployed to a server group, so each server process in a server group has the
same set of configured subsystems, and the same applications deployed, even if they are
running on different hosts.
Each server group is assigned a profile. A profile is a set of subsystems (such as logging, web,
SIP, and Infinispan), together with their configuration. For example, a profile specifies the logging
configuration such as handlers and log categories. Multiple server groups can share the same
profile.
LB server processes are part of a server group so that they can be associated with a profile;
however, you cannot deploy applications to them.
Typically, there is one server group for all AS server processes, and another for all LBs. This
enables each AS to share its state (for example, by replicating HTTP and SIP sessions) with the
other AS server processes in the cluster, and similarly for LBs.
A domain is a set of server groups that can be managed from a single point (the Domain Host
Controller). Most domains consist of two or three server groups:
Default Server Groups and Profiles

On installation, all FAS nodes typically have two server processes (an AS and an LB), the first
belonging to the main-server-group, and the second belonging to the lb-server-group. In addition,
the master node runs an additional server process (Management) that runs in its own separate
server group, called mgmt-server-group. These server groups are used as follows:
main-server-group
Deploy all SIP and Web applications to this group.
lb-server-group
Do not deploy any applications to this group.
mgmt-server-group
This group hosts the License Manager application.
The installer configures three profiles:
ha profile
Used by main-server-group. This profile has many configured subsystems (including Web, SIP,
Infinispan, and JGroups). For example, the Web and SIP subsystems are configured so that their
HTTP and SIP sessions are replicated.
lb profile
Used by lb-server-group. This profile configures the group of LB server processes. For example,
it is possible to change the behavior of the SIP stack used by the LBs.
management profile
Used by mgmt-server-group. This profile is used to configure the License Manager, SNMP and
Trust Management subsystems.
The configuration is physically stored in two files (domain.xml and host.xml); it is managed
through the Domain Host Controller, using a Management Console or CLI interface (see the
Fusion Application Server Administration Guide for details of these interfaces).
Two server groups can share the same profile, with either the same or different applications
deployed to each server group. The profiles can be adjusted (for example, to use a different
database schema) through the use of server group level system properties. See the Fusion

Application Server Administration Guide for details of what AS and LB attributes can be
configured.

Deployment Options
Fusion Application Server supports many different cluster topologies. This section shows a
number of examples of possible deployments.
The multi-box deployments are only suggested deployments; other combinations of hosts and
cluster components are possible.
Single Box Installation
Single-box installations have a small footprint; however, they are not high-availability (HA)
deployments. This type of deployment is most suitable for development or testing environments,
with a small number of subscribers.
A single box FAS server can be extended if required. This deployment may be used in
production where there is no need for HA.

High Availability Installations
In a distributed high-availability (HA) installation, each cluster component can be installed on a

separate physical server with redundancy, so that the cluster contains multiple LB and AS nodes.
You can scale the cluster by adding more AS nodes (and if required, LB nodes). This type of
solution provides full high-availability, so that if a cluster components fails, service continues.
The following sections show a number of suggested HA deployments, including a simple two-box
HA co hosted deployment, a four-box co-hosted deployment and a five-box non-co-hosted
deployment.
All hosts in an HA installation must have their clocks synchronized to a common time source.
Two-box HA Installation
This shows the components, processes, and flow of data in a two-box, high-availability
installation:
In some cases, when using the various SipApplicationSession targeting mechanisms, the ASs
will also send SIP directly to each other; see the Session Targeting Features section on page 18.
This deployment is typical of a small production cluster. The LB and AS processes are on the
same host, which simplifies topology.

Up to Ten-box HA Installation
FAS can scale to more than two nodes, simply by adding extra nodes, each with an LB and an
AS. The following diagram shows the components, processes, and flow of data in a four-box,
high-availability installation (a three-box installation would omit Host4; larger installations would
add extra hosts in the same way that Hosts 3 and 4 have been added to the two-box
installation):
In some cases, when using the various SipApplicationSession targeting mechanisms, the ASs
will also send SIP directly to each other; see the Session Targeting Features section on page 18.
In this deployment, each host has an LB and an AS server process running on it. This
deployment is typical for a production cluster that needs to scale (that is, with increasing
requests per session and maximum concurrent sessions) beyond what is possible in the two-box
HA installation (see the Two-box HA Installation section on page 11).
FAS currently uses a replicate to all nodes strategy, which cannot scale beyond 10 nodes
(depending on applications). Future releases will support larger cluster sizes.
HA Installation with Separate Load Balancers
Because the amount of processing that LBs do is very small, a typical cluster has several nodes,
each containing an LB and an AS, as in the Up to Ten-box HA Installation section on page 11.
However, if you prefer to separate load balancing and application server functions in a
production deployment, you can do so. Splitting ASs and LBs across different hosts can result in
more uniform call setup latencies.

The following diagram shows the components, processes, and flow of data in a five-box, high-
availability installation, where two hosts have LBs installed, and three have ASs:
In some cases, when using the various SipApplicationSession targeting mechanisms, the AS
nodes will also send SIP directly to each other; see the Session Targeting Features section on
page 18.
The ratio of LB nodes to AS nodes depends on the applications and usage profile. A sensible
default for small installations is to run one LB and one AS on each node. We recommend that
you speak to CBA Customer Support when planning a non-standard production installation such
as that in the diagram above.

High Availability
This section describes the HA functionality provided by Fusion Application Server. Details are
provided on how messages are routed to the correct AS using state information and segments,
and how a FAS cluster provides failover. This section also outlines some considerations for SIP
Servlet session targeting.
SIP and HA
All inbound SIP requests, both initial and subsequent, are routed to the ASs by the LBs. Initial
requests are sent to a randomly selected AS (except in cases where the initial request explicitly
targets an existing session; see the Session Targeting Features section on page 18). The LB
shares which AS it selected to process an initial request with the rest of the cluster, so that any
LB will later be able to send retransmissions of that request, CANCEL requests, and ACKs to
error responses, to the same AS. (When there are multiple LBs, this transaction-to-AS
mapping must be shared among all LBs because, for example, a CANCEL could be sent to a
different LB than the original INVITE, but must ultimately be sent to the same AS. The
transaction-to-AS state information is only held for the duration of the transaction.)
FAS routes subsequent requests according to information extracted from the request itself. It
extracts a Segment ID from the Route header (when the AS has acted as a record routing
proxy) or the to-tag (when the AS has acted as a User Agent). The LB sends the request to the
AS that owns that segment. This means that the LB does not need to store transaction-to-AS
mapping information for subsequent requests. When there are multiple LBs, each subsequent
inbound request can be processed by a different LB.
The AS does not send outbound initial or subsequent requests to the next downstream hop
through the LB. This is true whether the next hop is another AS or an external entity. When the
AS acts as a proxy and adds a Record-Route header to a request, or acts as a UA and inserts a
Contact header, the AS uses an address that resolves to all the LBs (that is, an FQDN which
resolves by DNS to all the LBs). This means that all subsequent requests are routed via the LBs.
This is necessary in order to support failover (see the SIP Failover section on page 15).
The cluster element discovery mechanism in FAS uses multicast based on Classful addressing.
You must ensure that all hosts in the cluster have addresses in the same Classful subnet, even if
your network infrastructure is configured with Classless addressing, and multicast will span
Classful subnets.

Segments
A segment is a logical construct which the AS uses to group sessions. Each AS creates a fixed
number of segments when it starts, and shares the segment IDs it is using with other ASs using
Infinispan. (Infinispan is a scalable, highly available datastore and distributed data grid platform
that provides distributed cache capabilities and state replication.) Each new session that the AS
processes is randomly assigned to a segment. Segments are used for:
Routing subsequent requests.
Routing session-targeted requests.
Distributing active sessions evenly among the remaining nodes when an AS fails.
Replication
In a FAS cluster, data is shared between the LB nodes, and between the AS nodes, using
Infinispan replicated caches.
LBs try largely to function as stateless proxies; they do require a small amount of state, however,
in order to route messages such as a CANCEL, or an ACK to an error response, to the same
node as the initial INVITE to which they relate. This state is shared between the LB nodes using
an Infinispan cache, which allows any LB to correctly route these messages, regardless of which
LB routed the initial request. Once a dialogue is established, subsequent requests contain
enough information to allow the LBs to route the request without the need of any state, so the
shared transaction-to-AS state is removed from the cache. If a dialog fails to become
established, the shared state is also removed from the cache.
AS nodes replicate sufficient information for another node to restore the sessions (SIP,
Application, and HTTP) maintained by a failed node, and to process subsequent transactions for
those sessions, whether they are SIP requests, servlet timers, or HTTP requests. This session
information is replicated atomically within the context of a SipApplicationSession at the following
replication points:
After processing the final response to a SIP request.
After processing an ACK.
After processing a servlet timer.
After processing an HTTP request.

After a session is invalidated.
The stored information is removed from the cache when the session to which it relates is
invalidated, or when the session timer it relates to fires or is canceled.
The Jain SIP stack within the AS maintains its own transaction and dialog state information. To
support failover of SIP sessions, the dialog state maintained by the stack must also be replicated
between the AS nodes. This state is shared using an Infinispan replicated cache.
SIP Failover
All LB and AS server processes join an Infinispan cache; Infinispan uses JGroups as its transport
layer; and JGroups is used to detect failover. At any one time the cache will have one
coordinator, which is ordinarily the oldest member of the cache. The coordinator can be an AS
or an LB.
JGroups uses several failure-detection mechanisms, including a configurable heartbeat

mechanism and monitoring connected TCP sockets to detect when a node is no longer
reachable. When it detects a node failure, it notifies the coordinator of the failure and gives it a
list of the remaining nodes. It reallocates the segments assigned to the failed AS to the
remaining ASs.
Each AS node is made aware of the new segment assignments, and acts upon any segments
assigned to it. It reproduces the sessions for that segment, and schedules any servlet timers and
expiry timers.
Calls that were in the middle of a transaction when the node processing them failed (that is, the
request had been received, but a final response had not yet been processed), are generally not
recoverable; these calls will be cleaned up after failover.
Load Balancer Failure

A SIP dialog consists of a series of transactions; each transaction consists of a request, and the
response(s) to that request up to and including the final response. The purpose of an LB is to
route initial and subsequent requests to an AS, so what happens if an LB fails depends on
whether the failure occurs between or during one of the transactions:
Failure between transactions
Any LB in the cluster can route subsequent requests to the correct AS node; it can determine
which node that is from information in the subsequent request itself. See the SIP External

Address Mode section on page 16 for more information on this.
Failure during a transaction
SIP standards require that a response follows the same path as the request (although in
reverse). For this reason, the LB will insert a Via header for itself into the request, so that the
response will always be routed back through the LB through which the request arrived.
Therefore, if the LB fails, the response cannot be routed, and the SIP transaction cannot be
completed.
Since SIP requests initially pass through the LB, if you have only one LB in your cluster, that LB
represents a single point of failure.
SIP External Address Mode
If an AS fails between transactions, there will be no impact on the external SIP endpoints or
servers that FAS communicates with. They do, however, need to react appropriately when a LB
failure occurs.
You can configure FAS to use an appropriate external address mode for the SIP endpoints or
proxies that it communicates with.
After setting up a call, the external endpoint or proxy sends subsequent SIP requests to the
address in either the top-most Route header or the Contact header of the message it received
from FAS; which it uses depends on whether FAS is acting as a proxy or UA. The values that
FAS puts in these headers depends on the configured external address mode. For information
on configuring the external address mode, see the Fusion Application Server Administration
Guide.
Possible values of external address mode are:
Mode Description Behavior
cluster The external address is the static In the case of a DNS

address defined in the cluster entry being used for the
address attribute (see cluster address, the
the Fusion Application Server endpoint or proxy must
Administration Guide). FAS react to an LB failure by
populates the Record-Route and routing subsequent
Contact headers with an address requests to another of the
that will target any LB. This LB addresses to which

address should be an FQDN that that DNS entry resolves.
resolves to all the LBs using Ideally the client will
DNS. This option requires DNS blacklist the failed LB for a
support in the network period of time so that it
does not keep retrying it.
The external address is an LB The client must be able to

node address. Where FAS sets route calls to any one of
the Record-Route or Contact the LB nodes. This can be
header on a message as a result achieved on some PBXs
of an incoming SIP message, it by making the LB
load‑balancer
uses the address of the LB addresses all part of the
through which that message same trunk group. If the
arrived. Otherwise FAS uses a LB fails, no further SIP
randomly-selected active LB messages can be
address. processed for that call.
The external address is that of

the local FAS node. This is a
application‑server legacy mode that is not needed
from version 2.1 onwards of
FAS.
Handling ‘Split-brain’
Network issues can sometimes result in one or more AS nodes being unable to communicate
with the other AS nodes in the cluster. When this happens, the AS nodes form two separate
subgroups which cannot share state; this is known as split-brain.
When the network issues are resolved, the two subgroups of AS nodes merge back into a single
group. However, sometimes the subgroups have different views of the state of the cluster; this
needs to be resolved, or the cluster will be unstable, even for new traffic. (For instance, two ASs
could believe they are both responsible for the same call, and each could overwrite the call state
of the other.)
The ASs detect when a merge occurs, and the largest subgroup becomes the surviving group
(if the groups are the same size, one of them is chosen at random). The ASs in the surviving
group continue processing normally, retaining their view of the cluster state; the ASs in the other
group or groups restart and rejoin the cluster. The cluster state is updated to include the

restarted ASs, and shared across all the ASs in the cluster, so that all nodes again share a single
view.
Any call state on the restarted AS nodes is lost, and therefore the ability to control further
requests on existing calls on those ASs.
Session Targeting Features
SIP Servlet session targeting features require special consideration in a clustered deployment:
Join and Replaces
When an LB receives an initial request with a Join or Replaces header, it checks the header for
the presence of a Segment ID. If a Segment ID exists, the request is sent to the AS that owns
that segment.
Encoded URI
When an LB receives an initial request addressed to an encoded URI, it inspects the Segment ID
encoded in that URI and sends the request to the AS that owns that segment.
Session Key
When an AS invokes an application to process an initial request, the application may bind the
new request to an existing SipApplicationSession. In a clustered deployment, that session might
be associated with a different AS node. In this case, the AS will proxy the request to that other
node.
Multiple applications can use the session key mechanism, with each targeted
SipApplicationSession on a different node; similarly, after each application invocation, a request
is re-examined for the presence of a Join header, Replaces header, or encoded URI. Since a
single request may be processed by a number of applications between entering and exiting FAS,
and each application may be on a different AS, a single request might move between ASs a
number of times.
Each application on a path can have a separate session targeting mechanism.
HTTP Session Targeting

HTTP session targeting is achieved by adding an appKey parameter to the request URI; the
parameter’s value is that of a session key, which uniquely identifies a SipApplicationSession. If

the SipApplicationSession corresponding to the session key is on another AS node, FAS
redirects the request to that node. After processing, the HTTP session for the request will be a
converged session within the corresponding SipApplicationSession.
If a request targets an existing HTTP session, using a session ID in a cookie or the request URI,
that session takes precedence, and any session key is ignored.

Application Architecture
This section details the architecture of a product running on FAS. The term product is used here
because application has a specific meaning in the SIP Servlet Specification and a typical real
world application (product) is made up of a number of SIP Servlet applications.
A product comprises:
A set of SIP Servlet applications; these can be SIP-only or converged (that is, HTTP and
SIP).
Each application can have multiple SIP servlets and HTTP servlets in it. A SipServlet is
analogous to a HttpServlet, but instead of sending HTML to a browser, it sets up a session
between one or more remote SIP User Agents.
SIP applications take on one or more of the following roles:
User Agent Client (UAC)
The application sends a request to a remote UA.
User Agent Server (UAS)
The application receives a request from a remote UAC or proxy and sends a response.
Proxy
The application routes the request or response on to its destination, applying relevant policies
(for example, adaptation or contact resolution), along the way.
Both UAC and UAS (also called a Back-to-Back or B2B UA)
The application receives a request, does some processing, and sends out a request to a
different user agent; when it receives a final response, it sends a final response to the original
request.
At the cost of being more computationally expensive, a B2B UA allows maximum control over the
call flow by splitting the communication channel between both parties in the call into two legs.
An Application Router

A product is made up of a set of SIP applications, which a SIP message typically traverses in
sequence.The application router determines the order of the applications in the chain by
selecting which application is next for each initial SIP request. When the message has traversed
all the necessary applications (a message does not need to traverse all the applications in a
product, and whether it does so is also a matter for the application router), the application router
indicates to the container that it has completed. The container then applies normal routing, which
might result in the message being sent to another server outside the cluster.
For example, an application router might send the message first to an authenticating application,
followed by a call-barring application, and finally to a contact-resolution application (find-me-
follow-me). The application router indicates that it has finished with the message, and the
container routes it to a SIP gateway to send it to the recipient.
Application Router Registry
The SIP Servlet specification assumes that there is only one application router; that assumption
makes it difficult to deploy two products, each with its own application router, to the same cluster.
FAS supports a single application router approach (as described in the Sip Servlet Specification,
which can be found at http://www.jcp.org/aboutJava/communityprocess/final/jsr289/), but also
offers an Application Router Registry for managing multiple products on the same FAS cluster,
each with its own application router and set of applications. FAS also supports each application
router being packaged within an application.
After deployment to the FAS Application Router Registry, an application router can be configured
to own a set of controlled domains (FQDNs). When a request arrives, FAS looks to see if the
request is targeting a controlled domain, and sends the request to the application router
associated with that controlled domain. When the first application router has finished choosing
applications, it sends the request back to the container. FAS examines the request again (the
request might have altered so that it is now targeting a different controlled domain), and if it is
targeting a known controlled domain, it sends it to that controlled domain’s application router.
The application router sends it to its own applications, and then returns control to FAS.
Eventually, when the request does not match any controlled domain, FAS sends it to an external
proxy or UA.
Co-hosting of products in this way can simplify topologies, and reduce hardware requirements
and latencies.
Application Router Selection

The following diagram shows an example of how the Application Router Registry is used to
select the applicable application router for two different call flows when separate products are co-
hosted on a single AS.
In the diagram there are three separate products installed on a single Application Server: ABC,
XYZ, and PQR.
ABC does not have any configured controlled domains, but its application router is set as
the default. This product bundles all of its artifacts within an EAR file, including an
application router.
PQR has the controlled domain fas.example.com configured for its application router. This is
also the cluster address of the FAS installation. This product also bundles all of its artifacts

within an EAR file, including an application router.
XYZ has the controlled domain xyz.example.com configured for its application router. XYZ
has an additional WAR artifact, along with an EAR file.
The diagram shows two calls:
Alice calls Bob (green):
1: An INVITE is sent directly to FAS, without any route headers. The request URI is
bob@example.com.
2: Because there is no route header, and the host part of the request URI does not
match any configured controlled domains, the ABC application router is invoked
because it is configured as the default.
3-6: The ABC application router invokes the two servlets located in its EAR file. It then
returns a route to xyz.example.com.
7-8: Because xyz.example.com is a controlled domain for the XYZ application router,
the request does not leave the container; instead, FAS clears all previous application
router state, and invokes the XYZ application router.
9-14: The XYZ application router invokes the two servlets located in its EAR file,
followed by the servlet in the additional WAR file. The servlets and application router do
not add or return any routes.
15-16: FAS forwards the request to bob@example.com (its request URI). This does not
match any controlled domains in the system so the request leaves the container.
Alice calls Support App (orange):
1: An INVITE is sent to FAS, containing a Route header, fas.example.com. The request

URI is support@example.com.
2: The PQR application router is invoked, because fas.example.com is a controlled

domain for the PQR application router.
3-6: The PQR application router invokes the two servlets located in its EAR file. The
servlets and application router do not add or return any routes.
7-8: FAS forwards the request to support@example.com (its request URI). This does
not match any controlled domains in the system so the request leaves the container.

SNMP Architecture
CBA applications that run on Fusion Application Server can generate SNMP event data, or
traps. This data can provide valuable usage and diagnostic information to administrators and
network operations personnel.
The SNMP system in FAS comprises a subsystem and an SNMP Agent. The SNMP system
provides a simple logEvent API for raising asymmetric SNMP traps via the subsystem.
Asymmetric traps are typically raised for one-off events: either an error, or some other action that
has occurred in the application, such as an application starting.
The SNMP system also has the ability to raise symmetric SNMP traps from MBeans
implemented by an application; these MBeans can be configured to raise Set and Clear SNMP
trap messages based on an attribute’s state. Symmetric traps represent a change of state in the
application. They are used when an application enters or leaves a specific state, either an error
state or some other type of state that an external system needs to know about.
An XML input control file is used to configure the SNMP system for each application. The
subsystem detects the deployment of applications, and if the application has an input control file
packaged with it, will create a JMX MBean of the type MonitoredProduct with the same name as
the deployed artifact, and an attribute called Metadata.
When an AS is started, or when a new application that contains SNMP metadata is deployed, the
current state of the attributes defined for symmetric SNMP trap messages are checked for both
the application and for FAS , and the SNMP Agent sends the appropriate Set or Clear SNMP
traps to the configured trap receivers; this provides any SNMP management clients with the
current status of the system if the SNMP Agent is restarted after a failure.
For example, when a FAS cluster is first started, the status of each host is tested. If the status is
fine, it raises a Clear trap, regardless of any previous state. Therefore, at least the
platformClearNodesNotRegisteredWithLoadbalancer and platformClearServerGroupDown traps
are raised on startup. The server processes in a FAS cluster start in an undefined order, so we
expect that some Set traps are raised, closely followed by the associated Clear traps, as (for
instance) the LB server process starts and previously unregistered AS nodes are able to register
with it. See the Fusion Application Server Administration Guide for details of the traps that
FAS can raise.
Once it has read a product’s metadata, the SNMP Agent starts to poll any configured MBean
attributes, and receives any event notifications for that product. It uses the metadata to translate

these into the appropriate SNMP traps. Each SNMP trap will be sent to each trap receiver (or
SNMP client) that is configured for the SNMP Agent, using the SNMP protocol version specified
for that trap receiver. Each trap is also added to the alert.log file in the <install dir>/domain/log
directory.
The OID (object identifier) of an event is defined in an associated MIB file, which should be
provided with the application.

Glossary
Term Description
This is a framework offered by applications to manage their

configuration. Unlike managing application configurations
Application
using standard system properties, this framework offers
Configuration
validation and publishing hooks that allow the application to
Framework (ACF)
check that configuration settings are valid, and to be informed
when configuration settings have changed.
Used for co-hosting multiple products on the same FAS

Application Router cluster. Where each product has its own application router
Registry and set of applications, the application router registry
determines which application router a request is sent to.
Server process running in FAS to which applications are

Application Server
deployed, and which executes the application logic. It is a
(AS)
JSR 289-compliant application server.
Application Server
FAS node running at least an AS server process.
node (AS node)
Group of FAS nodes, of which one is the master and the

Cluster
others are slave nodes.
A unique name within the enterprise that a cluster is known

Cluster name by. Specifying the cluster name when adding a new AS or LB
adds that component to the specified cluster.
Datasource The connection set up to a database from a server.
A set of Server Groups that can be managed from a single

point. Essentially equivalent to a cluster, though a cluster is
Domain
more physical (a set of host machines or virtual servers),
while a domain is more logical (a set of Server Groups).
A Host Controller that is in charge of all the others in a cluster,

Domain Host
and the point from which the Server Groups in a domain are
Controller
managed.

Dynamic Model
A tree-structure representation of the FAS attributes that can
Representation
be configured.
(DMR)
A combined SIP and HTTP application development and

delivery platform that can be used in multiple network
Fusion Application
architectures, ranging from the smallest enterprise
Server (FAS)
applications to carrier-scale IMS environments using SIP and
HTTP.
Host or virtual server running FAS, and which is part of a FAS

FAS node
cluster.
Host Controller The FAS process that provides the management interfaces.
A certificate that proves a resource’s identity, usually signed

Identity Certificate
by a Certification Authority. Used in TLS.
A scalable, highly available data store and distributed data

Infinispan grid platform that provides distributed cache capabilities and
state replication.
The Java API for XML Web Services. It is a Java

JAX-WS programming language API for creating web services, and is
part of the Java EE platform.
A graphical monitoring tool to monitor Java Virtual Machine

JConsole (JVM) and java applications both on a local or remote
machine.
A toolkit for reliable messaging. It can be used to create

JGroups groups of processes whose members can send messages to
each other.
A server process running within FAS. It is a largely stateless

Load Balancer
proxy for both SIP and HTTP that routes new requests to an
(LB)
AS server process.
Load Balancer
A FAS node running at least an LB server process.
node (LB node)
Managed domain In a managed domain each application server instance is a

member of a server group. You can manage multiple server

groups within a domain.
Management A server process running on the FAS master node in a cluster

Server (and only on the FAS master node).
The traffic from the CLI, Management Console and from

Management traffic
communication between master and slave host controllers.
The FAS node that hosts the Domain Host Controller, which
Master node the CLI and Management Console connect to to manage the
cluster.
Java Management Extensions (JMX) is a Java technology

that supplies tools for managing and monitoring applications,
MBeans system objects, devices and service oriented networks. Those
resources are represented by objects called MBeans (for
Managed Bean).
The reference implementation of the JAIN-SIP API. JAIN-SIP

is a low level protocol API for SIP. NIST stands for National
NIST SIP stack
Institute of Standards and Technology. JAIN stands for Java
APIs for Intelligent Networks.
The FAS process that manages the lifecycle of the other

Process Controller
processes - starting, stopping, and restarting as appropriate.
A profile is a set of subsystems (for example, logging, web,

Profile
SIP, Infinispan) together with their configuration.
A logical construct used by the AS to group sessions. Each

AS creates a fixed number of segments when it starts. The
Segments
assignment of Segment ID to AS is shared via Infinispan and
known to all FAS nodes.
Server processes across one or more hosts are grouped into

Server Groups. Applications are deployed to Server Groups,
Server Group
so all hosts in a Server Group will have the same set of
applications deployed.
A process running in FAS (AS, LB, or Management).

Server Process Unfortunately referred to as a server in the Management
Console.

Service traffic HTTP, HTTPS, SIP, and SIPS traffic.
The FAS nodes within a cluster that are not the Master are
Slave slaves, which receive their configuration changes from the
Domain Host Controller running on the Master node.
A process integrated with each Domain Host Controller and

Host Controller that collects information from the FAS
SNMP Agent platform, and applications hosted on FAS, and exposes this to
the external Network Management System. SNMP stands for
Simple Network Management Protocol.
A state resulting from network issues that prevent some AS

Split brain nodes from communicating with other AS nodes in the cluster,
forming separate subgroups.
A certificate from an external host that enables secure

Trust certificate
communication with that host. Used in TLS.
An abstraction layer on top of a more concrete file system that

Virtual File System
allows client applications to access different types of file
(VFS)
systems in a uniform way.
The Web Services Description Language is an XML-based

WSDL interface description language that is used for describing the
functionality offered by a web service.

FAS Architecture Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FAS Architecture Guide

Uploaded by

Copyright:

Available Formats

FAS Architecture Guide

YRP1-508, 3-4 Hikari-no-Oka Yokosuka-Shi, Kanagawa, 239-0847, Japan

All rights reserved.

Document version: 2.6

For technical support or other queries, contact CBA Support at:

For our worldwide corporate office address, see:

https://www.cba-japan.com (Japanese) https://www.cba-gbl.com (English)

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 2

Fusion Application Server Architecture Guide

Fusion Application Server Installation Guide

Fusion Application Server Administration Guide

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 3

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 4

What is Fusion Application Server?

Application Server (AS)

The AS is the server process that runs the applications.

Load Balancer (LB)

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 5

Each FAS node has a number of processes:

Provides the management interfaces, and an SNMP Agent.

Plus one or more of:

Masters and Slaves

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 6

Therefore, a master node will run the following processes:

Domain Host Controller

one or both of AS and LB

A slave node will run:

one or both of AS and LB

FAS Startup Process

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 7

4. The host controller reads the local configuration of the FAS:

The server process starts each subsystem in the profile.

Communication between ASs and LBs

Server Groups, Profiles, and Domains

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 8

Default Server Groups and Profiles

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 9

Deploy all SIP and Web applications to this group.

Do not deploy any applications to this group.

This group hosts the License Manager application.

The installer configures three profiles:

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 10

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 11

Single Box Installation

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 12

In a distributed high-availability (HA) installation, each cluster component can be installed on a

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 13

HA Installation with Separate Load Balancers

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 14

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 15

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 16

Routing subsequent requests.

Routing session-targeted requests.

After processing the final response to a SIP request.

After processing an ACK.

After processing a servlet timer.

After processing an HTTP request.

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 17

JGroups uses several failure-detection mechanisms, including a configurable heartbeat

Load Balancer Failure

Failure between transactions

© 2023 CBA | All Rights Reserved | Unauthorized use prohibited. Page 18

Failure during a transaction

SIP External Address Mode