About All Things... |
Declarative,
Mobile 2.0,
REST,
Cloud,
Web 2.0,
Ajax,
Publish / Subscribe,
Event-Driven Architectures,
JSON,
Atom,
Microformats,
Linked Data,
P2P,
Identity,
Copyright,
Multimedia,
Cyberspace.
|
...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:
|
...can be contacted by
and followed on Twitter.
|
|
|
|
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.
...
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.
...
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!
...
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.
...
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.
...
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.
...
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.
...
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.
...
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.
...
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...
...
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...
...
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...
...
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
...
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)
...
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...
...
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.
...
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
...
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...
...
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
...
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...
...
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...
...
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
...
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
...
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 |
...
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
...
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.
...
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
...
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
...
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.
...
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.
...
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.
...
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.
...
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.
...
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.
...
|
|
|
|