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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Michael F Fiedler/Durham/IBM@IBMUS To: [email protected] Date: 01/05/2012 09:22 PM Subject: [Oslc-Automation] Parameters: need for input and output parameters? Sent by: [email protected] 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 [email protected] 919-254-4170 _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
