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
