OSGi, Componentization, Virtualization and Dashboards

May 1, 2009

In yesterday’s Web panel discussion, WSO2’s Paul Fremantle and Sanjiva Weerawarana did a brilliant job answering questions from audience on contemporary topics in relation to SOA, middleware and the WSO2 stack. Initial discussion covered ground on the OSGi hype, WSO2’s adoption of the OSGi technology with its release of WSO2 Carbon, and its limitations. Sanjiva stated that pragmatic Carbon installations tends to take off with the adoption of a single product, which is then extended as per additional needs – rather than an installation that begins with the Carbon core, an enhanced with components. This seems more evident when we dive into popularus use cases driving middleware componentization. They are:

  • those who do not want to run separate products in multiple server instances in order to get a job done.
  • users who were frustrated with having to make a all-or-non decision taking on propriety middleware solutions – which meant they’d have to throw away all of their existing middleware in order to accommodate a new vendor.

The value of componentization, as Sanjiva pointed out, does not stop there. In fact, componentization has enabled innovative combinations of components in customer sites, that’s fused much more value added usage of WSO2 middleware, that was not envisioned at the point these compoenents were written. This to me is one of the greatest joys of technology. To watch new technology come out of research is certainly exciting, however, it is much more exciting to see the actual usage of a technology as it reaches the end users, which at time is far more outreaching that the technology initially planned. These innovative use cases then fuels additional research in that area of technology adoption.

Enforcing this cycle more rapidly means, there is constant feedback that results in continuous improvement to the technology in question. It is the value proposition behind the concept “release early, release often“.

As Paul and Sanjiva pointed out, componentization fits in very well with cloud computing and on-demand computing arena, in which users try squeeze in more and more value out of a single instance. With multiple virtualized platforms sitting in a single instance, virtualization stands to benefit greatly from componentization that leaves out having to live with fat and bloated solutions in cloud instances that would takes up considerable administrative efforts related to management and scalability.
On the cloud front, Sanjiva also emphasized the need to go a step forward from simply using it to host applications, which on its own clearly have merits, to actually host applications that are componentized. He referred to these as appliances – application component configurations that are assembled to meet very specific usage requirement,  reducing the total foot print of the installation. Along the same path, Paul mentioned that cloud computing with componentization could actually make the running of a data center a lot more efficient. They revealed WSO2 plans to offer its entire middleware stack on Amazon and Eucalyptus cloud infrastructures, just this same way.

In the presentation frontier, Paul mentioned WSO2 efforts in building a Carbon UI. He illustrated the the need for a business health monitoring portal requirement within an SOA. Such a system would then alert the health status of component deployments while exposing services that are otherwise distributed. A JSR-168 and iGoogle compatible personalized and componentized UI server solution is already in WSO2 agenda.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: