[Oslc-Automation] Implementation issues when Automation type is not known
Paul McMahan
pmcmahan at us.ibm.com
Tue Jul 3 13:35:02 EDT 2012
I suspect that adding a automationType property to automation resources
would not solve the problem because it actually surfaces before the
consumer starts to interact with any specific automation resources.
In the scenario mentioned by Jing below, the first moment of confusion for
end users would be when they are associating service providers, aka project
areas in Jazz based products. And the second moment is when they are
requesting a selection dialog. If they understood what type of automation
the service provider supports (test vs. deployment vs. build) then the
resources surfaced by selection dialogs, query results, creation factories,
etc can be assumed to work within that context, thus avoiding the
confusion.
One potential solution would be to define URIs for the automation
"subdomains" that we have discussed. Service providers that are not
general purpose automation tools like BuildForge and that cater to specific
subdomains could advertise it in their service provider resources [1] by
including additional oslc:domain properties. For example:
<ServiceProviderCatalog>
<oslc:domain rdf:resource="http://open-services.net/ns/auto#Test" />
<oslc:domain rdf:resource="http://open-services.net/ns/auto#Deploy" />
<oslc:serviceProvider>
<oslc:ServiceProvider>
<service>
<Service>
<oslc:domain
rdf:resource="http://open-services.net/ns/auto#Test" />
<creationFactory rdf:resource="..."/>
<queryCapability rdf:resource="..."/>
<selectionDialog rdf:resource="..."/>
<creationDialog rdf:resource="..."/>
</Service>
</service>
<service>
<Service>
<oslc:domain
rdf:resource="http://open-services.net/ns/auto#Deploy" />
<creationFactory rdf:resource="..."/>
<queryCapability rdf:resource="..."/>
<selectionDialog rdf:resource="..."/>
<creationDialog rdf:resource="..."/>
</Service>
</service>
</oslc:ServiceProvider>
<oslc:serviceProvider>
</ServiceProviderCatalog>
If there is support behind this idea then we should really get feedback
from OSLC Core as well since this could be seen as an unconventional use of
the domain property. The core spec [1] defines it as:
> Namespace URI of the specification that is implemented by this service.
In most cases this namespace URI will be for an OSLC domain, but other URIs
MAY be used
[1]
http://open-services.net/bin/view/Main/OslcCoreSpecification#Service_Provider_Resources
Best wishes,
Paul McMahan
IBM Rational
oslc-automation-bounces at open-services.net wrote on 07/03/2012 11:18:25 AM:
> From: David N Brauneis/Raleigh/IBM at IBMUS
> To: Jing Qian/New Haven/IBM at IBMUS
> Cc: oslc-automation at open-services.net, oslc-automation-bounces at open-
> services.net
> Date: 07/03/2012 11:46 AM
> Subject: Re: [Oslc-Automation] Implementation issues when Automation
> type is not known
> Sent by: oslc-automation-bounces at open-services.net
>
> 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: brauneis at us.ibm.com | phone: 720-395-5659 | mobile: 919-656-0874
>
>
>
> From: Jing Qian/New Haven/IBM
> To: David N Brauneis/Raleigh/IBM at IBMUS,
> Cc: oslc-automation at open-services.net, oslc-automation-
> bounces at open-services.net
> 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 at IBMUS,
>
> Cc:
>
> oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
>
> 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: 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,
>
> [image removed] 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.
>
> [image removed]
>
> 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
More information about the Oslc-Automation
mailing list