Skip to end of metadata
Go to start of metadata

Overview of "Define Interaction" Use Case

Describe pattern of interaction between actors


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

Metadata

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

Actors Protocol Specification Developer
References List of Repositories; Scribble
CIAD COI OV Conversation Management
UC.R1.10 Define Interaction
Uses  
Is Used By  
Extends  
Is Extended By  
In Acceptance Scenarios None
Technical Notes Interaction patterns are the blueprints for service conversations; they are specified electronically. Observers can (eventually) monitor conversations for compliance with an interaction pattern.
Lead Team COI
Primary Service Federated Facility Services (Virtual Organization) Part 1
Version 1.6
UC Priority 4
UC Status Mapped + Ready
UX Exposure PGM

Summary

This information summarizes the Use Case functionality.

The interaction patterns are the message sequences and formats between distributed (service) processes and other processes. Define an interaction pattern, using an Interaction Pattern Specification Language, by registering it; specifying its commands, states, conditions, and roles; validating it; and putting it into a repository.

Assumptions

  • Interaction pattern specification language exists and is sufficient for the Interaction Patterns to be specified in Release 2.

Initial State

System developer has identified a service requiring communication with other service(s) in the system, and wants to characterize those communications.

Scenario for "Define Interaction" Use Case

  1. Protocol Specification Developer names, registers, and characterizes interaction pattern.
    1. Interaction pattern can be registered before fully specified; in this case the specification is empty initially and incrementally enhanced (thereby creating new versions of the pattern)
    2. Interaction pattern can be registered once fully specified; this step would be partly invisible.
  2. Protocol Specification Developer creates interaction pattern definition using interaction pattern specification language.
    1. Define set of commands (aka operations, verbs, performatives). Each message in interaction pattern conveys one of the commands with additional context (aka arguments).
    2. Define states in which commands can be sent or received.
    3. Define conditions which may generate/anticipate more messages (an interaction pattern).
    4. Define roles for interacting participants in a pattern; specific participant processes assume such roles, when a pattern is instantiated into a conversation
    5. Command set may be partitioned into subsets used by complementary roles in a communication.
  3. <3> Protocol Developer registers latest version of interaction pattern definition as new version whenever changes are made.
  4. <3> When believed ready for use, interaction pattern definition is validated by automated processes.
    1. This can be as simple as successfully parsing the interaction pattern specification language.
  5. Source code to perform standard interface or monitoring tasks in (arbitrary) programming languages are implemented manually to meet the interaction pattern definition.
  6. A System Process Programmer associates processes to the interaction pattern through the interaction pattern repository.
  7. <1> Process monitoring interceptors analyze each message in a conversation communicated using this interaction pattern, comparing observed interactions to the interaction pattern definition.

Final State

Interaction pattern has been defined and associated with a service.

Comments

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

Interaction Patterns are invariant even as the operations of the participants may vary. The definition of the interaction pattern can be updated only by creating a new interaction pattern that effectively replaces the previous.

The Interaction Patterns are applied at the API level only. They enable automatic negotiation, validation, and governance.

Although Release 2 implements interactions manually, in future releases source code may be produced automatically for many CI tasks.

(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

Labels

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.
  1. Apr 19, 2012

    John Graybeal says:

    Can this be priority 2 or 3?

    Can this be priority 2 or 3?