[Oslc-Automation] Oslc-Automation Digest, Vol 8, Issue 4
Pramod K Chandoria
pchandor at in.ibm.com
Thu Oct 13 03:13:27 EDT 2011
Hi All,
Thanks for providing valuable comments on the Automation Tool integration
scenario.
<David>
>One thing I believe this scenario does not take into account is when the
>automation tool is a server/client implementation, it is assuming that
the
>automation server does not do any of the work and relies on standalone
>automation tools to perform work.
</David>
I agree with what David said that there could be both ways where
1. Automation provider itself is Automation tool as well
2. Automation provides is backed by heterogeneous or homogeneous
Automation tools/Agents
Practically We have observed that #2 is most common case like Build Forge,
Rational Quality Manager, Rational Team Concert all do not provides
automation capability by itself but depends on Automation Desktop Tools or
Command Scripts
One of the exception I have observed is AppScan server (Security Testing),
which falls under case #1. There might be other as well I am not aware of.
However for #1 case, We really don't require Automation Tool integration
scenario but for #2 it is extremely important.
The strong reason behind case #2 to be part of Automation spec is the fact
that, Automation Tool are heterogeneous.
e.g. RQM can use automation services from HP's QTP, Load Runner, or IBM's
RFT, RPT, Robot or any other automation tool in the world.
Integrating such Automation tools with Automation providers using standard
specification like OSLC Automation specification would provide such tools
to work out of the box with any such Automation provides.
This scenario is important to allow a large range of automation tools
market to be able to compliant with the spec we brings out.
Broadly speaking, proposed scenario does not go out of synch with what we
have been talking about the AutomationPlan, Automation Request and
Automation Result.
It just fits into the right position and answers "How to get Automation
Result from AutomationPlan".
It does not introduce any new resources here. Although if consider Tool
Registeration step(fist step of the scenario) to be standardized, it might
define another resource say "AutomationTool".
To answer to Charles comments and questions:
1. Yes registration is one time. Rerunning the Tool should just change
status of previously registered tool.
3. Exactly this is where this scenario fits into, Automation tool picks up
the Automaton Request created out of AutomationPlan to 'execute' it
4. Automation tool query for work, query url provided by Automation
provider. It is automation server which decides where to look for work.
Interestingly there could be two approaches here i.e. Static
binding and Dynamic binding
4.1 Automaton Request is bound to one of the registered Automation
tool. This is more important when end user decides where AutomationPlan
should be executed (early binding)
4.2 Automaton request is not bound to any tool. Any tool which
polls first gets work assigned and then Automaton Request is bound to that
"ready" tool .
It is like who comes first is better then anyone else who
might or might not be in available.
5. I think most of these information are custom to the tool expect some
common properties I have observed
-> Actual Resource (Script) to be executed (URI, Shared location,
local path etc..
-> Arguments (What arguments are would be tool specific)
-> Environment Variable (Most critic to tweak Automation tools to
work in different environments)
6. It is more about updating the progress of the Automation Request we
have been talking about.
I believe progress update (including taken), would be import part of
Automation Request.
Essentially Automation Request has got a life cycle
Queued -> Taken -> In Progress ( 0%< progress <100%) -> Complete
(progress=100% or cancelled)
7. It is updating the progress of Automation Request as mentioned in #6
above
9. Assuming there is an OSLC API to create AutomationResult, it might be
both either created or updated by the Automation tool depending upon the
need.
An Automation Provider might create a place holder AutomationResult
and let Tool update it or just let Tool create the result and update it
back to Automation Request to link the data.
e.g. An Automation Request might get cancelled before it can complete.
In that case it might not make sense always create results up front.
Automation Result is not the place holder for anything else except the
actual result of running the automation. It make sense to persist any
temporary data like (status, messages, error, variables, snapshots etc) in
the
Automation Request which relates to the governance of the the execution
activity. Automation Result is purely a result out of execution.
10. It does not introduce any new artifact. It is same AutomationResult.
It might be creation or update.
Regards,
___________________________________________________________________________
-|- Pramod K Chandoria
Advisory Software Engineer
IBM Rational, India Software Lab
Bangalore, India | +91-80-417-77045 | +91 99805 68253
What's new | Ask Question in forum | Online Help | Download RQM 3.0.1
From: oslc-automation-request at open-services.net
To: oslc-automation at open-services.net
Date: 10/13/2011 03:08 AM
Subject: Oslc-Automation Digest, Vol 8, Issue 4
Sent by: oslc-automation-bounces at open-services.net
Send Oslc-Automation mailing list submissions to
oslc-automation at open-services.net
To subscribe or unsubscribe via the World Wide Web, visit
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
or, via email, send a message with subject or body 'help' to
oslc-automation-request at open-services.net
You can reach the person managing the list at
oslc-automation-owner at open-services.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Oslc-Automation digest..."
Today's Topics:
1. Scenario for automation server/automation tool (worker,
agent, etc) interaction (Michael F Fiedler)
2. Re: Scenario for automation server/automation tool
(worker,
agent, etc) interaction (David N Brauneis)
3. Re: Scenario for automation server/automation tool
(worker,
agent, etc) interaction (Charles Rankin)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Oct 2011 12:10:45 -0400
From: Michael F Fiedler <fiedler at us.ibm.com>
To: oslc-automation at open-services.net
Subject: [Oslc-Automation] Scenario for automation server/automation
tool (worker, agent, etc) interaction
Message-ID:
<OF73FDE9B5.B612EC41-ON85257927.00511838-85257927.0058E012 at us.ibm.com>
Content-Type: text/plain; charset=US-ASCII
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.
It raises interesting points on how the instances performing the actual
automation work/execution find their providers and how they receive their
work (push/pull). We'll discuss the scenario in the next workgroup
meeting, but any discussion before then can take place on the list.
Examples of other interactions with automation providers would be of
interest.
[1] -
http://open-services.net/bin/view/Main/AutomationScenarios#AutomationTools
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
------------------------------
Message: 2
Date: Wed, 12 Oct 2011 16:53:44 -0400
From: David N Brauneis <brauneis at us.ibm.com>
To: Michael F Fiedler <fiedler at us.ibm.com>
Cc: oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
Subject: Re: [Oslc-Automation] Scenario for automation
server/automation tool (worker,
agent, etc) interaction
Message-ID:
<OF2EF667D0.319D9C24-ON85257927.00718797-85257927.0072C7C3 at us.ibm.com>
Content-Type: text/plain; charset="us-ascii"
One thing I believe this scenario does not take into account is when the
automation tool is a server/client implementation, it is assuming that the
automation server does not do any of the work and relies on standalone
automation tools to perform work.
I'm not sure this should be a part of the core scenarios for the first
version of the specification - this was discussed and debated in the past
but it was decided that the OSLC specification should not force a pattern
here either push or pull or define how the agent/agentless
systems/endpoints communicate with the server.
Regards,
David
____________________________________________________
David Brauneis
STSM, Rational Software Delivery Automation Chief Architect (RAF)
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
From: Michael F Fiedler/Durham/IBM at IBMUS
To: oslc-automation at open-services.net
Date: 10/12/2011 12:44 PM
Subject: [Oslc-Automation] Scenario for automation
server/automation tool (worker, agent, etc) interaction
Sent by: oslc-automation-bounces at open-services.net
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.
It raises interesting points on how the instances performing the actual
automation work/execution find their providers and how they receive their
work (push/pull). We'll discuss the scenario in the next workgroup
meeting, but any discussion before then can take place on the list.
Examples of other interactions with automation providers would be of
interest.
[1] -
http://open-services.net/bin/view/Main/AutomationScenarios#AutomationTools
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20111012/03712007/attachment-0001.html
>
------------------------------
Message: 3
Date: Wed, 12 Oct 2011 16:34:00 -0500
From: Charles Rankin <rankinc at us.ibm.com>
To: oslc-automation at open-services.net
Subject: Re: [Oslc-Automation] Scenario for automation
server/automation tool (worker,
agent, etc) interaction
Message-ID:
<OF821EE64E.AB524CCA-ON86257927.00712ABB-86257927.0076779B at us.ibm.com>
Content-Type: text/plain; charset="us-ascii"
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.html
>
------------------------------
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
End of Oslc-Automation Digest, Vol 8, Issue 4
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20111013/22291768/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20111013/22291768/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3624 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20111013/22291768/attachment-0001.gif>
More information about the Oslc-Automation
mailing list