[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-Automation mailing list