logo
Duncan Cragg on Declarative Architectures
About All Things...
...taking programming beyond:
Threads, Message Queues, Client-Server, CORBA, Web Services, SOAs, Agents, Synchronous Architectures, Imperative Programming - and even Applications, Desktops and Documents
Duncan Cragg...
...works for ThoughtWorks UK; originally from April 2002 to July 2007 and now recently re-joined. Previously worked as a Web Architect for the Financial Times.
...went to both UCL and Imperial College of the University of London (in the Eighties); specialising in Logic during his MSc.
...wonders when his LinkedIn Account will be useful
...has a phone-cam, and used it on himself once, just before his weekly shave:
Photo of Duncan Cragg
...can be contacted by and followed on Twitter.
Posts tagged 'architecture' Atom Feed for Posts tagged 'architecture'
 
 
CoAP and a Web of Things watching Things
May 19, 2014 21:21

With the expansion of the Internet of Things (IoT), and the diversity of products and technologies, the one thing that everyone agrees on is that it's time to start agreeing: the Internet of Things needs standards. Many agree that it needs open standards, like those that underpin the Web.

Obviously, a Web of Things is going to be quite different from the Web of Documents and Applications: it'll be much more fine-grained and much more "buzzy", with many sensors and actuators working together with many hubs and services. It's more likely to be at home with the next generation of the Internet Protocol: IPv6.

To meet the fine-grained and buzzy nature of the IoT, the Constrained Application Protocol, or CoAP, was created. CoAP is an open Internet standard for the Web of Things. It's based on the Web's core pipe: HTTP, but has many differences to allow it to be used by very resource-constrained devices and local radio networks.

CoAP can be used in many different ways, but there's a danger that a lack of clarity in exactly how it's used means it doesn't achieve its full potential to link up the world's embedded devices.

This article proposes a simple and clear way that CoAP could be used to build a uniform, global, decentralised Web of interacting and discoverable Things.

This article first appeared on the ThoughtWorks Insights pages.   ...

 
The Object Network Approach to Augmented Reality and the Internet of Things
March 1, 2014 11:24

After filling up that other blog recently with 61 pages of content, one page a day, I was challenged by my ThoughtWorks colleague, Andy McWilliams, to help him get in more easily to my explanations of the Object Network applied to Augmented Reality and the Internet of Things, especially around how my approach differs and is better than other approaches.   ...

 
Building The Object Network
January 27, 2014 11:36

I've started another blog called Building The Object Network, about how I'm experimenting with Augmented Reality for the Internet of Things using the Object Network approach.

So far I've been blogging every day.

Do subscribe!   ...

 
Cyrus in 2013
January 16, 2013 17:09

Well that worked out pretty well: I have a 3D environment on Android programmed in a simple but powerful declarative language which I've called "Cyrus".

Cyrus basically uses JSON all the way through: from user interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and commas. It looks very nice to me.   ...

 
The Basics | The Object Network
January 20, 2012 18:07
Updated: January 23, 2012 19:45

Right, let's get started with some basic conventions in the Object Network!

This part in the Object Network series will cover URLs, HTTP headers and some common JSON patterns.

Updated 23/1/12: I changed the URLs in the example to have one of each type.   ...

 
Why we should link up our Web APIs | The Object Network
January 19, 2012 20:58
Updated: January 22, 2012 16:05

OK, I'm trying to take a Big Idea and make it as Simple As Possible to grasp.

If we link our JSON data together and use the same formats, then our mobile, browser and server apps can become much simpler - through clean, stable, common, shared, re-used code - and much more powerful - through clean, stable, common, shared, linked, cached data.

This is the second part in the Object Network series, which will guide you away from building isolated Web APIs to engaging in a linked-up data landscape.   ...

 
Introduction | The Object Network
November 29, 2011 23:11
Updated: January 22, 2012 16:03

It's interesting to compare the current growth of Web APIs with the early growth of the Web itself. To save you jumping those links: the Web dramatically beats the APIs.

I believe that the most likely cause of such relatively slow growth (in what should be a booming ecosystem) is that each API forms a closed silo and cannot benefit from any network effects. Every API is different and there are no links between them. There usually aren't any links within a silo. You can't even use a given API without first consulting the documentation.

