[DISCUSS] RIP-35 queue service framework(QSF)

[Jason.Chen]

Status
 
??      Current State: Proposed
 
??      Authors: booom( booom (jason) ?? GitHub)
 
??      Shepherds: yukon( zhouxinyu (yukon) ?? GitHub)
 
??      Mailing List discussion: 
dev@rocketmq.apache.org
 
??      Pull Request: 
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Released: <relased_version&gt;
 
Background &amp; Motivation
 
What do we need to do
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Will we add a new module? Yes.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Will we add new APIs? No.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Will we add new feature? Yes.
 
Why should we do that
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Are there any problems of our current project?
 
The current mq client API is intrusive, to send message or consume message, we 
should code to manage the mq infrastructure, and mixed it up with our business 
logic codes. 
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What can we benefit proposed changes?
 
1.&nbsp;&nbsp;&nbsp;&nbsp; Encapsulate mq client API to support method invoking 
style usage.
 
2.&nbsp;&nbsp;&nbsp;&nbsp; The encapsulation is easily extensible, to support 
idempotence/eventually consistent/ fluid control extensions and so on.
 
3.&nbsp;&nbsp;&nbsp;&nbsp; Isolate the mq client manage code and the business 
logic code, to help mq users improve their systems?? maintainability.
 
&nbsp;
 
Goals
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What problem is this proposal designed to 
solve?
 
Unobtrusive mq client usage, and easily extensible to support 
idempotence/eventually consistent/ fluid control extensions and so on.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To what degree should we solve the problem?
 
100%.
 
Non-Goals
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; What problem is this proposal NOT designed to 
solve?
 
1.&nbsp;&nbsp;&nbsp;&nbsp; Add new features to classics mq client.
 
2.&nbsp;&nbsp;&nbsp;&nbsp; Affect compatibility.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Are there any limits of this proposal?
 
Only QSF(queue service framework) users will benefit.
 
Changes
 
Architecture
 
Interface Design/Change
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method signature changes
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;method name
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;parameter list
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;return value
 
Nothing.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Method behavior changes
 
Nothing.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CLI command changes
 
Nothing.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Log format or content changes
 
Nothing.
 
&nbsp;Compatibility, Deprecation, and Migration Plan
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Are backward and forward compatibility taken 
into consideration?
 
Yes.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Are there deprecated APIs?
 
Nothing.
 
??&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How do we do migration?
 
Upgrade normally, no additional migration required.
 
Implementation Outline
 
We will implement the proposed changes by 1 phase. (QSF is implemented and 
works well in our project)
 
Phase 1
   
Complete      the QSF mq client encapsulation.
  
Complete      the QSF idempotency support
  
Rejected Alternatives 
 
There are no other alternatives.