The component ‘SLE Operations’ shall implement one operation object class for every SLE operation defined for the service types it supports. Common operations shall be provided by all implementations.
NOTE – Common operations are defined in this subsection. Service-type specific operations are defined in the relevant supplemental Recommended Practice for the service-specific API.
Operation objects shall store the parameters defined for the SLE operation, and provide read and write access to these parameters. For confirmed operations, operation objects shall contain the invocation parameters and the return parameters.
A reference to the interface ISLE_Reporter may be optionally passed as an argument to the creator function. This interface can be used by implementations to report errors and inconsistencies detected in the attributes of operation objects.
The component shall provide an ‘operation factory’, which shall create operation objects in response to requests received via the interface ISLE_OperationFactory.
A reference to the operation factory shall be returned by the creator function for the component.
The operation object to be created shall be specified by an identifier for the operation object interface, the operation type, the service type and the version number of the service. When the component does not support objects with the specified interface, the service type, or version number, or when the operation is not defined for the service type and version the factory shall reject the request.
Following creation, the parameters held by an operation object shall be set to the initial values defined in annex A.1.1.1.1.1.1.1 for common operations and in the relevant supplemental Recommended Practice for the service-specific API for service-type specific operations.
NOTE – Deletion of operation objects shall be achieved by the reference counting scheme defined in annex A.1.48.1.1.1.1.2.
Unless specified differently in annex A.1.1.1.1.1.1.1, data passed to operation objects shall be considered the property of the operation object and be deleted when the object itself is deleted.
3.4.2Characteristics of Operation Objects
Common characteristics of operation objects shall be defined by the interface ISLE_Operation, which shall be inherited by all interfaces exported by operation objects.
NOTE – This subsection specifies essential characteristics but does not address every method of the interface. Annex A.1.1.1.1.1.1.1 defines the methods.
An operation object shall be identified by the combination of an identifier for the operation, an identifier for the service type and the version number of the service type. Operation objects shall provide methods to query these identifiers.
Operation objects shall provide methods to verify that the invocation arguments are complete, consistent and in range.
NOTES
The checks are specified in annex A.1.1.1.1.1.1.1 for common operations and in the relevant supplemental Recommended Practice for the service-specific API for service-type specific operations. These checks assume that the operation object has been passed from the proxy or is about to be passed to the proxy. Therefore the checks do not include parameters handled by the proxy.
Implementations may issue log messages to report errors detected by these methods using the interface ISLE_Reporter passed to the creator function of the component.
All operation objects shall store the parameter for the invoker credentials.
Operation objects shall provide a method to produce a human readable string including the names and values of all parameters set in the object. For binary data, the method shall produce a dump of hexadecimal digits, where the maximum length of the dump is constrained by an argument to the method.
NOTE – This specification does not prescribe the format of the printout nor the names of the parameters. When defining the output it should be considered that it will be included into diagnostic traces and must be interpreted by humans. The output should be understandable to engineers that are not programmers.
In order to increase performance, the interfaces provided by operation objects are not safe in a multi-threaded environment. However, operation objects shall support an advisory lock that can be set on the object. This lock must be used by clients in a multi-threaded environment. The implementation shall prevent self-inflicting deadlocks.
3.4.3Characteristics of Confirmed Operation Objects
Common characteristics of objects implementing confirmed operations shall be defined by the interface ISLE_ConfirmedOperation, which is inherited by all interfaces exported by confirmed operation objects.
NOTE – This subsection specifies essential characteristics but does not address every method of the interface. Annex A.1.1.1.1.1.1.1 defines the methods.
Confirmed operations shall store the invocation identifier used in the invocation PDU and in the return PDU.
Confirmed operations shall store the result of the operation and, if the result is set to ‘negative’, the associated diagnostics.
Confirmed operation objects shall store the parameter for the performer credentials.
Confirmed operation objects shall provide methods to verify that the return arguments are complete, consistent, and in range.
NOTE – The checks are specified in annex A.1.1.1.1.1.1.1 for common operations and in the relevant supplemental Recommended Practice for the service-specific API for service-type specific operations. These checks assume that the operation object has been passed from the proxy or is about to be passed to the proxy. Therefore the checks do not include parameters handled by the proxy.
All implementations shall provide operation objects for the following SLE operations:
the operation BIND;
the operation UNBIND; and
the operation PEER-ABORT.
The operations for association management shall be included in the set of service-type specific operations provided for a given service type. The implementation shall ensure that the service type information returned by these objects matches the service type for which it has been created.
NOTE – This specification implies, for instance, that a BIND operation object that has been created for the FSP service always returns the service type identification ‘FSP’.
3.4.4.2Other Common Operations
All implementations shall provide objects for the following SLE operations, which are used for more than one SLE service type:
NOTE – TRANSFER BUFFER is actually not defined as an SLE operation by the CCSDS Recommended Standards for return link services (references [4] and [5] and [6]). Within the API, the operation object shall implement the transfer buffer used for return link services. It shall correspond to the PDU used for transmission of the transfer buffer.
These operations shall be included into the set of service-type specific operations provided for a given service type. The implementation shall ensure that the service type information returned by these objects matches the service type for which it has been created.
NOTE – This specification implies, for instance, that a STOP operation object that has been created for the FSP service always returns the service type identification ‘FSP’.
The operation object for the pseudo-operation TRANSFER BUFFER shall provide a facility to queue and to de-queue any type of operation objects. The object shall not check what operation objects are inserted into the buffer.
NOTE – It is considered the responsibility of the client to insert only those objects for which buffering has been defined in the CCSDS Recommended Standards for return link services (references [4] and [5] and [6]). This implies that a client extracting objects from the buffer must verify that the type of the object is correct. Details on the features provided for queue handling are defined by the interface in annex A.1.1.1.1.1.1.1.
The component SLE Operations shall implement the following component objects and interfaces:
NOTE – Component objects are defined in annex A.1.48.1.1.1.1.2 of this specification. As explained there, a component object is an externally visible entity that may be implemented by a single object or by several internal objects, which co-operate to provide the required external view. As specified in annex A.1.48.1.1.1.1.2, every component object shall support the interface IUnknown in addition to the interfaces listed in this subsection. The interfaces referenced in the following are specified in annex A.1.1.1.1.1.1.1.
an object for the operation object factory exporting the interface ISLE_OperationFactory; and
operation objects for all operations required by the SLE service types supported.
NOTE – A separate object shall be supported for every operation object created via the operation factory.
Operation objects shall export the following interfaces and provide navigation between these interfaces via QueryInterface():
the interface ISLE_Operation;
the interface ISLE_ConfirmedOperation, if the SLE operation supported by the object is confirmed; and
the interface specified for the operation type supported by the object.