Batch calls and a macro command design pattern

[Grigori Kochanov]

Hi, we are implementing the JSON-RPC 2 protocol, and would like to offer an improvement.

We have a case where a request can register a customer, set the delivery address data, save the basket of goods selected and register an order.

A batch request seems a good approach where each action is called sequentially, within a single HTTP request.

The problem is that we need another macro-command to manage the process of each methods called.

The user may be registered, the address validation may fail, and the basket is saved, then the order registration should not be executed. 

If the user is not registered, all other methods should be skipped.

This is a case for a Command (action) design pattern described by GOF. We should register a macro command object and make our methods as sub-commands of a macro command.

What is the best way to describe the macro command in the JSON-RPC 2 protocol? It seems like there is no sub-methods described. I can simply create the method called MACRO and place it along with other methods, and parse it as a macro command in an application logic.

WBR, Grigori

[Burak Yiğit Kaya]

May be transaction support, built into JSON-RPC?

Burak Yiğit "BYK" Kaya <http://byk.im>

--
You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To view this discussion on the web visit https://groups.google.com/d/msg/json-rpc/-/D5XWRAnj-OoJ.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=en.

[Matt (MPCM)]

Hi,

First... batch is not sequential, it could be concurrent per the spec. So you are going to have to push this all into a single call. I don't consider this a bad thing, as the macro mapping you mention probably best lives with the procedure/function (my opinion).

Second, I've done this in a much more limited sense, which worked pretty well for the problem at hand. One option is to consider shipping source code as data to then be used in consideration of the macro command. I've always used dsl rule engines, just stored in json structures, as I wanted the logic cross language... but running javascript inside other languages isn't so bad these days.

Third, consider exposing your primary points of action as json-rpc. Then exposing another json-rpc service along side it, to do address the macro logic concepts but running   on sockets/IPC into the primary json-rpc service. This way you can use your api in a more traditional sense, but you have a way to group actions and logic that isn't far removed and without much additional overhead. Logging this way gives you a much clearer view of how all your calls are interlinked and called.

This is actually one of my favorite uses of json-rpc, but it can get complicated fast... it's just a different style of distributed computing ;)

--

Matt (MPCM)

[Grigori Kochanov]

Hi,  Matt, thanks a lot for ideas,

I am afraid to execute JS from a request because API will be open for the untrusted sources and the service is money-related.

I did not quite understand how to implement the idea with another json-rpc service along side of the main one.

How can I manage the methods in a batch request in one service with a request to another service?

Grigori

вторник, 10 июля 2012 г., 4:42:40 UTC+3 пользователь Matt (MPCM) написал:

[Matt (MPCM)]

On Tuesday, July 10, 2012 3:30:56 AM UTC-4, Grigori Kochanov wrote:

Hi,  Matt, thanks a lot for ideas,

I am afraid to execute JS from a request because API will be open for the untrusted sources and the service is money-related.

Couldn't agree more, just offering it as a thought if you need a rule engine without having to create your own syntax.

 

I did not quite understand how to implement the idea with another json-rpc service along side of the main one.

How can I manage the methods in a batch request in one service with a request to another service?

None of this would use batch in the json-rpc spec. Batch is very much a 'execute this set of requests', it does not impose any control flow around them.

If you need that control flow, it is best implemented in another method that has the flow coded into it. Or like you suggested in your first post, accepts a logic structure to follow in making the actual calls.

Service A would contain all the individual calls you would want to make (createCustomer, setBillingAddress, setShippingAddress, addProductToCart, etc.).
Service B would contain your logic structured calls (i.e. createFullCustomerWithProducst(createCustomer_Data, [addProductToCart_Data, addProductToCart_Data]) ).

Service B's methods would take more complex data payloads and implement the logic of calling createCustomer, setBillingAddress, etc. in Service A.

Having Service B removes the need for the client supply a complex logic structure, and just a call an implemented logic structure, albeit still segmented from A's primary methods. A and B could be in the same service, but I just wanted to show the difference. Instead of having the client supply the structure, implement it inside of Service B.

Giving the client the ability to supply that structure and then having to also limit what gets done as a result of that structure is a lot of work if you don't need the flexibility. Issues to consider when parsing a client supplied logic structure (code in essence): prevent infinite loops, prevent sequence calls that don't make sense contextual sense, unexpected injection of bad data from failed prior calls in the chain, chain call recovery, etc.