13.07.2015 Views

Mission Operations Reference Model. Draft ... - CCSDS

Mission Operations Reference Model. Draft ... - CCSDS

Mission Operations Reference Model. Draft ... - CCSDS

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

DRAFT RECOMMENDED PRACTICE FOR MISSION OPERATIONS REFERENCE MODELf) Provider Application. Implements the service-specific behaviour of the relevant MOservice specification.g) Provider MO Service Layer. Responsible for converting from the generic messagesprovided by the MAL abstract service below it to the service interface exposed to aprovider application.h) Provider MAL. Provides the standard messaging service that is used by the MOService Layer to communicate with its service consumer peer. All messagestransported by the MAL are passed via a Provider Access Control component via astandard abstract interface.i) Provider Access Control. Implements a standard service interface defined by theMAL and provides access control to services from the provider point of view. It canreject messages or augment with security credentials any messages that pass throughthe MAL. The actual access control policy in place is deployment specific.j) Provider Message Transport. Implements a standard message transport interfacedefined by the MAL for the transport of messages from a source to a destination. It isresponsible for converting the message from the language-specific representation tothe wire-level representation required for that transport. Combines both the relevantmessaging aspect (most probably a COTS) and an adaptation from the MAL interfaceto that software.NOTE – Whilst the above layers must logically be present in both the consumer andprovider, there is no requirement for them to physically be layered using softwareAPIs, etc. For example, it is perfectly legitimate for a service consumer orprovider to hardcode all aspects of the layers as long as all MO Services, MALand transport requirements are adhered to.3.4 SERVICE MESSAGESService messages are exchanged between a service consumer and provider to facilitate therequired service operation.a) A message is an abstract entity that is passed from one component to anothercomponent in the MO service model.b) Its physical representation is dependent on the programming language in use, theexchange point in the stack, and (at the Transport layer) the transport in use in thatdeployment.c) The physical representation is irrelevant conceptually as the model is concerned withinformation exchange. As long as the representation preserves all information, thenphysical presentation is only a concern for the immediate sender and receiver at thatpoint.<strong>CCSDS</strong> 520.1-R-1 Page 3-3 October 2009

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!