[oslc-core] Guidance on oslc:domain usage Fw: [Oslc-Automation] Implementation issues when Automation type is not known
Arthur Ryman
ryman at ca.ibm.com
Fri Jul 13 10:26:11 EDT 2012
Mike,
I think that is reasonable if you define the meaning of <
http://open-services.net/ns/auto#Build> in your vocabulary document. URIs
are opaque so maybe we should also introduce some core terms that define
Domain and the subdomain relation between domains.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, Chief Architect, Reporting &
Portfolio Strategy and Management
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
From:
Michael F Fiedler <fiedler at us.ibm.com>
To:
oslc-core at open-services.net
Cc:
oslc-automation at open-services.net
Date:
07/10/2012 06:21 PM
Subject:
[oslc-core] Guidance on oslc:domain usage Fw: [Oslc-Automation]
Implementation issues when Automation type is not known
Sent by:
oslc-core-bounces at open-services.net
The automation workgroup has run into set of scenarios where a consumer
might want/need to to know more about the "type" or "subdomain" of
automation a particular Automation provider or Automation Plan specialized
in. Example, a Test Management consumer product might need to know if an
Automation provider was a "build" provider or a "deployment" provider as
it might expose the picker/creation dialogs for these different types of
automation in different areas of its UI.
At the same time, there are very generic automation providers who provide
many types of automation, even within a single Automation Plan. The
discussion within the workgroup has been around how to address these
scenarios. One proposal (see below) is to define additional domain URIs
for Automation. Rather than just the usual
oslc:domain <http://open-services.net/ns/auto>
an automation provider could optionally use a hash-qualified domain such
as
oslc:domain <http://open-services.net/ns/auto#Build>
to hint to consumers that it is build automation provider. This is
somewhat of a departure from the currently approved specs, but still seems
in the spirit of the description of oslc:domain:
> 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
Any comments from folks in the Core area? Interesting enough to discuss
in the next meeting?
Regards,
Mike
Michael Fiedler
IBM Rational Software
fiedler at us.ibm.com
919-254-4170
----- Forwarded by Michael F Fiedler/Durham/IBM on 07/10/2012 06:06 PM
-----
oslc-automation-bounces at open-services.net wrote on 07/03/2012 01:35:02 PM:
> Paul McMahan/Raleigh/IBM at IBMUS
> Sent by: oslc-automation-bounces at open-services.net
>
> 07/03/2012 01:35 PM
>
> To
>
> David N Brauneis/Raleigh/IBM at IBMUS,
>
> cc
>
> oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
>
> Subject
>
> Re: [Oslc-Automation] Implementation issues when Automation type is not
known
>
> 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
>
>
> _______________________________________________
> Oslc-Automation mailing list
> Oslc-Automation at open-services.net
>
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
> _______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list