[Oslc-Automation] Consider pub/sub for asynchronized automation request
Xin Peng Liu
xinpengl at cn.ibm.com
Thu May 31 21:30:05 EDT 2012
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: 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
From: Pramod K Chandoria <pchandor at in.ibm.com>
To: Xin Peng Liu/China/IBM at IBMCN, Charles Rankin <rankinc at us.ibm.com>
Cc: oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
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 <xinpengl at cn.ibm.com>
To: Charles Rankin <rankinc at us.ibm.com>
Cc: oslc-automation at open-services.net,
oslc-automation-bounces at open-services.net
Date: 05/31/2012 08:41 PM
Subject: Re: [Oslc-Automation] Consider pub/sub for asynchronized
automation request
Sent by: oslc-automation-bounces at open-services.net
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: 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
From: Charles Rankin <rankinc at us.ibm.com>
To: oslc-automation at open-services.net
Date: 2012-05-31 22:37
Subject: Re: [Oslc-Automation] Consider pub/sub for asynchronized
automation request
Sent by: oslc-automation-bounces at open-services.net
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
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120601/2398d55c/attachment-0003.html>
More information about the Oslc-Automation
mailing list