[Oslc-Automation] Parameters: need for input and output parameters?
Pramod K Chandoria
pchandor at in.ibm.com
Fri Jan 6 12:17:33 EST 2012
If we do that ("define a ResultContribution type that is a name-value
pair"), that does not help to distinguish between what to be passed on to
next automation v/s what not to pass, except we decide to pass all
parameters to next request.
Comparatively, 'output parameters' could provide opportunity to limit
explicitly what is available as input for next automation request in
sequence. However It brings another problem who and how determines what to
be made available in output parameters. I think it would be the
responsibilities of the workflow orchestrator to determine what to be
passed on from one request to next request.In that case distinguishing
between input and output parameter may not be of worth.
Currently RQM uses similar concept to pass variables from one Testcase
Execution to next for Test Suite execution. In this case all variables all
passed and merged to next request.
There is NO difference between input v/s output parameter. At any stage,
any request have collection of parameters without distinguishing what was
input, what was modified or added. The result of request have all
parameters copied from request.
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: David N Brauneis <brauneis at us.ibm.com>
To: oslc-automation at open-services.net
Date: 01/06/2012 09:42 PM
Subject: Re: [Oslc-Automation] Parameters: need for input and
output parameters?
Sent by: oslc-automation-bounces at open-services.net
Paul,
I guess that I was not making the assumption that contribution is
necessarily a "resource" but that it could be... In fact, could we not
define a ResultContribution type that is a name-value pair???
Regards,
David
____________________________________________________
David Brauneis
STSM, Rational Software Delivery Automation Chief Architect
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
From: Paul McMahan/Raleigh/IBM at IBMUS
To: oslc-automation at open-services.net
Date: 01/06/2012 10:33 AM
Subject: Re: [Oslc-Automation] Parameters: need for input and
output parameters?
Sent by: oslc-automation-bounces at open-services.net
I was thinking that the difference between contributions and output
parameters is that a contribution is a "resource" - i.e. an autonomous
artifact with properties of its own that can be inlined in the result or
referenced via URL. On the other hand, output parameters are name/value
pairs that can be used to facilitate further downstream automation. For
example, another automation request might be created with input parameters
copied from the automation result's output parameters. Another scenario
could be if the provider actually changed the value of a particular input
parameter during the automation and needs to make a record of that. If
the parameters were not distinguished as input vs. output then there
wouldn't be any way to denote that the provider had used a different (or
maybe just more refined) value than what was provided as input.
Best wishes,
Paul McMahan
Rational Quality Manager
From: David N Brauneis/Raleigh/IBM at IBMUS
To: oslc-automation at open-services.net
Date: 01/06/2012 10:10 AM
Subject: Re: [Oslc-Automation] Parameters: need for input
and output
parameters?
Sent by: oslc-automation-bounces at open-services.net
Michael,
Thanks for taking the time to write this information up to the give the
group a starting point for the discussion going forward... I'm mostly in
agreement with everything that you have written down so far with the
exception of the outputParameters. I'm having a little trouble getting my
head around the need for an outputParameter and how that is really
different than a ResultContribution. Perhaps I am just being a little
dense
but I was thinking that the parameters (name-value pairs) would be input
with the request and would be read-only in the result but that anything
created during processing (like an MD5 checksum) would be a
ResultContribution. Am I thinking about this completely differently than
everyone else?
Regards,
David
____________________________________________________
David Brauneis
STSM, Rational Software Delivery Automation Chief Architect
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: 01/05/2012 09:22 PM
Subject: [Oslc-Automation] Parameters: need for input and output
parameters?
Sent by: oslc-automation-bounces at open-services.net
An important point came up at the end of today's call around the zero-many
*parameter* attribute on Automation Plans, Requests and Results. There
was
sentiment that there needs to be a distinction between input parameters
and
output parameters for Results, and possibly for each of the resources.
Continuing the discussion, here are some thoughts on what the usage might
be for each artifact:
Automation Plan: The parameters are likely to all be input parameters.
Some may have default values, others may be empty. These provide
consumers with a starting point of what parameters are required for
successful request creation. Are there scenarios for output parameters on
the Plan? None are occurring to me.
Automation Request: When creating a Request, consumers provide the input
parameters for actual automation execution (or at least the subset of
parameters they have control over). There is likely a scenario for the
service provider adding additional parameters to the request, but they
would still be input parameters. Is there a scenario for output
parameters on the Request artifact? Possibly as the result of processing
that the service provider does to "accept" the Request?
Automation Result: The input parameters here would be a "final" record of
what parameters were used to run this automation and create the result.
As discussed today, there also seems to be a strong case for output
parameters on the result. I.e., as the automation executed, certain
information, apart from the main result contributions, is generated and
needs to be captured in the result - especially for consumers of the
result
such as downstream automations. Examples might be the MD5 hash of a
binary which was the result of an automation or the filesystem location of
the primary automation result artifact.
We never reached the point of proposing it, but I think the direction was
to propose 2 sets of parameter attributes/predicates: inputParameter and
outputParameter. From the descriptions above, outputParameter might only
be appropriate for a subset of the artifacts, but could be included on all
for symmetry.
Comments? We'll discuss in the next meeting, but a discussion on list
would be fine as well.
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
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
_______________________________________________
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/20120106/5511253a/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/20120106/5511253a/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/20120106/5511253a/attachment-0001.gif>
More information about the Oslc-Automation
mailing list