Service-Oriented Information Infrastructure

Mark Lewis had an interesting write up a few days ago on Service Oriented Information Infrastructure (SOII) and I could not agree more with him. Actually, I believe that in many ways this trend has already started. Look at Amazon Simple Storage Services and how sites like SmugMug and YouOs use this infrastructure to essentially run their web sites. You are talking 60,000 customers utilizing 12 GB of storage and 80 GB of bandwidth per month for YouOS and 10 terabytes of new images each month for SmugMug. That's serious infrastructure there. In the case of SmugMug, the company estimates saving $1/2 million a month in storage expenditure!

So, I definitely agree, SOII is the way of the future for the storage industry, looking at Amazon S3 strategy is actually enlightening.


This actually strongly highlights the need for standards in that space. But, then imagine the possibilities: based on the value of their information, customers could either leverage an Amazon S3 services or internal storage for key business records. This also means that application providers need to anticipate such need and layer their product architecture accordingly.

This is starting to happen, Koral, a startup in the content management space is built from the ground up to support storage as a web service and has done a reference implementation using Amazon S3. It will take a while for this type of technology to be adopted in the enterprise, but given the profound impact it will have on established players' product architecture, this clearly has the potential to be a disruptive innovation.

Some thoughts on JSR 196

There are a few open source security framework out there that follow an SPI model for their security implementation. Acegi is one, Jetspeed security is another one. Both spring based frameworks follow an SPI concept, but the specifics are quite different from JSR 196. In the JSR 196 world, the javax.security.auth.container.AuthContextFactory is used to obtain context objects that encapsulate authentication modules and delegate to the ClientAuthModule or ServerAuthModule given the authentication context (ClientAuthContext or ServerAuthContext). Each authentication context is initialized according to a MessagePolicy that specifies what authentication guarantees the module is to enforce when securing or validating request and response messages within that context. A ServerAuthModule may delegate some of its security processing responsibilities to a LoginModule for JAAS authentication.

Regarding, the management of the authentication modules interaction, I found that comment in ServerAuthContext interesting:

Implementations also have custom logic to determine what modules to invoke, and in what order.

I could be nice to have policies or rules to manage that interaction...