Category: Collective Web

Architectural Principles of the World Wide Web is a W3C Working Draft published yesterday. I recommend everyone to read the draft. It is a good (technical) introduction to a restful approach to the web architecture. It is striking that the document does not mention SOAP/WSDL/UDDI at all. That’s because it doesn’t talk about web services, some may say. Well, Web Services Architecture Requirements, a W3C Working Draft 19 August 2002, doesn’t mention SOAP neither …

Yesterday, Phil Windley picked up on my comments on his paper in his comments on XML Schemas vs. DTDs and Other Issues.

I wrote: “DTDs? No, use XML Schemas, I’d say. and Phil replies:
I think using XML Schema instead of DTDs is probably the right choice. I’ll update the paper. In particular the XML Schema language gives you the power of a context free grammar (rather than a context free grammar) with little increase in complexity. They also probably have a brighter future. The main point is, however: document what you create and keep it up to date.

Nice. Good points too. I actually like(d) DTDs, but hey I also liked WordPerfect 4.1 and my old 286-machine once. Clearly, it is time to say goodbye to DTD and embrace XML Schema, if not for else just for the fact that we only then can truly say we “speak” XML all the way.

I had also written: WSIL? Hmmm. Maybe, but we (government) need to engage in UDDI too. On this, Phil writes:
I think UDDI is premature except inside the orgranization, so I stick by my recommendation to use WSIL. WSIL can be easily integrated with UDDI later when (if?) it takes off.

I (still) have to check up on WSIL. I am no particular UDDI-fan at all, and my point was more that we (government) must keep an eye to this, so we don’t get left behind anything important.

Lastly, on my raising issue with explaining all of this in more “layman’s” terms, Phil says “Boy, isn’t that the truth!” and speculates in revising his paper once more. Well, please keep the current version available, because … cool urls don’t change 😉 But don’t let that hold you back from writing more.

I hope to sometime soon be able to provide some English translations of the writings we’re doing in my office. We’ll be launching an international forum on e-gov architecture soon. Stay tuned.

Roger L. Costello presents a very sane approach to migrating to web services. In short: REST 1 = SOAP 0.

How far along is the industry in achieving the Web services vision?, he asks, and replies:

* The Web services vision is a mirage at the present. If you jump on it today you will loose.
* The only thing that’s real today is XML. Use it.

Here are his recommendations:

* Focus today on creating standardized XML vocabularies, and learning to exchange XML over the Web.
* Don’t get enticed by dynamic discovery, dynamic connectivity. That’s for tomorrow (2-5 years).Tomorrow will take care of itself.
* Don’t use SOAP, WSDL, and UDDI. I believe that they will be replaced with superior technologies in short order.
* Stand up Web services using standardized XML vocabularies. Be satisfied that you have migrated your company applications from HTML (or some proprietary format) to XML. That’s a big and important step.
* Describe your Web services textually using HTML (see an example of this here). HTML is “good enough” for today.
* Search for Web services using standard search engines – Google, Yahoo, etc. They are “good enough” for today.
* Design XML vocabularies today with your favorite schema language – XML Schemas, DTDs, or RELAX – but be prepared to rip them out within a year or two. RDF and DAML promise to give you the ability to produce vocabularies with much more semantic richness, to enable dynamic understanding.
* Evolve your companies applications to Web services. Don’t take the big bang, revolutionary approach.

I haven’t had the luxury of a vacation, but took some time off blogging. Partly because I (like Alan) have moved home, and been without net access from home, and partly because I’ve had to concentrate on drafting a policy document about our national IT architecture. I hope I can soon invite reveal what we’re up to, but my boss would kill me if I did so now and here …

Anyway (yeah, right), I’m still concerned about the standardisation processes around web services in general and SOAP in particular (though I realise WSDL and UDDI are equally important).

The most interesting document on this I’ve read for a long while (and I’ve been reading a lot) is Phil Windley’s Enabling Web Services. I must follow up more in details, because there are lots of good points, but also a few places where I disagree: DTDs? No, use XML Schemas, I’d say. WSIL? Hmmm. Maybe, but we (government) need to engage in UDDI too.

In policy-making terms, however, Phil and other RESTians have a particular and peculiar problem: How do you explain what it’s all about in political, non-technical words? I’m a techie, and I hardly understand it. My collegues (and bosses) are political scientists or whatever, and simply don’t get it at all.

