Could you please provide some demos to show how we use QSFProducer/Consumer?
On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen <[email protected]> wrote: > I am sorry that the RIP mail format is incorrect, and i write a > well-formed google doc version here: > > > https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg > > > > > > > RIP 35 queue service framework(QSF) > > Status > > ● Current State: Proposed > > ● Authors: booom( booom (jason) · GitHub) > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > ● Mailing List discussion: [email protected] > > ● Pull Request: > > ● Released: > > Background & Motivation > > What do we need to do > > ● Will we add a new module? Yes. > > ● Will we add new APIs? No. > > ● Will we add new feature? Yes. > > Why should we do that > > ● 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. > > ● What can we benefit proposed changes? > > 1. Encapsulate mq client API to support method invoking style usage. > > 2. The encapsulation is easily extensible, to support > idempotence/eventually consistent/ fluid control extensions and so on. > > 3. Isolate the mq client manage code and the business logic code, to > help mq users improve their systems’ maintainability. > > Goals > > ● 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. > > ● To what degree should we solve the problem? > > 100%. > > Non-Goals > > ● What problem is this proposal NOT designed to solve? > > 1. Add new features to classics mq client. > > 2. Affect compatibility. > > ● Are there any limits of this proposal? > > Only QSF(queue service framework) users will benefit. > > Changes > > Architecture > > To simplify a process, we need to consider what information is essential > and must be provided by users to execute this process? How to properly > organize this information so that it is most user-friendly? > > > Along this thinking path, we have extracted the necessary parameters for > mq calls and organized them into the java annotations @QSFConsumer and > @QSFProvider. After that, through the extension support of spring container > in each stage of bean life cycle, we can process @QSFConsumer @QSFProvider > annotation in BeanPostProcessor, extract method invocation information to > method invocation information object MethodInvokeInfo and send it out, and > locate it through MethodInvokeInfo at the message receiving endpoint. The > bean where the call is made, the method where it is located, the parameters > used, and then the method is called by reflection. > > > > > > Interface Design/Change > > ● Method signature changes > > ○ method name > > ○ parameter list > > ○ return value > > Nothing. > > ● Method behavior changes > > Nothing. > > ● CLI command changes > > Nothing. > > ● Log format or content changes > > Nothing. > > Compatibility, Deprecation, and Migration Plan > > ● Are backward and forward compatibility taken into > consideration? > > Yes. > > ● Are there deprecated APIs? > > Nothing. > > ● 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. > > > > > > > > ------------------ 原始邮件 ------------------ > 发件人: > "Jason.Chen" > < > [email protected]>; > 发送时间: 2022年3月16日(星期三) 中午12:55 > 收件人: "dev"<[email protected]>; > > 主题: [DISCUSS] RIP-35 queue service framework(QSF) > > > > > > > > Status > > ● Current State: Proposed > > ● Authors: booom( booom (jason) · GitHub) > > ● Shepherds: yukon( zhouxinyu (yukon) · GitHub) > > ● Mailing List discussion: > [email protected] > > ● Pull Request: > > ● Released: <relased_version> > > Background & Motivation > > What do we need to do > > ● Will we add a new module? Yes. > > ● Will we add new APIs? No. > > ● Will we add new feature? Yes. > > Why should we do that > > ● 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. > > ● What can we benefit proposed changes? > > 1. Encapsulate mq client API to support method invoking > style usage. > > 2. The encapsulation is easily extensible, to support > idempotence/eventually consistent/ fluid control extensions and so on. > > 3. Isolate the mq client manage code and the business > logic code, to help mq users improve their systems’ maintainability. > > > > Goals > > ● 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. > > ● To what degree should we solve the problem? > > 100%. > > Non-Goals > > ● What problem is this proposal NOT designed to > solve? > > 1. Add new features to classics mq client. > > 2. Affect compatibility. > > ● Are there any limits of this proposal? > > Only QSF(queue service framework) users will benefit. > > Changes > > Architecture > > Interface Design/Change > > ● Method signature changes > > ○ method name > > ○ parameter list > > ○ return value > > Nothing. > > ● Method behavior changes > > Nothing. > > ● CLI command changes > > Nothing. > > ● Log format or content changes > > Nothing. > > Compatibility, Deprecation, and Migration Plan > > ● Are backward and forward compatibility taken > into consideration? > > Yes. > > ● Are there deprecated APIs? > > Nothing. > > ● 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.
