1. CSTS Generic Procedures Assessment of the Current Status and Proposal for Next Steps M.Goetzelmann 12.09.2005

2. From the Athens Minutes “The Working Group received proposals to restructure the existing operations: group, divide and create new ones. The working-group participants agreed that the selection of the operations to be covered by the Tool Kit must be justified. In order to justify an operation, it must be part of a procedure.”

3. Procedures identified / described 1.Association control: BIND, UNBIND, PEER-ABORT ( ) 2.Authentication: all operations ( ) 3.Production status handling, based on CLTU (Annex G) production status ( ) Note: Document addresses configuration setting, state transitions, and status reporting 4.Throw-Event: THROW-EVENT, THROW-EVENT confirmation, Asynchronous notification reporting the result of the performed action ( ) 5.Status reporting: SCHEDULE-STATUS-REPORT required to initialize STATUS-REPORT ( )

4. Procedures identified / described (2) 6.Notification: ASYNC-NOTIFY ( ) Note: cancelled as procedure (TBC) 7.Configuration Query GET ( ) 8.Directive: INVOKE-DIRECTIVE specific to FSP (?) 9.Data processing: START, TRANSFER-DATA, STOP for forward service type ( ) 10.Data delivery: START, TRANSFER-DATA, STOP for return service type ( )

5. From the Athens Minutes (2) The following possible procedures were identified for the future services: –Procedures associated to Monitoring: JPL identified a set of scenarios / procedure. Note: Procedure/Service specification provided –RUFT –Radiometric –Monitoring (an Control) –Telemetry catalogue –Off-line: FTP based (TBD)

6. Discussions / Teleconference Procedures and “Auxiliary Procedures” –Operations sequencing –Authentication Patterns Procedures versus Operations

7. Observations Procedure definitions –are very detailed –Generally focus more on the sequence of interactions than on the purpose and semantics (“use case”) –mostly describe what is defined in the SLE books and are therefore often not generic enough for use in new services –Provide little explanation on the purpose and meaning of parameters Discussions often focused on how to present procedures and not on what is needed for what purpose

8. Objectives Athens: –justification for operations to be included into a generic toolkit specifications Considerations derived from experience with procedure definitions –Procedures capture behavior that cannot be described by addressing only operations –Some generic procedures allow/require a first step of refinement of abstract operations (example: Notify in Data Delivery) –Truly generic procedures could be a constituent element of a generic specification in their own right (in addition to operations)  Can we specify a catalogue of generic procedures (supported by extensible operations) from which future services can pick what they need and refine procedures if necessary?

9. Questions to be addressed later How to present operations and procedures in a Recommendation for “Generic Transfer Services” How to precisely specify behavior by means of state matrices (on procedure level? globally?) How to specify “Auxiliary Procedures” (or patterns) used by multiple “first class” procedures (examples: invocation identifiers, authentication, parameter checking) Details of how confirmed vs. unconfirmed operations shall be handled Rules for refinement of operations and procedures

10. Proposal of how to proceed In splinter meetings –Starting from existing procedure specifications prepare definitions of generic procedures that can be used by future yet unknown services either directly or after refinement –As part of these procedures define the generic operations. –Establish a list of questions/issues identified during this work In the group –Review procedure specifications and questions and attempt to agree on the set of procedures/operations to include in a new book and their outline description –Discuss (name), contents, and structure of the new book(s), addressing as far as possible questions identified in the previous slide Offline –Prepare first draft of the book(s)

11. Proposed Guidelines FOCUS ON Description (in abstract terms) of the objective –what problem shall be solved? –who are the stake holders? –what should be the result Description of an abstract model defining the terminology Concepts, i.e. “the abstract solution” Description of interactions that a specific to a given procedure INITIALLY IGNORE Details of general processing (sequencing, authentication, etc) How to formalize specifications (UML, state matrices, data representation & encoding) Extensibility mechanism for operations and behavior Precise relationship between procedures & operations Just note any issues identified for later discussion

12. Backward Compatibility As a baseline it should be possible to “re-specify” the procedures in existing SLE service books by refining generic procedures in a backward compatible manner If improvements are identified these should be suggested and the impact on the existing SLE servcies assessed If necessary provide an extra section on this subject.

13. Example: Data Delivery Data Delivery TM DeliveryOther RAFRCFROCFOther Protocol View Data Delivery TM DeliveryOther RAFRCFROCFOther “Software” View

14. Proposed Contents of Procedure Specs Purpose –Describe in abstract terms the task to be solved Usage –Can the procedure be used directly? What kind of definitions must be added to make it usable? Do we foresee any specific refinement? Concepts –What are the basic ideas/mechanisms? Definitions –Precisely define the terms used on an abstract level Sequence of events –Prose description without repeating global details such as invocation identifier checking etc. –If possible provide 1 st cut of state matrix Required Operations –Describe operations focusing on parameters defined for the procedure Issues

15. Assume Availablity of Specs for Association control identifying states “bound” and “unbound” and the effects of unbinding General headers for operation invocations and returns for confirmed and unconfirmed operations Handling of confirmed operations (asynchronous behavior, invocation identifier, etc) Authentication

16. Headers proposed in the ESA Toolkit TN Confirmed Operation StructureParameters HEADER invoker-credentials performer-credentials invoke-ID result Diagnostic (codes too be added per procedure) Unconfirmed Operation StructureParameters HEADER invoker-credentials

17. Suggested List of Procedures Already Identified Procedures 1.(Buffered) Data Delivery [P1] 2.Data Processing [P1] 3.Status Reporting [P2] 4.Configuration Query [P2] 5.Throw-Event (event processing) [P3] 6.Association Control [P4] For consideration Simple/un-buffered data delivery ? Confirmed data delivery ? Configuration setting ?