[Oslc-Automation] Implementation issues when Automation type is not known
Xin Peng Liu
xinpengl at cn.ibm.com
Mon Jul 2 21:41:50 EDT 2012
Hi, David,
thanks for your insightful reply. My comments list below inline as BLUE.
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: David N Brauneis <brauneis at us.ibm.com>
To: Jing Qian <jqian at us.ibm.com>
Cc: oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
Date: 2012-07-03 05:39
Subject: Re: [Oslc-Automation] Implementation issues when
Automation type is not known
Sent by: oslc-automation-bounces at open-services.net
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.
From RQM perspective, it is not expected the type values should be some
enumeration, because we also expecting more extensibility for OSLC
automation providers to be plugged into the QM project in the future. I
agree that in some automation scenarios other than those for QM usage,
such a "type" attribute is not even required. I think a better way here
is, we provide an optional AutomationType attribute (appear zero or one
time) with type String, while each actual providers could give meaningful
values as they mean in their domain.
This appears to be a unique RQM issue and not something that needs to be
added to the specification.
The current automation concept in spec is rather general to include all
automation behaviors. The type usage here is useful when for one service
provider hosting more than one automation plans, but the consumers need an
automatic and standard way to distinguish which one to be linked to and
get consumed accordingly. To some extend, RQM just has one application of
it here. But I feel it is not purely QM specific.
Regards,
David
____________________________________________________
David Brauneis
STSM, Rational Software Delivery Automation Chief Architect
email: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
From: Jing Qian/New Haven/IBM at IBMUS
To: oslc-automation at open-services.net,
Date: 07/02/2012 05:17 PM
Subject: [Oslc-Automation] Implementation issues when Automation
type is not known
Sent by: oslc-automation-bounces at open-services.net
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
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
_______________________________________________
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/dfc4c3c0/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120703/dfc4c3c0/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 38328 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120703/dfc4c3c0/attachment.jpe>
More information about the Oslc-Automation
mailing list