[Oslc-Automation] Implementation issues when Automation type is not known
Jing Qian
jqian at us.ibm.com
Tue Jul 3 10:30:20 EDT 2012
HI Charles and David,
Thanks for the comments, I added mine below in green.
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: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Xin Peng Liu <xinpengl at cn.ibm.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Charles Rankin/Austin/IBM at IBMUS, |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Jing Qian/New Haven/IBM at IBMUS, oslc-automation at open-services.net, oslc-automation-bounces at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|07/02/2012 09:47 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [Oslc-Automation] Implementation issues when Automation type is not known |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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.
<JQ> Yes, I agree, the automation service provider will be responsible for
how to display/organize them for selection. However, if the same provider
provides multiple types of automation, as the consumer at a integration
point, we can't tell which automation results to show if we don't know its
"type".
For example:
Let's say in RTC build result, we let the end user to pick an automation
(test) result. So as the RTC user, I only want to see the test automation
result in the picker, not other type of automation result.
But in the previous step 2, user picked "Uses - automation", say they
happen to pick the provision automation rather than the test automation,
since they're identical, both are "Uses - automation". Now at this step,
the picker would display a list of provision automation result(which
supplied by the same automation provider). And this is not what we want.
If we can have a standard way - i.e checking an optional AutomationType
attribute as String type (not an enumeration), then the consumer would be
able to distinguish them easily.
</JQ>
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/6b8c8cc0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120703/6b8c8cc0/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120703/6b8c8cc0/attachment-0001.gif>
More information about the Oslc-Automation
mailing list