Page Comparison

...

The Runtime Image

The Fabric3 Server runtime image is organized in the following way:

...

If the default runtime startup command is used:

java -jar server

a single-VM instance will be created using the configuration specified in runtimes/vm. Alternative configurations can be used by specifying the runtime name as shown below. The runtime name will map to a configuration contained under the {{runtimes} directory:

java -jar server.jar controller  -- launches a runtime using the configuration under {{runtimes/controller}} 
java -jar server.jar participant -- launches a runtime using the configuration under {{runtimes/participant}}  
java -jar server.jar foo -- launches a custom runtime using the configuration under {{runtimes/foo image}} 

Note it is possible to run multiple runtime instances from a single disk image. In this case, the image will contain multiple configurations under the runtimes directory. Each instance can then be started by specifying the runtime name, for example:

java -jar server.jar foo
java - jar server.jar foo2

...

For high-density clustered topologies such as cloud environments, Fabric3 provides the ability to clone runtimes. This allows new instances to be spawned from a configuration template using a single command without the need for manual setup. The following command clones a runtime image and launches the cloned instance:

java -jar server.jar clone:template runtime2

...

If more than one domain is run on the same physical network, it is necessary to create unique domain names. The domain name is configured using the domain attribute of the <runtime> element:

<config>
   <runtime domain="mydomain"/>
</config>

...

The runtime mode is configured using the mode attribute of the <runtime> element:

<config>
   <runtime mode="controller"/>
</config>

...

By default, Fabric3 is configured to use pass-by-reference semantics when invoking remotable services collocated with their clients. This avoids the overhead of parameter copying. In some cases, this may not be desirable, for example, if a service directly modifies parameter data that should not be visible to clients. To avoid this, the runtime can be configured to follow SCA by-value semantics by setting the @enableByValue attribute to true on the SCA setting in serviceConfig.xml:

<sca enableByValue="true"/>