I was reading this post on BW’s Blogspotting and at first I agreed with it, maybe in the future the companies that currently hold our data to release it to the outside so that it can be mashed-up with other data that we have created and that is stored in other applications.

A pretty nice picture of the future, but I don’t think anymore it will happen at a large scale because I think that data is the primary way that a company uses for binding an user to its services, an issue that I have briefly touched upon in this post. If the datastores get opened then the cost of user migration from one service to another goes down and with it the risk of seeing your users migrate to your competitors. The data a user creates while using a service, and not service’s functionality, is what makes a user continue to use that service because migrating to a similar service implies losing what the data that it has created.

One other road-block to exporting data and using it outside of the place where it originated is the way it will interact with the outside systems and the possible problem of standards: how will data from one service be packaged so that it can be consumed easily by other services? Exporting the data in some RSS format and mashing it up in a Yahoo Pipes fashion could provide a way around the thorny issue of standards.
Security is another issue that comes to mind when dealing with exporting data.

For some companies binding users to their services by locking their data down doesn’t apply and Netflix is a pretty good example: Netflix can open up their users data because their service is about renting hard-to-find movies and not about hoarding user’s data in one form or another (email services, RSS readers, on-line newspapers, etc… are all about storing users data and applying some sort of functionality to it).

So we will have to wait and see how this un-folds. Frankly I do not think that data will get freed any time soon, in a world in which user loyalty exists only in history books companies will try anything it takes to bind users to their services and this includes data hoarding.
Data will probably get shared (later edit: but it will not be free in the sense that we can cherry-pick who is using it and who is not) between the different services within a large corporation not across corporations or between various companies thru partnerships, but data will not be freed without constraints. Controlling the way a service’s data is made available to other services will bind a user to that service even more because giving up on a service will mean giving up on the data stored within that service as well as giving up on the integration between that service and its partner services (within or without the original service’s corporation).

Later edit: This is one example of how our data will be shared among various entities. The new portal as envisaged by Catherine Holahan is simply a way of storing user information and disseminating it into its partner sites. Interesting to watch…

You must have heard about the latest offering from Spring Source, the SpringSource Application Platform, a platform based on OGSi which aims to help developers partitions their application into logical units (called bundles) and then manage the interactions between them. A very interesting product from Spring Source in an environment which seems familiar: application management. To a certain extent the SpringSource Application Platform is the logical extension of their first product, the IoC container: an IoC container is managing the relationships between classes, the SpringSource Application Platform is managing the relatioships between components.

I have looked a bit at this product, but for now I do not have the time to try it out, so I read up a bit on it and read some blog posts. The award for the most imbecile post written about S2AP goes pretty easily to Marc Fleury who manages to get it wrong from the title: SpringSource`s Application Server. To him S2AP is an application server which is coming too late to the market, the market being currently dominated by, you must have guessed it, JBoss. Pretty hilarious as well as also his musings about VCs. The point is that S2AP is not an application server because it doesn`t provide the services that an application server typically provides, it is just a platform for putting together an application.

Another interesting post comes from Peter Kriens about S2AP extending the OSGi container: probably Spring Source is leveraging the market share it enjoys in order to add some headers that it finds necessary for doing a better logical partition of an application. It is confusing to the people behid OSGi, and probably a bit unfair(**), but I guess it it part of the game.

The fact that you have more control over the way you partition an application into bundles will drive the specialization of components further. In the future you will probably buy specialized bundles which target a very speficic functionality and wire them up in the SpringSource Application Platform, Billy Newport`s hits the nail on the head in this post. You will not need to buy an application server from IBM or BEA or someone else only because you need a state of the art transaction manager and not use, while paying for, the rest of the capabilities that that application server comes with, but rather you will be able to buy only the transaction manager, plug it into your application as a bundle, expose its services and then integrate it into your application’s components.
This is probably where Spring has the potential to do the most damage to the traditional app servers vendors in the future because it will force them to un-bundle their app servers into offerings that will be sold on the market as single bundles (a transaction manager, a JMS engine, etc…) rather than integrated solutions. It remains to be seen how this will un-fold, but the potential for damage is there. The road towards un-bundling of application servers into specialized components is a very disruptive process (*) to both app server vendors and their customers and as a result it will take a while to become mainstream but I think that this is where we are going: to specialized components bundled into applications.

I would conclude by saying that the future of S2AP is a bit uncertain, it is a brand-new product targetting a fairly new market, the market for composing applications out of components in OSGi (***). If there is a need for this type of application composition probably Spring will occupy a large part of the market leveraging their brand, their product portfolio and know-how.
I wish them a lot of luck in this enterprise and I will follow it closely.

* I think that this is the most disruptive product to be released by the Spring people since the IoC container. It took a while for the IoC container to start having an effect in the JEE world, but once its benefits were recognized it revolutionized JEE. Let’s see if this will happen again.

** As Glyn has pointed out the OSGi-like headers are syntactic sugar. They created a bit of a confusion, but apparently it is getting straightened out.

*** Later Edit: I don’t know why but I get the impression that setting up a marketplace for these components would help their adoption. At the very least this would open a venue for people interested in trying them out and people interested in selling them.