Author: administrator

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.