The best mobile Ajax application …

is the one that’s never written

Hypertext inventor Ted Nelson talked about “the two Gods of literature”[1],
publisher and reader, and the battle between them in determining what the
reader ultimately consumes.  Traditional Web programming with HTML and
CSS (no script) provides effectively equal power to each God, permitting the
publisher to provide the content together with declarations about how that
content could be presented, but enabling the reader to instruct its
agent to ignore and/or extend those declarations as it sees fit. 
Scripting, on the other hand, puts all the power in the hands of the
publisher, providing the reader two options; either execute it to be able
to consume the content it contains, or don’t and don’t.

The “reader power” afforded by declarative programming is especially important
for mobile use for at least two reasons.  First, it allows the
user agent to repurpose the content so it can be presented to the user in
the context of the particular nuances of the input and output methods of
the device.  Second, it allows the user agent to be shipped
with code which is optimized for the processing of the predefined
markup language, where “optimized” can be along any dimension: speed, size,
battery consumption, etc..

Fortunately, there exists an approach which permits us to have the best of
both worlds.  If we factored out the commonly used script components, and
extended HTML so that those components could be instantiated declaritively,
then we could use declarative programming for these common components but
continue to use script for the less common cases.  As an example, “drag
and drop” is a reasonably common feature implemented by scripts, but could
easily be accomplished via a declarative approach [2].

One downside of this hybrid approach is that standardization of the
extensions - and deployment of software which uses them - can take a very long
time.  However it is not as big a problem as it first seems. 
Somewhat ironically, we can use script to help us incrementally deploy
declarative content, by associating that content with script
which interprets and processes the extension tags when browsers don’t support
them (see [2] again for an example of this).

Some Javascript toolkits already provide for a somewhat similar approach, at
least regarding the binding of HTML extensions to script. 
Dojo includes “Dijits” (Dojo widgets) which permits, for
example, HTML forms to be extended with attributes whose value explicitly
references a Dojo-specific scripted TextBox widget.  Once the Dojo
libraries are linked in, the extended processing occurs.  All Dijits seem
to be missing is to acknowledge the value of standardizing their HTML
extensions.

HTML 5 (ne a bunch of WHAT WG specs) can also be seen in a new light when
considering its role in this proposed approach.  It defines
(amoungst other things) a number of extensions that aim to do in a declarative
manner what is currently done with script.  For example, in-browser form
validation.  The approach outlined here also suggests that there
would be value in developing a script which could process the HTML 5
extensions for HTML 4 browsers.

Note: see also the TAG’s view on declarative vs. imperative, in their Rule of
Least Power finding[3].

 [1] Theodore Nelson.  The Future of Information: Ideas,
Connections and the Gods of Electronic Literature.  ASCII Corp,
1997.  Unpublished.

 [2]
http://www.markbaker.ca/blog/2006/07/21/declarative-drag-and-drop/

 [3]
http://www.w3.org/2001/tag/doc/leastPower.html

See you in Montreal!

One observation; it looks like David’s using the term “versioning” to mean what I call “explicit versioning”, where the consumer of the document needs to know what “version” the document is in order to understand it. I think that’s an important difference between the general versioning problem which can have “no explicit versions” as a solution. I haven’t looked at the latest draft TAG finding to understand that view, but I suspect they use the term similarly to how I use it.

Update; Stefan Tilkov finds that Arjen Poutsma says essentially the same thing.

On the plus side, there’s been some very welcome progress in Web services vendors moving towards the Web. Having Web services stalwarts Chris Ferris and Glen Daniels acknowledge that the use of URIs and HTTP GET was a better way to request data, gave me the warm-and-fuzzies. But they didn’t go beyond that, to consider the value of the mutating-side of the uniform interface. Dave Orchard also reiterated his position that Web services need service-specific writes.

