[Oslc-Automation] Implementation issues when Automation type is not known

[Xin Peng Liu]

Hi, Charles,

My comments in BLUE below.

Xinpeng Liu (David,刘昕鹏)
Rational Quality Manager Development, IBM China Development Lab
Tel:8610-82452825,Cell Phone:(+86)13520163713
Notes:Xin Peng Liu/China/IBM
E-mail: xinpengl at cn.ibm.com
Fax: 8610-82451172 
Address:3F, Ring Building, 28#, Zhongguancun Software Park, 8, Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193 




From:   Charles Rankin <rankinc at us.ibm.com>
To:     Jing Qian <jqian at us.ibm.com>
Cc:     oslc-automation at open-services.net
Date:   2012-07-03 07:39
Subject:        Re: [Oslc-Automation] Implementation issues when 
Automation type is      not     known
Sent by:        oslc-automation-bounces at open-services.net



oslc-automation-bounces at open-services.net wrote on 07/02/2012 04:09:41 PM:

> From: Jing Qian/New Haven/IBM at IBMUS 
> [Snip]
> 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

Along the lines of what David mentioned, if you are going to have two 
automation providers inside the same server instance, then you need some 
means to distinguish between them based on the registration information. I 
don't see directly how providing typing within the OSLC Automation spec 
will alleviate this issue. 
It will give a spec level standard way to achieve this, or we have to 
provide some customized properties to do it, but that will be provider 
specific. 

> 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. 

I would expect the picker to be a delegated UI, so the underlying service 
provider would be responsible for how to display / organize potential 
Automation Plans for selection.  If the automation provider in question 
supports any form of Automation Plan typing, it would likely show up in 
this delegated UI. 
Yes, it is a great idea, and CLM link UIs are doing this, and the UI impl 
should be provider specific. But it still needs a standard way to provide 
such type source for UI to distill the info, that's why we think a type 
attribute is needed here.

Charles Rankin_______________________________________________
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/20120703/a562237c/attachment-0003.html>