Cool Innovations by WSO2

I've long held that the WSO2 suite of middleware products is one of the industry's best-kept secrets. But just what is it that makes these products so special?

Well, if the mere fact that there exists a functionally comprehensive, 100% Open Source middleware suite isn't remarkable enough, there are plenty of other reasons why IT practitioners should take a good look at WSO2's offerings.

I have had the opportunity for a few months now to work closely with the company's engineers and play with their products, using them to build (demo) distributed systems, and this is what I have found.

There is significant innovation here that is really cool. There may be even more that I haven't discovered yet.

1. OSGi bundles, functionality "features", and the fluid definition of a "product"

(WSO2 has no rigid products, although their brochures list about 12. The truth is that they have hundreds of capability bundles that can be combined with a common core to create tailored products at will.)

2. A "Middleware Anywhere" architecture that spans cloud and terrestrial servers

(When cloud-native features like multi-tenancy and elasticity are baked into the common core of the middleware product suite, there is no need for applications to be written differently for cloud and terrestrial deployments.)

3. Not just an ESB - the right tool for every job

(As in my writings on "Practical SOA for the Solution Architect", there are three core technology components required for SOA - the Service Container, the Broker and the Process Coordinator. They do different things and are not mutual substitutes. There are also eight supporting aspects at the technology layer. The ESB, being just the Broker component, cannot do all of these functions. WSO2 has products corresponding to all of them.)

4. Making a federated ESB an economically viable architecture

