I think we can extend Transport interface to a new interface named SQLTransport.
the SQLTransport also include 'with' function, but the parameters only requires
datasource/serviceName, sql and parameters.
Users can decide how to execute the sql of the datasource/serviceName in their
own SQLTransport implements.
In order to invoke SQLTransport successfully, we need to modify the Operation,
Transaction and Compensation setions of Format for matching new json requests.
the new json structure is:
{
"policy":"",
"requests":[
{
"id":"",
"type":"SQL",
"serviceName(or datasource)":"",
"parents":[],
"transaction":{
"sql":"",
"params":[] (or {})
},
"compensation":{
"sql":"",
"params":[] (or {})
}
}
]
}
------------------ ???????? ------------------
??????: "Willem Jiang"<[email protected]>;
????????: 2018??8??21??(??????) ????8:34
??????: "dev"<[email protected]>;
????: Re: [DISCUSS]Add a local or embedded interface to call Saga
The saga patten is quite simple, if call is failed, the compensation method
should be called.
I know someone already provide the framework[1] with Scala to simplify the
complex if else check.
The PersonService and EmailService can be the remote service or local
service.
val persistInvoiceAndSendEmail: Future[Email :: Person :: HNil] = saga
.part[Person](PersonService.addInvoice(person, invoice), p =>
PersonService.deleteInvoice(p, invoice))
.part[Email](EmailService.sendInvoice(person.email, invoice), letter
=> EmailService.sendExcuse(letter.email,
EmailService.createExcuse(letter)))
.run
persistInvoiceAndSendEmail.onComplete {
case Success(email :: person :: HNil) =>
logger.debug("There you can manage process results")
case Failure(SagaFailed(message, _)) =>
logger.error(s"One saga part has been failed due to $message")
}
[1]https://github.com/dobrynya/saga
Willem Jiang
Twitter: willemjiang
Weibo: ????willem
On Mon, Aug 20, 2018 at 10:26 PM, Zheng Feng <[email protected]> wrote:
> Thanks Willem and it is a good point here. Also I'm interesting how it
> could be used in the local or the embedded interface ? I wonder if you can
> consider the ACID transaction in this situation.
> The Saga in my options could be more used for the distributed environment.
>
> Regard,
> Amos
>
> 2018-08-20 18:00 GMT+08:00 Willem Jiang <[email protected]>:
>
> > the saga-core has a transport[1] interface which could be used for the
> > purpose, now it just have the Restful implementation.
> > If you want to implement a RPC or some local method, you can just
> implement
> > the transport interface.
> > As the saga-core using json for the invocation, you need to updated the
> > request/response json module[2] there.
> >
> > [1]
> > https://github.com/apache/incubator-servicecomb-saga/
> > blob/master/saga-core/src/main/java/org/apache/servicecomb/saga/core/
> > Transport.java#L20:18
> > [2]
> > https://github.com/apache/incubator-servicecomb-saga/
> > tree/master/saga-format
> >
> >
> >
> > Willem Jiang
> >
> > Twitter: willemjiang
> > Weibo: ????willem
> >
> > On Mon, Aug 20, 2018 at 5:37 PM, ???????????? <[email protected]> wrote:
> >
> > > Hi, all:
> > >
> > >
> > > Currently, service comb saga have implemented transaction management
> > based
> > > on microservice.
> > > But in some cases, users want to use Saga with a simpler way, such as
> > > local or embedded call.
> > > So we want to discuss whether it is possible to extend a local or
> > embedded
> > > interface.
> > > When the user implements the embedded interface and injects Saga into
> the
> > > native program,
> > > Saga calls the local method directly instead of calling the
> microservice.
> > >
> > >
> > > Best Wishes & Regards
> >
>
