Internet Alchemy

Since there’s a rather nice discussion going on around my weekend post on RMR and MVC I thought I’d dig out the description of MVC from the Gang of Four book to remind us all what we’re actually talking about. Often people forget that the GOF book didn’t include MVC as a design pattern but as a usage scenario that they decomposed into constituent patterns, most notably Observer, Strategy and Composite.

Here’s the relevant section from the book:

The Model/View/Controller (MVC) triad of classes [first described by Krasner and Pope in 1988] is used to build user interfaces in Smalltalk-80. Looking at the design patterns inside MVC should help you see what we mean by the term “pattern.” MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse.

MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model’s data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.

[...reference to diagram elided...]

Taken at face value, this example reflects a design that decouples views from models. But the design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer design pattern.

Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing
nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the CompositeView class, a subclass of View. CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views.

Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. This more general design is described by the Composite design pattern. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g., Button) and other classes define composite objects (CompositeView) that assemble the primitives into more complex objects.

MVC also lets you change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.

A view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller. It’s even possible to change a view’s controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn’t accept input simply by giving it a controller that ignores input events.

The View-Controller relationship is an example of the Strategy design pattern. A Strategy is an object that represents an algorithm. It’s useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate.

MVC uses other design patterns, such as Factory Method to specify the default controller class for a view and Decorator to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns.

From this text the two key benefits of MVC are that it allows you to:

• “attach multiple views to a model to provide different presentations” (view/model decoupling)
• “change the way a view responds to user input without changing its visual presentation” (view/controller decoupling)

Unexpectedly (for me, anyway) it says nothing about decoupling models and controllers. Anyway, my observation is that if you need the above flexibility then MVC is your best bet. However, if you don’t need those particular decouplings then you are adopting needless complexity and you’ll be paying for it in the long run.

Last year I wrote a short post titled MVC Obscures the Mechanics of the Web that drew together some other peoples writings on why MVC is poorly matched to the web. I didn’t give an alternative though, apart from indirectly in the comments. Now Paul James has written a succinct description of that alternative and christened it RMR – Resource Method Representation.

In RMR (which is simply REST as seen on the Web) the user interacts with resources using representations via restricted set of methods. As Paul explains, typically this is implemented as a set of classes representing the resources, a set of Response classes and some kind of routing to tie it all together. This is how frameworks like Tonic (written by Paul) and Konstrukt work. It’s also how my RDF framework Paget works, although that is very immature at the moment and doesn’t cover responses very well.

Here’s to banishing MVC from the web

Alan Dean is on a roll with a bunch of interesting REST posts:

• When Basket Checkout isn’t RESTful
• What a RESTful Basket Checkout might look like
• On RESTful Basket State

Since Danny is in an airplane going to Banff, I thought I’d have a go!

Is there a key message you focus on as the key take away for your talks on REST?

Engineer for serendipity.

Roy Fielding on rest-discuss

Something that hadn’t occurred to me, but in retrospect seems obvious now:

It’s interesting to note here the connection between REST and functional programming and the meaning of the word ‘function’. For most developers a function is a sequence of statements that do some ‘work.’ But for the few developers using a functional programming language a function is a well defined relationship between an input and output state. RESTful systems manifest the latter, ‘functional’ meaning of the word ‘function’. You might describe such a system as ‘B:HTTP(A)’ where a given HTTP request acts as a function and is applied to system state A. The application of this function in turn generates a new system state, B. In the end, as Duncan points out, many of benefits that RESTful systems have over SOAP are analagous to the advantages that functional languages have over procedural languages.

This is from a blog called discipline and punish which I’ve not come across before. Lots of interesting stuff there on OpenID, and a rant on syntax obsession that fits well with a current Talisian discussion.

If you haven’t seen Pete Lacey’s socratic dialogue on the evolution of SOAP then please go and read it straight away. An excerpt to whet your whistle:

Dev: Okay, where’s the spec on this?

SG: Oh, there is no spec. This is just what Microsoft seems to be doing. Looked like a good idea, so now all the cool kids are doing it. However, there is this new thing. I think you’re gonna like it. It’s called the Web Services Interoperability Group, or the WS-I. What they’re doing is trying to remove a lot of the ambiguity in the SOAP and WSDL specs. I know how you like specs.

Dev: So, in other words, the specs were so bad you need a standards body to standardize the standards. Lord. Well, will this solve my interoperability problems?

SG: Oh, yeah. So long as you use a WS-I compliant SOAP stack, avoid using 8/10ths of XML Schema, don’t use any unusual data types, and don’t count on working with WebSphere and Apache Axis.

There must be something in the air because Duncan Cragg has also written some fun and informative articles in the same style for a new series called the REST dialogues: Getting Data and Setting Data. If you want to get a better view of what it means to be resource-oriented then this series looks to be the business.

Sometime you need to make extreme statements to make a subtle point clearer:

It doesn’t matter how easy it is in [awesome VisualStudio/RubyOnRails/Python/IntellijIDEA]. It has to be easy in COBOL.

Robert Sayre on the permathread that is REST vs WS-*

This piece from Dare Obasanjo hot on the heels of the UDDI public registry closure adds weight to my suspicion that SOAP is finally being sidelined into a niche activity.

When I worked on the XML team, I used to interact regularly with the Indigo folks. At the time, I got the impression that they had two clear goals (i) build the world’s best Web services framework built on SOAP & WS-* and (ii) unify the diverse distributed computing offerings produced by Microsoft. As I spent time on my new job I realized that the first goal of Indigo folks didn’t jibe with the reality of how we built services. Despite how much various evangelists and marketing folks have tried to make it seem otherwise, SOAP based Web services aren’t the only Web service on the planet. Technically they aren’t even the most popular. If anything the most popular Web services is RSS which for all intents and purposes is a RESTful Web service. Today, across our division we have services that talk SOAP, RSS, JSON, XML-RPC and even WebDAV. The probability of all of these services being replaced by SOAP-based services is 0.

Mark Nottingham characterises the old REST vs SOAP debate in a different way. Now it’s SOAP vs. HTTP:

you can get any of the listed architectural styles [SOA, RPC, REST] with both SOAP and HTTP.

…[useful table - go see it!]…

When doing so, notice that REST is native in HTTP, and SOAP is native for SOA. Intuitively, I’d rather use HTTP if my chosen architectural style were REST, especially considering how widely deployed and provably interoperable it is. I can choose any number of off-the-shelf, commercial or Open Source intermediaries, caches and libraries to take advantage of REST in HTTP, but the same is not true of REST in SOAP.

My takeaway is: use HTTP if you’re doing REST (document based), use SOAP if you want SOA (message based).