Web 2.0 Definition? What is the Web 2.0?

I have been writing a lot lately for an upcoming book on the topic of Web 2.0 with James Governor and Dion Hinchliffe for O'Reilly. During the process, we have done an amazing amount of research in an effort to quantify some of the patterns surrounding the concept. The work was actually quite intense and started with examining a single table put forth by Tim O'Reilly. The table illustrated examples of what was web 1.0 vs. web 2.0. Many people have struggled to define and understand "Web 2.0" At this point, defining it probably won't happen due to the fact that there are so many differences in what people think it is, however, anyone can mine it for knowledge. I personally don't see this as a problem since there seems to be a lot of consensus surrounding what is and is not web 2.0. While definition has possibly slipped away, the ability to share the collective knowledge on the subject has not. The knowledge of web 2.0 can be caught and expressed in architectural patterns and models. This blog post is a teaser of the upcoming book on that exact subject.

So what are "Patterns"? A pattern is a repeatable solution to a frequently occurring problem. The value of patterns is that it captures the solution knowledge independent of the implementation which then allows the pattern to be re-applied to other instances of problems in different contexts. An example of a pattern is to note the collaborative tagging (A.K.A. "Folksonomy") and commenting patterns on Flickr, then realize that the same mechanism can be used for video, audio, scientific research, news articles etc. Entrepreneurs in general should be very interested in this book. New start up ideas will be plenty abound.

We started with this diagram:



From each of these examples, patterns were distilled from the instance. The methodology left us with a huge collection of patterns that are documented and can be used to compare the old way to the new way. From these patterns, we were able to create a model based on further abstracting the main concepts required to fulfill the patterns. The model itself is abstract but from the model we were able to create a reference architecture for developers and architects. The idea is that the reference architecture is abstract of all technologies, implementation detail yet presents a great technology component view that can be used to help guide architects and developers as they build their applications.




The value of this methodology is that anyone can take the reference architecture and build their own specialized architecture from it. The model is simple and reflects abstract concepts that are present in most of the patterns. So what does the model look like and what is different? The model is shown below:



The model is definitely different than the old internet in a number of ways. In order to reflect the capabilities necessary to fulfill the patterns mined form Tim's examples, developers need to extend the basic client server model. Instead of a simple "server", the Services Tier of the model reflect the core tenets of Service Oriented Architecture, itself a a core pattern of Web 2.0. SOA is a pattern that can be used to match needs and capabilities under disparate domains of ownership. In this context, SOA is independent of any specific implementation or technology family such as web services and aligned with the abstract definition in the OASIS Reference Model for SOA. SOA allows "capabilities" to be offered for consumption to potential consumers on a common fabric. The common fabric is defined in terms of "Reachability and Connectivity", often implemented by using common standards and protocols. The concept of web 2.0 as an open platform relies on these open standards and technologies to function. Work such as the Service Component Architecture will rely on this type of infrastructure to exist in order to work.

The services tier offering these services is necessary to fulfill many patterns. To deliver a Rich User Experience (RUE), the capabilities must be leveraged to add more depth to interactions between users. To enable people to build mashups or offer Software as a Service (SaaS), the services tier must beliver the capabilities whilst abstracting the client from how the capabilities are being fulfilled.

The the middle tier of Capabilities and Reachability, we have seen huge changes since the first iteration of the internet. The development of Web Services standards and new data serialization forms such as XML to supplement the simplistic HTTP and HTML model form the first internet are necessary to fulfill the promise of the first iteration of the web. Guys like Bob Sutor, David Orchard, Marc Goodner and Eric Newcomer have all been working on these new standards and protocols for a long time. Why? They are absolutely necessary for Web 2.0. The Web must be open and mashable (new word??) to enable the patterns.

Additional patterns beyond simple "Request-Response" are necessary to fulfill core patterns like the "Synchronized Web". This latter pattern being used a lot for online gaming, collaborative applications and other synchronous architectures of participation. We have seen the rise of AJAX as an asynchronous model and various other mutations to make the patterns reality. Models for interaction include Probe and Match, Request-Response, Subscribe-Push, Synchronized, Asynchronous and more.

