[Oslc-Automation] Scenario for automation server/automation tool (worker, agent, etc) interaction

[Charles Rankin]

oslc-automation-bounces at open-services.net wrote on 10/12/2011 11:10:45 AM:

> As discussed at the end of the last workgroup meeting, Pramod Chandoria 
has
> provided a proposed scenario [1] for how automation providers or servers
> interact with automation tools/agents/workers.

Thanks to Pramod for posting the scenario. 

> [1] -
> 
http://open-services.net/bin/view/Main/AutomationScenarios#AutomationTools

[CVR: Note, I've inlined the scenario for easier comments]

> 1. Automation Tool registers with Automation Server with the type of 
Automation Tool. Automation Server responds back with a URL to look for 
further work

I'm still of the opinion that "agents" (that's the term I'll use for this 
discussion) should be out of scope for the first spec.  For sake of 
discussion though, we would need to determine what "registers" means here. 
 Is this the creation of an, as yet undefined, AutomationAgent resource? 
That would normally be a one-time operation.  I seem to recall from 
previous discussion that in the specific tool that Pramod was working 
on/with that this was done each time the agent was started.  In that case, 
I'm guessing we would want an error if the same AutomationAgent resource 
was being created again (as opposed to getting duplicates created).  This 
could then trigger the agent to update the AutomationAgent with current 
information (e.g., last start time).  I would expect the creation request 
to come back with the URL to the newly created AutomationAgent on success. 
 In either case, the agent will likely need to obtain the URL used to 
query for work via another means.  This may be straightforward, since it 
already has the ServiceProvider for doing the initial AutomationAgent 
creation.

> 2. Automation Server User (manual or scheduling facility) initiates 
Execution of a Automation plan. 
>(Either user can choose one of the registered tool for execution or 
Automation Server can decides itselt to dynamically 
> allocate Execution to one of the Registered Automation tool.)
>
> 3. An Automation Task is created to track this request.

At present, we had been talking about the creation of an AutomationRequest 
resource (containing parameters) which references an AutomationPlan (which 
will be executed with the provided parameters).  It's a separate 
discussion (that really needs to happen soon, <grin>) of how all that will 
actually work, but I'm going to assume that there is traceability from the 
resultant AutomationRequest resource that is returned to the 
AutomationResult object that actually tracks the progress of automation as 
it runs.  However, I'm unclear if the "Automation Task" that you reference 
is one of these three resources, or if it is a new resource that hasn't 
been discussed yet.

> 4. Automation Tool polls periodically to Automation Server on provided 
URL for any work assigned

This should be viable given normal OSLC query capabilities.  Granted, we 
would need to figure exactly what resource(s) is/are being queried and 
what properties differentiate work for one agent from another.

> 5. Automation Tool, upon finding an Automation Task, follows the link to 
get more information about the request 
So, from the query in #4, the agent follows the link to the specific 
resource that it needs to operate on.  It would be useful to get a few 
examples of what "information" the agent will be looking for.  I'm mostly 
interested in whether this is information that is passed in via the 
AutomationRequest (which will be defined at some point), or if there is 
other "information" that might be needed as well.  In the latter case, I'm 
wondering if that is something that we'll want to standardize, or if it is 
assume that will be custom extensions on a tool by tool basis.
> 6. Automation Tool picks up the work and updates the Automation Server 
about the work it has taken

What does this really mean?  Is this simply an update of whatever resource 
represents the "Automation Task" referenced earlier?
I'll interject here that I'm skeptical that someone could use the OSLC 
Automation specification to create a generic agent that could work with 
any arbitrary OSLC Automation spec provider to perform work for it.  I 
strongly believe that we'll find that specific tools need specific agents 
with custom knowledge carried between them.  I would love to be wrong 
here.  And perhaps there is something that could be done if you can 
scope/type the agents.  I'm not sure we want to go there though 
(particularly in the first version of the spec).
> 7. Automation tool continues to work and keeps on updating Automation 
Server with progress and any other status messages.

Just to be clear, what resource is being updated here?  I had hoped this 
would be the AutomationResult, but I suspect this is still the "Automation 
Task" referenced in #3.  After that we need to determine how we would 
represent progress (states, percentage indicator, or something more 
sophisticated) and "status messages".
> 8. Optionally an user can Cancel the Automation task. Automation tool 
upon receiving such instruction cancel further execution and update 
Automation Task

This likely goes back to the AutomationRequest mechanism.  However, there 
does seem to be an implication that the agent will be polling some 
resource on a regular basis to determine if the "Automation Task" is still 
"live".  Is that what we want?  Maybe this is another case where an 
eventing/notification system would prove useful?
> 9. Automation Tool upon completion of the work, Creates Automation 
Result back to Automation Server.

And, this is why I assumed that "Automation Task" wasn't really 
referencing the AutomationResult.  :)  I think that the creation of the 
AutomationResult should happen by the underlying OSLC Automation spec 
provider during initial "execution".  I could see the agent updating the 
AutomationResult, but I'm not sold on it doing the creation.  In fact, I 
think I'd go so far as to say that AutomationResults are not externally 
createable at all.  Thoughts?

> 10. Automation tool updates Automation task to link with the result 
created and and mark Automation task as complete with 100% progress. 

This just continues my disconnect.  As an AutomationResult was intended to 
be the result of an ("executed") instance of an AutomationPlan.  This 
seems to indicate that the AutomationResult links to the "Automation 
Task".  Is simply reusing the same AutomationResult resource definition in 
multiple places, or is there a separate resource definition associated 
with AutomationPlans and with "Automation Tasks"?
Thanks again, Pramod, for posting the scenario.  There are lots of 
interesting things in this scenario, hence all my questions.  I've also 
got a lot of questions about presumed semantics of the various different 
tools that will be looking to implement the OSLC Automation Spec.  I'll 
wait on those until we can get some more clarity on how we would want this 
scenario to work.

Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20111012/aaa2d952/attachment-0003.html>