[cssm] Possible future use case for wrapper class with respect to CPIF, SPDF, Simple Schedule etc.

[Colin.Haddow at esa.int]

Hi Erik,
               after I replied to your earlier e-mail about the CPIF and 
wrapper classes some vague thoughts I'd had when I was initially defining 
the wrapper classes resurfaced. I'd meant to follow then up at the time, 
but the day job got in the road.

We have deliberately not tried to define how data entities generated as a 
result of SMURF requests are returned to the requestor, leaving that as an 
issue for the Management Service. However when I was defining the Wrapper 
classes it struck me that these could be useful in returning data. If we 
assume that we would use some sort of standard Reply data entity for 
returning data entities (a bit like the SMURF for the requests), then this 
could look something like

SMStandardReply
        AbstractEchoRequest (cardinality 1 and only 1)
        AbstractWrapper (cardinality 1 or more)

The SMStandardReply class would contain parameters that would be 
applicable to all replies, e.g.

Generating Organisation
Generation time
etc.

each SMStandardReply would contain 1 and only 1 instance (I think that it 
would make sense for a reply to deal with only 1 request, or possibly part 
of 1 request) of a class derived from the EchoRequestClass. The concrete 
class derived from this would contain metadata specific to the request 
type, e.g.

Status of request
Planning period range (for the case of a service package request with a 
standing order this would indicate the time range for which the enclosed 
SPDFs had been generated for, hence the above comments about a reply 
possibly only dealing with part of a request - standing orders could 
result in several replies being generated for 1 request)
etc.

each SMStandardReply would contain 1 or more instances of a concrete class 
derived from the AbstractWrapper class. The cardinality here is based on 
the fact that some of the SMURF requests can result in several data 
entities being returned, e.g. the Information Request can result in zero 
or more of each of the following data entities being returned;

Configuration Profile(s)
Event Sequence(s)
Service Agreement(s)
Service Package(s)
Trajectory(ies)
Delta DOR Scan Pattern(s)
Service Instance Configuration File(s)

As the above is pretty much hypothetical, and we don't really no yet what 
the Management service if going to look like, its probably too early to 
update the CPIF to add a wrapper class on the off change that the 
management service ends up using a data structure similiar to that above. 
I think however that it illustrates a possibly use case for the wrapper 
classes with respect to the CPIF, SPDF, Simple Schedule and Service 
Agreement, (there already being use cases for the wrapper class with 
respect to config profile, event sequence, trajectory data, DDOR scan 
patterns and SICFs).

Cheers for now,

Colin


---------------------------------------------------------------------------------------------------------
Dr. Colin R. Haddow,
HSO-GI, European Space Agency,
European Space Operations Centre,
Robert-Bosch-Str 5,
64293 Darmstadt,
Germany.

Phone; +49 6151 90 2896
Fax;      +49 6151 90 3010
E-Mail;  colin.haddow at esa.int
---------------------------------------------------------------------------------------------------------
 
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20211104/2a3084a9/attachment.htm>