[oslc-core] [Oslc-Automation] Guidance on oslc:domain usage Fw: Implementation issues when Automation type is not known
Steve K Speicher
sspeiche at us.ibm.com
Fri Jul 13 12:34:17 EDT 2012
Comments inlined below...
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
> From: Michael F Fiedler/Durham/IBM at IBMUS
> To: oslc-core at open-services.net,
> Cc: oslc-automation at open-services.net
> Date: 07/10/2012 06:21 PM
> Subject: [Oslc-Automation] Guidance on oslc:domain usage Fw:
Implementation
> issues when Automation type is not known
> Sent by: oslc-automation-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?
In the spirit of making this fit with the restrictions and approach we
have in Core V2, I see a couple ways this could be done without changing
the core:
1. Creating multiple domain URIs, like you said, but instead require
multiple oslc:Service entries
2. Leveraging the oslc:usage property. Requires a bit more work on the
client to discover these at a lower level.
> Interesting enough to discuss in
> the next meeting?
>
Next Core WG meeting is scheduled for July 25, so we could discuss there
if still needed but I know you are not available then. So I'll see where
this stands closer to that date.
>
> 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-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-Core
mailing list