Fabric3 is a platform for building distributed applications and integrating loosely coupled systems. Perhaps the best way to describe Fabric3 is to contrast it with other middleware technologies: 

• Unlike Java EE app servers, Fabric3 is designed with integration in mind as opposed to siloed applications. Fabric3 assembles composite applications from distributed services that may be hosted in a vairety of disparate systems.  
• Unlike Enterprise Service Buses (ESB), Fabric3 is not based on a proprietary programming and integration model that routes all communication through a messaging abstraction. Instead, Fabric3 relies on the SCA standards to wire application components directly or through typed channels without the complexity and overhead of an intermediary.  
• Dependency injection frameworks such as Spring and Guice assemble local application components; Fabric3 extends assembly from local to distributed services. 
• Fabric3 does not compete with messaging middleware (MOM), but often uses it for remote communication between services.
• Fabric3 does not replace web services but can be used to expose RESTful resources and WS-* endpoints to external clients.

Best desribed as a "fabric" for connecting 

Key Concepts

This section explains key concepts necessary to understand when designing, deploying and maintaining distributed applications with Fabric3.

The Domain

In SCA, a domain is a realm of control and administration. Specifically, a domain is a set of Fabric3 runtimes that act in that host applications and are 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 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 contributions.
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.

The Controller, Participants, and Zone Manager

A distributed domain is composed of runtimes that perform several different roles: the controller, participant, and zone manager.
The controller manages the domain, including contributions in a repository and deployment to zones. A participant runtime 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) 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.

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.

Scaling Down

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). However, it is also important to note that this architecture scales down. A domain can be confined to one runtime instance, in which case 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.

Installing the Controller

To install the controller, download and unzip the standalone distribution from the Fabric3 site and execute the following command from the /bin directory:
java -jar server.jar controller
The controller will boot and join the domain. The default HTTP port for the Controller is 8180.

Installing Participants

Download the standalone distribution (or make a copy of the previous download), unzip it, and execute the following command from the /bin directory:
java -jar server.jar participant
When the particpant boots, it will join the same domain as the controller. Since there is only one participant, it will act as a zone manager for the default zone, zone1. Both runtimes should display a console message indicating the participant has joined the domain as a zone manager.
The default port settings for the participant are:

• HTTP - 8181
• JMX - 1198
• Stop daemon – 8084

If more than one participant is run on a physical machine, Fabric3 will select an available port for these services.

Installing the Administration tool

The controller is administered through a separate admin tool that can connect to a local or remote running instance via JMX. Download and unzip the adminstration tool distribution. The tool can be run from the commandline or using an interactive shell. To start the interactive shell, execute the following from the /bin directory:
java -jar f3.jar
The shell will display the f3> prompt. Type the following command to display a list of installed contributions and their status:
f3> st
Alternatively, operations can can be executed from the command line. For example, the previous command can be issued directly using:
java -jar f3.jar st