[Top] | [Previous] | [Next]

Appendix F: SSCS Internal Functional APIs

The goal of an Application Programming Interface (API) definition is to identify the mandatory interfaces between system components and provide detailed characteristics about the required communication. A complete API definition for a given application should provide all information that a separate application needs in order to interface to it. For example, it should define how initiation and termination is performed, what interface protocol is used, what information is being sent and received, timing requirements, and other such attributes. A functional API should describe major implementation-independent attributes and specify the range of choices for the implementation-dependent attributes of the interface. For example, it should identify options related to publish/subscribe vs. broadcast, synchronous vs. asynchronous communication, candidate protocol and data standards.

The ultimate goal is to define a set of generic APIs that are implementation-independent. Developing software architectures based on common generic APIs increases modularity, which facilitates the plug and play of components and increases the ease with which COTS products can be integrated.

In the SSCS reference architecture the use of data stores is quite common. This implies the use of databases in the communication between processes, including flat files, relational DBMS, and object-oriented DBMS. It is important to understand that, in many cases, this communication method can be replaced by direct communication through middleware message passing for real-time processing. Security concerns or other implementation related assumptions may prohibit (or require) such variations.

Note that a number of items are To Be Determined (TBD). This is due to the complexity of precisely defining the data that flows between applications in the general case. It is not uncommon for these TBDs to persist until the API definition is actually applied in specifying an implementation.

The following is a description of the major functional interfaces between TT&C applications within the SSCS reference architecture. The API definitions consist of the following fields:

type - This defines the type of communication desired. Possible communications include request for service, acknowledgment, service result, data transfer (to/from a data store), and status.

method - This defines the delivery method of communication and is sometimes decided at implementation. Possible delivery methods include a discrete message, a published message, a continuous stream, a database read, and a data base write.

sync/async - This specifies whether the communication should be synchronous (wait until communication is complete) or asynchronous (continue processing while waiting for communication to complete).

timing - This defines any unique timing requirements for the communication.

API standards - This specifies one or more candidate API standards or protocols (formal or de facto) for communication. API standards can be defined for what is communicated between two components (e.g., IRIG time) as well as how data is communicated (e.g., SQL procedures).

data arguments - This is a description of the mandatory arguments that are passed in the communication. The following convention is used: { argument }+, which indicates a list of one or more arguments.

status reply - This is the status reply generated by the recipient of the communication. This status will often indicate success of the communication.

Of significant importance, but not presented here, are the functional APIs to system services (see Figure 4). Many efforts are underway within industry to define standard interfaces to common system services in distributed architectures.