Do-Ocracy

Subtitle: Why I'm not personally responsible for the completeness of the web

I recently pointed a group of people to the Web Services Stack Comparison page on the Apache wiki. This is a page that has been edited by a bunch of people from different Web Services projects, but not me personally. Its almost certainly not completely up-to-date - because the projects change rapidly - but its a still a useful resource, and being a wiki has the benefit that people from different projects can update it with their own details. This might be the most accurate available comparison - just because its self-edited.

However, the page has no entry for Apache CXF. I'm certain CXF would look good on this listing - its a nice project.

But the page isn't complete: it also has no entries for Spring Web Services, ZSI, SOAP4R, PHP5, or a host of other Web Services stacks. It doesn't have entries for the WSO2 stacks either: WSF/C, WSF/PHP, WSF/Ruby, etc.

Why am I telling you this? Because someone took offense at my referencing this incomplete page. So guess what? I suggested they or someone from CXF updated it. Yes - its a wiki! That's how they work. If you look at the edit history for this page you will see that people from Apache, Sun, Oracle and elsewhere have all added their own details.

The wiki culture is very similar to the Open Source culture. If you want something done, just do it. Its called a "do-ocracy" - the power is with the people who actually write the code, do the work and make the changes. Its probably the biggest shock to people in traditional hierarchical organizations. Because once you succeed as a developer you get promoted to be an architect. And then you forget how to actually do things.

Unfortunately my suggestion - that the person in question add CXF - fell on deaf ears, so I've sent a note to the CXF mailing list suggesting they add a column - and offering to help.

As a final note, I would like to make it clear that the internet, in conjunction with almost every other form of information, is incomplete. Yep. It isn't finished. It cannot be relied on to let you know every possible piece of information. And while I do my best to keep it up to date, I'm not going to accept responsibility for the whole web!

Fremantle Saga continues to run

Those of you who read my blog regularly will remember my "Fremantle Trust Saga". For years I have been getting wrongly addressed e-mail because the Fremantle Trust (a care provider based in the UK) cannot do something as simple as get their OWN email addresses correct.

Last October I blogged about it and it got picked up by the press. I was immediately contacted by the Fremantle Trust who promised to sort it out. I rejoiced in the fact that I would stop receiving personal details of residents, employees and other confidential information I didn't want.

At the time I was warned: "Beware. They're still incompetent."

Those words have turned out to be prophetic. This month (which is only half over), I have received 21 emails aimed for the Fremantle Trust. Its actually going up. And some of them are "new offenders" - in other words new people who have just started sending email wrongly. So you can't even blame the email client's auto-complete for this.

Here are some of the subject I've recently received:

• FARLEY HOUSE, LUTON, PLANNING
• Swag [actually about getting rid of past resident's property I believe]
• GP Permission to crush tablets
• Benchmarking of Finance Services
• Team Meeting Notes
• Sharnbrook Next of Kin

In the past I have contacted the Chief Executive of Fremantle, as well as various local authorities, managers and so forth. It seems amazing that 4 months after they said they would sort this out, the level of email has actually increased.

WSO2 Registry 1.0 ships

Today we shipped the first release of the WSO2 Registry. You can read the release note here on the registry-dev list where we openly develop it. Those of you who read my blog will have read about this already.

The WSO2 Registry is interesting for two simple reasons, which happen to be related.

1) Its a completely REST-based design, building on the Atom and AtomPub protocols. Everything you store in the Registry is a resource. You can link to these by their URLs - either generically or to a specific versions. There are three simple interfaces to the Registry:

• the Web UI - which is designed so that even my mother should be able to use it (no offense Momma);
  
• the Java API, which is dead simple and clean, and
  
• the AtomPub protocol API, which allows any client, including command line tools like wget and curl to access and update resources.

It's also fully versioned and secure.

2) The Registry has been designed around humans. This is what we call "The Social Enterprise", but has also been known as Enterprise 2.0. The idea is that an SOA registry is the bridge between all the different people (and systems) involved in Enterprise SOA. Some examples include:

• Business users adding hierarchy to the Registry to map out the business domains: e.g. /finance/operations/
• Developers, using the ability to add comments to any resource, describing what WSDL2Java binding options worked for them, or
  
• Explaining what they would like improved in the next version of this service, and
  
• Rating the service, and
• Tagging it with useful tags
  
• The service provider subscribing to the comments on this service using a simple Atom feed
• Service users subscribing to the service and being notified when new versions are published
• Allowing the ESB to use a specific version of the WSDL until the latest version has the right metadata to say its production ready.
  

All these simple things are made possible by thinking about the human aspects of SOA. SOA is as much about trust as about distributed computing - if I don't trust you to provide a good service, it doesn't matter whether its REST or SOAP - I'm not going near it.

I firmly believe that the REST design of this helped unify the goals of making this Registry work technically. The REST approach is proven to work technically - every SOA client can grab a schema or WSDL from an HTTP URL (which can't be said of UDDI - except that UDDI 3.0 also finally exposes resources as HTTP URLs). But even more importantly, the close integration between the Atom design and the Web UI meant that this is not only a simple product to use, but you can do useful things you just can't without the REST nature - such as subscribing using Atom, sending permanent URLs to other users, managing dependencies between resources as URL dependencies.

Take a look, join the discussion and comment, rate and tag us :)

JackBe is now paying us for "WSO2 Mashups"

If you type "Mashup Server" into Google, WSO2 gets the top two entries. I guess that is why JackBe are still buying an advert with the title "Wso2 Mashups". I blogged a while back about this, and I guess I assumed it was a mistake, but now I'm beginning to think it must be on purpose.This is a screen capture from today. I do have to admit its kind of cool that "WSO2 Mashups" is now a generic term: I'm really glad JackBe are implementing the WSO2 kind and not any other inferior mashups.

Now the funniest part of this? Guess where I screen-captured that from? Yep, the WSO2 Oxygen Tank. So not only are they giving us free advertizing, but they are actually paying us for it! Yep, JackBe are (via Google) giving us money to put the words WSO2 Mashups on our own site. You gotta love it.