(Economics forces many organisations to deploy their expensive ESB product in a centralised, hub-and-spokes architecture, which leads to a single point of failure and a performance bottleneck. But Brokers are best deployed in a federated manner close to service provider and service consumer endpoints. WSO2's affordable pricing model makes it easy for organisations to do the right thing, architecturally speaking.)

5. The "Server Role" concept - enabling a logical treatment of SOA topology

(Architects don't think in terms of products but in terms of functional capability. One would rather earmark an artifact for deployment to a "mainframe proxy" and another to a "customer complaints process node" than to an "ESB" or a "Business Process Server" instance. Tagging both servers and artifacts with a user-defined "Server Role" makes it possible to speak in these convenient abstractions.)

6. The CAR file as a version snapshot of a working and tested distributed system

(In distributed systems, upgrading the version of software X can break its interoperability with software Y. That's why version change in distributed systems is such a nightmare involving expensive regression testing and a higher probability of outage after an upgrade. But what if a related set of changes can be tested together, certified as interoperable, labelled as a single version, and deployed to multiple systems through a common mechanism? We've just described the Carbon Archive.)

7. The CAR file and Carbon Studio as a unifier of diverse developer skillsets

(Developing distributed systems is challenging from a skills perspective. Writing business logic in Java and exposing it as a web service requires different skills from writing data transformation in XSLT, which is again different from specifying process logic in WS-BPEL. And then there are specialised languages to codify business rules, etc. WSO2 has a single IDE to support all these diverse developer needs - Carbon Studio. It also provides a single package that can hold all these types of artifacts - the Carbon Archive.)

8. The Admin console and support for configuration over coding

(Not every artifact needs to be "developed" through code. Every WSO2 server product has an Admin console that looks largely alike, yet tailored to the peculiarities of the artifacts deployed on that server. Following an 80-20 rule, the bulk of the (simple) artifacts that need to be deployed on a server can be created through configuration using the admin console.)

9. Port offsets and the ability to run multiple servers on the same machine

(Owing to their common core, all WSO2 server products listen on the same ports - 9763 (HTTP) and 9443 (HTTPS). Obviously, port conflicts will result when attempting to run two servers (or even two instances of the same server product) on a single machine. But with a simple configuration change (a "port offset"), a server can be nudged away from its default port to a non-conflicting one. A port offset of 1 will have a server listening on ports 9764 (HTTP) and 9444 (HTTPS), for example.)

10. The dark horse - Mashup Server and server-side JavaScript

(Nodejs has refocused industry attention on server-side JavaScript and the power that brings. But Nodejs has no support for E4X! If you're doing XML manipulation of data from multiple sources, which is what mashups often entail, WSO2's Mashup Server is worth a serious look.)

11. Carbon Studio - A light-touch IDE for middleware developers

(The best GUIs are those built on top of non-visual scripting. Every artifact used by the WSO2 development process is text-based, including the build process that relies on Maven. Command-line junkies can coexist peacefully with those who prefer a GUI, because the IDE imposes no additional requirements on developers. It's purely an option, not an obligation. You can even use another IDE like IntelliJ's IDEA with no loss of capability.)

12. Governance Registry - for control both mundane and subtle

(Governance or plain management? People often use the former term when they mean the latter. In any case, for the mechanics of what you want to hold to support either of these functions, the WSO2 registry and repository tool is simple, flexible and powerful enough to support you. The registry is embedded inside every server product as well as being a standalone server, so the way one can choose to store and share configuration settings as well as policy files is pleasurably versatile.)

If you work with middleware, you should be seriously checking out the offerings of WSO2.

Nutshell Definitions

When conducting the Practical SOA workshops in different Australian cities last month, I felt the need to explain a few concepts for my audience in very simple and memorable terms. I realised I have already been doing this for myself for a long time. I try and distil a concept into a single word, or at most a short phrase, in order to understand it. This has been very useful to me in evaluating the merits of technologies and comparing them to others. Call these my trade secrets which I'm now sharing with you :-).

OK, so here are some of my definitions of popular terms, each in a nutshell:

Service-Oriented Architecture (SOA):

1. In one word, dependencies. More precisely, it is the science of analysing and managing dependencies - making implicit dependencies explicit and eliminating unnecessary dependencies between systems. That's what it's all about.

2. Alternative definition: Lego-isation of the Enterprise, i.e., refactoring the various application silos in an enterprise into reusable building blocks based on their core functions.

Middleware:

That which converts organisational silos into Lego blocks.

Integration:

This is a tricky one. When you point your browser at a website and the page loads, no one thinks of it as integration. For something to be recognised as "integration", it seems it cannot afford to appear effortless! For this reason, I steer clear of trying to define integration in terms of technology. The best integration is seamless and not seen as such. It's an art that involves dependency management (see the definition of SOA above). Minimalism is a virtue here, and appropriate data design is an unacknowledged part of integration.

Governance, as opposed to plain old Management:

Governance has suddenly become a very fashionable word, and not just in IT. "Corporate governance" is a phrase that is parrotted by commentators when they often mean just management. So what's the difference?

In a nutshell,
Governance is about doing the right thing, the "what", the "goal".
Management is about doing things right, the "how", the "task".

Cloud computing as opposed to conventional "terrestrial" computing:

The leasing of IT capability as opposed to ownership. "IT capability" is a very loose term, and its nature varies based on the type of cloud (below). Leasing has several benefits as opposed to ownership - no upfront costs, pay-as-you-go scalability that is easy on startup operations, i.e., practically limitless capacity without having to provision it upfront, etc.

Infrastructure as a Service (IaaS):

Leasing infrastructure (storage, compute power and networking), and owning all applications above it.

Platform as a Service (PaaS):

Leasing infrastructure as well as some application frameworks and common utilities, and owning all applications above it. The frameworks and utilities make it easier to build the applications above.

Software as a Service (SaaS):

Leasing all the application functionality required, and owning nothing.

Virtualisation:

Imagine separating your "mind" from your "brain". We assume exactly one mind per brain and vice-versa. But what if you can have multiple minds within a single brain, a kind of benign schizophrenia? Or more eerily, if a mind can span multiple brains and think more powerful thoughts as a result? That's virtualisation - turning a one-to-one relationship between mind and brain into a many-to-many one.

Cloud computing as opposed to virtualised servers in "terrestrial" computing:

In virtualisation, you still own the brains. In cloud computing, you lease them.

Private cloud:

Leasing brains to yourself to run minds on. This may make sense in certain cases, like with transfer pricing between business units of the same enterprise. But because you haven't rid yourself of the responsibilities of ownership, it may not be as attractive as a public cloud. Nevertheless, it's attractive because sometimes legislation prevents minds from running on strange brains, and you may yourself be testing the concept of mind-brain separation before trusting someone else's brains with the sensitive job of running (and therefore knowing) your minds.

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.]