diff options
Diffstat (limited to 'CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html')
-rw-r--r-- | CIAO/connectors/dds4ccm/tutorials/Shapes/Tutorial/06_compilation.html | 248 |
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 <node> 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/> - - <<b>connection</b>><br/> - <<b>name</b>>writer_connection<<b>/name</b>> - <font color="grey">//unique name of the connection</font><br/> - <<b>deployRequirement</b>><br/> - <<b>name</b>>edu.dre.vanderbilt.DAnCE.ConnectionType<<b>/name</b>><br/> - <<b>resourceType</b>>Local_Interface<<b>/resourceType</b>> - <font color="grey">//The connection between the Sender and the DDS4CCM connector is 'local'</font><br/> - <<b>deployRequirement</b>><br/> - <<b>internalEndpoint</b>> - <font color="grey">//First endpoint (the Sender component).</font><br/> - <font color="grey">//PortName is defined as follows</font><br/> - <font color="grey">//<name_of_port_in_sender_component_idl>_< - name_of_interface_in_extended_port>(see ccm_dds.idl)</font><br/> - <<b>portName</b>>info_write_data<<b>/portName</b>><br/> - <<b>provider</b>>false<<b>/provider</b>> - <font color="grey">//The Sender component doens't provide the interface</font><br/> - <<b>kind</b>>SimplexReceptacle<<b>/kind</b>><br/> - <<b>instance</b> xmi:idref="SenderComponentInstance" /> - <font color="grey">//Reference to the artifact (the Sender component instance in this case)</font><br/> - <<b>/internalEndpoint</b>><br/> - <<b>internalEndpoint</b>> - <font color="grey">//First endpoint (the Sender component).</font><br/> - <font color="grey">//PortName is defined as follows</font><br/> - <font color="grey">//<name_of_port_in_dds4ccm_connector>_< - name_of_interface_in_extended_port>(see ccm_dds.idl)</font><br/> - <<b>portName</b>>supplier_data<<b>/portName</b>><br/> - <<b>provider</b>>true<<b>/provider</b>> - <font color="grey">//The DDS4CCM connector provides this interface</font><br/> - <<b>kind</b>>Facet<<b>/kind</b>><br/> - <<b>instance</b> xmi:idref="Shapes_SenderConnectorInstance" /> - <font color="grey">//The reference to the connector instance.</font><br/> - <<b>/internalEndpoint</b>><br/> - <<b>/connection</b>><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> |