[email protected] 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
