The Promise And The Potential Of WSO2

(I write this piece with a bit of trepidation as I don't know how it will be taken, but I mean it with the very best of intentions and wishes for my ex-colleagues.)

Looking over the list of my FaceBook friends, I am struck by how many of those I connected with during my brief assignment with WSO2 (Aug-Dec 2011) have moved on to pursue graduate programs of study at US universities. Just like Macquarie Bank in Australia was once called "The Millionaire Factory" for making so many employees rich through bonuses, this little company is rapidly becoming an Intellectuals' Factory. If they succeed in staying in business over the next decade, they will have seeded some very powerful and influential links in academia and the higher levels of the technology world.

Which brings me to my main point - does WSO2 have what it takes to survive the next decade? I believe they do, and not just survive but also move up to the next higher level. But to do that requires a kind of thinking I have not seen from the company's leadership so far.

For at least the last five years, I have been searching for a "next-generation SOA company". I thought I had found it with WSO2, but was quickly disappointed when I realised that this was a company with traditional SOA thinking and only a next-generation business model (free software and paid-for support). That's not quite what I was looking for, and to me, it explains why WSO2 hasn't yet hit the big time in spite of a decent product suite and some very smart, sincere and hard-working people. They're just not revolutionary enough for the market to take notice.

OK, so what do I have in mind?

The view of SOA as being ultimately about SOAP-based Web Services in its implementation (OK, and some REST as well) is so last-decade. That view of SOA, I am convinced, is actually toxic to organisations. The impacts of that kind of SOA to agility and cost are entirely negative. (I have numbers to prove it but I could be sued by more than one ex-employer for breach of confidentiality, so you'll just have to take my word for it.)

If you sell traditional SOA with a different business model, you're not even half revolutionary. You're an interesting sideshow to the main game, and when the traditional SOA model gets discredited, as it largely has already, you get washed away in a way the IBMs and Oracles don't because of their size. (Which is a pity because I simply hate the IBMs and Oracles for what they have done to the industry - milked customers while providing them no benefit.)

My view of SOA is simple - it's "dependency-oriented thinking", and it applies to every layer of the organisation - Business, Applications, Information and Technology. Unfortunately, every SOA guru, after paying ritual obeisance to the notion that "SOA is not technology", proceeds to insult our collective intelligence by discussing Web Services technology (or lately, REST). It seems we just need to look away for a second after someone says SOA is not technology, and we find they're talking technology when we next look!

Similarly, I have a very jaundiced view of the term "SOA governance" as it is popularly applied. I suspect most SOA experts wouldn't be able to define the term in a readily comprehensible manner if they were tied to a chair and threatened with a copy of Lotus Notes. I also suspect most of them use the term "governance" for effect when all they mean is plain old "management".

My definitions of governance versus management are also simple - "doing the right thing" versus "doing things right" - in other words, the "what" versus the "how".

And so, "SOA Governance" is nothing but the process of determining the right dependencies that ought to exist at all layers (Business, Applications, Information and Technology) and identifying the dependencies that do exist. "SOA Management" is about using these as a starting point and eliminating the dependencies that should not exist, formalising the ones that should exist into contracts, and ensuring that fresh dependencies do not creep in. That's all there is to SOA governance and practice, but the benefits are significant and will not escape attention.

I talk about all this at some length in my InfoQ interview. [Update 29/11/2012: I've now also written a white paper on it, which interested folk can download from box.com.]

There is so much potential for a truly SOA-enlightened consultant to enter a client organisation and point out all the areas of tight coupling that are driving up their costs and risks and driving down their agility. Heck, if all that the consultant did was concentrate on tight coupling at the data layer, so much wasted potential could be unleashed. That's the power of SOA in the right hands.

What I want to see in a next-generation SOA company is an organisation that is not fixated on technology but on education and consultancy, because it's SOA thinking that is so badly in need of a reboot. WSO2 is full of smart people, but they're focused on the wrong thing. It's not technology they need to be tinkering with. They need to apply their screwdrivers to the minds of IT and business folk at all levels. They need to hire fewer nerds and more business-savvy consultant types trained to think about dependencies. People with backgrounds in risk management, project management and contract law are especially good at thinking about every kind of dependency or "fine print" that could trip up an undertaking, and these are the kinds of people needed for SOA consultancy.

Admittedly, that's a bit hard to do when you do technology too well. Perhaps WSO2 ought to start by setting up a consultancy arm (which isn't focused on selling their own technology support services), getting that division to drive SOA thinking from the business layer down, and then watching it outgrow its older sibling as customers start to see its dramatic impact.

Can they rise to the challenge?

Building RESTful applications using the WSO2 platform

Someone taking a casual look at the WSO2 middleware platform might be forgiven for thinking this is exclusively about SOAP and WS-*. But there is in fact strong support for building RESTful applications with this platform using the JAX-RS framework library, and Prabath Siriwardena (one of WSO2's experts on Identity Management) has blogged about the recommended component architecture to achieve this. There is also a WSO2 workshop on this topic conducted by Asanka Abeysinghe, who has many years of experience on the customer side of the fence and understands both the vendor (technology) and customer perspectives. This workshop is on Dec 8th and should be worth attending for people living close to Palo Alto.

An interesting sidelight: In Practical SOA for the Solution Architect, I re-introduce the practitioner to SOA principles by talking about three core technology components - the Service Container, the Broker and the Process Coordinator. According to this view of SOA, a service can be exposed through any of these components and a service consumer will be none the wiser as to the nature of its implementation. In other words, the Practical SOA approach does not make any prescriptions about which component should be the consumer-facing one. All of them are equally valid candidates, and the only criterion for choosing one over the other is the nature of the service enablement mechanism (bespoke, brokered or orchestrated).

In Prabath's architecture diagram below, the reader will notice that runtime clients must all consume services through the ESB (the Broker), even though these services are hosted on the App Server (the Service Container). Why can't services be exposed directly from the App Server where they are hosted?

Prabath explains that using a Broker (ESB) instance as the front-end for services is recommended practice because the ESB can provide security features like authentication and authorisation, as well as throttling capabilities to guard against Denial of Service (DoS) attacks.

So in the real world, we may often need to front-end Service Containers and Process Coordinators with an instance of the Broker that is dedicated to providing these security and traffic shaping features. This could (and should!) be a different instance of the Broker from those used to mediate access to backend systems. Such an architecture will work well because ESBs are better deployed in a federated topology than in a centralised hub-and-spokes fashion. [The unnatural hub-and-spokes topology for ESB deployment, which the high cost of most commercial ESBs forces on customer organisations, then results in a performance bottleneck and a single point of failure. Fortunately, the more favourable economics of WSO2's Commercial Open Source model makes it feasible for customer organisations to implement a more flexible federated architecture for the ESB.]

PaaS by Lineage

If you've ever wondered about what "Platform as a Service" (PaaS) really means, then you may find this analysis of mine useful.

The traditional NIST model of Cloud Computing shows three layers from a consumer's perspective:

Infrastructure as a Service refers to (shared and scalable) infrastructural capabilities such as compute power, storage and networking, as provided by a cloud vendor. The attributes "shared" (or "multi-tenanted") and "scalable" (or "elastic") distinguish cloud solutions from "terrestrial" alternatives. Amazon's EC2 (Elastic Compute Cloud) and S3 (Simple Storage Service) are examples of IaaS.

Software as a Service refers to applications that you don't have to install on your own computers but can consume through your browser. For an individual, Gmail is the best example of SaaS, while companies can relate to SalesForce.com.

But PaaS has always been a bit of a mystery. What is a "platform", exactly? This is a rather nebulous (pardon the cloudy adjective) area between IaaS and SaaS, and appears to be defined by what the other two are not. The market segment is also still in flux and yet to mature, and there are many players here, each staking out a piece of turf and attempting to define the segment to its own advantage.

I have a high-level, vendor-neutral view of this. [Disclosure: I'm currently working for one of the PaaS vendors, WSO2.]

My preferred categorisation of the PaaS landscape is by lineage. In other words, where did the various PaaS offerings evolve from? I think this is a useful way to look at PaaS because it indicates the traditional strengths of a vendor and therefore where their PaaS offering is likely to be stronger than its competitors. Potential consumers who are looking for a particular emphasis in their PaaS solution will know which vendors are likely to meet their requirements better.

In short, I think PaaS offerings have evolved from one of three directions.

IaaS vendors like VMWare (with their vCloud IaaS) have added DevOps capability to their traditional strength and are targeting organisations that want to develop and run generic applications on the cloud. Their version of PaaS is CloudFoundry.

SaaS vendors like SalesForce.com have made their application more generic and supportive of customisation. Organisations that want to build employee-oriented applications can do so through configuration rather than coding. Their version of PaaS, which is more oriented towards a vertical segment (employee-oriented applications), is called Force.com.

A third direction from which PaaS has evolved is from traditional "terrestrial" middleware (also known as Integration or SOA products). WSO2, which has a full stack of SOA middleware products collectively referred to as Carbon, has added cloud-native features (multi-tenancy, elasticity, etc.) to its suite of products to turn them into yet another version of horizontal PaaS called Stratos. Their DevOps tools have also been upgraded to be able to deploy applications to the cloud just like they do to terrestrial servers.

The diagram below that loosely follows the NIST layering, illustrates my analysis. There may be more versions of PaaS depending on where a vendor has traditionally been based, and I will update this model as more such examples appear.

Glamorous Tech and Workhorse Tech

IT people are biased towards the new, the cool and the "sexy". Perhaps Node.js and Cloud Computing fall into this category. Glamorous technology is very attractive, because it promises to be "the next big thing", but it's usually not usable today. Like Benjamin Franklin's proverbial new-born baby, it's full of potential, but does nothing for us in the here and now.

Contrast this with "workhorse technology", which is mature and relatively boring, and used to build working real-world systems that make or save money today. Not many people get excited about workhorse technology, but the majority of them work with it anyway, because it pays the bills.

I want to talk about one particular category of workhorse technology that I'm discovering can be quite glamorous as well. I have gradually become more familiar with this over the last few months of working with WSO2, writing the "Practical SOA for the Solution Architect" white paper, conducting a webinar and then hitting the road to conduct workshops in three Australian cities. I've realised that the combination of a lightweight SOA methodology in combination with a lightweight SOA product suite can be a very effective workhorse technology that is usable today and saves real dollars. In addition, it's actually pretty cool because of how quickly and easily it can help practitioners integrate diverse and distributed systems into an end-to-end business solution.

In a nutshell, in the white paper, webinar and workshops, I evangelise the message that SOA is not an esoteric and complex black art but simple commonsense that can be readily applied. I talk about the technology layer of SOA, of course, but also cover the equally important data layer that is often neglected and that contributes to the "tight coupling" that plagues so many solution designs and prevents them from realising the benefits of SOA. I talk about three core technology components to use (the Service Container, the Broker and the Process Coordinator) and when to use them, the inefficiencies that result from using the wrong tool for the job, and the dangers of treating the Broker as a singleton, centralised component and deploying it in a hub-and-spokes architecture rather than a federated one. I also cover four simple Data layer principles (make implicit dependencies explicit, remove unnecessary dependencies, loosely couple internal domain data with externally-visible message data, and settle on an intermediate granularity for domain data model(s) rather than a single overarching Canonical Data Model for the entire enterprise).

To drive home these concepts, we work through the real-world example of a well-known banking process, i.e., opening an account. Using the lightweight Practical SOA methodology, participants are encouraged to try their hand at producing an outline solution design to a described requirement in about 15 minutes, using a few standard Lego-style components from the SOA technology layer. Then we demonstrate how that solution design can actually be implemented, substituting each of the conceptual Lego blocks with an actual platform product that hosts the corresponding logic, and get the entire system to work.

Here's a view of the conceptual building blocks that form the outline solution design, once the lightweight SOA methodology is applied to the business problem:

In the next step, the conceptual components are replaced by actual WSO2 SOA products that perform each of those functions, and the physical version of the above diagram looks like this:

The Customer Master Database, the Mainframe and the Card System are all mock objects. A Data Services Server exposes the Customer Master as a set of CRUD services. A Broker (ESB) component exposes the mainframe as a set of Account services, and a second Broker exposes the Card System as a set of Card Services. Since the mainframe can usually only be accessed over IBM MQ in real-life, we simulate that through a JMS connection over ActiveMQ. A Process Coordinator (Business Process Server) coordinates all these services into a BPEL process that performs the account opening business function.

It was gratifying to see that participants at all the workshops we conducted were visibly impressed by this demonstration. In the space of 45 minutes, we had moved from a problem, through a conceptual solution design, to a working implementation. And since we had their active participation through the design exercise, they had an emotional investment in the solution and were able to appreciate it all the more. [To be fair, the demo was developed earlier over 6 person-days of effort, and in the workshop, we stepped quickly through the development by copying code that was written earlier.]

Traditional SOA vendors and the big-name analysts have done the industry a disservice by complicating SOA and scaring off practitioners. In our workshops, we've shown that SOA is just commonsense and relies on just a few simple principles that practitioners can readily apply. Once they know the right tools to use in the solution, it's a simple matter to gather those required components and hook them together to create the end-to-end solution.

This is obviously workhorse technology, because it's mature enough to solve bread-and-butter business problems today. But the lightweight methodology and product suite also make it glamorous.

I hope this attracts more practitioners towards the practice of lightweight SOA and the use of simple and cost-effective products like the WSO2 product suite.

Enterprise Shared Services and the Cloud

I've worked in the area of Enterprise Shared Services (or Enterprise Utilities) for many years, so when InfoQ approached me asking if I would be interested in writing an article on cloud computing, this was one of the angles I thought of. Of course, I'm also working with WSO2 at present, and WSO2 has a distinct type of PaaS (Platform as a Service) offering called Stratos. PaaS usually either evolves up from IaaS (Infrastructure as a Service) with the addition of support for DevOps (the development-operations continuum) or evolves down from SaaS (Software as a Service) with the addition of customisation support for the software application. Stratos is unique because it has evolved "sideways" from enterprise middleware with the addition of cloud-native features. The 12 SOA products of WSO2 are all available as cloud-native middleware on the Stratos PaaS.

In any case, since InfoQ wanted vendor-neutral content, I couldn't write about Stratos (which I will write about in some context because I find it fascinating). So I fell back to my old favourite - Enterprise Shared Services.

The long and short of it is that when we factor in Enterprise Shared Services, the old monikers of SaaS and PaaS are no longer enough. We have to deal with "vertical" and "horizontal" variants of these, and the distinction is important because in an organisational context, they have unique characteristics around how they are requisitioned, evaluated for feasibility, funded and charged back.

I'll let you read about it here.

A Good Primer on NoSQL

NoSQL databases are all the rage, but the array of choices before us is bewildering. I must confess I'm still confused about the features and differences between BigTable, GAE DataStore, GemFire, SimpleDB, SQLFire, CouchDB, MongoDB, RavenDB, Redis, Cassandra, Riak, HBase, Neo4j and so many other names that I have only recently begun to hear about. I'm sure many others would be in the same situation.

I was therefore happy to see that my colleague at WSO2, Dr Srinath Perera, has analysed the NoSQL landscape in depth, zeroed in on the characteristics of NoSQL databases that are relevant, and summarised this for our common understanding in an InfoQ article that provides a simple overview of the choices that designers and developers have today, choices that go beyond the traditional relational databases that we're familiar with.

I've often wondered about why NoSQL should be so popular in the first place. Srinath explains:

A few years ago, most systems were small and relational databases could handle [their requirements] without any trouble. Therefore, the storage choices for architects and programmers were simple. However, the size and scale of these systems have grown significantly over the last few years. High tech companies like Amazon and Google faced the challenge of scale before others. They soon observed that relational databases could not scale to handle those use cases.

In other words, this demanding new requirements wave has probably not hit most of us yet, but with the jump in the number of connected devices (smartphones, tablets and the coming "Internet of Things"), applications dealing with huge volumes of data are probably not going to be as rare as in the past. And when we say "huge", we're not even talking Gigabytes anymore. It's Terabytes and larger. As we learnt from Godzilla, size does matter. And drastic situations call for drastic measures, hence the NoSQL revolution.

Srinath refers to Eric Brewer's CAP theorem, which states that a distributed system can only have two of the three properties - Consistency, Availability, and Partition Tolerance. The NoSQL databases aim to break through the limitations imposed on traditional relational databases by loosening the fundamental principles on which these have been based, dropping one or more constraints as appropriate, to obtain a desired behaviour.

Depending on the constraints dropped, the resulting solution falls into one of several new categories:

• Local memory
• Distributed cache
• Column Family Storage
• Document storage
• Name-value pairs
• Graph DB
• Service Registry
• Tuple Space

...in addition to the traditional filesystems, relational databases and message queues that are familiar to IT practitioners today.

Perhaps the most important contribution of Srinath's article is his distilling of the four primary characteristics that are important from a usage point of view - data structure, the level of scalability required, the nature of data retrieval and the level of consistency required. He then puts these characteristics together in various combinations to show which of the above-listed categories of data store would be the most appropriate solution to use.

He's certainly succeeded in demystifying NoSQL for me, although I suspect I'll need to go back and read the article a few times till I've fully internalised the concepts in it. This is an overview article that I'd recommend to anyone trying to make sense of NoSQL and wanting to decide on the appropriate product category that would be right for their needs.

I can see the demand for a follow-up article from Srinath drilling down into each of these data storage categories and providing recommendations about actual products (e.g., Cassandra, Redis, CouchDB, etc.) While the sands shift more rapidly in the product space, it's also a more practically urgent decision for a developer or architect to make. So while such an article might need to be updated quite frequently, the advice in it would be more practical than this one, which provides the necessary initial understanding of the NoSQL landscape.

Practical SOA for the Solution Architect

This is a story that has had a fairly long history, so stay with me till the end.

I've worked as an architect in the shared services space for almost a decade now, at some of Australia's biggest, richest and technologically diverse financial services organisations. During that time, I first heard about Service-Oriented Architecture (SOA), learnt what it was about, bought into its philosophy and attempted to implement it at work.

And while I have seen a few successful examples of SOA projects (mostly individual services, truth be told), by and large, I did not see SOA having an impact at all at these large and reputed organisations. Many hundreds of thousands of dollars were spent on acquiring SOA tools from vendors as reputed as IBM and TIBCO, and many millions more were spent on integration projects using these tools, but somehow, the results failed to live up to the SOA promise. [I guess organisations need a terrorising CEO like Amazon's Jeff Bezos to achieve the benefits of SOA. Read the fascinating story of how an online bookstore built a platform that it now rents out to others.]

For a while, I lost faith. Influenced by a few cynical colleagues, I too began to think SOA was marketing hype and nothing more. But then, as I continued to work in the shared services domain and had the opportunity to review more solution designs, I had an epiphany. Most of the designs I was seeing used SOA products (usually an ESB) or were implemented as Web Services, yet I could see they were still tightly-coupled at the level of the application design, i.e., the data. Also, it was very common for solution designers to use the wrong tool for the job, simply because it was the one they were most familiar with. They even seemed to lack a conceptual ability to tell which tool would be right for a given requirement.

With that epiphany, I revisited my understanding of SOA. I realised that solution architects needed to be educated to produce SOA-compliant application designs, otherwise all the investment made by their organisations in SOA tool suites would be a waste. Worse still, SOA itself would be unfairly blamed for the waste of resources, when it in fact remains the best hope to reduce waste, improve business agility and reduce operational risk.

I've been tossing this idea around in my head for at least a couple of years now, the idea that a lightweight method is required to get solution architects up to speed with the required concepts quickly. Unfortunately, most solution architects would bristle if it was suggested to them that they don't really understand SOA. "Can't you see we're using an ESB?" would be the defensive response. That the response is a non sequitur would be lost on them. One can use an ESB and still come up with a design that is not SOA-compliant. How can we educate solution architects when they don't know what they don't know?

Fortuitously, I had a chat about this in August this year with Sanjiva Weerawarana, the CEO of the innovative Open Source middleware company, WSO2. Our needs meshed perfectly. WSO2 has a full suite of middleware products based on SOA concepts and Web Service standards. They are compact and not bloated, fairly straightforward to install and use, fully Open Source under the Apache Software Licence, and for which WSO2 offers a very attractively priced support model as well as other professional services. For such an innovative range of value-for-money products, the level of awareness in the customer community has been surprisingly low. Sanjiva has been trying to raise the level of awareness in the industry about his company's products for some time now. For too long WSO2's pitch had been aimed at developers (techies talking to techies), but for a real breakthrough, they needed to target decision-makers and decision-influencers. They were looking for a way to reach the solution architect with a compelling message.

And here I was, trying to educate the same solution architect about SOA using a new, lightweight approach. So Sanjiva and I came to an understanding. I would do a paid consulting assignment with WSO2 for a few months and turn out a few white papers to present their offerings to an audience that was higher up the corporate food chain than the developers. In return (in addition to helping me pay the bills), they would provide me a vehicle to popularise some of my ideas on SOA, especially the lightweight methodology I came to call "Practical SOA". I guess this approach is the good cop to Jeff Bezos's bad cop :-).

The first of those white papers ("Practical SOA for the Solution Architect") has now been completed and is available on WSO2's website. It's my audacious hope that a Solution Architect can read it in half an hour and be immediately effective on their project thanks to a simpler and more powerful mental model of SOA. A short summary of the paper is available for you to skim through, but I would encourage you to download the full paper (a free registration is required), since it has much more detailed descriptions, extensive explanations for the final conclusions and a couple of industry examples to drive home the concepts. So please have a read and, if you like it, recommend it to all your architect- and designer-type friends. (At my own request, my name doesn't appear on this document because I don't want to dilute the appeal of the method by causing it to look like a mere individual's opinion. WSO2's cachet is better than mine!)

A second white paper that is currently in the works will describe the full suite of WSO2's products and how they map to the framework established in the first. Stay tuned for that too. The first white paper will equip you with concepts. The second will equip you with know-how about a comprehensive set of reasonably-priced tools. Together, they should provide a customer organisation with excellent value for money and the long sought-for return on their investment in SOA.

Back from WSO2Con 2011

I'm back home in Sydney after a very enjoyable week in Colombo attending WSO2's 3-day conference as well as the pre-conference and post-conference tutorial sessions flanking it.

Over the next few days, I'll be posting a detailed trip report with my impressions of the highlights of the conference. In this post, I want to record my overall impressions.

I was highly impressed by a few things.

One, I could not but be impressed by the rapid rise to prominence of a visionary software company. The "Open Source middleware" niche has only one serious player with a complete range of offerings. That's WSO2, a five year old company. This relative newcomer is giving established players like IBM, TIBCO and Oracle a good run for their money. I have no doubt that middleware prices will come down in a few years from their current extortionate levels to something much more reasonable, and the credit will go in large measure to WSO2's disruptive impact on the market.

Two, I also had to marvel at the achievements of a country. I spoke to a few Indian delegates at the conference, and we all agreed that in spite of the huge number of Indian IT professionals and some very large Indian IT companies, no one in India has achieved (or even attempted) what a relatively small Sri Lankan company (WSO2) has pulled off. In hindsight, it shouldn't have been too hard. Take some software products from the Apache stable, enhance them to make them usable by corporate customers, release the lot again under an Apache licence, and charge customers for just support and professional services. It takes some vision of course, but a lot more courage and conviction, and WSO2's CEO Sanjiva Weerawarana has that in spades. It has been his determination that Sri Lanka should be a leading Open Source nation, not just in terms of usage but in terms of contribution, that has led to the success of WSO2. Today, I'm told Sri Lanka ranks third in the world in terms of Open Source contribution, behind the US and Germany. It would be good if Indian companies and professionals took inspiration from their smaller neighbour and started contributing to the world through Open Source.

I was also very glad to see the number of Sri Lankans (not just WSO2 employees but also others from Universities and the like) using Ubuntu Linux on their laptops. I felt right at home after a long time of appearing like a curiosity. Indian and Australian professionals, on the other hand, seem to have sold their souls to Microsoft (or else to Apple). Any argument that Linux is "not there yet" is just an excuse. These people have been using Linux exclusively and are none the worse for the experience. They also have a bit more cash left in their pockets as a result of their choice :-).

Three, I was very impressed with the way the conference was organised. Everything went like clockwork. Events started and ended (largely) on time with very few overruns. Sri Lanka follows Indian Standard Time, but fortunately, the other connotations of the term have not been infectious ;-).

There were distinguished speakers from around the world, giving the conference an international flavour. This was not just a Sri Lankan affair.

IBM Fellow C Mohan giving the main keynote speech of the conference

Gregor Hohpe, author of Enterprise Integration Patterns, giving another keynote speech on the final day of the conference

eBay's Distinguished Architect Sastry Malladi gave a talk and participated in a "fireside chat" to talk about, among other topics, eBay's use of WSO2's ESB to process a billion transactions a day

David Schumm of the Institute of Architecture of Application Systems (IAAS), Stuttgart, talking about BPM research at his institute based on WSO2 Business Process Server and similar products

Dmitry Lukyanov, Head of Integration Solutions, Alfa Bank, Ukraine, talking about his bank's positive experience with the WSO2 middleware suite

Cognizant's Principal Architect Dipanjan Sengupta's presentation demonstrating the interoperability between IBM's WebSphere Service Registry & Repository (WSRR) and WSO2's Governance Registry, was very well received

Catering was top-class, though some of the Western delegates found the food excessively spicy. (I had no complaints, except that I have probably put on some weight ;-). The hotel accommodation and local transport were great and there were no snafus of any kind. It was testimony to the conscientiousness and attention to detail that the people involved displayed.

Four, I realised that the conference was a showcase not just for WSO2's technology but also for Sri Lankan culture. Every evening, after the main technical events were over, there was some cultural program or the other that was fascinating. Day One had an elephant ride (with people able to feed the elephant by hand before the rides got started).

There was also a very interesting talk and slideshow by a conservationist on "human-elephant conflict" and possible solutions, with very moving and often tragic stories about individual elephants. Then there was a set of folk dances that I can hardly do justice to with mere words or even pictures.

Day Two's cultural event was a Jam Session, where WSO2's employees enthralled the crowd with their musical talent.

That, and the musical talents of CTO Paul Fremantle and VP (Business Development & Product Design) Jonathan Marsh, made me think one needs to have musical ability as well as software competency in order to work at WSO2!

Fremantle and Marsh present a musical mashup (In India, it would be called a Jugalbandi)

On Day Three, a well-known local group "Bathiya and Santhush" (rather like Shaan or Hariharan in India) performed and the whole crowd danced to their music. The lyrics were in Sinhala, but the beat had universal appeal.

That was WSO2Con at a glance, and I'm sure next year's event will be even bigger and better. Those who missed this year's experience should try not to miss the next!

(Disclosure: I am in advanced negotiations with WSO2 to join them in a suitable role reporting to the CTO. While this obviously makes me an interested party, I promise not to make any statements or representations about the company and its products that I do not sincerely believe in. My decision to consider a position with WSO2 is itself driven by my conviction that (1) their product suite is fit for purpose and very good value for money, (2) the company operates in accordance with the ideals of Open Source - there is no proprietary version of any of their products, and (3) there is a good cultural fit because I like the people and the company culture (they never use the word "resource" for people) and found myself getting along very well with people across the organisation. Regardless of my relationship with the company, I'm determined to remain a voice that readers of this blog can trust, because I'm acutely conscious that my independent stance on technology matters has always been my biggest source of credibility as a commentator.)

Preparing for WSO2Con 2011

Well, it looks like I'm going to be attending WSO2's annual technical conference WSO2Con in Colombo this September (12th-16th). It'll be good to hear speakers from around the world speak about SOA-related topics and the WSO2 product suite in particular. I believe the latter is one of the SOA industry's best-kept secrets. Here is a comprehensive suite of middleware products that is completely Open Source, and for which commercial support is available at very reasonable rates. I'm surprised more organisations aren't using it. Perhaps the awareness wave is just breaking and we'll see a surge in adoption in the next couple of years. Let's see.

I'm also slated to conduct an introductory tutorial on SOA on the first day of the conference, and I'm excited about that. Over the last few years, I've been developing a few ideas on "Practical SOA for Solution Architects" that I'd like to present, and I'm eager to get feedback on that approach.

What I've seen to my disappointment over the past several years is that in spite of extensive coverage of SOA in the IT industry, the actual payoff from the application of SOA is embarrassingly low. In fact, I hear from sources in large IT shops that have rolled out multi-million dollar SOA initiatives that the cost of building services today is higher than in the past when older EAI techniques were used.

I've been puzzled at this, and have discussed it at length with colleagues and peers. It looks like three different factors are at work.

1. Cynicism: There is a view among many IT professionals that SOA is yet another buzzword that has come and gone, and it's no longer relevant to the industry. So they don't even bother to learn what it's about.
   
2. The theory-practice gap: Lots of IT folk have been exposed to core SOA concepts ("Loose coupling"), but they don't seem to be able to apply it in real-world solution designs. SOA remains in the realm of theory, which is a pity, because it can be a real money-saver.
   
3. Products as surrogates for principles: Organisations have collectively spent a packet on SOA products from IBM, TIBCO, Oracle and the like, but the actual solution designs being produced in-house for business projects are as tightly-coupled as ever, suggesting that IT practitioners seem to think the use of SOA products is an adequate substitute for Service-Oriented application design.
   

I have come to the conclusion that what's required is a new approach to educating people about SOA. It has to be less theoretical and more focused on real-world situations. And it has to be lightweight, because people are busy and don't have the attention span required for a heavyweight methodology. Above all, it has to be sound, because we don't want to spread incorrect practices in the name of simplicity.

I'm preparing a whitepaper on this, and it will probably be released through WSO2, since a lot of the encouragement for it has come from Sanjiva Weerawarana, WSO2's CEO. It's only fitting that WSO2 get the credit for bringing this educational tool to a wider audience.

I'll also be posting my slides from the conference on this blog when I'm done. I'm sure they'll also be available from the WSO2Con conference website.

Stay tuned.

My (unsubstantiated) Snapshot View of SOAP/WS-* and REST

At the moment, I haven't got the links to back me up, but I thought it's important to capture the thought before it escapes me.

I think SOAP/WS-* is an ambitious 100% vision for SOA that is 60% implemented.
And I think REST is a pragmatic 80% vision for SOA that is more than 90% implemented.

That model then explains to me the mutual contempt of both camps. The SOAP/WS-* group criticises REST for an overly simplistic model that does not cover a number of use cases - notably Quality of Service specification (security, reliability, transactions), policy-driven service interactions, process definition, exploitation of "industrial strength" message queue infrastructure, etc. That's because the SOAP/WS-* brief is all-encompassing. They've bitten off a lot.

The REST group criticises SOAP/WS-* for exactly that. They believe that SOAP/WS-* has bitten off more than it can chew. REST has taken a modest bite of the SOA problem, and has produced tangible results. What has SOAP/WS-* delivered except complexity?

A year ago, the winner of this argument would have been REST. But the SOAP/WS-* camp has been steadily chewing away at what they've bitten off. And delivering, bit by bit. Two words - Tango and WSO2. SOAP/WS-* complex? Vapourware? Not anymore.

Now it's the REST camp's turn to be defensive about their incompleteness of vision. We're beginning to hear mumblings about WADL, HTTPR and message-level security. I detect an air of defensiveness in talk about transactions and process definition. My long years of experience dealing with commercial vendors tells me that when someone questions the need for a capability, it usually means their product doesn't have it (yet). (Once they have the feature, it of course becomes indispensible and any rival product without it isn't serious competition.) Many of the RESTafarian arguments against the "unnecessary" features of SOAP/WS-* give me a feeling of déjà vu.

And oh, while REST is ahead of SOAP/WS-* on implementation, it's still not at 100%. Do let me know, for example, when PUT and DELETE are finally implemented by browsers. Ouch.

I'm not gloating that a bit of the REST smugness has been punctured (OK, just a little bit). I'm happy that the two worlds are improving their levels of maturity. In 2008, I'll be looking for REST to expand their vision, and for SOAP/WS-* to deliver on their vision.