Introduction to SLE API.

The ESA SLE API package uses TCP/IP for communications. The TCP and IP protocols are available as part of the operating system for all supported platforms. The operating systems also provide programs for configuration of these protocols.

An API supporting SLE user applications interfaces directly with TCP, and does not require any further infrastructure. An API supporting SLE provider applications uses a special TCP communications server process as indicated in Figure 1 .

The communications server process must be started before any application starts the API. It is recommended to start it as a background (daemon) process after booting the operating system. When the API in an application process is started, it establishes an inter-process communication (IPC) channel to the communication server process. When the application creates and configures a service instance, the API registers the service instance identifier at the communications server process. The API de-registers the service instance identifier, when the application deletes the service instance.

Figure 1: Communications Infrastructure for the ESA SLE API Package

The communication server process

• listens for incoming TCP connect requests;
  
  
• receives BIND invocations and routs them to the application process that has registered the service instance identifier identified in the BIND invocation PDU;
  
  
• receives SLE PDU?s from the TCP connection and passes them to the proxy in the application process;
  
  
• accepts SLE PDU?s from the proxy in the application process and transmits them via the TCP connection;
  
  
• sends log messages, notifications and trace records associated with a TCP connection to the proxy.
  
  

When receiving a BIND invocation with a service instance identifier that has not been registered, the communications server process rejects the BIND invocation with the appropriate diagnostics.

If an application wishes to receive log messages and notifications that are not related to a registered service instance, it must provide a process that receives these messages via the ?default logger? interface. This can be a special process or a process using the API. Only one single instance in one single process can use this interface at a time.

The NCTRS can be used as well in third-party missions support. In such a case, the external MCS is connected to the IP network via a firewall.