Another point I tried to make is that the coordination or lack of it between XDI messages and replies is currently assumed to be in the code sending XDI messages, which could be serial in one thread, or completely parallel and asynchronous, or something in between or more complex. It is not necessarily something that has to be expressed in the XDI syntax or protocol itself, though that is worth thinking about too.On Jul 8, 2010, at 5:04 PM, Markus Sabadello wrote: I think both sync and async should be supported, because sync is must easier to get started with (you just HTTP POST your request and get back the response).
And I don't view the sync/async distinction as "inherent" to XDI messaging, it's just two different ways to transport the request and response, but the syntax of the messages should be the same in both cases.
Markus
On Fri, Jul 9, 2010 at 12:09 AM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:
Another topic discussed on today's call was that we haven't addressed whether XDI messaging is inherently asynchronous or synchronous, and if asynchronous what the method for doing that will be.
My personal POV is that I think it should be inherently asynchronous to match the need for XDI service interactions being distributed and concurrent, so that we avoid blocking. The model I suggested, ignoring for now link contracts, was:
1. A request initiator (R) discovers the XRI where requests for a particular service provided by a service provider (P) are added, most likely a publicly writable but not readable endpoint
2. R then adds an XRI for their request to the graph at that location, this XRI points to a graph under their data authority (or a broker's data authority) that represents the request
3. When P is ready to service the request it reads the request from R's graph, services it
4. P then finds under the request graph where the result is to go, or if not specified writes to the graph in a specific location the XRI where the results are in P's graph
I think this model has the advantages of being asynchronous, designed to be suitable for a distributed worker model, and non blocking. During the discussion I came to the view that maybe it should support both sync and async, as some use cases will not need/want async. My preference though would still be for a purely async model. I also think this will help XDI adoption, given the current drive towards languages that handle concurrency and non-blocking operations as the preferred method for doing things, such as Erlang, Node.js, Scala, Go, and Clojure.
The model above has the disadvantage of increased round-tripping, but I suspect the view will be that given the scalability benefits from async the round tripping costs are outweighed. I'm by no means convinced of that though and would like to discuss it further with everyone.
Joseph made the good point that even if we decide to go async the above is not the only possible pattern and we need to discuss what pattern we want to use.
John also made a good point in that there are large benefits to async from the perspective of the world of distributed computing, which I've incorporated into my comments above.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|