-<!doctype html public "-//w3c//dtd html 4.0 transitional//en">\r
-<html>\r
-<head>\r
- <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">\r
- <meta name="GENERATOR" content="Mozilla/4.73 [en] (WinNT; I) [Netscape]">\r
- <title>Main Page</title>\r
-<link href="doxygen.css" rel="stylesheet" type="text/css">\r
-</head>\r
-<body>\r
- \r
-<center><table WIDTH="96%" >\r
-<tr>\r
-<td><a href="http://www.opencascade.com"><img src="sources/logocorp.gif" BORDER=0 height=46 width=122></a></td>\r
-\r
-\r
-<td>\r
-<div align=right><a href="http://www.opencascade.org/SALOME/"><img src="sources/application.gif" BORDER=0 height=46 width=108></a></div>\r
-</td>\r
-</tr>\r
-</table></center>\r
-\r
-\r
-<h1><a name="page2">General overview</a>\r
-</h1>\r
-<a name="cont"></a><h2>Table of contents </h2>\r
-<b><i>\r
-<ul>\r
- <li><a href="#1">1. Introduction</a></li>\r
- <li><a href="#2">2. Basic principles </a></li>\r
- \r
- <li><a href="#3">3. Services and features of the SALOME kernel module</a></li>\r
- <ul>\r
- <li><a href="#3_1">3.1 Session service</a></li>\r
- <li><a href="#3_2">3.2 Registry service </a></li>\r
- <li><a href="#3_3">3.3 Notification service </a></li>\r
- <li><a href="#3_4">3.4 Module catalog service </a></li>\r
- <li><a href="#3_5">3.5 Data type catalog </a></li>\r
- <li><a href="#3_6">3.6 Resource catalog </a></li>\r
- <li><a href="#3_7">3.7 Engine </a></li>\r
- <ul>\r
- <li><a href="#3_7_1">3.7.1 Component class </a></li>\r
- <li><a href="#3_7_2">3.7.2 Container class </a></li>\r
- </ul>\r
- </ul>\r
-</ul>\r
-</i> </b> <br>\r
-<a name="1"></a><h2>1. Introduction</h2>\r
-<p>The kernel corresponds to the minimal set of services required for the use of SALOME components (Supervisor, IAPP). \r
-The kernel is also used by application software components (solver) and their container. \r
-The kernel is associated to a unique user who can launch only one kernel at once. \r
-The kernel is launched and destroyed by voluntary actions of the user. These functions are realized via the\r
-use of scripts.</p>\r
-<p>The list of the kernel services related to communication issues is:</p>\r
-<ul>\r
- <li>The Naming service</li>\r
- <li> The Session service </li>\r
- <li>The Life Cycle service </li>\r
- <li>The Registry service </li>\r
- <li>The Notification service </li>\r
-</ul>\r
-<p>This list is enlarged with CORBA independent services :</p>\r
-\r
-<ul>\r
- <li>The module catalog service </li>\r
- <li>The Data Type Catalog service </li>\r
- <li>The resource catalog service </li>\r
-</ul>\r
-<p> SALOME kernel module also encapsulates the Engine\r
-<i><a href="#cont">Back to the contents</a></i>\r
-<a name="2"></a><h2>2. Basic principles </h2>\r
-<p>The SALOME user's desktop is a process on a machine. This process includes:</p>\r
-<ul>\r
- <li>A graphic interface (based on Qt), </li>\r
- <li>A text interface (Python interpreter), </li>\r
- <li>A 3D visualization window shared by components.</li>\r
-</ul>\r
-<p>SALOME Modules decompose into an interface (widgets GUI, text mode TUI, 3D visualization V3D) and\r
-an engine.</p>\r
-<p>The description of a module and its components is obtained by consulting the module catalog.</p>\r
-<p>The interface is dynamically loaded in the process of the SALOME user's desktop. The engine is a CORBA\r
-server launched either on the local machine or on the distant machine.</p>\r
-<p>The engine (CORBA server) is created by a factory (or container). \r
-This factory is also a CORBA server. Several containers can be present on a machine. \r
-Some containers are specialized for types of components requiring a specific management. \r
-For example, a specific container is required for components performing parallel calculations.\r
-The engine includes at least a dynamically linked library in the container process. \r
-This library is the implementation of the CORBA server associated to the engine. \r
-If the engine is built from a pre-existent executable code, the library is simply a wrapper of the encapsulated code. \r
-It launches the code in a separate process. Wherever possible, the code is included into the dynamic library.\r
-<p>The container is one of the kernel services. If one needs to create a container on a distant machine, one creates a process resuming a part of the kernel services. The kernel can create other containers on distant machines via the trader (rsh). All the containers and the kernel share the same CORBA naming service with which they register.</p>\r
-<p>The user reaches the functions of various SALOME'S components, either in graphic interactive mode (GUI) or in command mode ( TUI), via a Python interpreter.</p>\r
-<i><a href="#cont">Back to the contents</a></i>\r
-<a name="3"></a>\r
-<h2>3. Services and features of the SALOME kernel module </h2>\r
-<p>This section gives a brief overview of the services composing the kernel module. \r
- The <a href="overview_Life_Cycle.html">Life Cycle</a> and <a href="overview_Naming.html">Naming</a> \r
- services are described in separate chapters of this reference manual.</p>\r
- \r
-<a name="3_1"></a><h3>3.1 Session service </h3>\r
-<p>SALOME session describes the period starting from the kernel creation and \r
- ending with its destruction. During this period the user can connect the session \r
- and disconnect from it without ending this session. One connection log could \r
- be written. A priori, no information resulting from another (past) session can \r
- be used by the current session. </p>\r
- <p>Implementation of this service in SALOME application is provided by the class \r
-<a href="interfaceSALOME_1_1Session.html">Session</a> encapsulated in the package \r
-<a href="namespaceSALOME.html">SALOME</a>.</p> \r
-\r
-<a name="3_2"></a><h3>3.2 Registry service </h3>\r
-<p> The active component registry should contain:</p>\r
-\r
-<ul>\r
- <li>The list of the active components</li>\r
- <li>The list of the active containers during a SALOME session.</li>\r
-</ul>\r
-<p>It should allow the state of a session. It also should allow to know if session can be stopped.</p>\r
-<p>The API reference for this service is not included in the current version of the reference manual.</p>\r
-\r
-<a name="3_3"></a><h3>3.3 Notification service </h3>\r
-<p>The notification service is a kernel function which allows exchanging of events between CORBA objects.</p>\r
-<p>In comparison with traditional CORBA event service, SALOME notification service allows to:</p>\r
-<ul>\r
- <li>Filter the events, </li>\r
- <li>Structure the events,</li>\r
- <li>Establish quality policies of services,</li>\r
- <li>Subscribe to various event channels.</li>\r
-</ul>\r
-<p>The API reference for this service is not included in the current version of the reference \r
- manual. </p>\r
- \r
-<a name="3_4"></a><h3>3.4 Module catalog service </h3>\r
-<p>There are two module catalogs in SALOME application:</p>\r
-<ul>\r
-<li>General module catalog : This first catalog is common to all SALOME users once the the platform is installed (for example for a particular company or a service). This catalog will be managed by the integrator or the administrator of the platform,\r
-<li>Personal module catalog : A specific catalog for every user (possibly empty). This catalog should notably allow the developers to test a new component before integrating it into the general catalog.\r
-</ul>\r
-<p>The objective of these two module catalogs is to:</p>\r
-<ul>\r
-<li>List the available modules;\r
-<li>Allow the addition, the modification and the deletion of a module in catalogs;\r
-<li>Look for a module and\or a service fulfilling some given criteria (in catalogs);\r
-</ul>\r
-<p><p>Implementation of this service in SALOME application is provided by two classes \r
-<a href="interfaceSALOME__ModuleCatalog_1_1ModuleCatalog.html">ModuleCatalog</a>and <a href="interfaceSALOME__ModuleCatalog_1_1AComponent.html">AComponent</a> encapsulated in the package \r
-<a href="namespaceSALOME__ModuleCatalog.html">SALOME_ModuleCatalog</a>.</p> \r
-\r
-<a name="3_5"></a><h3>3.5 Data type catalog </h3>\r
-\r
-<p>The data exchanged between components services have definite types. During description of input, output, and \r
-configuration parameters of components in the module catalog, the\r
-definition of the parameters types is taken from data type catalog. During the editing of execution of \r
-graphs, it is necessary to check that the connections output-input parameters are of compatible\r
-types.</p>\r
-<p>The data types correspond to CORBA object classes, including attributes and access methods (defined by their IDL). \r
-These types can be created by specialization of generic data types.</p>\r
-<p>The purpose of the data type catalog is to:</p>\r
-<ul>\r
-<li>List the available data types in the catalog;\r
-<li>Browse the type hierarchy to check the compatibility of types (specialized output toward generic input);\r
-<li>Allow the addition, the modification and the deletion of a data type in the catalog;\r
-</ul>\r
-<p>The API reference for this service is not included in the current version of the reference \r
- manual. </p>\r
- <a name="3_6"></a><h3>3.6 Resource catalog</h3> \r
- \r
-<p>This catalog describes machines, possible types of container on a machine, resources of machines... This catalog is used by the SALOME LifeCycle service.</p>\r
-<p>The API reference for this service is not included in the current version of the reference \r
- manual. </p>\r
- \r
-<a name="3_7"></a><h3>3.7 Engine</h3> \r
-<p>The engine represents a shared library which can be dynamically loaded by a container. The container can load this library, \r
-given an interface name and an implementation\r
-name. The container dynamically resolves an extern_C function in the library,\r
-which constructs the CORBA Engine servant object.</p>\r
-<p>The SALOME engine in\r
- the current version of the application is implemented \r
- as <b>Engines</b> package of interfaces. It encapsulates two classes: Component, Container.</p> \r
-<p>The API refernce for <b>Engines</b> package can be found <a href="namespaceEngines.html">here</a>. \r
-</p>\r
-<a name="3_7_1"></a><h4>3.7.1 Component class</h4> \r
-<p>This class is used for interaction between the container and the component and between the components inside the container. \r
-</p> \r
-<p>The API reference for this class can be found <a href="interfaceEngines_1_1Component.html">here</a>.</p>\r
-\r
-<a name="3_7_2"></a><h4>3.7.2 Container class</h4> \r
-<p>This class provides a set of methods which are necessary for definition of the process of loading and registration of new components in SALOME application.</p> \r
-<p>The API reference for this class can be found <a href="interfaceEngines_1_1Container.html">here</a>.</p>\r
-\r
-<i><a href="#cont">Back to the contents</a></i> \r
-</body>\r
-</html>\r
+<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+ <meta name="GENERATOR" content="Mozilla/4.73 [en] (WinNT; I) [Netscape]">
+ <title>Main Page</title>
+<link href="doxygen.css" rel="stylesheet" type="text/css">
+</head>
+<body>
+
+<center><table WIDTH="96%" >
+<tr>
+<td><a href="http://www.opencascade.com"><img src="sources/logocorp.gif" BORDER=0 height=46 width=122></a></td>
+
+
+<td>
+<div align=right><a href="http://www.opencascade.org/SALOME/"><img src="sources/application.gif" BORDER=0 height=46 width=108></a></div>
+</td>
+</tr>
+</table></center>
+
+
+<h1><a name="page2">General overview</a>
+</h1>
+<a name="cont"></a><h2>Table of contents </h2>
+<b><i>
+<ul>
+ <li><a href="#1">1. Introduction</a></li>
+ <li><a href="#2">2. Basic principles </a></li>
+
+ <li><a href="#3">3. Services and features of the SALOME kernel module</a></li>
+ <ul>
+ <li><a href="#3_1">3.1 Session service</a></li>
+ <li><a href="#3_2">3.2 Registry service </a></li>
+ <li><a href="#3_3">3.3 Notification service </a></li>
+ <li><a href="#3_4">3.4 Module catalog service </a></li>
+ <li><a href="#3_5">3.5 Data type catalog </a></li>
+ <li><a href="#3_6">3.6 Resource catalog </a></li>
+ <li><a href="#3_7">3.7 Engine </a></li>
+ <ul>
+ <li><a href="#3_7_1">3.7.1 Component class </a></li>
+ <li><a href="#3_7_2">3.7.2 Container class </a></li>
+ </ul>
+ </ul>
+</ul>
+</i> </b> <br>
+<a name="1"></a><h2>1. Introduction</h2>
+<p>The kernel corresponds to the minimal set of services required for the use of SALOME components (Supervisor, IAPP).
+The kernel is also used by application software components (solver) and their container.
+The kernel is associated to a unique user who can launch only one kernel at once.
+The kernel is launched and destroyed by voluntary actions of the user. These functions are realized via the
+use of scripts.</p>
+<p>The list of the kernel services related to communication issues is:</p>
+<ul>
+ <li>The Naming service</li>
+ <li> The Session service </li>
+ <li>The Life Cycle service </li>
+ <li>The Registry service </li>
+ <li>The Notification service </li>
+</ul>
+<p>This list is enlarged with CORBA independent services :</p>
+
+<ul>
+ <li>The module catalog service </li>
+ <li>The Data Type Catalog service </li>
+ <li>The resource catalog service </li>
+</ul>
+<p> SALOME kernel module also encapsulates the Engine
+<i><a href="#cont">Back to the contents</a></i>
+<a name="2"></a><h2>2. Basic principles </h2>
+<p>The SALOME user's desktop is a process on a machine. This process includes:</p>
+<ul>
+ <li>A graphic interface (based on Qt), </li>
+ <li>A text interface (Python interpreter), </li>
+ <li>A 3D visualization window shared by components.</li>
+</ul>
+<p>SALOME Modules decompose into an interface (widgets GUI, text mode TUI, 3D visualization V3D) and
+an engine.</p>
+<p>The description of a module and its components is obtained by consulting the module catalog.</p>
+<p>The interface is dynamically loaded in the process of the SALOME user's desktop. The engine is a CORBA
+server launched either on the local machine or on the distant machine.</p>
+<p>The engine (CORBA server) is created by a factory (or container).
+This factory is also a CORBA server. Several containers can be present on a machine.
+Some containers are specialized for types of components requiring a specific management.
+For example, a specific container is required for components performing parallel calculations.
+The engine includes at least a dynamically linked library in the container process.
+This library is the implementation of the CORBA server associated to the engine.
+If the engine is built from a pre-existent executable code, the library is simply a wrapper of the encapsulated code.
+It launches the code in a separate process. Wherever possible, the code is included into the dynamic library.
+<p>The container is one of the kernel services. If one needs to create a container on a distant machine, one creates a process resuming a part of the kernel services. The kernel can create other containers on distant machines via the trader (rsh). All the containers and the kernel share the same CORBA naming service with which they register.</p>
+<p>The user reaches the functions of various SALOME'S components, either in graphic interactive mode (GUI) or in command mode ( TUI), via a Python interpreter.</p>
+<i><a href="#cont">Back to the contents</a></i>
+<a name="3"></a>
+<h2>3. Services and features of the SALOME kernel module </h2>
+<p>This section gives a brief overview of the services composing the kernel module.
+ The <a href="overview_Life_Cycle.html">Life Cycle</a> and <a href="overview_Naming.html">Naming</a>
+ services are described in separate chapters of this reference manual.</p>
+
+<a name="3_1"></a><h3>3.1 Session service </h3>
+<p>SALOME session describes the period starting from the kernel creation and
+ ending with its destruction. During this period the user can connect the session
+ and disconnect from it without ending this session. One connection log could
+ be written. A priori, no information resulting from another (past) session can
+ be used by the current session. </p>
+ <p>Implementation of this service in SALOME application is provided by the class
+<a href="interfaceSALOME_1_1Session.html">Session</a> encapsulated in the package
+<a href="namespaceSALOME.html">SALOME</a>.</p>
+
+<a name="3_2"></a><h3>3.2 Registry service </h3>
+<p> The active component registry should contain:</p>
+
+<ul>
+ <li>The list of the active components</li>
+ <li>The list of the active containers during a SALOME session.</li>
+</ul>
+<p>It should allow the state of a session. It also should allow to know if session can be stopped.</p>
+<p>The API reference for this service is not included in the current version of the reference manual.</p>
+
+<a name="3_3"></a><h3>3.3 Notification service </h3>
+<p>The notification service is a kernel function which allows exchanging of events between CORBA objects.</p>
+<p>In comparison with traditional CORBA event service, SALOME notification service allows to:</p>
+<ul>
+ <li>Filter the events, </li>
+ <li>Structure the events,</li>
+ <li>Establish quality policies of services,</li>
+ <li>Subscribe to various event channels.</li>
+</ul>
+<p>The API reference for this service is not included in the current version of the reference
+ manual. </p>
+
+<a name="3_4"></a><h3>3.4 Module catalog service </h3>
+<p>There are two module catalogs in SALOME application:</p>
+<ul>
+<li>General module catalog : This first catalog is common to all SALOME users once the the platform is installed (for example for a particular company or a service). This catalog will be managed by the integrator or the administrator of the platform,
+<li>Personal module catalog : A specific catalog for every user (possibly empty). This catalog should notably allow the developers to test a new component before integrating it into the general catalog.
+</ul>
+<p>The objective of these two module catalogs is to:</p>
+<ul>
+<li>List the available modules;
+<li>Allow the addition, the modification and the deletion of a module in catalogs;
+<li>Look for a module and\or a service fulfilling some given criteria (in catalogs);
+</ul>
+<p><p>Implementation of this service in SALOME application is provided by two classes
+<a href="interfaceSALOME__ModuleCatalog_1_1ModuleCatalog.html">ModuleCatalog</a>and <a href="interfaceSALOME__ModuleCatalog_1_1AComponent.html">AComponent</a> encapsulated in the package
+<a href="namespaceSALOME__ModuleCatalog.html">SALOME_ModuleCatalog</a>.</p>
+
+<a name="3_5"></a><h3>3.5 Data type catalog </h3>
+
+<p>The data exchanged between components services have definite types. During description of input, output, and
+configuration parameters of components in the module catalog, the
+definition of the parameters types is taken from data type catalog. During the editing of execution of
+graphs, it is necessary to check that the connections output-input parameters are of compatible
+types.</p>
+<p>The data types correspond to CORBA object classes, including attributes and access methods (defined by their IDL).
+These types can be created by specialization of generic data types.</p>
+<p>The purpose of the data type catalog is to:</p>
+<ul>
+<li>List the available data types in the catalog;
+<li>Browse the type hierarchy to check the compatibility of types (specialized output toward generic input);
+<li>Allow the addition, the modification and the deletion of a data type in the catalog;
+</ul>
+<p>The API reference for this service is not included in the current version of the reference
+ manual. </p>
+ <a name="3_6"></a><h3>3.6 Resource catalog</h3>
+
+<p>This catalog describes machines, possible types of container on a machine, resources of machines... This catalog is used by the SALOME LifeCycle service.</p>
+<p>The API reference for this service is not included in the current version of the reference
+ manual. </p>
+
+<a name="3_7"></a><h3>3.7 Engine</h3>
+<p>The engine represents a shared library which can be dynamically loaded by a container. The container can load this library,
+given an interface name and an implementation
+name. The container dynamically resolves an extern_C function in the library,
+which constructs the CORBA Engine servant object.</p>
+<p>The SALOME engine in
+ the current version of the application is implemented
+ as <b>Engines</b> package of interfaces. It encapsulates two classes: Component, Container.</p>
+<p>The API refernce for <b>Engines</b> package can be found <a href="namespaceEngines.html">here</a>.
+</p>
+<a name="3_7_1"></a><h4>3.7.1 Component class</h4>
+<p>This class is used for interaction between the container and the component and between the components inside the container.
+</p>
+<p>The API reference for this class can be found <a href="interfaceEngines_1_1Component.html">here</a>.</p>
+
+<a name="3_7_2"></a><h4>3.7.2 Container class</h4>
+<p>This class provides a set of methods which are necessary for definition of the process of loading and registration of new components in SALOME application.</p>
+<p>The API reference for this class can be found <a href="interfaceEngines_1_1Container.html">here</a>.</p>
+
+<i><a href="#cont">Back to the contents</a></i>
+</body>
+</html>
