Thanks Reply:)
QSF is a step further than rocketmq-spring. Using QSF, users can get the most
intuitive experience that is almost identical to that of local method calls;
moreover, QSF reserves a good extension capability, which can easily provide
features such as idempotent, eventual consistency and flow control
and so on.
For a simple usage example of QSF, please see the discussion above :)
------------------ ???????? ------------------
??????:
"dev"
<[email protected]>;
????????: 2022??3??16??(??????) ????8:44
??????: "dev"<[email protected]>;
????: Re: [DISCUSS] RIP-35 queue service framework(QSF)
Nice to see this proposal of yours, but it seems a bit like what
rocketmq-spring[1] does, so can you elaborate on the difference between QSF
and rocketmq-spring?
[1]https://github.com/apache/rocketmq-spring
yukon <[email protected]> ??2022??3??16?????? 20:23??????
> 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
> >
> > ??&nbsp; Current
State: Proposed
> >
> > ??&nbsp; Authors:
booom( booom (jason) ?? GitHub)
> >
> > ??&nbsp;
Shepherds: yukon( zhouxinyu (yukon) ?? GitHub)
> >
> > ??&nbsp; Mailing
List discussion: [email protected]
> >
> > ??&nbsp; Pull
Request:
> >
> > ??&nbsp;
Released:&nbsp;
> >
> > Background &amp; Motivation
> >
> > What do we need to do
> >
> > ??&nbsp; Will we
add a new module? Yes.
> >
> > ??&nbsp; Will we
add new APIs? No.
> >
> > ??&nbsp; Will we
add new feature? Yes.
> >
> > Why should we do that
> >
> > ??&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; 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
> >
> > ??&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; To what
degree should we solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ??&nbsp; What
problem is this proposal NOT designed to solve?
> >
> > 1. Add new features to classics mq
client.
> >
> > 2. Affect compatibility.
> >
> > ??&nbsp; 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?&nbsp;
> >
> >
> > 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
> >
> > ??&nbsp; Method
signature changes
> >
> > ??&nbsp;
&nbsp; &nbsp; method name
> >
> > ??&nbsp;
&nbsp; &nbsp; parameter list
> >
> > ??&nbsp;
&nbsp; &nbsp; return value
> >
> > Nothing.
> >
> > ??&nbsp; Method
behavior changes
> >
> > Nothing.
> >
> > ??&nbsp; CLI
command changes
> >
> > Nothing.
> >
> > ??&nbsp; Log
format or content changes
> >
> > Nothing.
> >
> > &nbsp;Compatibility, Deprecation, and Migration Plan
> >
> > ??&nbsp; Are
backward and forward compatibility taken into
> > consideration?
> >
> > Yes.
> >
> > ??&nbsp; Are
there deprecated APIs?
> >
> > Nothing.
> >
> > ??&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.
> >
> >
> >
> >
> >
> >
> >
> > ------------------&nbsp;????????&nbsp;------------------
> > ??????:
>
>
"Jason.Chen"
>
>
<
> > [email protected]&gt;;
> > ????????:&nbsp;2022??3??16??(??????) ????12:55
> > ??????:&nbsp;"dev"<[email protected]&gt;;
> >
> > ????:&nbsp;[DISCUSS] RIP-35 queue service framework(QSF)
> >
> >
> >
> >
> >
> >
> >
> > Status
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Current State: Proposed
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Authors: booom( booom
(jason) ?? GitHub)
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Shepherds: yukon(
zhouxinyu (yukon) ?? GitHub)
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Mailing List discussion:
> > [email protected]
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Pull Request:
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Released:
<relased_version&gt;
> >
> > Background &amp; Motivation
> >
> > What do we need to do
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Will we add a new module?
Yes.
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Will we add new APIs? No.
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Will we add new feature?
Yes.
> >
> > Why should we do that
> >
> > ??&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; What can we benefit
proposed changes?
> >
> > 1.&nbsp;&nbsp; &nbsp; Encapsulate mq client API to
support method
> invoking
> > style usage.
> >
> > 2.&nbsp;&nbsp; &nbsp; The encapsulation is easily
extensible, to support
> > idempotence/eventually consistent/ fluid control extensions and so on.
> >
> > 3.&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; 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; To what degree should we
solve the problem?
> >
> > 100%.
> >
> > Non-Goals
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; What problem is this
proposal NOT designed to
> > solve?
> >
> > 1.&nbsp;&nbsp; &nbsp; Add new features to classics mq
client.
> >
> > 2.&nbsp;&nbsp; &nbsp; Affect compatibility.
> >
> > ??&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; Method signature changes
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp;
&nbsp;&nbsp;&nbsp; method name
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp;
&nbsp;&nbsp;&nbsp; parameter list
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp;
&nbsp;&nbsp;&nbsp; return value
> >
> > Nothing.
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Method behavior changes
> >
> > Nothing.
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; CLI command changes
> >
> > Nothing.
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Log format or content
changes
> >
> > Nothing.
> >
> > &nbsp;Compatibility, Deprecation, and Migration Plan
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Are backward and forward
compatibility taken
> > into consideration?
> >
> > Yes.
> >
> > ??&nbsp;&nbsp;&nbsp; &nbsp; Are there deprecated APIs?
> >
> > Nothing.
> >
> > ??&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.
>
