I'm sorry but I have to disagree - most AutomationProviders will be supporting more than a single type of automation (often in a single AutomationPlan) and I do not think that many of the AutomationProviders are planning to provide multiple server instances. Most of the AutomationProviders that I can think of are more generic than this very explicit use case - things like Build Forge, Hudson/Jenkins, and even Rational Team Concert. Unless we are going to change all of the products to require a user to set this field when creating AutomationPlans (for which there will be a huge migration effort for existing products with all previously defined AutomationPlans before the OSLC Automation Specification).
This can be solved by using an optional parameter that is set as a part of your explicit provider implementation (since you will understand in your implementation which "type" these AutomationPlans are for...). Regards, David ____________________________________________________ David Brauneis STSM, Rational Software Delivery Automation Chief Architect email: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Jing Qian/New Haven/IBM To: David N Brauneis/Raleigh/IBM@IBMUS, Cc: [email protected], [email protected] Date: 07/03/2012 09:45 AM Subject: Re: [Oslc-Automation] Implementation issues when Automation type is not known Hi David, Thanks for your reply. I agree this is only an issue when a given server instance provides more than one type of Automation. But this may not be unique to only RQM, I think there could be other product sharing the same issues, i.e. In theory, Build Forge could be an automation provider for build as well as an automation provider for provisioning. So from consumer side, it would be nice if we have some kind of standard way to deal with such situation. One way would be to check for the optional AutomationType attribute if it is set. And it is the provider's responsibility to set such this attribute if they are providing more than one type of automation. This attribute does not need to be an enumeration field, it could be just a String field, servers for "label" purpose. Jing J. Qian Development, Rational Quality Manager Rational Software IBM Software Group 4205 S. Miami Blvd. Durham, NC 27703 Tel: 919-254-9455 T/L: 444-9455 From: David N Brauneis/Raleigh/IBM To: Jing Qian/New Haven/IBM@IBMUS, Cc: [email protected], [email protected] Date: 07/02/2012 05:38 PM Subject: Re: [Oslc-Automation] Implementation issues when Automation type is not known In my opinion this appears to be a problem of your own creation - you have defined two different Automation Providers for different purposes in your own product and now you are having a problem in presenting this to end users. But most of the Automation Providers are not defining themselves as an Automation Provider multiple times in a single runtime instance... Are you suggesting that we should define AutomationType as an enumeration for AutomationPlan (since it would need to be an enumeration with predefined well-known values it would have to be required). I have many concerns about this since we would essentially be forcing every other product to make changes and require end users to "type" their AutomationPlans in order to simplify your usage scenario... And would would be defining the AutomationTypes??? Most product could support numerous AutomationPlans that might be in support of different (or multiple) types of activities. This appears to be a unique RQM issue and not something that needs to be added to the specification. Regards, David ____________________________________________________ David Brauneis STSM, Rational Software Delivery Automation Chief Architect email: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 From: Jing Qian/New Haven/IBM@IBMUS To: [email protected], Date: 07/02/2012 05:17 PM Subject: [Oslc-Automation] Implementation issues when Automation type is not known Sent by: [email protected] Hi, In a previous discussion, Pramod has proposed to a oslc_auto:automationType attribute, but there is some objection to it, see the thread here - http://open-services.net/pipermail/oslc-automation_open-services.net/2012-June/000182.html see the thread here - http://open-services.net/pipermail/oslc-automation_open-services.net/2012-June/000182.html Automation plan: We don't have oslc_auto:automationType attribute. Without this we can't distinguish whether Automation is for build, test, deployment, cloud etc.. I think this needs to be typed. <dnb>I actually do not agree with an approach that types the automation, there are some automation plans that might perform one or more of those different types as a part of the workflow (think a continuous integration or continuous delivery product - i.e., DevOps)... How would you characterize those? Also, some automation providers will exist that can support more than one type of automation and do not need them to be separated. What do we gain by forcing this? </dnb> <pchandor>I think when a AutomationPlan represents a group of Automations (like TestSuite in RQM, workflow in DevOps), it might make sense to call them "complex" type. Consider a scenario like user is defining a workflow in RTC, that when a build automation is completed, wants to run a Test Automation. When user will query automation from the automation provider (RQM), It would definitely like automation plan of 'test' type be listed to choose from. Do we think this should be defined in service providers name space?. I think having a type in spec will provide client hint about what type of Automation plan it is.</pchandor> <dnb>I really think this is unnecessary, it is by choosing the automation plans from the provider where this "hint" of what the automation plan might do. I think that the type would like end up being close to unique per automation provider which kind of defeats the purpose. What about automation providers that can do some generic automation work, would it then be up to the Automation Provider to change and require the end user to define the type of automation it is from a list of categories. I do not see what the gain for the consumer is here... If I ask RQM and it returns test, if I ask RTC and it returns build, and if I ask RAF and it returns deployment (always in each of these cases) what is the purpose?</dnb> I'm bringing this discussion up again, because from end user story point of view, we have an issue not knowing the type of automation. Consider this user scenario: As a RTC user, I want to set the test(automation) result inside my build result so that I can view the test result directly from RTC. When user configures the cross server communication in RTC, the steps are usually the following Step1 - Set up server friend relationship Step2 - Set up the project areas associations If the friend server is an automation provider that provides several types of automation (build, test, provision, deployment...etc.), it could be confusing for the user which one is for which. Here is an example, RQM is an automation service provider for both test and provisioning, this could be in its rootservice.xml <jd:oslcCatalogs> <oslc:ServiceProviderCatalog rdf:about=" https://myserver1.ibm.com:9443/qm/auto/test/catalog";> <oslc:domain rdf:resource="http://open-services.net/ns/auto#"/> </oslc:ServiceProviderCatalog> <oslc:ServiceProviderCatalog rdf:about=" https://myserver1.ibm.com:9443/qm/auto/provision/catalog";> <oslc:domain rdf:resource="http://open-services.net/ns/auto#"/> </oslc:ServiceProviderCatalog> </jd:oslcCatalogs> As you can see, <oslc:domain> for these 2 service providers are the same, however, they just have different rdf:about URL, one is for test automation, the other is for provision automation. But to the end user, when they have to choose the project area association, all they see are 2 "Uses - Automation" choices, they don't know which one is for which. The association would show 2 "Uses - Automation" options, with no additional information to show which one is for test, which one is for provisioning Step3 - Using a picker to choose an Automation result When programming this picker, it will need to be in the context of some integration points, but if we don't know what type is the automation association, how can we make sure we display the right content? e.g. we need to bring up the UI picker to choose an automation (test) result, but it could show a list of the automation result for provisioning rather than for test. Jing J. Qian Development, Rational Quality Manager Rational Software IBM Software Group 4205 S. Miami Blvd. Durham, NC 27703 Tel: 919-254-9455 T/L: 444-9455 _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
