 |
 |
|
|
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.
The list of the kernel services related to communication issues is:
This list is enlarged with CORBA independent services :
SALOME kernel module also encapsulates the Engine Back to the contents
The SALOME user's desktop is a process on a machine. This process includes:
SALOME Modules decompose into an interface (widgets GUI, text mode TUI, 3D visualization V3D) and an engine.
The description of a module and its components is obtained by consulting the module catalog.
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.
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.
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.
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.
Back to the contentsThis section gives a brief overview of the services composing the kernel module. The Life Cycle and Naming services are described in separate chapters of this reference manual.
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.
Implementation of this service in SALOME application is provided by the class Session encapsulated in the package SALOME.
The active component registry should contain:
It should allow the state of a session. It also should allow to know if session can be stopped.
The API reference for this service is not included in the current version of the reference manual.
The notification service is a kernel function which allows exchanging of events between CORBA objects.
In comparison with traditional CORBA event service, SALOME notification service allows to:
The API reference for this service is not included in the current version of the reference manual.
There are two module catalogs in SALOME application:
The objective of these two module catalogs is to:
Implementation of this service in SALOME application is provided by two classes ModuleCatalogand AComponent encapsulated in the package SALOME_ModuleCatalog.
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.
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.
The purpose of the data type catalog is to:
The API reference for this service is not included in the current version of the reference manual.
This catalog describes machines, possible types of container on a machine, resources of machines... This catalog is used by the SALOME LifeCycle service.
The API reference for this service is not included in the current version of the reference manual.
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.
The SALOME engine in the current version of the application is implemented as Engines package of interfaces. It encapsulates two classes: Component, Container.
The API refernce for Engines package can be found here.
This class is used for interaction between the container and the component and between the components inside the container.
The API reference for this class can be found here.
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.
The API reference for this class can be found here.
Back to the contents