What are the core issues? Open standards? Loosely coupled systems? …?

A bit related, but from another area: DestiCorp ‘s White Papers, especially their Dancing with Your Customer: The Next Copernican Revolution and also Why Web Services and Grid Computing will Turn the Travel Industry on Its Head – and Why that’s a Good Thing!.

For a good while now, I have been following the debates and developments around web services and the technological and architectonal standards around “web services”, and generally been struggling to understand what it has been all about, and to find out how we from an eGov position should look at things.

The Interoperability Frameworks from UK, Australia and NZ are onto something here:

Clearly defined policies and specifications for interoperability and information management are also key to staying connected to the outside world and aligned to the global information revolution. The e-Government Interoperability Framework (e-GIF) provides these. It is a fundamental Framework Policy for the e-Government strategy.
UK e-Government Interoperability Framework Version 4

e-GIF contains “the high level policy statements, management, implementation and compliance regimes” as well as “the technical policies and table of specifications, and a glossary and abbreviations list” for “the areas of interconnectivity, data integration, content management and information access via multiple channels”. In one word, this all comes down to XML, we are told.

Over a rather short time, the UK e-GIF has evolved through four versions. For the first three versions, it all looked like the project was to “XMLify” government. In April 2002, we saw e-GIF4, in which another (or, the real?) bomb is dropped:

Future WEB based service delivery is to be based on SOAP, UDDI and WSDL.

SOCITM’s comments on this point are worth quoting:

“These standards represent a step-change in introducing interoperability across Government. Before a mandate is introduced, guidance and toolkits must be made available to enable local strategies to be built and appraised.
While XML and SOAP are now the de facto standard, UDDI and WSDL are still emerging. Consequently a mandate should not be applied until these standards are established and mainstream.”

Indeed, I must agree with these comments. The UK e-GIF is an example of SOAP purism, if we follow eclectic’s definitions:

• REST Purist — Web services should be implemented using REST principles, according to the letter of the HTTP specifications. No other way is acceptable
• REST Realist — SOAP adds too much overhead, I prefer plain XML over HTTP, but aren’t too worried if I breach the specs occasionally. I need this to work now, but don’t see a need for more tools.
• SOAP Realist — I’m only really interested in the HTTP binding. SOAP makes my life easier because I can hide all the protocol ugliness behind the toolset. SOAP works for me, why shouldn’t I use it?
• SOAP Purist — SOAP is the only way to implement Web Services. The HTTP binding isn’t worth arguing about, as we’re going to bind to all kinds of other protocols as well. We need to to move on and deal with issues like orchestration, etc, etc.

In other words, if you thought the “battle” was between J2EE vs .NET, you thought wrong. The real battle is between purists and realists of both “sides”, SOAP vs REST.

And the REST is …

As Roy Fielding, the coiner of REST, put it:

REST is an architecture that separates server implementation from the client’s perception of resources, scales well with large numbers of clients, enables transfer of data in streams of unlimited size and type, supports intermediaries (proxies and gateways) as data transformation and caching components, and concentrates the application state within the user agent components.

Hmmm. So, what does that actually mean? According to the Rest FAQ, it means:

REST stands for REpresentational State Transfer. It is an attempt to describe the undocumented architectural design principles behind the Web.

Tricky definition, huh? Theory is practice, or, practice is theory. Or? RestArchitecturalStyle:

In a nutshell, REST defines identifiable resources, and methods for accessing and manipulating the state of those resources. As implemented on the World Wide Web, URIs identify the resources, and HTTP is the protocol by which resources are accessed. REST argues that HTTP itself — its minimal method set and semantics, and the ability to extend this method set as required — is sufficiently general to model any application domain; i.e., traditional OOP modeling of application objects with type-specific interfaces is unnecessary and replaced by modeling things as hierarchical families of abstract resources with a common interface and semantics defined by HTTP itself.

So, what is not REST? According to the RESTwiki contributors, the most important contrast with the REST architectural model is the Remote Procedure Call (or RPC) model, which “attempts” to take the local programming model of a function call and make it work across the network. SOAP is an example of the RPC model, of course. RESTwiki concludes:

The success of REST and the “failure” […] of previous attempts at RPC architectures such as DCOM, CORBA and RMI suggests that REST has superior characteristics of scalability and mass adoption, largely because of the low coordination costs.

