[Oslc-Automation] Oslc-Automation Digest, Vol 8, Issue 4

David N Brauneis brauneis at us.ibm.com
Thu Oct 13 03:59:43 EDT 2011


Pramod,

I really think that we are getting off the point of OSLC levels of 
integration when we are prescribing as a part of the specification how the 
automation server communicates and registers with it's endpoints...and 
then we are further complicating it by trying to define how the actual 
commands or tools are used by those endpoints - I think this never going 
to be able to really gain acceptance (think that many of the tools that 
are invoked during an automation plan could just be command shells, ant, 
make, maven, compilers, middleware administration tools, etc.). Do we 
really think that everyone that provides a tool (that might ever be called 
by an automation process) is going to generate OSLC interfaces for it???

Also, many of the tools that play in the automation space are not 
necessarily automation tools but tools that can be used in an automated 
workflow.

If you really believe different tools from different categories need to 
provide a common interface to invoke and get results, perhaps that is 
something that would be better for the specifications in those individual 
areas as tools from the different categories might actually be quite 
different in how they are invoked and what they require/return.

It feels like the scenario for the specification is forcing a specific 
implementation in the automation server space and that will limit what 
automation servers can/will participate in implementing and/or consuming 
the specification.

Actually I believe that Rational Team Concert - Team Build actually falls 
into both category1 and category 2 because of some of the built-in 
functionality provided for invoking some tools already.

As for other products that might fall into category 1, some examples would 
be:
        Hudson*
        Tivoli Provisioning Manager*
        Rational Automation Framework*

* Note: These products might also fall into category 2 as well in some 
cases.

Just my thoughts...but I think we are really biting off a lot for the 
first version of the specification (not saying this is not something to 
look at over time but this is going to significantly raise the bar to 
entry for implementation).

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:   Pramod K Chandoria <pchandor at in.ibm.com>
To:     oslc-automation at open-services.net
Cc:     oslc-automation-bounces at open-services.net
Date:   10/13/2011 03:15 AM
Subject:        Re: [Oslc-Automation] Oslc-Automation Digest, Vol 8, Issue 
4
Sent by:        oslc-automation-bounces at open-services.net



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
*********************************************
_______________________________________________
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/20111013/cc9bde6f/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/cc9bde6f/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/cc9bde6f/attachment-0001.gif>


More information about the Oslc-Automation mailing list