Yes, it is relate to the Operation that Saga already defined in saga-core. I just want to add a new String named TYPE_SQL like TYPE_REST and TYPE_NOP. The TYPE_SQL may be used by JsonSagaRequest interface to let Jackson find the implement class based on 'type' property.
Some questions about JIRA, which issue type should I choose? And should the UML design document be in markdown or other formats, or just a UML diagram? ------------------ ???????? ------------------ ??????: "Willem Jiang"<[email protected]>; ????????: 2018??8??22??(??????) ????4:29 ??????: "dev"<[email protected]>; ????: Re: [DISCUSS]Add a local or embedded interface to call Saga Just a quick question about the Operation's TYPE_SQL? I'm not sure if it is relate to the Operation that Saga already defined. BTW, you can create a JIRA and attached the UML design document to it. Willem Jiang Twitter: willemjiang Weibo: ????willem On Wed, Aug 22, 2018 at 3:51 PM, ???????????? <[email protected]> wrote: > sorry, the image link seems to be invalid. > > > https://raw.githubusercontent.com/KomachiSion/incubator- > servicecomb-saga/share/docs/static_files/SCSagaDesign.png > > > ------------------ ???????? ------------------ > ??????: "????????????"<[email protected]>; > ????????: 2018??8??22??(??????) ????3:49 > ??????: "dev"<[email protected]>; > > ????: Re:[DISCUSS]Add a local or embedded interface to call Saga > > > > SCSagaSQLFormatDesign.png > > > This picture is my design for embedded interface to call Saga. > In the design, we need to extend TYPE_SQL=sql in Operation interface and > JsonSubTypes in JsonSagaRequest interface. > And we need to add some classes to match the new json we defined before. > we also can reuse SagaRequestImpl during JsonSagaDefinition building and > Saga workflow after JsonSagaDefinition > built. > > > ------------------ ???????? ------------------ > ??????: "????????????"<[email protected]>; > ????????: 2018??8??21??(??????) ????10:40 > ??????: "dev"<[email protected]>; > > ????: Re?? [DISCUSS]Add a local or embedded interface to call Saga > > > > sorry, the picture is a simple UML of SQLTransport > > > https://github.com/KomachiSion/incubator-servicecomb-saga/blob/master/ > docs/static_files/Transport.jpg > > > ------------------ ???????? ------------------ > ??????: "Willem Jiang"<[email protected]>; > ????????: 2018??8??21??(??????) ????10:20 > ??????: "dev"<[email protected]>; > > ????: Re: [DISCUSS]Add a local or embedded interface to call Saga > > > > Yeah, the json format of SQL Transport sounds good. > As we normally use the text in the mailing list, so please draw asiis > picture or put a permanent link in the mail for us to review. > > > > Willem Jiang > > Twitter: willemjiang > Weibo: ????willem > > On Tue, Aug 21, 2018 at 10:11 AM, ???????????? <[email protected]> wrote: > > > 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 > > > > > > > > > > > >
