You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicecomb.apache.org by Zheng Feng <zh...@gmail.com> on 2018/01/12 01:28:47 UTC
Some thoughts about PACK of the servicecomb-saga
Hi all,
I've tried to understand about the new architecture PACK of the
servicecomb-saga.
1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
'Saga Coordinator'.
2. They communicate each other with the underlying gRPC connections.
3. The TxEvent is defined as the sequences of the record, such like
SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
TxAbortedEvent, TxCompensatedEvent. And currently the event type is relied
by the TxEvent className. I think it would be better to use the enum type
since the class name could be changed with the issue of compatibility.
4. The annotation SagaStart is used to indicate the boundary edge of the
Saga Transaction. I assume that we can use like the following
@SagaStart
public Response svc( ) {
restTemplate() -> invoke (serviceA);
retsTemplate() -> invoke (serviceB);
}
So I suggest that we use the @Saga or @SagaContext to replace the
@SagaStart to make it clear. Also in the processor of this annotation, the
SagaStartedEvent and SagaEndedEvent are sent.
5. After going through the omega codes, I think it could be possible to
introduce a OmegaClient interface to handle all of the events related with
the Saga. some pseudo code looks like
public interface OmegaClient {
void saga_start( );
void saga_close( );
void saga_cancel( );
void saga_tx_start( );
void saga_tx_end( );
void saga_tx_failed( );
void saga_compensate( );
}
So we can get the GrpcOmegaClient to implement it with the gRPC
connection. This could be helpful if we have the other underlying
connection in the future.
6. I have not find any annotation with the participant. So it could be
possible to introduce the @Participant just like
public class ServiceA {
@Participant
public Response work( );
@Compensate
public void undo( );
}
and it could be useful to add the type SUPPORT, NOT_SUPPORT, MANDATORY,
...
Anyway, I will be happy to involved in the servicecomb saga and welcome for
any input.
Thanks,
Zheng
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Sean Yin <se...@gmail.com>.
Hi Zheng,
Sorry, I forgot that EventAwareInterceptor is in still in PR (
https://github.com/apache/incubator-servicecomb-saga/pull/112)
On Fri, Jan 12, 2018 at 10:53 PM, Zheng Feng <zh...@gmail.com> wrote:
> Thanks and it works now.
>
> 2018-01-12 22:28 GMT+08:00 Willem Jiang <wi...@gmail.com>:
>
> > Don't worry, I just add you into the contributor group. Now you can
> assign
> > the task yourself.
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> > http://jnn.iteye.com (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Jan 12, 2018 at 9:56 PM, Zheng Feng <zh...@gmail.com> wrote:
> >
> > > yeah, I raised https://issues.apache.org/jira/browse/SCB-228 for the
> > issue
> > > of TxEvent type and feel free to assign to me. I think I have no access
> > to
> > > assign myself as I am not the member of the servicecomb
> > >
> > > 2018-01-12 17:39 GMT+08:00 Willem Jiang <wi...@gmail.com>:
> > >
> > > > Hi FengZheng，
> > > >
> > > > It's good to see you here and we are looking forward your valuable
> > inputs
> > > > and contribution :)
> > > >
> > > >
> > > > Willem Jiang
> > > >
> > > > Blog: http://willemjiang.blogspot.com (English)
> > > > http://jnn.iteye.com (Chinese)
> > > > Twitter: willemjiang
> > > > Weibo: 姜宁willem
> > > >
> > > > On Fri, Jan 12, 2018 at 3:38 PM, Zheng Feng <zh...@gmail.com>
> wrote:
> > > >
> > > > > comment inline,
> > > > >
> > > > > 2018-01-12 10:17 GMT+08:00 Sean Yin <se...@gmail.com>:
> > > > >
> > > > > > Hi Zheng,
> > > > > >
> > > > > > Thank you for taking your time to go through our Pack
> architecture
> > of
> > > > > > ServiceComb Saga.
> > > > > >
> > > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks
> > like
> > > a
> > > > > > > 'Saga Coordinator'.
> > > > > > > 2. They communicate each other with the underlying gRPC
> > > connections.
> > > > > >
> > > > > >
> > > > > > You are right about the roles of Omega and Alpha in this
> > > architecture.
> > > > > And
> > > > > > the suggestions you provided are very valuable to us.
> > > > > >
> > > > > > 3. The TxEvent is defined as the sequences of the record, such
> like
> > > > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event
> type
> > is
> > > > > > relied
> > > > > > > by the TxEvent className. I think it would be better to use the
> > > enum
> > > > > type
> > > > > > > since the class name could be changed with the issue of
> > > > compatibility.
> > > > > >
> > > > > >
> > > > > > We are in short of developers and cut some corners in our
> > > > implementation,
> > > > > > such as using TxEvent class names as event type. :)
> > > > > >
> > > > > OK, I will raise a SCB jira for this if you agree.
> > > > >
> > > > > >
> > > > > > 4. The annotation SagaStart is used to indicate the boundary edge
> > of
> > > > the
> > > > > > > Saga Transaction. I assume that we can use like the following
> > > > > > > @SagaStart
> > > > > > > public Response svc( ) {
> > > > > > > restTemplate() -> invoke (serviceA);
> > > > > > > retsTemplate() -> invoke (serviceB);
> > > > > > > }
> > > > > >
> > > > > >
> > > > > > Yes, we have integration tests to illustrate this idea in
> > pack-tests
> > > > > > module.
> > > > > >
> > > > > > So I suggest that we use the @Saga or @SagaContext to replace
> > the
> > > > > > > @SagaStart to make it clear. Also in the processor of this
> > > > annotation,
> > > > > > the
> > > > > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > > > >
> > > > > >
> > > > > > Proper naming is hard and we can definitely give it more
> thoughts.
> > > > > Indeed,
> > > > > > we have code to send SagaStartedEvent and SagaEndedEvent around
> > > > > @SagaStart
> > > > > > in success scenario.
> > > > > > In failure cases, we try to achieve that Alpha writes
> > SagaEndedEvent
> > > by
> > > > > > itself, since compensations are done asynchronously.
> > > > > >
> > > > > > 5. After going through the omega codes, I think it could be
> > possible
> > > to
> > > > > > > introduce a OmegaClient interface to handle all of the events
> > > related
> > > > > > with
> > > > > > > the Saga. some pseudo code looks like
> > > > > > > public interface OmegaClient {
> > > > > > > void saga_start( );
> > > > > > > void saga_close( );
> > > > > > > void saga_cancel( );
> > > > > > > void saga_tx_start( );
> > > > > > > void saga_tx_end( );
> > > > > > > void saga_tx_failed( );
> > > > > > > void saga_compensate( );
> > > > > > > }
> > > > > > > So we can get the GrpcOmegaClient to implement it with the
> > gRPC
> > > > > > > connection. This could be helpful if we have the other
> underlying
> > > > > > > connection in the future.
> > > > > >
> > > > > >
> > > > > > We do have a communication interface (MessageSender) for
> potential
> > > > > > extension in the future. And another interface
> > > (EventAwareInterceptor)
> > > > > for
> > > > > > composing these saga events.
> > > > > > Like you said, we probably should have given methods in
> > > > > > EventAwareInterceptor more meaningful names.
> > > > > >
> > > > > Can you point me the link for the EventAwareInterceptor ? I can not
> > > find
> > > > it
> > > > > in the incubator-servicecomb-saga.
> > > > >
> > > > > >
> > > > > > 6. I have not find any annotation with the participant. So it
> could
> > > be
> > > > > > > possible to introduce the @Participant just like
> > > > > > > public class ServiceA {
> > > > > > > @Participant
> > > > > > > public Response work( );
> > > > > > > @Compensate
> > > > > > > public void undo( );
> > > > > > > }
> > > > > >
> > > > > >
> > > > > > The annotation for partcipants is @Compensable.
> > > > > >
> > > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > > > MANDATORY,
> > > > > >
> > > > > >
> > > > > > I did not quite understand what you mean. Could you please
> > elaborate
> > > a
> > > > > bit
> > > > > > more?
> > > > > >
> > > > > The idea is from the traditional transaction of EJB, you can find
> > > > > https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
> > > > >
> > > > > >
> > > > > > You have been working on data consistency problems for quite a
> > while
> > > > and
> > > > > > must have many useful insights.
> > > > > > We are very lucky if you join us on this project!
> > > > > >
> > > > > > Thank you!
> > > > > >
> > > > > > Best Regards,
> > > > > > Sean
> > > > > >
> > > > > > On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I've tried to understand about the new architecture PACK of the
> > > > > > > servicecomb-saga.
> > > > > > >
> > > > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks
> > > like
> > > > a
> > > > > > > 'Saga Coordinator'.
> > > > > > > 2. They communicate each other with the underlying gRPC
> > > connections.
> > > > > > > 3. The TxEvent is defined as the sequences of the record, such
> > like
> > > > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event
> type
> > is
> > > > > > relied
> > > > > > > by the TxEvent className. I think it would be better to use the
> > > enum
> > > > > type
> > > > > > > since the class name could be changed with the issue of
> > > > compatibility.
> > > > > > > 4. The annotation SagaStart is used to indicate the boundary
> edge
> > > of
> > > > > the
> > > > > > > Saga Transaction. I assume that we can use like the following
> > > > > > > @SagaStart
> > > > > > > public Response svc( ) {
> > > > > > > restTemplate() -> invoke (serviceA);
> > > > > > > retsTemplate() -> invoke (serviceB);
> > > > > > > }
> > > > > > > So I suggest that we use the @Saga or @SagaContext to
> replace
> > > the
> > > > > > > @SagaStart to make it clear. Also in the processor of this
> > > > annotation,
> > > > > > the
> > > > > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > > > > >
> > > > > > > 5. After going through the omega codes, I think it could be
> > > possible
> > > > to
> > > > > > > introduce a OmegaClient interface to handle all of the events
> > > related
> > > > > > with
> > > > > > > the Saga. some pseudo code looks like
> > > > > > > public interface OmegaClient {
> > > > > > > void saga_start( );
> > > > > > > void saga_close( );
> > > > > > > void saga_cancel( );
> > > > > > > void saga_tx_start( );
> > > > > > > void saga_tx_end( );
> > > > > > > void saga_tx_failed( );
> > > > > > > void saga_compensate( );
> > > > > > > }
> > > > > > > So we can get the GrpcOmegaClient to implement it with the
> > gRPC
> > > > > > > connection. This could be helpful if we have the other
> underlying
> > > > > > > connection in the future.
> > > > > > >
> > > > > > > 6. I have not find any annotation with the participant. So it
> > could
> > > > be
> > > > > > > possible to introduce the @Participant just like
> > > > > > >
> > > > > > > public class ServiceA {
> > > > > > > @Participant
> > > > > > > public Response work( );
> > > > > > >
> > > > > > > @Compensate
> > > > > > > public void undo( );
> > > > > > > }
> > > > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > > > > MANDATORY,
> > > > > > > ...
> > > > > > >
> > > > > > > Anyway, I will be happy to involved in the servicecomb saga and
> > > > welcome
> > > > > > for
> > > > > > > any input.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Zheng
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Zheng Feng <zh...@gmail.com>.
Thanks and it works now.
2018-01-12 22:28 GMT+08:00 Willem Jiang <wi...@gmail.com>:
> Don't worry, I just add you into the contributor group. Now you can assign
> the task yourself.
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jan 12, 2018 at 9:56 PM, Zheng Feng <zh...@gmail.com> wrote:
>
> > yeah, I raised https://issues.apache.org/jira/browse/SCB-228 for the
> issue
> > of TxEvent type and feel free to assign to me. I think I have no access
> to
> > assign myself as I am not the member of the servicecomb
> >
> > 2018-01-12 17:39 GMT+08:00 Willem Jiang <wi...@gmail.com>:
> >
> > > Hi FengZheng，
> > >
> > > It's good to see you here and we are looking forward your valuable
> inputs
> > > and contribution :)
> > >
> > >
> > > Willem Jiang
> > >
> > > Blog: http://willemjiang.blogspot.com (English)
> > > http://jnn.iteye.com (Chinese)
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Fri, Jan 12, 2018 at 3:38 PM, Zheng Feng <zh...@gmail.com> wrote:
> > >
> > > > comment inline,
> > > >
> > > > 2018-01-12 10:17 GMT+08:00 Sean Yin <se...@gmail.com>:
> > > >
> > > > > Hi Zheng,
> > > > >
> > > > > Thank you for taking your time to go through our Pack architecture
> of
> > > > > ServiceComb Saga.
> > > > >
> > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks
> like
> > a
> > > > > > 'Saga Coordinator'.
> > > > > > 2. They communicate each other with the underlying gRPC
> > connections.
> > > > >
> > > > >
> > > > > You are right about the roles of Omega and Alpha in this
> > architecture.
> > > > And
> > > > > the suggestions you provided are very valuable to us.
> > > > >
> > > > > 3. The TxEvent is defined as the sequences of the record, such like
> > > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type
> is
> > > > > relied
> > > > > > by the TxEvent className. I think it would be better to use the
> > enum
> > > > type
> > > > > > since the class name could be changed with the issue of
> > > compatibility.
> > > > >
> > > > >
> > > > > We are in short of developers and cut some corners in our
> > > implementation,
> > > > > such as using TxEvent class names as event type. :)
> > > > >
> > > > OK, I will raise a SCB jira for this if you agree.
> > > >
> > > > >
> > > > > 4. The annotation SagaStart is used to indicate the boundary edge
> of
> > > the
> > > > > > Saga Transaction. I assume that we can use like the following
> > > > > > @SagaStart
> > > > > > public Response svc( ) {
> > > > > > restTemplate() -> invoke (serviceA);
> > > > > > retsTemplate() -> invoke (serviceB);
> > > > > > }
> > > > >
> > > > >
> > > > > Yes, we have integration tests to illustrate this idea in
> pack-tests
> > > > > module.
> > > > >
> > > > > So I suggest that we use the @Saga or @SagaContext to replace
> the
> > > > > > @SagaStart to make it clear. Also in the processor of this
> > > annotation,
> > > > > the
> > > > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > > >
> > > > >
> > > > > Proper naming is hard and we can definitely give it more thoughts.
> > > > Indeed,
> > > > > we have code to send SagaStartedEvent and SagaEndedEvent around
> > > > @SagaStart
> > > > > in success scenario.
> > > > > In failure cases, we try to achieve that Alpha writes
> SagaEndedEvent
> > by
> > > > > itself, since compensations are done asynchronously.
> > > > >
> > > > > 5. After going through the omega codes, I think it could be
> possible
> > to
> > > > > > introduce a OmegaClient interface to handle all of the events
> > related
> > > > > with
> > > > > > the Saga. some pseudo code looks like
> > > > > > public interface OmegaClient {
> > > > > > void saga_start( );
> > > > > > void saga_close( );
> > > > > > void saga_cancel( );
> > > > > > void saga_tx_start( );
> > > > > > void saga_tx_end( );
> > > > > > void saga_tx_failed( );
> > > > > > void saga_compensate( );
> > > > > > }
> > > > > > So we can get the GrpcOmegaClient to implement it with the
> gRPC
> > > > > > connection. This could be helpful if we have the other underlying
> > > > > > connection in the future.
> > > > >
> > > > >
> > > > > We do have a communication interface (MessageSender) for potential
> > > > > extension in the future. And another interface
> > (EventAwareInterceptor)
> > > > for
> > > > > composing these saga events.
> > > > > Like you said, we probably should have given methods in
> > > > > EventAwareInterceptor more meaningful names.
> > > > >
> > > > Can you point me the link for the EventAwareInterceptor ? I can not
> > find
> > > it
> > > > in the incubator-servicecomb-saga.
> > > >
> > > > >
> > > > > 6. I have not find any annotation with the participant. So it could
> > be
> > > > > > possible to introduce the @Participant just like
> > > > > > public class ServiceA {
> > > > > > @Participant
> > > > > > public Response work( );
> > > > > > @Compensate
> > > > > > public void undo( );
> > > > > > }
> > > > >
> > > > >
> > > > > The annotation for partcipants is @Compensable.
> > > > >
> > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > > MANDATORY,
> > > > >
> > > > >
> > > > > I did not quite understand what you mean. Could you please
> elaborate
> > a
> > > > bit
> > > > > more?
> > > > >
> > > > The idea is from the traditional transaction of EJB, you can find
> > > > https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
> > > >
> > > > >
> > > > > You have been working on data consistency problems for quite a
> while
> > > and
> > > > > must have many useful insights.
> > > > > We are very lucky if you join us on this project!
> > > > >
> > > > > Thank you!
> > > > >
> > > > > Best Regards,
> > > > > Sean
> > > > >
> > > > > On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com>
> > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I've tried to understand about the new architecture PACK of the
> > > > > > servicecomb-saga.
> > > > > >
> > > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks
> > like
> > > a
> > > > > > 'Saga Coordinator'.
> > > > > > 2. They communicate each other with the underlying gRPC
> > connections.
> > > > > > 3. The TxEvent is defined as the sequences of the record, such
> like
> > > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type
> is
> > > > > relied
> > > > > > by the TxEvent className. I think it would be better to use the
> > enum
> > > > type
> > > > > > since the class name could be changed with the issue of
> > > compatibility.
> > > > > > 4. The annotation SagaStart is used to indicate the boundary edge
> > of
> > > > the
> > > > > > Saga Transaction. I assume that we can use like the following
> > > > > > @SagaStart
> > > > > > public Response svc( ) {
> > > > > > restTemplate() -> invoke (serviceA);
> > > > > > retsTemplate() -> invoke (serviceB);
> > > > > > }
> > > > > > So I suggest that we use the @Saga or @SagaContext to replace
> > the
> > > > > > @SagaStart to make it clear. Also in the processor of this
> > > annotation,
> > > > > the
> > > > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > > > >
> > > > > > 5. After going through the omega codes, I think it could be
> > possible
> > > to
> > > > > > introduce a OmegaClient interface to handle all of the events
> > related
> > > > > with
> > > > > > the Saga. some pseudo code looks like
> > > > > > public interface OmegaClient {
> > > > > > void saga_start( );
> > > > > > void saga_close( );
> > > > > > void saga_cancel( );
> > > > > > void saga_tx_start( );
> > > > > > void saga_tx_end( );
> > > > > > void saga_tx_failed( );
> > > > > > void saga_compensate( );
> > > > > > }
> > > > > > So we can get the GrpcOmegaClient to implement it with the
> gRPC
> > > > > > connection. This could be helpful if we have the other underlying
> > > > > > connection in the future.
> > > > > >
> > > > > > 6. I have not find any annotation with the participant. So it
> could
> > > be
> > > > > > possible to introduce the @Participant just like
> > > > > >
> > > > > > public class ServiceA {
> > > > > > @Participant
> > > > > > public Response work( );
> > > > > >
> > > > > > @Compensate
> > > > > > public void undo( );
> > > > > > }
> > > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > > > MANDATORY,
> > > > > > ...
> > > > > >
> > > > > > Anyway, I will be happy to involved in the servicecomb saga and
> > > welcome
> > > > > for
> > > > > > any input.
> > > > > >
> > > > > > Thanks,
> > > > > > Zheng
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Willem Jiang <wi...@gmail.com>.
Don't worry, I just add you into the contributor group. Now you can assign
the task yourself.
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Jan 12, 2018 at 9:56 PM, Zheng Feng <zh...@gmail.com> wrote:
> yeah, I raised https://issues.apache.org/jira/browse/SCB-228 for the issue
> of TxEvent type and feel free to assign to me. I think I have no access to
> assign myself as I am not the member of the servicecomb
>
> 2018-01-12 17:39 GMT+08:00 Willem Jiang <wi...@gmail.com>:
>
> > Hi FengZheng，
> >
> > It's good to see you here and we are looking forward your valuable inputs
> > and contribution :)
> >
> >
> > Willem Jiang
> >
> > Blog: http://willemjiang.blogspot.com (English)
> > http://jnn.iteye.com (Chinese)
> > Twitter: willemjiang
> > Weibo: 姜宁willem
> >
> > On Fri, Jan 12, 2018 at 3:38 PM, Zheng Feng <zh...@gmail.com> wrote:
> >
> > > comment inline,
> > >
> > > 2018-01-12 10:17 GMT+08:00 Sean Yin <se...@gmail.com>:
> > >
> > > > Hi Zheng,
> > > >
> > > > Thank you for taking your time to go through our Pack architecture of
> > > > ServiceComb Saga.
> > > >
> > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like
> a
> > > > > 'Saga Coordinator'.
> > > > > 2. They communicate each other with the underlying gRPC
> connections.
> > > >
> > > >
> > > > You are right about the roles of Omega and Alpha in this
> architecture.
> > > And
> > > > the suggestions you provided are very valuable to us.
> > > >
> > > > 3. The TxEvent is defined as the sequences of the record, such like
> > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> > > > relied
> > > > > by the TxEvent className. I think it would be better to use the
> enum
> > > type
> > > > > since the class name could be changed with the issue of
> > compatibility.
> > > >
> > > >
> > > > We are in short of developers and cut some corners in our
> > implementation,
> > > > such as using TxEvent class names as event type. :)
> > > >
> > > OK, I will raise a SCB jira for this if you agree.
> > >
> > > >
> > > > 4. The annotation SagaStart is used to indicate the boundary edge of
> > the
> > > > > Saga Transaction. I assume that we can use like the following
> > > > > @SagaStart
> > > > > public Response svc( ) {
> > > > > restTemplate() -> invoke (serviceA);
> > > > > retsTemplate() -> invoke (serviceB);
> > > > > }
> > > >
> > > >
> > > > Yes, we have integration tests to illustrate this idea in pack-tests
> > > > module.
> > > >
> > > > So I suggest that we use the @Saga or @SagaContext to replace the
> > > > > @SagaStart to make it clear. Also in the processor of this
> > annotation,
> > > > the
> > > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > >
> > > >
> > > > Proper naming is hard and we can definitely give it more thoughts.
> > > Indeed,
> > > > we have code to send SagaStartedEvent and SagaEndedEvent around
> > > @SagaStart
> > > > in success scenario.
> > > > In failure cases, we try to achieve that Alpha writes SagaEndedEvent
> by
> > > > itself, since compensations are done asynchronously.
> > > >
> > > > 5. After going through the omega codes, I think it could be possible
> to
> > > > > introduce a OmegaClient interface to handle all of the events
> related
> > > > with
> > > > > the Saga. some pseudo code looks like
> > > > > public interface OmegaClient {
> > > > > void saga_start( );
> > > > > void saga_close( );
> > > > > void saga_cancel( );
> > > > > void saga_tx_start( );
> > > > > void saga_tx_end( );
> > > > > void saga_tx_failed( );
> > > > > void saga_compensate( );
> > > > > }
> > > > > So we can get the GrpcOmegaClient to implement it with the gRPC
> > > > > connection. This could be helpful if we have the other underlying
> > > > > connection in the future.
> > > >
> > > >
> > > > We do have a communication interface (MessageSender) for potential
> > > > extension in the future. And another interface
> (EventAwareInterceptor)
> > > for
> > > > composing these saga events.
> > > > Like you said, we probably should have given methods in
> > > > EventAwareInterceptor more meaningful names.
> > > >
> > > Can you point me the link for the EventAwareInterceptor ? I can not
> find
> > it
> > > in the incubator-servicecomb-saga.
> > >
> > > >
> > > > 6. I have not find any annotation with the participant. So it could
> be
> > > > > possible to introduce the @Participant just like
> > > > > public class ServiceA {
> > > > > @Participant
> > > > > public Response work( );
> > > > > @Compensate
> > > > > public void undo( );
> > > > > }
> > > >
> > > >
> > > > The annotation for partcipants is @Compensable.
> > > >
> > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > MANDATORY,
> > > >
> > > >
> > > > I did not quite understand what you mean. Could you please elaborate
> a
> > > bit
> > > > more?
> > > >
> > > The idea is from the traditional transaction of EJB, you can find
> > > https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
> > >
> > > >
> > > > You have been working on data consistency problems for quite a while
> > and
> > > > must have many useful insights.
> > > > We are very lucky if you join us on this project!
> > > >
> > > > Thank you!
> > > >
> > > > Best Regards,
> > > > Sean
> > > >
> > > > On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com>
> wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I've tried to understand about the new architecture PACK of the
> > > > > servicecomb-saga.
> > > > >
> > > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks
> like
> > a
> > > > > 'Saga Coordinator'.
> > > > > 2. They communicate each other with the underlying gRPC
> connections.
> > > > > 3. The TxEvent is defined as the sequences of the record, such like
> > > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> > > > relied
> > > > > by the TxEvent className. I think it would be better to use the
> enum
> > > type
> > > > > since the class name could be changed with the issue of
> > compatibility.
> > > > > 4. The annotation SagaStart is used to indicate the boundary edge
> of
> > > the
> > > > > Saga Transaction. I assume that we can use like the following
> > > > > @SagaStart
> > > > > public Response svc( ) {
> > > > > restTemplate() -> invoke (serviceA);
> > > > > retsTemplate() -> invoke (serviceB);
> > > > > }
> > > > > So I suggest that we use the @Saga or @SagaContext to replace
> the
> > > > > @SagaStart to make it clear. Also in the processor of this
> > annotation,
> > > > the
> > > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > > >
> > > > > 5. After going through the omega codes, I think it could be
> possible
> > to
> > > > > introduce a OmegaClient interface to handle all of the events
> related
> > > > with
> > > > > the Saga. some pseudo code looks like
> > > > > public interface OmegaClient {
> > > > > void saga_start( );
> > > > > void saga_close( );
> > > > > void saga_cancel( );
> > > > > void saga_tx_start( );
> > > > > void saga_tx_end( );
> > > > > void saga_tx_failed( );
> > > > > void saga_compensate( );
> > > > > }
> > > > > So we can get the GrpcOmegaClient to implement it with the gRPC
> > > > > connection. This could be helpful if we have the other underlying
> > > > > connection in the future.
> > > > >
> > > > > 6. I have not find any annotation with the participant. So it could
> > be
> > > > > possible to introduce the @Participant just like
> > > > >
> > > > > public class ServiceA {
> > > > > @Participant
> > > > > public Response work( );
> > > > >
> > > > > @Compensate
> > > > > public void undo( );
> > > > > }
> > > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > > MANDATORY,
> > > > > ...
> > > > >
> > > > > Anyway, I will be happy to involved in the servicecomb saga and
> > welcome
> > > > for
> > > > > any input.
> > > > >
> > > > > Thanks,
> > > > > Zheng
> > > > >
> > > >
> > >
> >
>
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Zheng Feng <zh...@gmail.com>.
yeah, I raised https://issues.apache.org/jira/browse/SCB-228 for the issue
of TxEvent type and feel free to assign to me. I think I have no access to
assign myself as I am not the member of the servicecomb
2018-01-12 17:39 GMT+08:00 Willem Jiang <wi...@gmail.com>:
> Hi FengZheng，
>
> It's good to see you here and we are looking forward your valuable inputs
> and contribution :)
>
>
> Willem Jiang
>
> Blog: http://willemjiang.blogspot.com (English)
> http://jnn.iteye.com (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Fri, Jan 12, 2018 at 3:38 PM, Zheng Feng <zh...@gmail.com> wrote:
>
> > comment inline,
> >
> > 2018-01-12 10:17 GMT+08:00 Sean Yin <se...@gmail.com>:
> >
> > > Hi Zheng,
> > >
> > > Thank you for taking your time to go through our Pack architecture of
> > > ServiceComb Saga.
> > >
> > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> > > > 'Saga Coordinator'.
> > > > 2. They communicate each other with the underlying gRPC connections.
> > >
> > >
> > > You are right about the roles of Omega and Alpha in this architecture.
> > And
> > > the suggestions you provided are very valuable to us.
> > >
> > > 3. The TxEvent is defined as the sequences of the record, such like
> > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> > > relied
> > > > by the TxEvent className. I think it would be better to use the enum
> > type
> > > > since the class name could be changed with the issue of
> compatibility.
> > >
> > >
> > > We are in short of developers and cut some corners in our
> implementation,
> > > such as using TxEvent class names as event type. :)
> > >
> > OK, I will raise a SCB jira for this if you agree.
> >
> > >
> > > 4. The annotation SagaStart is used to indicate the boundary edge of
> the
> > > > Saga Transaction. I assume that we can use like the following
> > > > @SagaStart
> > > > public Response svc( ) {
> > > > restTemplate() -> invoke (serviceA);
> > > > retsTemplate() -> invoke (serviceB);
> > > > }
> > >
> > >
> > > Yes, we have integration tests to illustrate this idea in pack-tests
> > > module.
> > >
> > > So I suggest that we use the @Saga or @SagaContext to replace the
> > > > @SagaStart to make it clear. Also in the processor of this
> annotation,
> > > the
> > > > SagaStartedEvent and SagaEndedEvent are sent.
> > >
> > >
> > > Proper naming is hard and we can definitely give it more thoughts.
> > Indeed,
> > > we have code to send SagaStartedEvent and SagaEndedEvent around
> > @SagaStart
> > > in success scenario.
> > > In failure cases, we try to achieve that Alpha writes SagaEndedEvent by
> > > itself, since compensations are done asynchronously.
> > >
> > > 5. After going through the omega codes, I think it could be possible to
> > > > introduce a OmegaClient interface to handle all of the events related
> > > with
> > > > the Saga. some pseudo code looks like
> > > > public interface OmegaClient {
> > > > void saga_start( );
> > > > void saga_close( );
> > > > void saga_cancel( );
> > > > void saga_tx_start( );
> > > > void saga_tx_end( );
> > > > void saga_tx_failed( );
> > > > void saga_compensate( );
> > > > }
> > > > So we can get the GrpcOmegaClient to implement it with the gRPC
> > > > connection. This could be helpful if we have the other underlying
> > > > connection in the future.
> > >
> > >
> > > We do have a communication interface (MessageSender) for potential
> > > extension in the future. And another interface (EventAwareInterceptor)
> > for
> > > composing these saga events.
> > > Like you said, we probably should have given methods in
> > > EventAwareInterceptor more meaningful names.
> > >
> > Can you point me the link for the EventAwareInterceptor ? I can not find
> it
> > in the incubator-servicecomb-saga.
> >
> > >
> > > 6. I have not find any annotation with the participant. So it could be
> > > > possible to introduce the @Participant just like
> > > > public class ServiceA {
> > > > @Participant
> > > > public Response work( );
> > > > @Compensate
> > > > public void undo( );
> > > > }
> > >
> > >
> > > The annotation for partcipants is @Compensable.
> > >
> > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > MANDATORY,
> > >
> > >
> > > I did not quite understand what you mean. Could you please elaborate a
> > bit
> > > more?
> > >
> > The idea is from the traditional transaction of EJB, you can find
> > https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
> >
> > >
> > > You have been working on data consistency problems for quite a while
> and
> > > must have many useful insights.
> > > We are very lucky if you join us on this project!
> > >
> > > Thank you!
> > >
> > > Best Regards,
> > > Sean
> > >
> > > On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > I've tried to understand about the new architecture PACK of the
> > > > servicecomb-saga.
> > > >
> > > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like
> a
> > > > 'Saga Coordinator'.
> > > > 2. They communicate each other with the underlying gRPC connections.
> > > > 3. The TxEvent is defined as the sequences of the record, such like
> > > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> > > relied
> > > > by the TxEvent className. I think it would be better to use the enum
> > type
> > > > since the class name could be changed with the issue of
> compatibility.
> > > > 4. The annotation SagaStart is used to indicate the boundary edge of
> > the
> > > > Saga Transaction. I assume that we can use like the following
> > > > @SagaStart
> > > > public Response svc( ) {
> > > > restTemplate() -> invoke (serviceA);
> > > > retsTemplate() -> invoke (serviceB);
> > > > }
> > > > So I suggest that we use the @Saga or @SagaContext to replace the
> > > > @SagaStart to make it clear. Also in the processor of this
> annotation,
> > > the
> > > > SagaStartedEvent and SagaEndedEvent are sent.
> > > >
> > > > 5. After going through the omega codes, I think it could be possible
> to
> > > > introduce a OmegaClient interface to handle all of the events related
> > > with
> > > > the Saga. some pseudo code looks like
> > > > public interface OmegaClient {
> > > > void saga_start( );
> > > > void saga_close( );
> > > > void saga_cancel( );
> > > > void saga_tx_start( );
> > > > void saga_tx_end( );
> > > > void saga_tx_failed( );
> > > > void saga_compensate( );
> > > > }
> > > > So we can get the GrpcOmegaClient to implement it with the gRPC
> > > > connection. This could be helpful if we have the other underlying
> > > > connection in the future.
> > > >
> > > > 6. I have not find any annotation with the participant. So it could
> be
> > > > possible to introduce the @Participant just like
> > > >
> > > > public class ServiceA {
> > > > @Participant
> > > > public Response work( );
> > > >
> > > > @Compensate
> > > > public void undo( );
> > > > }
> > > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > > MANDATORY,
> > > > ...
> > > >
> > > > Anyway, I will be happy to involved in the servicecomb saga and
> welcome
> > > for
> > > > any input.
> > > >
> > > > Thanks,
> > > > Zheng
> > > >
> > >
> >
>
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Willem Jiang <wi...@gmail.com>.
Hi FengZheng，
It's good to see you here and we are looking forward your valuable inputs
and contribution :)
Willem Jiang
Blog: http://willemjiang.blogspot.com (English)
http://jnn.iteye.com (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Fri, Jan 12, 2018 at 3:38 PM, Zheng Feng <zh...@gmail.com> wrote:
> comment inline,
>
> 2018-01-12 10:17 GMT+08:00 Sean Yin <se...@gmail.com>:
>
> > Hi Zheng,
> >
> > Thank you for taking your time to go through our Pack architecture of
> > ServiceComb Saga.
> >
> > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> > > 'Saga Coordinator'.
> > > 2. They communicate each other with the underlying gRPC connections.
> >
> >
> > You are right about the roles of Omega and Alpha in this architecture.
> And
> > the suggestions you provided are very valuable to us.
> >
> > 3. The TxEvent is defined as the sequences of the record, such like
> > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> > relied
> > > by the TxEvent className. I think it would be better to use the enum
> type
> > > since the class name could be changed with the issue of compatibility.
> >
> >
> > We are in short of developers and cut some corners in our implementation,
> > such as using TxEvent class names as event type. :)
> >
> OK, I will raise a SCB jira for this if you agree.
>
> >
> > 4. The annotation SagaStart is used to indicate the boundary edge of the
> > > Saga Transaction. I assume that we can use like the following
> > > @SagaStart
> > > public Response svc( ) {
> > > restTemplate() -> invoke (serviceA);
> > > retsTemplate() -> invoke (serviceB);
> > > }
> >
> >
> > Yes, we have integration tests to illustrate this idea in pack-tests
> > module.
> >
> > So I suggest that we use the @Saga or @SagaContext to replace the
> > > @SagaStart to make it clear. Also in the processor of this annotation,
> > the
> > > SagaStartedEvent and SagaEndedEvent are sent.
> >
> >
> > Proper naming is hard and we can definitely give it more thoughts.
> Indeed,
> > we have code to send SagaStartedEvent and SagaEndedEvent around
> @SagaStart
> > in success scenario.
> > In failure cases, we try to achieve that Alpha writes SagaEndedEvent by
> > itself, since compensations are done asynchronously.
> >
> > 5. After going through the omega codes, I think it could be possible to
> > > introduce a OmegaClient interface to handle all of the events related
> > with
> > > the Saga. some pseudo code looks like
> > > public interface OmegaClient {
> > > void saga_start( );
> > > void saga_close( );
> > > void saga_cancel( );
> > > void saga_tx_start( );
> > > void saga_tx_end( );
> > > void saga_tx_failed( );
> > > void saga_compensate( );
> > > }
> > > So we can get the GrpcOmegaClient to implement it with the gRPC
> > > connection. This could be helpful if we have the other underlying
> > > connection in the future.
> >
> >
> > We do have a communication interface (MessageSender) for potential
> > extension in the future. And another interface (EventAwareInterceptor)
> for
> > composing these saga events.
> > Like you said, we probably should have given methods in
> > EventAwareInterceptor more meaningful names.
> >
> Can you point me the link for the EventAwareInterceptor ? I can not find it
> in the incubator-servicecomb-saga.
>
> >
> > 6. I have not find any annotation with the participant. So it could be
> > > possible to introduce the @Participant just like
> > > public class ServiceA {
> > > @Participant
> > > public Response work( );
> > > @Compensate
> > > public void undo( );
> > > }
> >
> >
> > The annotation for partcipants is @Compensable.
> >
> > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> MANDATORY,
> >
> >
> > I did not quite understand what you mean. Could you please elaborate a
> bit
> > more?
> >
> The idea is from the traditional transaction of EJB, you can find
> https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
>
> >
> > You have been working on data consistency problems for quite a while and
> > must have many useful insights.
> > We are very lucky if you join us on this project!
> >
> > Thank you!
> >
> > Best Regards,
> > Sean
> >
> > On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com> wrote:
> >
> > > Hi all,
> > >
> > > I've tried to understand about the new architecture PACK of the
> > > servicecomb-saga.
> > >
> > > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> > > 'Saga Coordinator'.
> > > 2. They communicate each other with the underlying gRPC connections.
> > > 3. The TxEvent is defined as the sequences of the record, such like
> > > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> > relied
> > > by the TxEvent className. I think it would be better to use the enum
> type
> > > since the class name could be changed with the issue of compatibility.
> > > 4. The annotation SagaStart is used to indicate the boundary edge of
> the
> > > Saga Transaction. I assume that we can use like the following
> > > @SagaStart
> > > public Response svc( ) {
> > > restTemplate() -> invoke (serviceA);
> > > retsTemplate() -> invoke (serviceB);
> > > }
> > > So I suggest that we use the @Saga or @SagaContext to replace the
> > > @SagaStart to make it clear. Also in the processor of this annotation,
> > the
> > > SagaStartedEvent and SagaEndedEvent are sent.
> > >
> > > 5. After going through the omega codes, I think it could be possible to
> > > introduce a OmegaClient interface to handle all of the events related
> > with
> > > the Saga. some pseudo code looks like
> > > public interface OmegaClient {
> > > void saga_start( );
> > > void saga_close( );
> > > void saga_cancel( );
> > > void saga_tx_start( );
> > > void saga_tx_end( );
> > > void saga_tx_failed( );
> > > void saga_compensate( );
> > > }
> > > So we can get the GrpcOmegaClient to implement it with the gRPC
> > > connection. This could be helpful if we have the other underlying
> > > connection in the future.
> > >
> > > 6. I have not find any annotation with the participant. So it could be
> > > possible to introduce the @Participant just like
> > >
> > > public class ServiceA {
> > > @Participant
> > > public Response work( );
> > >
> > > @Compensate
> > > public void undo( );
> > > }
> > > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> > MANDATORY,
> > > ...
> > >
> > > Anyway, I will be happy to involved in the servicecomb saga and welcome
> > for
> > > any input.
> > >
> > > Thanks,
> > > Zheng
> > >
> >
>
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Zheng Feng <zh...@gmail.com>.
comment inline,
2018-01-12 10:17 GMT+08:00 Sean Yin <se...@gmail.com>:
> Hi Zheng,
>
> Thank you for taking your time to go through our Pack architecture of
> ServiceComb Saga.
>
> 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> > 'Saga Coordinator'.
> > 2. They communicate each other with the underlying gRPC connections.
>
>
> You are right about the roles of Omega and Alpha in this architecture. And
> the suggestions you provided are very valuable to us.
>
> 3. The TxEvent is defined as the sequences of the record, such like
> > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> relied
> > by the TxEvent className. I think it would be better to use the enum type
> > since the class name could be changed with the issue of compatibility.
>
>
> We are in short of developers and cut some corners in our implementation,
> such as using TxEvent class names as event type. :)
>
OK, I will raise a SCB jira for this if you agree.
>
> 4. The annotation SagaStart is used to indicate the boundary edge of the
> > Saga Transaction. I assume that we can use like the following
> > @SagaStart
> > public Response svc( ) {
> > restTemplate() -> invoke (serviceA);
> > retsTemplate() -> invoke (serviceB);
> > }
>
>
> Yes, we have integration tests to illustrate this idea in pack-tests
> module.
>
> So I suggest that we use the @Saga or @SagaContext to replace the
> > @SagaStart to make it clear. Also in the processor of this annotation,
> the
> > SagaStartedEvent and SagaEndedEvent are sent.
>
>
> Proper naming is hard and we can definitely give it more thoughts. Indeed,
> we have code to send SagaStartedEvent and SagaEndedEvent around @SagaStart
> in success scenario.
> In failure cases, we try to achieve that Alpha writes SagaEndedEvent by
> itself, since compensations are done asynchronously.
>
> 5. After going through the omega codes, I think it could be possible to
> > introduce a OmegaClient interface to handle all of the events related
> with
> > the Saga. some pseudo code looks like
> > public interface OmegaClient {
> > void saga_start( );
> > void saga_close( );
> > void saga_cancel( );
> > void saga_tx_start( );
> > void saga_tx_end( );
> > void saga_tx_failed( );
> > void saga_compensate( );
> > }
> > So we can get the GrpcOmegaClient to implement it with the gRPC
> > connection. This could be helpful if we have the other underlying
> > connection in the future.
>
>
> We do have a communication interface (MessageSender) for potential
> extension in the future. And another interface (EventAwareInterceptor) for
> composing these saga events.
> Like you said, we probably should have given methods in
> EventAwareInterceptor more meaningful names.
>
Can you point me the link for the EventAwareInterceptor ? I can not find it
in the incubator-servicecomb-saga.
>
> 6. I have not find any annotation with the participant. So it could be
> > possible to introduce the @Participant just like
> > public class ServiceA {
> > @Participant
> > public Response work( );
> > @Compensate
> > public void undo( );
> > }
>
>
> The annotation for partcipants is @Compensable.
>
> and it could be useful to add the type SUPPORT, NOT_SUPPORT, MANDATORY,
>
>
> I did not quite understand what you mean. Could you please elaborate a bit
> more?
>
The idea is from the traditional transaction of EJB, you can find
https://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
>
> You have been working on data consistency problems for quite a while and
> must have many useful insights.
> We are very lucky if you join us on this project!
>
> Thank you!
>
> Best Regards,
> Sean
>
> On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com> wrote:
>
> > Hi all,
> >
> > I've tried to understand about the new architecture PACK of the
> > servicecomb-saga.
> >
> > 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> > 'Saga Coordinator'.
> > 2. They communicate each other with the underlying gRPC connections.
> > 3. The TxEvent is defined as the sequences of the record, such like
> > SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> > TxAbortedEvent, TxCompensatedEvent. And currently the event type is
> relied
> > by the TxEvent className. I think it would be better to use the enum type
> > since the class name could be changed with the issue of compatibility.
> > 4. The annotation SagaStart is used to indicate the boundary edge of the
> > Saga Transaction. I assume that we can use like the following
> > @SagaStart
> > public Response svc( ) {
> > restTemplate() -> invoke (serviceA);
> > retsTemplate() -> invoke (serviceB);
> > }
> > So I suggest that we use the @Saga or @SagaContext to replace the
> > @SagaStart to make it clear. Also in the processor of this annotation,
> the
> > SagaStartedEvent and SagaEndedEvent are sent.
> >
> > 5. After going through the omega codes, I think it could be possible to
> > introduce a OmegaClient interface to handle all of the events related
> with
> > the Saga. some pseudo code looks like
> > public interface OmegaClient {
> > void saga_start( );
> > void saga_close( );
> > void saga_cancel( );
> > void saga_tx_start( );
> > void saga_tx_end( );
> > void saga_tx_failed( );
> > void saga_compensate( );
> > }
> > So we can get the GrpcOmegaClient to implement it with the gRPC
> > connection. This could be helpful if we have the other underlying
> > connection in the future.
> >
> > 6. I have not find any annotation with the participant. So it could be
> > possible to introduce the @Participant just like
> >
> > public class ServiceA {
> > @Participant
> > public Response work( );
> >
> > @Compensate
> > public void undo( );
> > }
> > and it could be useful to add the type SUPPORT, NOT_SUPPORT,
> MANDATORY,
> > ...
> >
> > Anyway, I will be happy to involved in the servicecomb saga and welcome
> for
> > any input.
> >
> > Thanks,
> > Zheng
> >
>
Re: Some thoughts about PACK of the servicecomb-saga
Posted by Sean Yin <se...@gmail.com>.
Hi Zheng,
Thank you for taking your time to go through our Pack architecture of
ServiceComb Saga.
1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> 'Saga Coordinator'.
> 2. They communicate each other with the underlying gRPC connections.
You are right about the roles of Omega and Alpha in this architecture. And
the suggestions you provided are very valuable to us.
3. The TxEvent is defined as the sequences of the record, such like
> SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> TxAbortedEvent, TxCompensatedEvent. And currently the event type is relied
> by the TxEvent className. I think it would be better to use the enum type
> since the class name could be changed with the issue of compatibility.
We are in short of developers and cut some corners in our implementation,
such as using TxEvent class names as event type. :)
4. The annotation SagaStart is used to indicate the boundary edge of the
> Saga Transaction. I assume that we can use like the following
> @SagaStart
> public Response svc( ) {
> restTemplate() -> invoke (serviceA);
> retsTemplate() -> invoke (serviceB);
> }
Yes, we have integration tests to illustrate this idea in pack-tests module.
So I suggest that we use the @Saga or @SagaContext to replace the
> @SagaStart to make it clear. Also in the processor of this annotation, the
> SagaStartedEvent and SagaEndedEvent are sent.
Proper naming is hard and we can definitely give it more thoughts. Indeed,
we have code to send SagaStartedEvent and SagaEndedEvent around @SagaStart
in success scenario.
In failure cases, we try to achieve that Alpha writes SagaEndedEvent by
itself, since compensations are done asynchronously.
5. After going through the omega codes, I think it could be possible to
> introduce a OmegaClient interface to handle all of the events related with
> the Saga. some pseudo code looks like
> public interface OmegaClient {
> void saga_start( );
> void saga_close( );
> void saga_cancel( );
> void saga_tx_start( );
> void saga_tx_end( );
> void saga_tx_failed( );
> void saga_compensate( );
> }
> So we can get the GrpcOmegaClient to implement it with the gRPC
> connection. This could be helpful if we have the other underlying
> connection in the future.
We do have a communication interface (MessageSender) for potential
extension in the future. And another interface (EventAwareInterceptor) for
composing these saga events.
Like you said, we probably should have given methods in
EventAwareInterceptor more meaningful names.
6. I have not find any annotation with the participant. So it could be
> possible to introduce the @Participant just like
> public class ServiceA {
> @Participant
> public Response work( );
> @Compensate
> public void undo( );
> }
The annotation for partcipants is @Compensable.
and it could be useful to add the type SUPPORT, NOT_SUPPORT, MANDATORY,
I did not quite understand what you mean. Could you please elaborate a bit
more?
You have been working on data consistency problems for quite a while and
must have many useful insights.
We are very lucky if you join us on this project!
Thank you!
Best Regards,
Sean
On Fri, Jan 12, 2018 at 9:28 AM, Zheng Feng <zh...@gmail.com> wrote:
> Hi all,
>
> I've tried to understand about the new architecture PACK of the
> servicecomb-saga.
>
> 1. The Omega acts like a 'Saga Participant' and the Alpha looks like a
> 'Saga Coordinator'.
> 2. They communicate each other with the underlying gRPC connections.
> 3. The TxEvent is defined as the sequences of the record, such like
> SagaStartedEvent, SagaEndedEvent, TxStartedEvent, TxEndedEvent,
> TxAbortedEvent, TxCompensatedEvent. And currently the event type is relied
> by the TxEvent className. I think it would be better to use the enum type
> since the class name could be changed with the issue of compatibility.
> 4. The annotation SagaStart is used to indicate the boundary edge of the
> Saga Transaction. I assume that we can use like the following
> @SagaStart
> public Response svc( ) {
> restTemplate() -> invoke (serviceA);
> retsTemplate() -> invoke (serviceB);
> }
> So I suggest that we use the @Saga or @SagaContext to replace the
> @SagaStart to make it clear. Also in the processor of this annotation, the
> SagaStartedEvent and SagaEndedEvent are sent.
>
> 5. After going through the omega codes, I think it could be possible to
> introduce a OmegaClient interface to handle all of the events related with
> the Saga. some pseudo code looks like
> public interface OmegaClient {
> void saga_start( );
> void saga_close( );
> void saga_cancel( );
> void saga_tx_start( );
> void saga_tx_end( );
> void saga_tx_failed( );
> void saga_compensate( );
> }
> So we can get the GrpcOmegaClient to implement it with the gRPC
> connection. This could be helpful if we have the other underlying
> connection in the future.
>
> 6. I have not find any annotation with the participant. So it could be
> possible to introduce the @Participant just like
>
> public class ServiceA {
> @Participant
> public Response work( );
>
> @Compensate
> public void undo( );
> }
> and it could be useful to add the type SUPPORT, NOT_SUPPORT, MANDATORY,
> ...
>
> Anyway, I will be happy to involved in the servicecomb saga and welcome for
> any input.
>
> Thanks,
> Zheng
>