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 <[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
>
