Web 2.0 + SOA = Web Services

It is easy to be caught up in the hype and the latest terms, certainly, when your cabbie ask you about Web2.0 you know that marketing engine has been working in overdrive. Well that is actually, what happened to me today.

Whilst catching a cab today, my friendly cabbie asked me what I did, I replied with the standard line 'I work with computers' , Before I knew it he was telling about his son the wiz and asked me about Web2.0 and how I thought I would change the 'net'.

Therefore, this posting is for you George...

Web2.0, SOA, Web Services are all so interconnected I cannot do the subject justice by covering just one area. The whole push behind web2.0 is to allow people to work to collaborate and discovery new synergies. Web2.0 are software applications which are more like work environments that are inclusive and aims to bring the best out of your colleagues. As to what functionality these include, this is only limited by our own creative thoughts but these application will seek to leverage collective wisdom of people who where normally separated by distances, time zones and social economic barriers.

Social Bookmarking at del.icio.us is a great example of web2.0, its value and utility increases as more people participate; clearly, wiki is another great example that follows this rule.

However, here is the interesting thing the 'Technologies' behind the above two example are not new the same applies to many things we associate with Web2.0. I can a few voices off in the distance they are saying "What about AJAX"? Yes, the term is new, yet the enabling technology XMLHttpRequest has been around since 1999 if I recall correctly.

Yes, standards have been refined and new tools have made it easier to implement functionality, but as for enabling technology, most of it has been around for at least five years. Therefore, it would be fair to say that Web2.0 is the application of web/internet technologies in new and creative ways. This in itself speak mountain for the human creative spirit, I like to think of it as Web1.0 is characterized by humans duplicating what they had in the physical world online and Web2.0 is characterized by human discovering new way of doing things without the shackles of physical work practices, traditions and limitations.

So what does this all have to do with SOA (Service Orientated Architecture)? Well like Web2.0, SOA is about doing things differently, without the restrains of old world thinking and old world habits. Now there are some, which believe that this new world thinking is a fad and the cite pass things such as Modular Programming of the 70's, Event-Oriented Deign of the 80's and Component Approaches of the 90's. For anyone who has lived each of the above they would not say it is fad rather evolution.

Clearly, I was not coding in 70, but I have maintained allot of code from that, era and anyone can see that Modular Programming has influenced the single responsibility concept that all us OO Architects bang on about today. The same applies to the Event-Orientated approach that was so hot in the 80's, which has greatly influenced messaging today. The same applies for Components in 90's which today is still realized in many of our current designs. All of these approaches have stood upon the shoulders of their parents and the same applies to SOA.

OK we know that SOA is way of design a style if you will and we know where is has come from, it heritage but what is it?

From my perspective as an Architect, Service Orientated Architecture is way of putting together a system or application that uses existing systems/services and newly built components systems/services in such a manner that quickly, and cost effectively meets an organisations objectives whilst cutting across ownership boundaries.

Let us get practical; in this example, the brief is to deliver an email and SMS marketing application. After studying and decomposing the requirements, we can draw some big boxes on a white board. The first box is something to send and receive emails and another box to do the same for SMS's, another to compose the messages and one to maintain a list of folks who would get marketing message then on top of all that we need another box to report outcomes from these activities.

Reality check... if the above was the requirements we could probably find a few services that provided it all today and we just hook-up to their API to move data back and forth and write some report stuff.

However, let us for this example assume such a service does not exist and will not likely to exist in the future.

In the old days, we would have just built a 'sendmail' server and hooked up the serial post of the same server to a mobile phone to drive the SMS stuff. (Clearly not thinking about scalability issues here) Then we would have written heap and heaps of code and then probably a GUI and an import and export function so we could move data to and from the customer database.

Being that this is the enlighten age we would use a third party SMS provider or if one did not exist we would seek out a partner to own and operate a SMS service after we built it. Being the enlighten age we will build the SMS box/gateway in a fashion that was independent of the rest of the application, so it could be used by other application and other parties in the future.

In doing this, we would be concerned about coupling at the service level as well as the implementation level, we would ensure that way of communicating with this SMS box/gateway and getting to do stuff like sending SMS's and dump back replies where clearly define and that the inter-workings where clearly abstracted away.

Our objective here is to build a standalone SMS gateway that is capable of evolving to become the best SMS gateway around (will it be evolved is another matter which is commercial in nature).

We follow the same approach for our boxes, firstly looking for existing services, which are built to standards and using these if possible, then we consider building it with others and lastly build it in house (Clearly using another order if your core business was the provision of services).

In the ideal world, there would be services out there on the net that one could 'discover' and integrate together.

The above is the SOA style or way of building an application in addition to my perspective and there are generally accepted principal of SOA and reference implementations I strong recommend that every architect study and implement on their own.

The design principals are nothing new and you are probably using day to day as an architect, they are:

Abstraction

Autonomy

Compos-ability

Coupling

Discoverability

Encapsulation

Optimization

Reuse

Service/Interface Contracts

The only one in the above list I probably need to elaborate on is Discoverability, and certainly, this is an advance design feature. It should be noted that within the standards from OASIS, which I have strongly suggest, that everyone read, discoverability is necessary feature. In the commercial setting, unless you are building for a commercial provider it will probably not make the final cut on the specifications.

Discoverability is similar to reflection, it allows for the finding and querying of a service to get it measurements so to say. In a SOA sense where one is, building web services there is a couple discovery protocols you need to understand, being, UDDI and WS-Discovery. They both are different in that UDDI is more like a phone book (directory or service broker) and WS-Discovery is multicast 'who is out there' type protocol.

Also not to confuse but there is one more protocol to get you head around and that is WSDL, which is really simple it is basic a XML format that describes the web service , stuff like end points on the Net, address and ports and list of available command and any special data types.

You may have noticed the introduction of the term of web services in the last few paragraphs, well our SOA approach has lead us to build these boxes, which are, known as web services. Therefore, we can say that one of the artefacts of SOA is web services.

Within this realm or at this level also is a set of standards and specifics that can be used to find our out way out of the dark. These are from W3C and are again easy to get your head around, these standards position web services as client/server that exchanges XML messages that follow SOAP. There are alternative ways of doing this, but this is probably the simplest way, and there are plenty or reference implementations.

Therefore, as we can see web2.0 or peoples' creativity is driving the demand for new applications and the new way of building them is SOA when combined results in web services, that simple.