On the down side though, I don’t think much was accomplished at the workshop itself. The point I was trying to make in my presentation, about SOA/WS not separating interface and implementation, must have gone totally over peoples’ heads because nobody commented on it, either to agree or disagree. And the recommendations seemed largely toothless with respect to doing something about this mess within the W3C… though I suppose the WS-Core proposal to consolidate maintenance of the W3C WS-* specs would save some resources.

As always though, it was great to get together with this group of folks; despite our technical disagreements, and the occasional hurt feeling over the past few years, there’s still a lot of mutual respect there. It was also nice to meet some people face-to-face for the first time, such as Pete and Dims.

Speaking of Pete, he also had, IMO, the best line of the workshop. On the topic of description languages, he commented;

Stop trying to stop the world and describe it

Bang on.

Update; I forgot to mention that I met Chuck as well. He has a great workshop-followup post with an example of why GET+URIs are better.

It’s a short presentation because I anticipated (and received!) lots of questions. The objective was to drill down to the primary technical reason why I believe the Web is better; it’s the same reason I’ve been writing about a lot recently.

A position paper for the W3C Workshop on Web of Services for Enterprise Computing, by Mark Baker of Coactus Consulting.

My position

For those that might not be aware of my position regarding Web services, I will state it here for clarity.

I believe that the Web, since its inception, has always been about services, and therefore that “Web services” are redundant. Worse than that though, while the Web’s service model is highly constrained in order to provide important degrees of loose coupling, Web services are effectively unconstrained, and therefore much more tightly coupled. As a result, Web services are unsuitable for use at scale; certainly between enterprises, but even between departments in larger enterprises.

With that in mind …

Problem statement

I begin from the assumption then, that Web services are not part of the solution, and that the Web is. And while I believe that the Web is far more capable as a distributed system than commonly believed, there is also little doubt that it is lacking in some important ways from an enterprise perspective … just not as much as some believe.

I suggest that the problem statement is this;

How can the Web be used to meet the needs of the enterprise?

Part of the Solution

When looking at how to use the Web - how to add new “ilities” (architectural properties) or modify amounts of existing ones - we need an architectural guide to help us understand the tradeoffs being made by either relaxing existing constraints, or adding new ones. I suggest that the REST architectural style is a good starting point, because in addition to being rigorously defined and providing well documented kinds and degrees of properties, it is also the style used to craft the foundational specifications of the Web; HTTP and URIs.

Tradeoffs

I anticipate that most of the improvements that are developed will be REST extensions; solutions which provide additional constraints atop REST, and therefore don’t require disregarding any of REST’s existing constraints. In my experience, this is a desirable situation in general because of the emphasis of REST on providing simplicity, and the role many of its constraints have in providing it. In addition, on the Web, it means that network effects are maximized and centralization dependencies (and other independent evolvability issues) avoided. It’s also often achievable in practice, as long as the problem continues to involve document exchange, in my experience… but not always.

For example, when performance is a make-or-break proposition, and other avenues for improving it have been exhausted, sometimes the stateless constraint will need relaxing. This comes with reasonably large costs - reliability, scalability, and simplicity are reduced for example - but if those costs are fully appreciated and the benefits worth it, then it is the right choice. Because, of course, the solution isn’t REST as a panacea, it’s REST as a starting point, a guide.

The Enterprise Web?

So what features do enterprises need exactly? Some of the common ones mentioned include reliability, security, and transactions. Let’s dig a little deeper into those …

Reliability

Reliability is often mentioned by Web services proponents as a property in which the Web is lacking. But what is meant by “reliability” in that context? Commonly, it’s used to refer to a quality of the messaging infrastructure; that HTTP messages are not, themselves, reliable. That’s true of course, but it’s equally true of any message sent over a network which is not under the control of any single authority, like the Internet; sometimes, messages are lost.

The issue, therefore, is how to build reliable applications atop an unreliable network.

