Hi, Pramod, As I mentioned in the first notes, the interaction mode will affect some of the RESTful interface definitions, so I think there is a need for OSLC specs to consider it (so some extend, it is not purely in the implementation level or algorithm, just as you can see from Web Service world's WS-Notification spec[ http://www.ibm.com/developerworks/library/ws-resource/ws-notification.pdf ]). But I agree with Charles that this is not specific to Automation domain, and more concisely it may have another working group work on it, while Automation group could have some pre-work on it.
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: [email protected] Fax: 8610-82451172 Address:3F, Ring Building, 28#, Zhongguancun Software Park, 8, Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 From: Pramod K Chandoria <[email protected]> To: Xin Peng Liu/China/IBM@IBMCN, Charles Rankin <[email protected]> Cc: [email protected], [email protected] Date: 2012-05-31 23:26 Subject: Re: [Oslc-Automation] Consider pub/sub for asynchronized automation request RQM also had similar requirement of Execution Adapter and RQM interaction to be solved by Automation OSLC specification. Eventually it was concluded that OSLC specification does not spec out any algorithms on how two parties should communicate(poll, push, pub/sub etc..), rather it defines the integration API (resources and resources attributes) . I think notification and subscription kind of things will remain outside of the OSLC scope. @Charles: However we postponed (for next version) the need for chaining mechanism which will help to trigger output of one automation to execute other automation. Probably that should help in this case. e.g. In this case, an Build automation plan upon completion can create Automation Request for execution Test Automation Plan through the chaining mechanism. Regards -|- Pramod Chandoria From: Xin Peng Liu <[email protected]> To: Charles Rankin <[email protected]> Cc: [email protected], [email protected] Date: 05/31/2012 08:41 PM Subject: Re: [Oslc-Automation] Consider pub/sub for asynchronized automation request Sent by: [email protected] Hi, Charles, I completely agree the events/notifications is not restricted by automation, and may better be a separate spec in OSLC world. We will try to apply such mechanism if possible in product implementation of OSLC automation, and provide more detailed feedback for that. Thanks a lot for your info. 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: [email protected] Fax: 8610-82451172 Address:3F, Ring Building, 28#, Zhongguancun Software Park, 8, Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 From: Charles Rankin <[email protected]> To: [email protected] Date: 2012-05-31 22:37 Subject: Re: [Oslc-Automation] Consider pub/sub for asynchronized automation request Sent by: [email protected] 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 <[email protected]> To: [email protected] 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: [email protected] 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 [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
