Tuesday, June 15, 2010

Building an Enterprise App Store with WSO2 Gadget Server

In my previous post, Portals and Mashups in the Cloud, I described an ecosystem that can be deployed either in your data centre or in the cloud.

An ecosystem such as above will allow enterprises to do two important things;
  1. Expose APIs for third party mashup/gadget developers to utilise in their apps
  2. Maintain a repository where business users can visit, browse and select apps from. These apps run in their personal portal pages.
Within that post lies the fundamentals of an Enterprise App Store. What is an enterprise app store? Well, in the mobile device world of iPhones, Androids and Symbians, we all use an app store at one point or the other. Whether it's iTunes, The Android Market Place or Nokia's OVI Store, we all visit them and they provide one significant benefit in general. We get to personalise our device with the applications we need. We get to build, at a software level, a phone that is optimised for our day-to-day use, without being programmers. We also get to influence the programmers who write these apps, by requesting new features for existing apps or, at times, encouraging them to develop new ones. The role of the device vendor here is to provide the best API possible for the app programmers. The vendor benefits by increased user base and the programmers get intrinsic and more often financial rewards for their creations.

An Enterprise App Store brings this to your organisation's IT department.

"The premise of an app store model for enterprises is simple: By removing the middleman, the famous bottleneck between the business and IT demand can be reduced in many cases. Application backlogs can shrink, consumption of internal and external IT resources will increase, and fierce competition to provide the best solutions to niches can greatly improve overall quality (the long tail of IT argument), all while reducing costs. At least, that’s what is possible if we look at what’s happening to the non-enterprise software market today." - Source, Dion Hinchcliffe.
This is why we had an Enterprise Gadget Repository in the WSO2 Gadget Server from day one. If you already run it within your enterprise (either in your data centre or in the cloud), you already have the infrastructure for an Enterprise App Store.

Adding gadgets to the repository.
An administrator can add gadgets to the repository in a few easy steps (we have documented how).

How users interact with the App Store.
Users sign in to the portal and see a default set of gadgets configured by the administrator. Of course they can change the layout of these gadgets and save their personal preferences for each. They can add new tabs, clone existing tabs to build new tabs.. but I digress. Let's see how they interact with the App Store. When they decide to add gadgets, they are re-directed to the gadget repository.

Apart from browsing the directory and adding gadgets to their portal pages, the users get to rate and comment on them.

This builds a community where users see what others think about the app, feature requests and even bug reports. They also see how many are already running this app.
"That is, the app store supports an ecosystem of developers and creators, but acts as a governance mechanism to make sure the crappy and malicious stuff doesn't degrade and contaminate the ecosystem." - Source, Joe McKendrick.
A nice software delivery mechanism for an SOA isn't it? :)

Additional Resources:

Thursday, June 10, 2010

Portals and Mashups in the Cloud

A few days ago Azeez, the senior architect behind WSO2 Stratos wrote a detailed post about its deployment architecture. He tells the story of how we migrated our carbon product stack to the cloud-native platform that we named WSO2 Stratos.

So what does the future hold for portal and mashup developers? How will Stratos change our lives?

As you can see the WSO2 Mashup Server and WSO2 Gadget Server are also deployed in Stratos as cloud-native services. This means that organisations will be able to deploy highly scalable, highly available, distributed applications with ease. And they will be far less expensive than today with a granular, pay-as-you-go model.

This is good news for mashup developers because now we can re-use code and services in a massive scale without an exponential increase in infrastructure costs as our mashups become popular. For instance, imagine that you have a mashup and plan to sell it as a service. The old model would demand that you invest heavily on servers and bandwidth, and then worry about scaling once the demand catches up. With Stratos, you can forget about this initial cost and adopt a pay-as-you-go approach. Scaling takes care of itself, leaving you time and money to invest in making your mashup awesome.

The same story applies for portals both at the portal user level and, a much more granular gadget level. Since users would want to use those super-cool gadgets from your portal in their blogs, web pages and various other places, because Stratos takes care of scalability, you will have more time to promote your portal and its gadgets . Your gadgets are using mashups? No problem.

Actually, if you carefully look at the deployment architecture, you can migrate, mashup and gadgetise any service using the set of products available there.

An example deployment of an ecosystem based on WSO2 Gadget and Mashup servers will be similar to that shown below. The portal plays a prominent role helping human users collaborate. But what's noteworthy is the amount of collaboration points for non-human consumers such as third party apps via APIs and Feeds. This type of consumption is usually recursive in nature and the demand is usually unpredictable as your community grows (think Facebook, its users and the amount of Apps).

Soon, with the introduction of WSO2 ESB along with the auto scalability of Stratos, a company would be able to set up an eco-system such as the one above with minimum infrastructure costs.

Wednesday, June 02, 2010

Introducing WSO2 Stratos and Friends

What's Stratos? It's the cloud-native version of WSO2's award winning Carbon Platform. I emphasised cloud-native because there's a difference between that and just deploying a web application to a service like Amazon EC2. Cloud-native implies five things ...
  1. Elasticity: Stratos manages your underlying cloud infrastructure to seamlessly handle the scalability demands of your application.
  2. Multi-tenancy: Departments, developer groups, or projects run fully independently, but share the same middleware platform for maximum resource utilization.
  3. Billing and Metering: Each tenant can meter their actual resource use for internal billing purposes.
  4. Self Provisioning: Authorized users can provision new tenants from a web portal in moments.
  5. Dynamic Discovery: Linking up services that reside in a dynamic and elastic environment can be tricky but Stratos simplifies and automates this process with standards-based service
    discovery and automatic configuration capabilities.
  6. Incremental Testing: Cloud fundamentally changes the way you test and deploy applications, but doesn't reduce your quality requirements! Stratos allows you to deploy service versions side by side and carefully dial up the traffic sent to each version.
With this initial release of Stratos, we have WSO2 Mashup Server, WSO2 Gadget Server, WSO2 Application Server, WSO2 Governance Registry, WSO2 Identity and WSO2 BAM as cloud-native instances running together seamlessly integrated. An organisation can create a tenant, activate the applications of choice and be immediately on their way.

We will be adding WSO2 ESB and other products to Stratos in the coming days. So stay tuned :)