11/20/07 :: [SOA] REST,Resources, Lifecycles, States and Actions [permalink]
Bill, thanks for replying. I think we are at the heart of the discussion. Hopefully the pictures are not just pretty, they help illustrate and reason about this discussion.
Bill: I'm not sure what my post about RESTFaces has to do with anything [you are] talking about
JJ: To clarify, you said in your earlier post about RESTFaces: "The giveaway word is "action"; unfortunately that's not REST style, that's RPC". I am not sure my post had anything to do with business processes. I really talked about a resource, its lifecycle and the operations that can be invoked to change its state (not its content). Of course, these types of operations are often invoked as part of business processes, but I really would like to focus the discussion on resource lifecycle (states and transitions). I don't want to use concepts other than the one that REST claims you need.
Bill: It seems to me that the "business interface" mentioned is the exchange of well understood document/schema along with well understood operations. In other words you have to define both.
JJ: No, they are orthogonal. The tragedy of modern programming models (including and above all OOP, RDBMS or even the latest LinQ API) is that they do not distinguish between content and state. I actually never saw a developer clearly articulating the state machine of a business entity or an object, let alone change its state in an orderly manner. The business interface contains the operations that will trigger a state transition. Some content may be provided to decide if the transition is valid, but the intent is to trigger a state transition, not to update content, which can be achieved with a PUT (a schema would simply avoid mundane data type errors). It would be a good pattern to enforce the separation between content update and state transition requests.
Bill: why can't I GET the state and have a well-understood formal document returned citing the state of that entity? Or for that matter PUT the updated state to that entity?
JJ: You can PUT the updated state, this works perfectly fine. My argument is that in doing so, you cannot ignore the semantics of the business interface -unless I am missing something. How do you know that changing a value in the "representation" of the resource, will actually trigger a transition from one state to another? Don't you need to share this understanding between the consumer of the resource representation and the resource? How could you expect consistent results otherwise?
Back to your first point, could you please be more precise about what you mean by "a well-understood formal document returned citing the state of that entity"? I am not sure REST has any semantics which can even come close to what I can imagine reading this sentence. Are you talking about a schema? a business interface?
In general you don't want to expose the state machine, this is private information. It may even be expressed in a formalism that is incompatible between the representation consumer and the resource itself. Incidentally, the state machine may not even be expressed at all. It might just be "in-the-implementation" as it is so often today. You are generally more inclined to specify the actions that cause state transitions, this is a much better separation of concern, a lot easier to agree on, both on the semantics and the expression of these actions. You may call them RPC, but they are not (I am not calling a procedure).
Bill: Certainly there are document schema for interchange in BPM space, but they seem to be stuck on non-uniform methods, aka operations, as were the WS-* standards before them.
JJ: I think you may be mistaken. Are you familiar with the work of the Open Applications Group? They actually recommend using a very small number of verbs (9 verbs) and an infinite amount of nouns. Now, it does not mean that I necessary buy this limitation... because they are not making states explicit either. OAGi Verbs include "Process" or "Synch" (which are content based, the OAGi architecture predates REST and is some form of Business-REST). At the end of the day, I am not sure I can construct a business interface with these verbs (I have a tough time any ways), I will have to agree out-of-band on combinations of (Verb,PropertyValues) as actions, I argue that this is worse than having an explicit business interface.
Bill: One downside of non-uniform (or per process) operations is that you have to worry about the order the operations are executed in, and ultimately that reduces to a programming/scripting exercise, but happening across system boundaries.
JJ: That's what I am talking about, I am not sure you can ignore "them" and the order they are executed in otherwise you will sometimes require transitions which are forbidden and generate a fault. What's the point? Do you want to create systems that "try-until-it-works"? Note that you don't seem to be alone in that camp. Most of the thought leaders of our times simply don't get it. For instance for Don Box:
Personally, my dream stack would be ubiquitous WS-Security/WS-Trust over HTTP GET and POST and tossing out WSDL in favor of doing direct XML programming against payloads from VB9 (or XQuery), but hey, I have unusual tastes.
The scary thought is that his team is now designing the next generation programming language of .Net. I know exactly how it will look like.
Bill: Perhaps all the SOA/BPM community are saying is that REST doesn't have a formal interlingua for business processes
JJ: No, this is irrelevant, this is more profound: it is at the root of the programming model. This is about making states explicit. The genius behind REST is that it works perfectly for human-system interactions. The system can expose actions as part of the Representational State (i.e. application state as opposed to resource content) and humans can make sense of them without effort or any kind of a priori information exchange (you do need user's manuals from time to time, but for the most part they have been eliminated). So, what I am arguing is that
a) the REST camp is thoroughly denying that actions are a necessary semantic as part of the programming model
but they will always be there. they will never go away, they are part of the nature of resources (not processes)
b) REST makes things a lot more complex when two servers interact and are expected to transition a resource to a new state as part of this interaction.
you are on your own to express and code the business interface. In server-to-server interactions REST becomes a "protocol" over which the business interface is layered (painfully).
Simply put, REST benefits are not transposable to server-to-server interactions without an implicit understanding of the "business interface". A "schema" really optimizes the utilization of the "PUT" pattern for updating content.
Bill: but why would it any more than an NFA state machine formalism would? That would be bad layering
JJ: Of course, it is the other way around, you want to associate a (DFA) State Machine to a resource, not a resource formalism to a state machine formalism. A lifecycle is an intrinsic part of a resource. Any resource, especially business entities. These state machines are very intuitive, very easy to design and would be easy to leverage if only the handful of computer scientists that define programming language semantics would understand that this is a terrible mistake to think that these semantics can be derived from a smaller set of semantics because of the amount of inefficiencies that are generated by having to recode these concepts over and over.
Bill can you imagine the amount of useless work that is/would be performed in the world simply because these semantics were not important to you/people like you? It would be like talking with a vocabulary of 4 words. Now, REST does not stop here, it even goes further, it says, you don't even need the semantics of a business interface because you have a PUT. I am sure we could invent a language based on a vocabulary of two words. That's not the problem, the question is, is it what we need?
Bill the problem is not to find the simplest set of semantics - this is an interesting exercise - but by forcing everyone to adopt these semantics, you would be killing IT. If I may I would like to suggest another interesting exercise. How about finding the smallest amount of application semantics that would make it easiest to develop your typical information system?
Bill please note that I am not asking you to endorse WS-*, I am only talking at the semantic level, you can still think that WS-* is XXX. WS-* is all I have ... for now, so I take it. In the end you will realize that I am even a stronger RESTifarian than you or Stefan are since I am advocating to put the resource (and resource representations) at the center of the programming model, but in doing so, I make no assumption about the programming model itself, I try to find the best programming model on this foundation.