summaryrefslogtreecommitdiff
path: root/CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html
diff options
context:
space:
mode:
Diffstat (limited to 'CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html')
-rw-r--r--CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html248
1 files changed, 0 insertions, 248 deletions
diff --git a/CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html b/CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html
deleted file mode 100644
index fed4dfae73f..00000000000
--- a/CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html
+++ /dev/null
@@ -1,248 +0,0 @@
-<!--// -->
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <title>DDS4CCM Tutorial Shapes - Compilation and deployment</title>
-</head>
-
-<body>
- <table width="100%" border="0">
- <tr>
- <td align="left"><a href="./05_coding.html">Previous<a></td>
- <td align="center"><img width="4%" height="5%" src="./images/images.png"/></td>
- <td align="right"></td>
- </tr>
- </table>
- <hr />
-
- <h1>Compilation and deployment<h2>
-
- <h2>Compilation</h2>
- <p>
- Once all the code has been written, compilation of the code would be the next
- step.<br/>
- MPC is used in order to create the Makefiles and projects files. All MPC files
- that are needed for this tutorial are in the same directory as the accompanying
- IDL and executor files.<br/>
-
- In order to make the GNU make files or the Visual Studio project files,
- the following steps should be performed :
- <ul>
- <li>Start a command shell and navigate to : <br/>
- <code>%CIAO_ROOT%/connectors/dds4ccm/tutorials/Shapes/Shapes_asm</code>
- </li>
- <li>Run<br/>
- <ul>
- <li><code>perl %ACE_ROOT%/bin/mwc.pl -type vc9</code> to create Visual
- Studio 2008 project files.
- </li>
- <li><code>perl %ACE_ROOT%/bin/mwc.pl -type gnuace</code> to create
- the GNU make files.
- </li>
- </ul>
- <li>Now compile the code like you're used to.
- </li>
- </li>
- </ul>
- </p>
- <p>
- If all went well, all libraries are in the Shapes_asm/lib directory.
- </p>
- <h2>Deployment</h2>
- <p>
- Once all binaries are compiled, they're ready to be deployed. In this tutorial
- we are using DAnCE to deploy our system.<br/>
- DAnCE starts a system in two phases :
- <ol>
- <li>configuration_complete</li>
- <li>ccm_activate</li>
- </ol>
- DAnCE shuts down a system again in two phases :
- <ol>
- <li>passivate</li>
- <li>ccm_remove</li>
- </ol>
- Each component should have these four methods implemented. The business logic
- implemented in each step depends on you implementation.<br/>
-
- There're several processes taking care of the total deployment process.
- See the DAnCE documentation for more information about which processes there
- are and what their responsibilities are.<br/>
- DAnCE will start and shutdown a system with the aid of a deployment plan. A
- deployment plan describes which artifacts must run on which nodes and which
- components are connected to eachother via which interface (more on this later).
- All connections between components are made before 'configuration_complete' is
- called.
- <p>
- The deployment plan will be generated by the modelling tools but we take a
- brief look at the most important items of a deployment plan. A deployment plan
- is a XML based file which is devided into the following (main) sections:<br/>
- <ul>
- <li>Implementations</li>
- <li>Entry points</li>
- <li>Instances</li>
- <li>Connections</li>
- <li>Artifacts</li>
- </ul>
- </p>
-
- <b><i>All deployment code fragments mentioned in the rest of this tutorial are
- *NO* exports of any modelling tool.</i></b>
-
- <h3>Implementations and Entry Points</h3>
- <p>
- This defines which executor and servant artifacts (binaries) should be
- used. Implementations also defines which entry points in the binaries
- should be used. <a href="./Code/Deployment/implementation.cdp">This<a> file shows the
- implementation section of the controller.<br/>
- Beware that artifacts and entry points are exact otherwise deployment will
- fail.<br>
- </p>
-
- <h3>Instances</h3>
- <p>
- Instances define which artifacts run on which node. Every fysical artifact in
- the system results in one instance. The &lt;node&gt; section refers to the
- fysical node on which this instance will be deployed.<br/>
- An instance always refers to an implementation.
- It's possible that more than one instance refers to the same implementation.<br/>
- The instance section also provide the initial values of all attributes
- defined on the component.<br/>
- <a href="./Code/Deployment/instance.cdp">This</a> file shows the instance section of
- the controller.<br/>
- </p>
-
- <h3>Connections</h3>
- <p>
- A connection section defines which components are connected together.
- To define a connection one should know which type of DDS4CCM connector is used.
- <br/><br/>
- <b>Example</b><br/>
- The sender component is connected to a DDS4CCM connector via the DDS_Write
- extented port of the DDS_Event basic port. The DDS_Write port for the
- DDS_Event connector is called 'supplier' and the Writer interface on this
- extented port is called 'data' (see ccm_dds.idl). In Shapes_Sender_comp.idl,
- the DDS_Write port is called 'info_write'. The DDS4CCM connector provide
- the writer interface, the Sender component uses this.<br/>
- The connection is 'local' since a connector and a component are always running
- in the same process.<br/>
- Now that we have got all the data we need to know to make a connection
- between the Sender and DDS4CCM connector regarding the writer port.<br/><br/>
-
- &lt;<b>connection</b>&gt;<br/>
- &nbsp;&nbsp;&lt;<b>name</b>&gt;writer_connection&lt;<b>/name</b>&gt;
- <font color="grey">//unique name of the connection</font><br/>
- &nbsp;&nbsp;&lt;<b>deployRequirement</b>&gt;<br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>name</b>&gt;edu.dre.vanderbilt.DAnCE.ConnectionType&lt;<b>/name</b>&gt;<br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>resourceType</b>&gt;Local_Interface&lt;<b>/resourceType</b>&gt;
- <font color="grey">//The connection between the Sender and the DDS4CCM connector is 'local'</font><br/>
- &nbsp;&nbsp;&lt;<b>deployRequirement</b>&gt;<br/>
- &nbsp;&nbsp;&lt;<b>internalEndpoint</b>&gt;
- <font color="grey">//First endpoint (the Sender component).</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;<font color="grey">//PortName is defined as follows</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;<font color="grey">//&lt;name_of_port_in_sender_component_idl&gt;_&lt;
- name_of_interface_in_extended_port&gt;(see ccm_dds.idl)</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>portName</b>&gt;info_write_data&lt;<b>/portName</b>&gt;<br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>provider</b>&gt;false&lt;<b>/provider</b>&gt;
- <font color="grey">//The Sender component doens't provide the interface</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>kind</b>&gt;SimplexReceptacle&lt;<b>/kind</b>&gt;<br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>instance</b> xmi:idref="SenderComponentInstance" /&gt;
- <font color="grey">//Reference to the artifact (the Sender component instance in this case)</font><br/>
- &nbsp;&nbsp;&lt;<b>/internalEndpoint</b>&gt;<br/>
- &nbsp;&nbsp;&lt;<b>internalEndpoint</b>&gt;
- <font color="grey">//First endpoint (the Sender component).</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;<font color="grey">//PortName is defined as follows</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;<font color="grey">//&lt;name_of_port_in_dds4ccm_connector&gt;_&lt;
- name_of_interface_in_extended_port&gt;(see ccm_dds.idl)</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>portName</b>&gt;supplier_data&lt;<b>/portName</b>&gt;<br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>provider</b>&gt;true&lt;<b>/provider</b>&gt;
- <font color="grey">//The DDS4CCM connector provides this interface</font><br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>kind</b>&gt;Facet&lt;<b>/kind</b>&gt;<br/>
- &nbsp;&nbsp;&nbsp;&nbsp;&lt;<b>instance</b> xmi:idref="Shapes_SenderConnectorInstance" /&gt;
- <font color="grey">//The reference to the connector instance.</font><br/>
- &nbsp;&nbsp;&lt;<b>/internalEndpoint</b>&gt;<br/>
- &lt;<b>/connection</b>&gt;<br/>
- </p>
- <p>
- Take a look at <a href="./Code/Deployment/connections.cdp">this</a> file to see which
- connection should be made by DAnCE in order to run the shapes system properly.
- Also take a look at the connection between the Controller and the Sender. This
- one is different because no DDS4CCM connector is used.
- </p>
- <p>
- When the deployment tools (in this case DAnCE) deploys this system, it'll connect
- all defined connectors before the system is started (i.e. before configuration_complete
- is called on a component).<br/>
- </p>
- <h4>Coding connections</h4>
- <p>
- Every component has got a context. The context is set by DAnCE and is
- the 'gateway' to all other component your component is connected to. The
- context caches all these connections so that the user doesn't need to
- cache those in his/her component.
- </p>
- <p>
- <b><u>Sender</u></b><br/>
- The Sender uses the writer connection of the DDS_Write extented port of the
- DDS_Event basic port. The following code retrieves the connection to the
- Writer interface from the context.
- <br/>
- <code>::Shapes::ShapeType_conn::Writer_var writer =
- this->context_->get_connection_info_write_data ();</code>
- <br/>
- </p>
-
- <p>
- <b><u>Controller</u></b><br/>
- The Controller uses the 'Control_obj' interface of the Sender component.
- Since this isn't a connection to a DDS4CCM connector, the code is rather
- simple. Looking at the IDL of the sender and receiver, the following code can be
- constructed in order to get the connection the Control_obj interface:
- <br/>
- <code>::Shapes::Control_obj_var control =
- this->context_->get_connection_control ();</code>
- <br/>
- </p>
-
- <p>
- <b><u>Receiver</u></b><br/>
- The Receiver 'listens' to DDS and thus should provide a callback for the
- DDS4CCM connector. Please take a look at the generated code of the executor
- <a href="./Code/Shapes_Receiver_comp/Shapes_Receiver_comp_exec.cpp">code</a>
- of the receiver to see how this can be done.<br/>
- By default, a DDS4CCM connector is not listening so one should instruct the
- DDS4CCM connector to start listening to samples. Therefor
- a DataListenerControl interface (data_control) is available. The following
- code ensures that the DDS4CCM connector starts listening to the desired samples.
- <br/>
- <code>
- ::CCM_DDS::DataListenerControl_var lc =
- this->context_->get_connection_info_out_data_control ();<br/>
- lc->mode (::CCM_DDS::ONE_BY_ONE);<br/>
- </code><br/>
- This ensures that 'on_one_data' is gets invoked by the DDS4CCM connector
- for each sample.<br/>
- It's also possible to use ::CCM_DDS::MANY_BY_MANY. This will make sure that
- on_many_data on the listeners callback gets invoked by the DDS4CCM connector.<br/>
- To turn off listening, just call <code>lc->mode (::CCM_DDS::NOT_ENABLED);</code>
- <br/>
- </p>
-
- <h3>Artifacts</h3>
- Artifacts sections contains the names of the binaries. See
- <a href="./Code/Deployment/artifacts.cdp">this</a> files for an overview of all
- artifacts in the shapes system.
-
- <h3>Complete plan</h3>
- <a href="./Code/Deployment/Plan.cdp">This</a> file shows the complete deployment
- plan.<br/>
-
- <hr />
- <table width="100%" border="0">
- <tr>
- <td align="left"><a href="./05_coding.html">Previous<a></td>
- <td align="center"><img width="4%" height="5%" src="./images/images.png"/></td>
- <td align="right"></td>
- </tr>
- </table>
-</body>