[Oslc-Automation] Scenarios for outputParameter on Automation Request
Pramod K Chandoria
pchandor at in.ibm.com
Mon Oct 22 16:13:13 EDT 2012
The scenarios to consider which demands parameter on automation request
resource
Scenario 1:
1. User submits an Automation Request for execution
2. Automation Request is picked up by one of the [worker] 'client' of
Automation Provider
3. 'client' start initiating the automation
4. 'client' needs to change certain parameter or provide additional
parameter during the course of initiating, executing and completing the
automation
4. Upon completion of the automation, 'client' POST Automation result,
passing parameters from Automation request.
Scenario 2: Chaining the execution: First specification version has not
addressed it explicitly, but still providers can implement it's own
chaining mechanism
1. User submit request for execution of 'Group of Automation Plan', [kind
of sequential workflow].
2. Automation service provider generates automation request for the first
Automation Plan
3. 'client' executes the first Automation Request and completes it
4. Automation provider upon completion of first Automation request,
triggers execution of next Automaton Plan in sequence.
5. It creates Automation Request for next step, passing all parameters
from previous step. This passing of parameters continue from step to step.
I think the reason we are perceiving that outputParameter is not that
important from end user scenario perspective who is looking for final
result after submitting the request.
However if look from little different "how" perspective, how provider will
execute the automation, it might make sense. I am assuming most of the
automation providers will need some sort of 'client' to execute the
automation.
The current specification enforces implementers should create the
Automation Result as early as Automation Request is submitted for
'clients' to participate in contributing to the parameters
Regards
-|- Pramod Chandoria
From: Michael F Fiedler <fiedler at us.ibm.com>
To: oslc-automation at open-services.net
Date: 10/22/2012 11:25 PM
Subject: [Oslc-Automation] Scenarios for outputParameter on
Automation Request
Sent by: "Oslc-Automation"
<oslc-automation-bounces at open-services.net>
In last Thursday's automation workgroup meeting we discussed the recent
mailing list thread [1] on the possible need for an outputParameter (or
perhaps other name) attribute on Automation Requests. Pramod agreed to
consider documenting a scenario he had thought of on the list for
consideration. Some of the points from the workgroup meeting were:
- It is understood that the purpose of the outputParameter attribute on
the Result is a means recording what parameters went into producing the
result without saying anything about when they were introduced.
- it is understood that a provider could add such an attribute itself,
even if not defined in the spec, if it is useful for its scenarios.
Drawback would be generic consumers might not look there for it.
- the scenario around using an attribute in the Request as a placeholder
or means of carrying parameters across the execution was probably not
sufficient in itself. But Pramod had put some thought into future
chaining or composite automation where it may be useful or required and
will document.
If anyone else has scenarios around this where you feel having
outputParameters (or some attribute to hold new/changed parameters on the
request), please bring them up on the list.
[1] -
http://open-services.net/pipermail/oslc-automation_open-services.net/2012-October/000326.html
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/20121023/c632c3e0/attachment.html>
More information about the Oslc-Automation
mailing list