Skip to end of metadata
Go to start of metadata

Resource Agent Model

The Resource Agent Model has been defined with the COI Resource Management services.

Resource Agent Interactions

A resource can be a physical resource, a service, an application, etc. The Resource Agent has responsibilities for monitoring, control, contract management, and to advertise the capability of the resource.

Generic Interaction Patterns

Generic patterns include Simple-Request, Request-Response, and Subscribe. In the following, we first show these generic patterns and then describe how they are used for Resource Agent interactions.

Figure 1. Simple Request interaction pattern (OV-6)

Figure 2. Request-Response interaction pattern (OV-6)

Figure 3. Subscribe interaction pattern (OV-6)

Monitoring Interactions

A Resource Agent can:

  • monitor resource events or states
    • pull strategy - the Resource Agent asks explicitly for state getState(). Could be a full Request-Response pattern, where Resource Agent plays Requester role and Resource plays Participant role
    • push strategy - the Resource Agent subscribes to changes and the resource fires events or notifies when state changes. Uses the Subscribe pattern, where Resource Agent plays Requester role, and Resource plays Participant role
  • monitor the messages exchanged by the resource. It can observe messages and build an internal state model for the resource
  • get information from the host environment (JVM, host container, platform, cluster environment) regarding the resource. Could be a full Request-Response pattern, where Resource Agent plays Requester role, and Resource plays Participant role
  • project resource state to the environment. Uses the Subscribe pattern, where the environment plays Requester role, and Resource Agent plays Participant role

Control Interactions

A Resource Agent can request the resource to execute a command (e.g., start up, shut down, etc). Could be a Simple-Request pattern (for resources that you cannot rely on to answer to commands) or a full Request-Response pattern (where resources will reject the command or execute it and send a result back). Resource Agent plays Requester role and Resource plays Participant role

Advertise Capability

At startup of the resource, the agent will update the Resource registry (or Service Registry) with the description of the resource (capability, interaction patterns supported, etc).

Life cycle:

  • Deploy phase: A deployer states the existence of an instance of a resource agent and an instance of a resource and the binding between the two
  • Install/configure phase: Beforehand or the first time the resource agents runs an install and registers the resource capabilities
  • Use phase: the resource agent starts the resource

Contract Management Interactions

For the general concepts of sending and receiving messages in the context of governance (contracts), see Capability Container interactions

When a resource sends a message, it goes to the capability container who sets some headers and sends the message to the Resource Agent. The agent will update its knowledge base and act - the sender agent might block the message to go out, in which case the denial should propagate back to the application. If the agent does not block the message, it goes to the signer, who adds the signature. Then, the Messaging Abstraction component converts it to AMQP format and sends it to the Broker.

When a resource receives a message, it will have additional steps via the Message Validator and Policy Enforcement Point.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.