[Oslc-Automation] Consider pub/sub for asynchronized automation request

[Charles Rankin]

The general idea of events/notifications was discussed very early on in 
the workgroup.  You can see it was listed in some early scenarios here (
http://open-services.net/bin/view/Main/AutomationScenarios). We decided to 
place this out of scope for the first version of the specification.  Note, 
in some initial discussions there was general agreement that such an event 
mechanism would be useful outside of Automation.  To that end, this might 
want to be its own workgroup (with a separate specification), possibly 
with the Automation workgroup providing some initial investigation and 
collateral. 

Charles Rankin
Rational CTO Team -- Mobile Development Strategy
101/4L-002 T/L 966-2386




From:
Xin Peng Liu <xinpengl at cn.ibm.com>
To:
oslc-automation at open-services.net
Date:
05/31/2012 03:21 AM
Subject:
[Oslc-Automation] Consider pub/sub for asynchronized automation request



Hi, All, 

We are now investigating some new features in adopting OSLC automation 
spec that could be included for RQM in 2012 release. We are considering 2 
scenarios here: 1. Automation integration between RQM and cloud 
provisioning tools for testing env booking and follow-up testing on it; 2. 
Build integration, especially between RTC and RQM, in which RQM will take 
build automation results from RTC for scheduled follow-up testing 
behavior. I found in current spec draft still some gaps for asynchronized 
style automation support shared by these 2 scenarios. Specifically: 

Do we need to explicitly support sub-pub mechanism in asynchronized style 
automation execution or we just put this part as a vendor implementation 
details From my view, I would like we formally support in spec language 
(if not in version 1) to allow: 
Provide an OSLC endpoint for subscribing of an asynchronized long-run 
automation plan from automation provider side; 
Provide an OSLC endpoint for call-back notification of automation plan's 
accomplishment. 
In above subscription HTTP request, allow automation consumer pass and get 
registered of consumer notification endpoint.

The requirement for this comes from: 
For deployment&execution scenario, product (e.g., RQM) which books a 
virtual/physical testing env will have to wait for sometimes hours before 
the provision tools could finishing preparing and send back the reference 
for the env. This is typically an asynchronized call. But in current spec 
content, we seem have to use polling to periodically query from provision 
tool side to see if the task is finished, which is not a descent way; 
For build integration scenario, suppose two products perform sequential 
build activities, but the latter one depends on the former result(e.g., 
RTC build followed by RQM's test scheduling), if we do not depends on a 
global automation process to steer and pass the data, a pub-sub chain 
would be much better than request-response mode interaction. Taken RTC and 
RQM as an example, here, RQM acting as automation consumer to consume the 
build result from RTC, but it will be very odd for RQM to submit a request 
to RTC for that, since usually the process is triggered by RTC. In 
currently RQM impl, we also use notification mechanism to rule this out.

I have an internal product level discussion with Paul McMahan, and we both 
think it is worthy to discuss in group here. 

Xinpeng Liu (David,刘昕鹏) 
Rational Quality Manager Development, IBM China Development Lab
Tel:8610-82452825,Cell Phone:(+86)13520163713
Notes:Xin Peng Liu/China/IBM
E-mail: xinpengl at cn.ibm.com
Fax: 8610-82451172 
Address:3F, Ring Building, 28#, Zhongguancun Software Park, 8, Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193 
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120531/e6ccc003/attachment-0003.html>