Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current Restore this Version View Page History

« Previous Version 5 Next »

Composites

Applications are composed of one or more composites.  A composite is an XML file that contains a set of component definitions:

<composite xmlns='http://docs.oasis-open.org/ns/opencsa/sca/200912'
           targetNamespace='urn:tempuri.org'
           name='SampleComposite'>

    <component name='SampleComponent'>
        <f3:implementation.java class="org.sample.SampleComponent"/>
    </component>

</composite>

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.  
  • A composite may be distributed and span multiple runtimes. In this case, wiring will be remote.

Bindings

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. The following demonstrates how to expose an endpoint to a JMS queue:

<composite xmlns='http://docs.oasis-open.org/ns/opencsa/sca/200912'
           targetNamespace='urn:tempuri.org'
           name='SampleComposite'>

    <component name='TargetComponent'>
        <f3:implementation.java class="org.sample.TargetComponent"/>
        <service name="TargetService"> 	   
           <binding.jms>
              <destination jndiName="SampleQueue"/>           
           </binding.jms>
        </service>
    </component>

</composite>

Wires

A component can act as a client to a service by wiring a reference:

<composite ...>

    <component name='SampleComponent'>
        <f3:implementation.java class="org.sample.SampleComponent"/>
	<reference name="service" target="TargetComponent"/>
    </component>


    <component name='TargetComponent'>
        <f3:implementation.java class="org.sample.TargetComponent"/>    
    </component>

</composite>

In the above example, the wire from SampleComponent/service to TargetComponent can be local or remote (possibly passing through a message queue) depending on if the two components are collocated.

Channels

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 an event network using a channel:

<composite ...>


    <channel name="SampleChannel"/>


    <component name='SampleComponent'>
        <f3:implementation.java/>
	<producer name="channel" target="SampleChannel"/>
    </component>

    <component name='TargetComponent1'>
        <f3:implementation.java/>    
        <consumer name="channel" source="SampleChannel"/>    
    </component>


    <component name='TargetComponent12>
        <f3:implementation.java/>    
        <consumer name="channel" source="SampleChannel"/>    
    </component>

</composite>

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).