The Resource Agent Model has been defined with the COI Resource Management services.
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 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)
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
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
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).
- 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
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.