<span style=" font-size:10pt;font-family:sans-serif">Hi Erik,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
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.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">SMStandardReply</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
AbstractEchoRequest (cardinality 1 and only 1)</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
AbstractWrapper (cardinality 1 or more)</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">The SMStandardReply
class would contain parameters that would be applicable to all replies,
e.g.</span>
<br>
<ul>
<li><span style=" font-size:10pt;font-family:sans-serif">Generating Organisation</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Generation time</span>
<li><span style=" font-size:10pt;font-family:sans-serif">etc.</span></ul>
<br><span style=" font-size:10pt;font-family:sans-serif">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.</span>
<br>
<ul>
<li><span style=" font-size:10pt;font-family:sans-serif">Status of request</span>
<li><span style=" font-size:10pt;font-family:sans-serif">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)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">etc.</span></ul>
<br><span style=" font-size:10pt;font-family:sans-serif">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;</span>
<br>
<ul>
<li><span style=" font-size:10pt;font-family:sans-serif">Configuration
Profile(s)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Event Sequence(s)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Service Agreement(s)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Service Package(s)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Trajectory(ies)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Delta DOR Scan
Pattern(s)</span>
<li><span style=" font-size:10pt;font-family:sans-serif">Service Instance
Configuration File(s)<br>
</span></ul><span style=" font-size:10pt;font-family:sans-serif">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).</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Cheers for now,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Colin</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif"><br>
---------------------------------------------------------------------------------------------------------<br>
Dr. Colin R. Haddow,<br>
HSO-GI, European Space Agency,<br>
European Space Operations Centre,<br>
Robert-Bosch-Str 5,<br>
64293 Darmstadt,<br>
Germany.<br>
<br>
Phone; +49 6151 90 2896<br>
Fax; +49 6151 90 3010<br>
E-Mail; colin.haddow@esa.int<br>
---------------------------------------------------------------------------------------------------------<br>
</span><PRE>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@esa.int).
</PRE>