The Object Network is designed to fix this, with linked-up JSON in common formats. This will allow easier mashing, sharing and cacheing of data and allow client code to be shared and reused.   ...

 
OTS: The Benefits of both Native and Web Mobile
May 10, 2011 11:11

The Web, in its purest form - declarative HTML and CSS documents, XML feeds - is mashable, linkable, sharable. It's easy to create documents that slot into the global Web and can be accessed on any device; accessed by just a simple link. Servers can easily scale through statelessness and cacheing.

Native Mobile Apps are fast and slick. They are intimate with the dynamic, interactive, tactile mobile user interface, intimate with the capabilities of the device and intimate with the domain of mobile: photos, locations, contacts, messages.

OTS is a simple, clean, powerful approach to delivering Mobile functionality and content that is designed to realise these benefits of both Native Apps and the Web.   ...

 
Mature REST In Six Lines!
May 6, 2011 11:11

Like Subbu, I also have been sitting on a blog post about the Richardson Maturity Model. I have different reasons for feeling uncomfortable with this Model, however.

The following came out of a discussion on an internal list at ThoughtWorks, where a number of people were talking about how they aspired to reach the "Holy Grail" of REST Level 3, and still thought they were basically "doing REST" by addressing most of the uniform interface.

But, as indeed pointed out in that article, REST is only at Level 3.

However, fortunately, you can jump right to Level 3 without much effort.   ...

 
Minted Media Types are Usually Less RESTful Than JSON
May 5, 2011 12:16

This post is a response to a question that came up on an internal ThoughtWorks list. The question was, in summary: "Is using JSON more RESTful than minting our own Media Types as required, given that using raw JSON means reading inside the content in order to know what type is being transferred?"

TL;DR: Yes, use a common Media Type and "switch" on the internal data type; create a new Media Type only when something generic and broad and new and useful settles out.

Seems controversial to you? Read on...   ...

 
Deriving FOREST
November 25, 2009 21:29

Say we want to integrate multiple applications which handle order processing. OK, that's got to be one of the dullest starts to a blog post. Never mind, bear with me...

So, we have applications on separate servers for handling and driving data such as orders, product descriptions and catalogues, stock lists, price lists, tracking, packing notes and delivery notes, invoices, payments, etc.

We may choose an SOA approach, of course. But let's say our sponsors have heard of this cheaper alternative: REST! Which to them means 'using Web technology to save money'.

Now .. suppose we push the time slider right back to before Mark Baker and the SOA -vs- REST Wars - or the 'SOAP -vs- REST Wars' as people naively called it. To when REST was simply (!) a description of the Web's architectural style...

What if we revisit the applicability of the Web, and its abstraction into REST, to the architecture of machine-to-machine distributed systems - to something like our order processing integration?

I think we'd quickly arrive at something that looks more like FOREST than, say, AtomPub...   ...

 
FOREST: a GET-only REST Integration Pattern
October 9, 2009 17:14
Updated: October 11, 2009 11:46

Since the day in 2006 that our dialogue took place with an imaginary eBay Architect, he has been promoted to imaginary Enterprise Architect in an investment bank! Convinced by the merits of REST, he took his enthusiasm for it into his new job and embarked on architecting a trading system using REST or ROA as an alternative to SOA.

Now, he hit upon a snag: he had a REST "bank server" generating bids on an instrument and POSTing them into that instrument's REST "market server". But then he had two copies of his bid! One held by the bank server on one URI, and the other in a "bid collection" held by the market server's instrument - on another URI.

He asked himself: "Which URI is the real one? Which host 'owns' the bid? Is the market's copy just a cache? If so, why does it have a new URI? Why doesn't the market host know the URI of the bank's original bid? Why can't servers become clients and just GET the data that their own data depends upon?" The server seemed to be dominating the conversation, not letting its 'client' server have a say in things.

Our worried Enterprise Architect noticed that such Service-Orientation permeated REST practice: there were "REST APIs" to Web sites, or "Web services" with a small 's'. Even AtomPub had a "service document"! Some patterns, like AtomPub, offered just simple read/write data services through the full HTTP method set. Some simply used such a read/write interface as a wrapper around more complex service functions.

He wondered: "Where's the Web in REST integration? The Web works great without PUT and DELETE: isn't using GET on its own RESTful enough?"