In general, there is little that can be done for a Web services based solution. As arbitrary Web services clients and servers share knowledge of little more than a layer 6 message framing technology and processing model (SOAP), the only option for addressing the problem is at this level, using that knowledge. So we can take actions such as assigning messages unique identifiers in an attempt to detect loss or duplication, but not much else. Solutions at this level tend to do little more than tradeoff latency (i.e. wait time for automated retries) for slightly improved message reception rates. But even then, applications still have to deal with the inevitable case of message loss. Some might even argue that “reliable messaging” is an oxymoron, and that RM solutions are commonly attempts to mask the unmaskable.

Web servers and clients though, share a lot more than just a message framing and processing standard; they share a standardized application interface (HTTP GET, PUT, POST, etc.. as well as associated headers and features), and a naming standard (URIs), both richer (layer 7) artifacts that a generic Web services solution can’t take advantage of. As a result, the options for providing reliability are greater and, in my experience, simpler.

Consider that a reliable HTTP GET message would make little sense, as HTTP GET is defined to be safe; if a GET message is lost then another can be dispatched without fear of the implications of two or more of those messages arriving successfully at their destination. The same also holds for PUT and DELETE messages; though they’re not safe, they are still idempotent. Known safe and/or idempotent operations are a key tool in enabling the reliable coordination of activities between untrusted agents. Most important though, is that there exist known operations, as this makes a priori coordination possible in the first place.

HTTP POST messages, however, due to POST being neither safe nor idempotent, have some of the same reliability characteristics as do Web services. But despite this, the use of POST as an application layer semantic, together with standardized application identifiers, permits innovative solutions such as POE (POST Once Exactly), which uses single-use identifiers to ensure “only once” behaviour.

The “404″ response code is also sometimes mentioned as a reliability problem with HTTP, but it is not at all; quite the opposite, in fact. The 404 response code, once received, reliably tells the client that the publisher of the URI has, either temporarily or permanently, detached the service from that URI. A distributed system without an equivalent of a 404 error is one which cannot support independent evolvability, and therefore is inherrently brittle and unreliable.

Security

Security on the Web today is likely the best example of how the Web itself has been limited by the canonical “Web browsing” application. The security requirements for browsing were primarily to provide privacy, and the simplest solution providing privacy was to use SSL/TLS as a secure transport layer beneath HTTP (aka “HTTPS”).

For the enterprise, and for enterprise-to-enterprise integration in particular, privacy is necessary, but insufficient in the general case as requirements such as non-repudiation, intermediary based routing, and more are added (others can better speak to these requirements than myself). Of course, TLS doesn’t really begin to address these needs, and work is clearly needed.

Luckily, I’m not the first person to point this out. There have been at least two initiatives to add message-level security (MLS) to HTTP; SEA from 1996, HTTPsec from 2005. One might also consider S/MIME and OpenPGP as simple forms of MLS insofar as they’re concerned with privacy and sender authentication.

Interestingly, message-level security is actually more RESTful than transport level security in two respects; that visibility is improved through selective protection of message contents (versus encrypting the whole thing with transport layer security), and that layering and self-descriptiveness (possibly including statelessness) are improved by using application layer authentication instead of (potentially - when it’s used) transport layer authentication.

Transactions

This is obviously an immensely broad topic that we couldn’t begin to cover in a position paper in detail sufficient to actually make a point. Suffice it to say though, that as with reliability, my position is that the space of possible solutions is transformed considerably by the use of a priori known application semantics (and otherwise within the constraints of the REST architectural style), and therefore that solutions will look quite unlike those used for Web services.

Perhaps there will be an opportunity to work through a scenario at the workshop, if there’s enough interest.

Conclusion

The Web offers a more highly constrained, more loosely coupled service model than do “Web services”. While enterprises can often afford the expense of maintaining and evolving tightly coupled systems, inter-enterprise communication and integration is inherrently a much larger scale task and so requires the kind of loose coupling provided by the Web (not to suggest the Web has a monopoly on it, of course). Even within the enterprise though, loose coupling using existing pervasively deployed standards (and supporting tooling, both open source and commercial) could offer considerable benefits and savings. REST should be our guide toward that end.

