Skip to end of metadata
Go to start of metadata

Overview of "Control Service Interactions" Use Case

System monitors, logs, and validates service-to-service interactions for conformance to protocol.

Tip: Key Points
UC Priority= 4 or 5: Critical, is in R2
Only boldface steps are required
<#> before a step —> lower priority
(optional) —> run-time option

Related Jira Issues:   Open   •   All


Refer to the Product Description and Product Description Release 2 pages for metadata definitions.

Is Used By  
Is Extended By  
In Acceptance Scenarios None
Technical Notes This use case deals with verifying that service-to-service interactions follow any established/defined protocols for those interactions. (It is not about policy enforcement.)
Lead Team COI
Primary Service Federated Facility Services (Virtual Organization) Part 1
Version 2.0
UC Priority 1
UC Status Mapped + Ready
UX Exposure SYS


This information summarizes the Use Case functionality.

System monitors service-to-service interactions within the system, records them for auditing purposes and flags and optionally rejects any invalid interactions.


  • Interaction monitor service is operational.

Initial State

Message is generated by a service for delivery to another service.

Scenario for "Control Service Interactions" Use Case

  1. Messages containing service-to-service interactions are routed through an interaction monitor service.
    1. Note most messages likely represent service-to-service interactions.
  2. Interaction monitoring service checks each message to see if it is subject to action.
    1. Possible actions could be Record All, Record Significant, Flag Issues, and Reject Violations.
    2. The ability to record significant, flag issues, or reject violations only applies to service interactions that are recognizable/analyzable by the interaction monitor service.
    3. Analysis is typically done by protocol verification.
  3. If message is subject to action, interaction monitor service applies appropriate policy/governance criteria to determine appropriate action(s).
    1. Actions could be Record, Flag, or Reject.
    2. Rejected interactions result in additional activities, depending on policy/governance specifications.
  4. If a message is subject to one or more actions, each appropriate action is performed in turn, until all possible actions are exhausted or an action labeled as 'final' is encountered.
  5. If no 'final' action has been encountered, message is forwarded to its (next) destination via data distribution service.

Final State

Message has been intercepted, checked for conformance to protocol, acted upon if necessary, and routed to its destination (with minimal delay).


These comments provide additional context (usually quite technical) for editors of the use case.

(click on # to go to R2 use case)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61     27B


r2-usecase r2-usecase Delete
usecase usecase Delete
productdescription productdescription Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.