Visit Citebite Deep link provided by Citebite
Close this shade
Source:  http://www.ebpml.org/blog/106.htm

07/08/08 :: [SOA] Programming Models Matter  [permalink]

|

The latest column of Steve Vinoski generated quite a stir.

I would like to comment on one point that I feel is essential -and not surprisingly missing from Steve's argumentation: Programming Models Matter.

The grand goal of Remoting was to make a given programming construct both remotely accessible and appear as local. RPC is an example of remoting. Remoting implies extreme coupling and requires the highest levels of cohesion by definition. But more importantly, remoting also implies a particular composition mechanism imposed by the programming model from which a particular remoted construct originates. To illustrate this point, I'd like to use this quote from John Hughes coming from his seminal paper on functional programming. 

When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the sub-problems and combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together.

Remoting in general, and RPC in particular, exacerbate the lack of appropriate decomposition/recomposition mechanisms (of current programming models) suited for building connected systems. Specifically, remoting technologies have never enforced any particular factoring that would match the characteristics of the network. This is the core of all problems and this is why patterns like the DTO pattern emerged and to a certain extend this is why Resource Representation interchanges could be viewed as a better approach, specially with notions such as "safe" methods.

The reason why a large number of developers can't write connected systems is simply and solely because the factoring implied by traditional programming models and techniques is not suited to "glue [connected] solutions together". As long as the remoting bunch will continue to believe that there must be a technical way to make remoting work (i.e. any call can be worth remoting) we will remain in the deep black hole where we are today. Arbitrary remoting does not work, only a certain type of interactions can flow across the network.

Most recently, the remoting bunch has set its eyes on REST/HTTP. Insidiously, they hi-jacked and disrupted an otherwise outstanding piece of work established on a solid rationale for a complete different purpose, the Web. The Web IS-A giant piece of middleware, not: the Web is an information system that happens to use some middleware components. Roy's REST modeled the Web as an information system and derived REST based on the model of this particular information system. Do all information systems look like the Web? no, does the Web share similarities with other information system types (such as document centric, data centric, or metadata centric information systems), sure. But the remoting bunch does not care about these petty considerations, they salivate at  something they could have only dreamed of, just a few years ago: a gianganticus middleware infrastructurus (world-wide scale) and self-expanding, if you please. It doesn't matter to them that Roy, or Tim for that matter, never thought about the Web that way. They will take no prisoners in their quest to conquer what they consider myopically the wholly grail of middleware.

Incidentally, Roy's REST offers an incredibly innovative "ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together", HATEOS offers composition capabilities unheard of before (ok, there was Apple's hypercards), and again it has to be noted that the programming model and new programming constructs (hypermedia) enable this capability. Remoting alone has nothing to do with that.

That being said, the remoting bunch wants to make people believe that somehow because REST/HTTP is programming language independent there is no underlying programming constructs being remoted and REST/HTTP is not remoting. The remoting bunch has been very quiet on the implementation details of what they would consider "RESTful". When Stefan finally told us how he was implementing RESTful "calls" it became crystal clear. This is what he said:

I force my application semantics to adhere to the common HTTP semantics, which means that for every operation, I have to decide whether it's a derivative of PUT, POST, DELETE, or GET. POST is the one with the least meaning. So in the end, I mind end up with a mixture of mapping, some matching [message passing], some matching [CRUD].

After years of discussions, this is the only thing I could get out of Stefan to explain how exactly a REST implementation looked like. Not a single time in his articles does he talk about how this is implemented. Of course, explaining how a REST implementation looks like (a "minor" detail) would immediately uncover what REST-as-a-middleware infrastructure is about. 

You have to understand that in the (other) REST, programming model constructs (of your choice) are hard-wired on both sides (client and server) to your code "opportunistically". This is not as "transparent" for the developer as previous remoting approaches since you have to go through the "mapping ritual" of remoting calls to HTTP and down to the resources, without forgetting the error codes. The mapping happens as you go (and as you can) based on patterns, tricks and tips exchanged over blogs. The benefit? there is a benefit over traditional remoting technologies like WCF, CORBA, RMI or EJBs: pretty much anyone on the planet can write a "REST" client as long as they can open an HTTP connection, better, it is potentially accessible from anywhere in the world. This is not bad, but it is only a trade-off.

So you probably going to ask me at this point "what is not remoting?". You are not doing remoting when your "glue" supports:

  • Interactions, limited to:
    • events
    • actions (in the state machine sense)
    • queries
  • Loose coupling at several levels
    • communication protocols
    • security
    • business protocol
    • activation
  • Forwards compatible versioning schemes (to be clear when a consumer of version N can still consume a service upgraded to version N+1)
  • Peer-to-peer interactions
  • Asynchronous interactions
  • An assembly mechanism

REST/HTTP is a remoting technology because:

1) it cannot support a versioning scheme satisfactorily since there is nothing to version.

2) offers no loose coupling capabilities. By definition, it is HTTP and its security mechanism, but more importantly REST/HTTP offers no capabilities to achieve business protocol loose coupling.  Activation is somewhat independent of the the approach since it is a service implementation capability, it is however important to include it in this list. REST/HTTP does fare well in this capability because of the architecture of Web Servers.

3) it does not support events and actions, it is limited to a set of predefined actions. REST/HTTP supports queries.

4) it is inherently client/server and synchronous.

5) It does not have an assembly mechanism.

When you look at that list, you realize that we are actually very close to having the capabilities required to build robust connected systems if only we would care to look. Indeed WS-* does not fare too bad, but you also realize how far away REST/HTTP is.

It should now be clear to you that the programming models in use today exhibit a terrible mismatch between the capabilities that are needed to assemble a connected system and their programming constructs, and no "mapping ritual" can bridge that.

So at the end of the day, it should be no surprise that 96% of developers and architects can't build a decent connected system easily. They simply have no chance, no matter how smart they are or how many patterns they use. You simply can't build serendipitously the capabilities on that list, be it on top of RPC, CORBA, J2EE, WCF or REST/HTTP for that matter.

As soon as you understand and agree on what's needed to build connected systems, you must change the programming model, there is simply no other way around. We could spend another 50 years circling as Stu suggested (actually, I have no problem to believe that the remoting bunch could circle for another 50 years and every 5 years or so claim that they were wrong again). On the other hand we could also consider that maybe, just maybe, 40 years is enough. I personally don't have that much time left, at best 20-25 years.

So, I repeat, the corny Synchronous CRUD-oriented Client/Server programming model that has been in use for the last 40 years is going to be marginalized (not disappear). An Asynchronous Inter-Action Oriented Peer-to-Peer programming model is going to be the dominant programming model for building connected systems.

The (other) REST is a fraud and everyone knows it.