Schemas, on the other hand, when used in a typical “gatekeeper” style - where the software doesn’t see the document until after it’s passed validation - break encapsulation by enforcing some business rules separately from the software responsible for them. In practice, it’s rarely the case that software doesn’t also have some of these rules, meaning that they’re duplicated, creating a maintainability issue.

Yet another way of looking at the problem is as a communication problem (or lack thereof in this case). In the scenario described in the previous post, the meaning of the document with the field value of “4″ is still unambiguously clear to both sender and recipient, it’s just that the recipient isn’t expecting that specific value, and so it rejects the whole message as a result.

It’s true that there will be cases where unknown values like this need special attention; for example, if the “4″ represented “nuclear core shutdown procedure #4″ and the software only currently knows numbers 1 to 3. But we know how to handle those cases - by defining sensible fallback behaviour as part of our extensibility rules - and schemas play no part in that solution. More often than not, software which can handle the value “3″ can also handle the value “4″ without any trouble; an age of “200″, a quantity of “100000″, the year “8000″, a SKU following a non-traditional grammar, etc…, and the only reason we don’t accomodate those values is because we don’t currently believe them to be reasonable.

But that’s really no way to write long-lived software, is it? To expose - essentially as part of the contract to the outside world - a set of assumptions made at some soon-to-be-long-past point in time? Is this anything less than an announcement to the world of the inability of the developers of this software to adapt? Isn’t it also an implementation detail, further eroding the separation of interface and implementation?

If the message can be understood, then it should be processed.

Today’s sacred cow is document validation, such as is performed by technologies such as DTDs, and more recently XML Schema and RelaxNG.

Surprisingly though, we’re not picking on any one particular validation technology. XML Schema has been getting its fair share of bad press, and rightly so, but for different reasons than we’re going to talk about here. We believe that virtually all forms of validation, as commonly practiced, are harmful; an anathema to use at Web scale. Specifically, our argument is this;

Tests of validity which are a function of time make the independent evolution of software problematic.

Why? Consider the scenario of two parties on the Web which want to exchange a certain kind of document. Party A has an expensive support contract with BigDocCo that ensures that they’re always running the latest-and-greatest document processing software. But party B doesn’t, and so typically lags a few months behind. During one of those lags, a new version of the schema is released which relaxes an earlier stanza in the schema which constrained a certain field to the values “1″, “2″, or “3″; “4″ is now a valid value. So, party A, with its new software, happily fires off a document to B as it often does, but this document includes the value “4″ in that field. What happens? Of course B rejects it; it’s an invalid document, and an alert is raised with the human adminstrator, dramatically increasing the cost of document exchange. All because evolvability wasn’t baked in, because a schema was used in its default mode of operation; to restrict rather than permit.

Just because it only makes sense for a field in a document to contain the values “1″, “2″, or “3″ today, does not necessarily mean “4″, “0″, or “9834″ won’t be valid tomorrow. Similarly, just because a document doesn’t now contain a field named “Blarg”, it doesn’t mean it won’t later. A good rule of thumb in document design is to avoid making assumptions about what won’t be there in the future, and a rule of thumb for software is to defer checking extension fields or values until you can’t any longer.

On the Web, you need to be able to process messages from the future.

P.S. if you’re wondering what time-independent validity looks like, we’ll cover that at a later date (check the tags of this post for a hint).

In your opinion, what is the one thing that most clearly separates REST from SOA?

The answer I gave was… generality.

If you ignore identifiers, hypermedia, and all those other Webby things, and just look at REST and SOA as two architectural styles, the main difference is that REST internalizes the best practice that generalized interfaces are better (in the general case of document oriented distributed systems). That’s really 90% (to pick a large number out of the air) of the difference. If you’ve come from an RPC or OO-RPC background (CORBA, DCE, DCOM, RMI, Web services, etc..), and understand that, then you understand the Web. And if you don’t, you don’t.