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