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

[Charles Rankin]

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.

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

Charles Rankin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120702/b433b651/attachment-0003.html>