I was just reading over an article that gives a very high level overview of GXA, which, like so many others, makes the fundamental mistake of talking about HTTP as a “transport protocol”. Of course, one only need look at the HTTP spec to see that it’s not, it’s a transfer protocol, which is a very different beast; a coordination language dealing in state.
But after writing about coordination languages last night, something occurred to me; that the more general a transfer protocol, the easier it is to mistake it for a transport protocol. HTTP, effectively, has only two methods; GET and POST, and they are commonly confused with the semantics of send() and recv(). Other transfer protocols, like SMTP, or IM protocols, are also often confused with transport protocols, for the same reason.
Coordination languages come in very general and very specific flavours. WS-Transaction is very specific, for example, as it deals only in “transactions”; any task which can be modelled as a transaction, can be accomplished with WS-Transaction.
An example of a very general coordination language, would be tuple space based systems such as Linda or Javaspaces. These are general because they both deal in an abstraction known as a “space”. A space is a more general abstraction than a “transaction”, because more things can be modelled as spaces. But not every thing. For example, modelling a lightbulb as a space leaves one no way, without additional agreement, to check if the bulb is on or off.
Of all the coordination languages that exist though, I suggest that there is one that is the most general, and it is REST’s “uniform interface”; it deals in “resources”, which includes every thing.