Early discussion about Exposing arbitrary actions on RDF resources
From http://open-services.net/pipermail/oslc-automation_open-services.net/2013-May/000425.html
When I think about this,
I envision two predominant camps of providers. Those that are effectively
generic with no idea what their actions are doing, and those that are
purpose built which have an explicit understanding of what they are being
asked to do. In the generic case, I don’t see any really viable way for
this to be handled without conscious intent by the users of the provider
in creating appropriate automation teardown plans (possibly dynamically)
to complement those that were created to instantiate the environment. So,
in the generic case, the coupling of multiple automation plans into a
cohesive group is user-defined. For the purpose-built case, my
expectation is there is a “resource” that exists that the provider knows
it can take a specific set of actions on (possibly with the ability to
have that set extended by the user). As a simple example, let’s think of
a system for managing Virtual Machines. The VM is the resource here, and
the system likely knows how to instantiate one, (re)start/stop it, and
delete it. Technically, there are probably two resources, the VM image
and the live VM instance. You’d take the instantiation action on the
image and the (re)start/stop and delete actions on the instance. That
distinction will actually come in handy in a moment.
Keeping with the VM example. I would expect that the provider would
expose the VM image as a resource of some kind (but not as an Automation
Plan itself). In that resource there would be a link to the instantiate
action (i.e., the Automation Plan that knows how to instantiate an
instance of that image). A consumer could submit an Automation Request
for that Automation Plan. The Automation Result generated from that,
amongst other things, would have a link (probably through a Contribution)
to the resultant VM instance (which is, again, some other type of
resource, but not an Automation Result itself). That instance would have
links to various actions (Automation Plans) that could be taken on it
(e.g., the (re)start/stop and delete mentioned above). Note, the
“provider” I mentioned at the top of this paragraph is really two (or
more) providers. One for the VM resources (and whatever domain/spec they
belong to) and one for the Automation spec.
In the generic provider scenario, I would envision that further actions
that could be taken as a result of the completion of one Automation Plan
would show up as contributions on the first. Those contributions may be
dynamically generated by the first automation plan itself, or generated by
the provider due to (user-defined) metadata associated with the Automation
Plan. It seems like it could be useful for us to define this type of
contribution explicitly (mostly just an action name/type and a link to the
appropriate Automation Plan).
From http://open-services.net/pipermail/oslc-automation_open-services.net/2013-May/000427.html
My feeling is that the Automation Plan is a definition of the action
that is to be taken, not of the resource on which the action is to be
taken. Typical OSLC resources describe some form of “object” (give me a
touch of latitude here for the sake of an upcoming analogy). And OSLC
describes mechanisms to do basic CRUD (Create/Read/Update/Delete)
operations on them (in OO parlance, OSLC would provide new/delete and
getter/setter methods). My view is that the OSLC Automation spec provides
a means to define arbitrary “functions” or “methods” for OSLC “objects”
(or “actions” on “resources” if you prefer).
In the v2 version of the spec, I think we basically worked through the
mechanics of how to execute/invoke actions in a standardized way. Now, as
we look to the v3 version of the spec, we are really starting to
understand how to apply that mechanism to various tasks and/or domains.
In the generic provider scenario, I think there are exactly 3 plans here,
one for each of restart/start/stop. One of the parameters into the plan
would be the URL to the VM Instance resource upon which to act. Thus, it
doesn’t actually scale out based on the number of VM Instances. For the
purpose built provider, I could easily see the same mechanism being used,
meaning the references to the restart/start/stop plans on the VM Instance
are pointing to the “generic” versions, and you still pass the VM Instance
URL as one of the parameters. And, if it’s truly purpose built, then the
plans are likely to not exist as real resources, but rather OSLC
Automation facades to existing functionality. So, the definitions are
just generated (or responded to) on the fly.
Responses:
Pros:
- Can expose arbitrary number of arbitrary actions on any RDF resource
- Reuses existing ability to execute an action
Cons:
