In Fabric3, application code is organized as a set of components implemented as POJOs. A component may have one or more services it exposes to clients and may contain references to other services it depends on. The following illustrates a calculator component (taken from the samples) that is wired to operand services:
Components can provide one or more services to clients. Clients may be remote or local. For remote clients, a component service can be exposed as an endpoint using a binding such as WS-*, JAX-RS or JMS.
Fabric3 supports native JAX-RS annotations for binding a component service as an endpoint:
Fabric3 also provides annotations for binding services to other transports. The
WebServiceBinding annotation exposes the calculator service as a WS-* endpoint:
The following demonstrates how to expose an endpoint to a JMS queue:
A component can act as a client to a service by wiring a reference.
The following shows how to wire a reference in a composite:
In the above example, the wire from
AddService can be local or remote (possibly passing through a message queue) depending on if the two components are collocated. For distributed services, bindings can be specified on references:
The above example wires
AddService using a ZeroMQ socket. Note that IP addresses and port bindings do not need to be specified - these will be resolved transparently to the application by the Fabric3 runtime.
Components can be defined using annotations (in which case they will be scanned by the runtime) or by XML or a Java-based DSL. If you prefer to define components using one of the latter methods, you must create a composite containing the components. A composite can be defined by an XML file containing a set of component definitions:
Alternatively, a composite can be defined using the Fabric3 DSL:
A composite is similar to a Spring application context but with several important differences:
- An application can be comprised of 1..n composites that are peers or nested in a top-level composite.
- Composites define visibility boundaries for encapsulation. It is not possible to wire to components within a composite unless they are explcitly made visibile outside the composite through promotion. Promotion is similar to making a method public on a Java class.
Fabric3 also supports pub/sub interactions where components pass events through a channel as opposed to being directly wired. A component producer is connected to a channel, which in turn may be connected to 0..N component consumers.
The following shows how to create pub/sub interaction using a channel using XML:
Channels may be local or remote depending on where its producers and consumers are deployed. In the case where producers and consumers are remote, Fabric3 will bind a channel to a remote transport such as a JMS topic (channels may also be explicitly bound using the <binding> element in a composite).