On the top side of the model, the old notion of "client" has been widened to become a "Client Applications/Runtimes". The purpose of this is to perform client duties and prepare the ultimate user to connect to the web. We noted that there is a new entity above the client. This entity is the User. The user is now a core part of the model for the internet and vice verse. Users are involved is so many patterns it would be difficult to ever devise an inclusive list. The Collaborative Tagging pattern ("Folksonomy), Collaboration-Participation Pattern, Rich User Experience Pattern, Semantic Web Patterns, Synchronized Web Patterns, Declarative Living and many others all include the notion of the user. Note that 'users' are not limited merely to humans but may include applications or other agents.

Some more about the model? This model can be used as a pattern between any two entities on the web. It is not about simply making one model for a platform of all interconnected devices. The model can be used in Peer to Peer patterns (one peer has a capability that gets consumed by another peer using protocols like BitTorrent via services for the ultimate benefit of a human actor) or other patterns like the Web Services * architecture, reflected in a great book by Chris Kurt.

Note that we do not consider the model to be the one single model that forever defines Web 2.0. It is simply "a" model which people can use, even if they disagree with it. If you disagree, you still have a model to use as a point of reference to describe your disagreements.

The reference architecture was presented during a recent session at Web 2.0 in San Francisco but I am not going to repost it here just yet. It will be the subject of another entry. In true Web 2.0 style, the book will have a sister website that allows anyone to collaborate and contribute to the set of patterns. This will be announced when the book is published.

The list of patterns identified to date is as follows:

Adaptive Software (software that gets better the more it gets used)
Asynchronous Particle Exchange
Collaboration Participation
Collaborative Tagging
Declarative Living
Mashup
Persistent Rights Management
Rich User Experience
Semantic Web
SOA
Software as a Service
Synchronized Web
Tag Gardening
...

Expect this list to grow as the work continues and others start contributing patterns. Note that Rich Internet Applications (RIA's) use a combination of patterns (RUE, Mashup, etc). Patterns themselves may be combined and used together.

Ahh - back to work..TGIF!!!

David Linthicum gets SOA - a good read.

I have just read an article by David Linthicum on SOA Reference Models and Reference Architectures. David has explained how the two relate to each other very well and I consider it a good read. There are a couple of points he makes that I am also wanting to expand upon.

In David's blog post, he writes:

"Again, abstraction, one is an instance(s) of the other, if I understand this correctly."

This infers that the SOA Reference Architecture work at OASIS is an instance of the SOA Reference Model. While close, this is not quite accurate. The OASIS Reference Model for SOA is in fact abstract. By definition, an abstract entity cannot have instances, the same definition shared by UML 2.0 and programming languages like Java. The relationship is best described as the Reference Architecture "is based" upon the Reference Model. The OASIS SOA RM TC always knew that there would be multiple SOA works (architectures) based on the Reference Model. Such is the purpose of a model, to allow various architectures to be based upon it which maintaining a common language and understanding of the core concepts, axioms and relationships.

David also writes:

"I urge you to download and read this 31-page document to get some additional details. Also, get involved, if you like. I always love the comeback from standards bodies that deal with criticism and debate around the concepts they put forward: "If you don't like it, join us and change it." Can't argue with that."

and

"You have to give them an A for effort, but you can see where the debates are going to pop up. It's really a matter of understanding, a marketing issue really. I understand different levels of architectural abstractions, but what is really needed is a reference framework or model, and a set of steps to figure out how to build something that's proper for your problem domain."

David correctly notes the true purposes of a reference model here. Even if you disagree with it, it is a point of reference a person can use to explain their variances in definition. For example, if someone claimed that SOA was not what the reference model stated, they have a point of reference for their definition. As such, there will likely never be newer editions of the RM work unless some great inconsistencies are uncovered during he RA works going on in various bodies, companies and vendors.

FWIW - I give David an "A" for his continued clarification of SOA. I'm adding him to my blogroll.