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.
