Skip to content

zArchive: Action Notes

Jump to bottom
Andrew Berezovskyi edited this page Mar 6, 2020 · 1 revision

Notes on OSLC Actions v2.0.

Specification: actions.html Notes: Actions, Actions Specification Strategy

Core TC Actions, open-services.net The Actions 2.0 specification is not part of OSLC Core 2.0, it is a separate specification that is extended by Automation 2.0.

Motivation

What appears to be needed is some simple CEP like MQTT or Pub/Sub capability like IFTTT or Zapier that allows an OSLC app to send events and data to other interested OSLC apps. This would provide additional behavioral integration through loose coupling between the applications. It would also allow mediation applications to act as controllers for the integration of OSLC apps without having any direct impact on those apps in terms of data, UI or behavior.

Actions is the opposite of this - it allows providers to advertise actions on resources that clients can discover and invoke - like reflective remote procedure calls.

CEP is an inverted model that allows providers to advertise events that might occur, and for clients to discover, subscribe to, and respond to those events.

Both approaches are useful -

  • Actions: Client Initiates or Drives the scenario
  • CEP: Provider Initiates or Drives the scenario.

Profile: The minimal subset of an OSLC core or domain specification that clients and servers must implement.

Review Notes

Accommodations for actions that can be performed on, or in the context of, a resource.

  • provides a list of actions that can be performed on a resource
  • users do not have to know the resource type, properties, lifecycle, etc.

Provides a means of discovering actions on resources. State transitions. List actions on a resource without needing to understand type, properties, lifecycle.

Actions bindings define:

  • what actions are available on a resource - its oslc:action properties
  • what they do
  • how to execute the action
  • how to determine if it succeeded or failed

Providers - annotate resources with actions

Consumers -

  • discover available actions on resources
  • domain or profile specific clients use specifications to define actions
  • Generic (cross-domain) clients rely on Actions to display and/or invoke actions
  • access the resource URI
  • discover actions and bindings on resources
  • execute those actions
  • determine success or failure

Server Exposes resources with actions, executing actions, provide results

  1. What resources provide actions
  2. For each resource
    1. find existing actions that can have bindings
    2. add the actions to be exposed as a new oslc:binding or oslc:action link

Client Discover actions it needs to consume, executes them, and uses the result

  1. What resources require actions
  2. for each resource:
    1. find available actions using oslc:action predicate
    2. For each action:
      1. use oslc:binding predicate to discover available bindings
      2. For Each Binding
        1. For each HTTP interaction pattern supported by the consumer
          1. Determine if client is compatible with binding
          2. determine whether the binding uses that interaction pattern
          3. ensure interaction pattern adheres to any restrictions on the bindings the consumer can execute
  3. If at least one binding is compatible with the client, then the action is compatible with this consumer
  4. invoke the action based on instructions for forming and making the request in the oslc:binding
  5. process the result

Definitions

Action: LDP resource describing a commonly used means to accomplish an end based on HTTP interaction pattern The description of an End and a Means of achieving the end via HTTP-based interaction patterns. a process or operation that cam be excited against a resource

  1. What the action does
  2. How to execute the action
    • the Resource URI
    • access action bindings on R using oslc:action and oslc:binding properties
    • execute the desired binding
  3. How to determine if it was successful

Providers annotate resources with actions Consumers discover available actions

  • Domain specific clients may be constrained
  • Generic clients only rely on the Actions specification

Action Binding: a means of, or instructions for executing an action: URI and request body. Actions can have multiple bindings for different interaction patterns.

A means of executing an action. An action may have multiple action bindings for different interaction patterns. Each binding uses an interaction pattern nd specific value that consumer much apply to that iteration pattern in order to execute the particular action.

  • Find bindings for an action using the oslc:binding property
  • Determine if consumer is compatible with the binding - the binding uses the integration pattern and adheres to restrictions on the binding the consumer can execute
  • Execute the action by following the iteration pattern

Interaction Pattern: how client and server interact to execute an action, clients use action binding to recognize interaction patterns, instruction for sending messages, and determining results.

An abstract definition of how a consumer and provider interact to execute an action including a rule to recognize and action binding uses the interaction pattern, instructions for sending messages, and instructions to access the result. Templates

  • for resource creation, automation scripts, query template, etc.

Example interaction patterns:

  • HTTP request with empty body
  • HTTP request with Resource Ship in the request body
  • HTTP request with fixed body
  • Automation request
  • Delegated UI dialog for immediate execution
  • Delegated UI dialog for later execution
  • Automation Creation Factory

Specification Profile: Subset of a specification, often used in domain specifications. Actions specification profile defines interaction patterns for each action resource governed by that profile and provided by an actin binding. Used to define specific subsets of capabilities provided by servers and consumed by clients.

Summary

Resource oslc:action oslc:Action*. Action

  • title
  • description
  • type (at least oslc:Action)
  • oslc:binding [http:Request, oslc-automation:AutomationRequest, oslc:Dialog]
  • oslc:executes oslc:Action — future actions

http:Request

  • requestURI
  • mthd [POST | other]
  • httpVersion
  • body - ResourceShapes for parameters
  • usage usage pattern for the resource
  • oslc:finalStatusLocation

Open Issues

  • There are too many, complex interaction patterns. The purpose of these different interaction patterns are to give servers flexibility in how they provide access to resource actions, and clients flexibility on how to invoke the actions and get the results. Interactions would typically be:
  • Simple HTTP request/response with or without an entity request body
  • Specific message patterns to reflect a client/server protocol for more complex sequences of actions
  • Long running conversations
  • Asynchronous interactions

However, this moves the complexity to requiring clients to determine compatible interaction patterns and can result in higher coupling. Actions should consider simplification to one basic RESTful interaction pattern, and let clients implement interactions patterns in their own code as needed, using more primitive RESTful services.

For example, it is not clear that pattern-delegated-execution-dialog is needed. A client can use a more primitive action and put up their own dialog to effect their desired UI.

The OASIS 3.0 specification was essentially copied and reformatted from the 2.0 specification and has not yet been updated.

  • Section 1, especially section 1.2 does should provide a scenario and example. It is difficult to understand Actions from the current description
  • The introduction relies on terms that are not defined until section 2.
  • Intended audience seems out of order
  • Motivation, Basic Concepts are empty
  • Core Actions references non-core Automation TC specification
  • There are no examples

Main links

Clone this wiki locally