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 <[email protected]> wrote: > comment inline, > > 2018-01-12 10:17 GMT+08:00 Sean Yin <[email protected]>: > > > 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 <[email protected]> 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 > > > > > >