So, remembering something I said about "Symmetric REST", he contacted me again...   ...

 
Web Objects Ask, They Never Tell | The REST Dialogues
August 13, 2009 11:43

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP.

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 9: Web Objects Ask, They Never Tell   ...

 
WS-Are-You-Sure | The REST Dialogues
July 16, 2009 16:16

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP.

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 8: WS-Are-You-Sure (Security, Reliable Messaging and Transactions)   ...

 
Mobile Widgets aren't the Mobile Web
February 11, 2009 16:20

Mobile Monday London met last night to discuss the Mobile Web and Widgets. It was an engaging and thought-provoking evening.

Your intrepid reporter was there and, in spite of the crashing of his sad, clunky old Windows Mobile Xperia X1, losing all his notes, he brings you this hot report from right out of his memory (somewhat steamed up by subsequent socialising, but reclarified by Google).

After that, I give an explanation of why I believe that Widgets are not the solution to what Mobile 2.0 needs...   ...

 
The Mobile 2.0 Killer App is the App Killer
December 19, 2008 17:05

Mobiles are unique - if you want to miss out on the opportunity they represent, you could choose to see them as just slow computers with tiny interfaces and dodgy Internet connections. Then try to squeeze in your traditional applications; try squeezing the office desktop metaphor with its sedentary documents into a device the size of a mouse!

Alternatively, see them as the most personal, social and dynamic of devices that are becoming connected to the Internet. Now a multi-billion-scale global opportunity opens up to you. That's customers and dollars! In trying to grasp this, some are calling it 'Mobile 2.0', by analogy with its sibling, Web 2.0.

In that light, the Killer App for Mobile 2.0 is the sharer, masher and updater of People, Things, Times and Places... The key to getting Mobile 2.0 right is for it to merge seamlessly into our lives. That means the handling of dynamic and shared data becomes the top priority, even above the handling of applications.

This article describes a Mobile 2.0 platform that makes people and their stuff first class - not applications.   ...

 
Business Conversations | The REST Dialogues
December 11, 2008 11:45

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP.

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 7: Business Conversations   ...

 
The Universe Web
July 18, 2008 19:49

Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.

I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.

Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.

Here's how I would architect the Universe Web...   ...

 
Content-Types and URIs | The REST Dialogues
February 16, 2008 23:44

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 6: Content-Types and URIs   ...

 
Google Micro Conference
October 5, 2007 11:22

Last night's Google London Open Source Jam (also here) was on the subject of the 'Web' (didn't they invent that? Oh no, that was Microsoft).

This event has been getting better and better each time I've attended. There were some very interesting lightning talks held together with a tight structure and plenty of chance to chat, drink cold Leffe and eat cold pizza. And nick [transatlantic translation: 'steal'] the Green & Black's chocolate.

An ideal Micro Conference...   ...

 
How Ruby can enable the Web 2.0 Platform
June 26, 2007 15:17

Web 2.0's definition includes seeing the Web as an application platform. Which means it is in competition with Java and .Net, and with SOA, for both local and widely distributed applications.

If the Web is going to be a platform, the skills you need to learn to program it are the core Web 2.0 technologies such as Ajax, JSON, Atom, Microformats and OpenID.

And Ruby. This language, that's capturing the hearts of many Web 2.0 programmers, is ideal for easing the transition from the Java and .Net platforms to the Web platform, as I will show.

Even if you're part of a big company that is generally immune to the latest trends, the marriage of Ruby and the Web-as-platform may be something to prepare for. It could even displace your SOA agenda...   ...

 
The Distributed Observer Pattern | The REST Dialogues
June 20, 2007 22:42

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 5: The Distributed Observer Pattern   ...

 
Inter-Enterprise REST Integration | The REST Dialogues
April 8, 2007 13:38

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 4: Inter-Enterprise REST Integration   ...

 
Lighter-than Wins in 2007
January 18, 2007 11:12

What do all the MAJOR Web 2.0 technologies of 2007 have in common?

Let me list them first:

    M.icroformats (including tags)
    A.jax (including Comet)
    J.SON (plus YAML)
    O.penID (plus SXIP, LID, Yadis)
    R.EST (including Atom, APP)

What these technologies have in common is that they're all lighter than their competitors:

Microformats

Lighter than the Semantic Web

Ajax

Lighter than Fat Client (!)

JSON

Lighter than XML

OpenID

Lighter than SAML/Liberty Alliance

REST

Lighter than SOA

  ...

 
Business Functions | The REST Dialogues
January 10, 2007 14:21

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 3: Business Functions   ...

 
eBay's Working Architecture
December 14, 2006 14:15

There were two things I knew about eBay's Architecture - that they use J2EE and that they seem to like SOA. Both are approaches I give, ahem, special mention to on all my pages at the bottom of the left-hand column.

So it was with some apprehension that I opened up this (PDF) slide pack from Dan Pritchett and Randy Shoup of eBay, presented at SD Forum 2006 recently. I was expecting my prejudices around the issues and techniques of scaling web sites to be challenged, at least.   ...

 
Setting Data | The REST Dialogues
November 15, 2006 23:37

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for one of the many function calls that they make available via SOAP (GetSearchResults).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 2: Setting Data   ...

 
Getting Data | The REST Dialogues
November 14, 2006 00:05

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for one of the many function calls that they make available via SOAP (GetSearchResults).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 1: Getting Data   ...

 
The Right Way to do Ajax is Declaratively
July 13, 2006 14:33

Don't write your interactive Web application in custom Javascript! The Web's Declarative nature needn't be broken just because you want two-way dynamic data instead of one-way documents on your site.

Instead, write Declaratively to generic Javascripts, plugins and browser features such as Hijax, hInclude, XForms, SVG, XBL, etc.   ...

 
The 2006 'What Now How' Awards for REST Protocols
June 15, 2006 00:30

It gives me great pleasure to announce the 2006 'What Now How' Awards for REST Protocols (or 'APIs') in the Read/Write Category.

All this year's awardees share the distinction of being truly worthy of the 'REST' label; these Read/Write Protocols are acknowledged here for their uncompromising adherence to the simple principles of the World Wide Web.   ...

 
STREST (Service-Trampled REST) Will Break Web 2.0
May 25, 2006 19:05

The vast majority of supposedly 'REST' Web APIs are simply abusing HTTP to carry function calls. I call these APIs 'Service-Trampled REST', or STREST.

STREST APIs come with specific costs which could stifle the two-way data Web (Web2.0) if allowed to propagate unchecked. Although 'mashability' is a supposed benefit of the current proliferation of APIs, true interoperability and scalability can only be guaranteed by true REST interaction.

This is not an academic, purist or aesthetic stance, but one based on practical consequences, as I will explain.   ...

 
Excuse me - did you say 'Web' Services?
May 17, 2006 00:27

Distributing an application over a network isn't just a case of splitting it down a natural line and putting a network in-between. What works in-process simply doesn't work so well across the wire.

And just calling such an Internet version of application and process interfaces 'Web' Services doesn't mean it has anything at all to do with the Web, or that it in any way shares the Web's scalability, flexibility and robustness.

Indeed, I claim that you cannot distribute without also 'inverting'; you have to face what I call the 'Imperative-to-Declarative Inversion', if you really want a successful, scalable, distributed application.

Declarative Architectures such as REST (i.e. the Web, and now 'Web 2.0') dominate the broader Internet.   ...

 
The "Imperative to Declarative Inversion": Open Data is OK!
May 11, 2006 21:36

There is something about the Internet that nurtures open data, and something about computers that nurtures closed. It is often necessary, but often painful, to make the jump from local, closed data to global, open data.   ...

 
Welcome to 'What Not How'
March 22, 2006 17:00

Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.

I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.

Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.

I believe that saying What, not How, will become the dominant paradigm in programming.   ...

 
 
Recent Posts
EUP, IoT, AR and Minecraft | NetMash | Object Network
CoAP and a Web of Things watching Things
The Object Network Approach to Augmented Reality and the Internet of Things
Building The Object Network
Cyrus in 2013
Empowering the World | NetMash
Fun and Virtual Worlds | NetMash
The Basics | The Object Network
Why we should link up our Web APIs | The Object Network
Introduction | The Object Network
OTS: The Benefits of both Native and Web Mobile
Mature REST In Six Lines!
Minted Media Types are Usually Less RESTful Than JSON
FOREST News
JSON-Mash
Tags