Comments inlined below... Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645
> From: Michael F Fiedler/Durham/IBM@IBMUS > To: [email protected], > Cc: [email protected] > 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: [email protected] > > 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 > [email protected] > 919-254-4170 > ----- Forwarded by Michael F Fiedler/Durham/IBM on 07/10/2012 06:06 PM ----- > > [email protected] wrote on 07/03/2012 01:35:02 PM: > > > Paul McMahan/Raleigh/IBM@IBMUS > > Sent by: [email protected] > > > > 07/03/2012 01:35 PM > > > > To > > > > David N Brauneis/Raleigh/IBM@IBMUS, > > > > cc > > > > [email protected], [email protected] > > > > 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 > > > > [email protected] wrote on 07/03/2012 11:18:25 AM: > > > > > From: David N Brauneis/Raleigh/IBM@IBMUS > > > To: Jing Qian/New Haven/IBM@IBMUS > > > Cc: [email protected], oslc-automation-bounces@open- > > > services.net > > > Date: 07/03/2012 11:46 AM > > > Subject: Re: [Oslc-Automation] Implementation issues when Automation > > > type is not known > > > Sent by: [email protected] > > > > > > 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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 > > > > > > > > > > > > From: Jing Qian/New Haven/IBM > > > To: David N Brauneis/Raleigh/IBM@IBMUS, > > > Cc: [email protected], oslc-automation- > > > [email protected] > > > 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@IBMUS, > > > > > > Cc: > > > > > > [email protected], > > [email protected] > > > > > > 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: [email protected] | phone: 720-395-5659 | mobile: 919-656-0874 > > > > > > > > > > > > > > > From: Jing Qian/New Haven/IBM@IBMUS > > > To: [email protected], > > > Date: 07/02/2012 05:17 PM > > > Subject: [Oslc-Automation] Implementation issues when > > > Automation type is not known > > > Sent by: [email protected] > > > > > > > > > > > > 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 > > > [email protected] > > > > > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net > > > > > > _______________________________________________ > > > Oslc-Automation mailing list > > > [email protected] > > > > > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net > > > > > > _______________________________________________ > > Oslc-Automation mailing list > > [email protected] > > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net > > _______________________________________________ > Oslc-Automation mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