State of Utah CIO, Philip Windley, takes a RESTian stance when he proposes the 12 principles for enabling web services. I can subscribe to almost all the principles, and I will try and use them in the Danish and the European e-GIFs.

Then Sam Ruby comes along and suggest that it is really not REST vs SOAP, it is REST + SOAP! Now I’m officially confused.

People like Tim O’Reilly and Jon Udell are “internet trend-makers” just as much as Microsoft and IBM are. In his weblog on June 18 2002, Tim O’Reilly writes that their vision of web services is that they create a loosely coupled architecture in which people could build new functionality out of small, independent tools. O’Reilly looks back at the (short) history of web services, and writes about the early days (two years ago): “But I was disappointed to see that web services seemed to go off into an enterprise black hole (what Clay Shirky calls EDI++), rather than becoming the freewheeling next generation internet programming and power user environment that Jon and I had imagined.”

O’Reilly argues that web services should be seen as disruptive innovations: “Innovation will come from APIs that support “unintended consequences”. As Bill Joy likes to say, ‘All the smart people don’t work for us.’ Giving developers a playground extends your development staff, bringing in new ideas and features at the same time as it builds your brand and image. ”

From Tim O’Reilly on the Amazon Web Services API

Loosely coupled architecture allowing for disruptive innovations. What a great concept!

Just as Cluetrain Manifesto co-authour David Weinberger’s concept of the web being small pieces loosely joined is a great concept, mainly because he brings in the human perspective on the web: “the Web is binding not just pages but us human beings in new ways. We are the true “small pieces” of the Web, and we are loosely joining ourselves in ways that we’re still inventing.”

Googling around, I found LooselyCoupled.com, “the entry-point to a family of websites providing comment, news and resources on the use of loosely coupled web services to automate online business services,” which is definately a site to watch.

Like many others, I have been playing with the new Amazon api (the latter link is BTW also demonstration of the Google api).

Agile as I am (or like to think I am … :-), I’ve also put together another example of small pieces loosely joined: My
favorite blogs monitor is a (RESTful) web service, where I grab my blo.gs XML/RSS-feed and runs it through an XNL-parser for presentation. The blo-gs feed itself is using weblogs.com‘s feeds, which consists of lists with sites pinging weblogs.com. Hence I have a dynamic blogroll, since the most recently updated of my favorite blogs comes up on top of the list. Since it runs live queries it is a bit slow at the moment (I think others than me use blo.gs! (what a fantastic domain name, BTW).

Phillip Windley, the CIO of the State of Utah, has An Open Offer to Utah State IT Employees. He writes:

“I believe that the 900 or so IT employees of the State of Utah would benefit from speaking and listening to each other more. I think we need groups of specialists inside various departments to communicate with others in their specialty and without. Consequently, I’d like to see more people writing blogs and communicating their ideas through an open forum like the one blogs engender. To that end, I’m willing to pay the licensing fee to Userland for the first 100 employees who start a blog.”

I love this 🙂
So did Dave Winer, who commented: Bravo! I actually think Dave would have endorsed the initiative almost just as much had it not been his own product being offered.

So, it is about government officials creating blogs, that is, what I call GovBlogs, as a way to get them to communicate more. This makes perfect sense to me, but I am not sure it does make sense to everyone else, especially more senior officials and old-fashioned red tape lovers, of which there are plenty in all governments I have ever encountered.

GovBlogs will eventually change government communications, just as “ordinary” (all) blogs has started to change (communications in) society at large. In fact, it is not “just” communications that changes, hence the brackets. Learning, knowledge, practices, everything changes …

My strategy has hitherto been to combine blogging initatives with other initiatives, such as holding a workshop about communities of practice.

I wonder if Windley’s idea would work in Denmark? I am not sure how many IT employees we have in the state, but I guess it’s about the same as in Utah. Sadly, I don’t have the funds to cough up with fees for 100 Radio licences, but I will hereby offer all Danish state employees a free, hosted blog. No strings attached. Just email me and ask nicely.

You gotta love’em: MovableType has done it again (been innovative): TrackBack.

Open Source Intelligence, what a wonderful concept. Check out Openflows: People are intelligent, machines are tools. Openflows is a cluster of initiatives to develop, provide and use tools to bring together the work and ideas of people who want to collaborate. Openflows fosters networks — people who share interests, needs, or goals — that engage in the process of Open Source Intelligence.