Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In SCA, a domain is a realm of control and administration. Specifically, a domain is a set of Fabric3 runtimes that are coordinated and managed together. A domain may be large, comprising multiple runtime instances on separate physical machines, or small, consisting of a single runtime. In a domain, policy and contributions components may be wired and connected to channels and contribution artifacts may be shared. 

Zones

It is often convenient to partition large domains into a set of smaller regions, or zones. For example, an organization may decide to deploy one application to a set of runtimes and another application to a different set of runtimes. If the organization assigned the applications to different domains, they would not be able to share policies or contributionsmanage them as a whole.

Zones partition a domain into smaller managed units.  A zone is a set of one or more runtimes where applications (contibutions) are deployed. A domain always has at least one zone and may contain more.
While a domain may be heterogeneous (i.e. it may be composed of many different runtime types), a zone is homogenous. All runtimes in a zone are the same. Furthermore, all runtimes in a zone host replicas of the same applications. 

...

A distributed domain is composed of runtimes that perform several different roles: the controller, participant, and zone managera controller runtime and participant runtimes

The controller manages the domain, including contributions in maintaining a contribution repository and deployment deploying applications to zones. A participant runtime is a member of a single zone and hosts application components for the zone it is a member of. Each zone also has a dynamically elected zone manager which is responsible for coordinating with the domain controller for operations such as deployment. A Fabric3 domain is segmented such that the controller only communicates directly to zone managers, which in turn are responsible for managing individual participants. 
Fabric3 uses JGroups ([http://www.jgroups.org|http://www.jgroups.org]) as its underlying communications technology, although this may be substituted by alternative technologies. 

Deployment Plans

Deployment plans are XML files that specify zones components in a contribution should be deployed to. They may also contain deployment-specific configuraton. Deployment plans can be installed in the domain as part of a contribution or separately. In addition, contributions may be deployed multiple times using different deployment plans. Only participants host components and process requests. The controller acts a simple manager and may be shut down without affecting the ability of the domain to service requests.

Clustering

Clustering is provided through zones. When components in a contribution are deployed to a zone, they are replicated to all runtimes configured as part of the zone. 

...

Using this architecture, it is possible to construct domain topologies that are easy to manage and scale. A domain may span multiple runtime types (e.g. different application servers). consist of multiple zones, each containing clustered participant runtime. However, it is also important to note that this architecture scales down. A domain can be confined to one comprised of a single runtime instance, in which case the runtime acts both as the controller and participant runtime are the same. 

Setting up a Distributed Domain

Setting up a distributed domain requires the Fabric3 standalone distribution. Note that each runtime must be booted from a separate file system directory