Skip to main content


Showing posts from 2006

Demographics & Computing

It has not slipped my attention that the most valuable companies in technology industry today tend to be culturally oriented (Goog, Apple, RIMM etc). Sometimes also called consumer oriented technology. Contrast this to the most valuable companies of the 90s which were infrastructure oriented. One could justify this trend to reasoning derived from study of economic business cycle which says first there is overinvestment in a trend followed by bust and painful restructuring and another (and longer) boom. Analogies are drawn between railroad construction bubble followed by bust followed by boom. Using this reasoning, the internet industry should have restructured and the next killer application should have been business oriented. Instead what we seeing is the killer application for the internet is "Cultural Networking".

I think the driver is shifting demographics in the world. Rutgers university did some research on the demographics in US, specifically, of people between 18-25 …

Web 2.0 Infrastructure

In one week, I heard the two major networking companies's CEO mention Web 2.0 and SOA - trends normally associated with computing. What makes these digital plumbing companies interested in Web 2.0 and SOA?

As I have been blogging now for the last 4 years, it is all about converting a compute problem into a networking problem. These two trends shift the focus of innovation away from shared APIs and data adaptation which was the focus of the integration business to standards based networking of application components.

The networking companies who so far been content with connecting stateful compute devices now have to start figuring out how to connect a stateless compute device with its state which could be resident anywhere on the network. In other words, they have to move beyond "Can you hear me now?" to "I can be there now (digitally at least)!"

This is going to require a major shift in thinking (and later business model) for networking companies. The CEOs of the…

Industry Is Climbing a Layer of Abstraction

Where ever you look in the industry, there is a new trend that is driving research and development of the next step in the ladder of abstraction in computer science. You only have to scratch the surface of household buzzwords like SOA, Web 2.0, Grid Computing, Virtualization, On-Demand, Utility Computing and (of course) Application Overlay Networks or AONs to realize that these trends are nothing more than a layer of abstraction over everything that is being done today.

Start with SOA, it is a layer of abstraction on top of currently dominant programming paradigms. At this new layer, one has to independent of Language, the underlying hosting environment, the underlying data model and inter and intra application communication protocol. You are seeing XML driven data models take hold on top of a hosting environment that is supports platform independent interfaces and the interfaces themselves are described in a platform and language independent fashion.

Look at Web 2.0 abstracts the web t…

Ubiquitous Purchase Order

If you ever get into a conversation which discusses use cases of SOA, then you have probably heard of the Purchase Order (PO). The use case goes something like this, there is a PO which needs to be routed across multiple enterprise components (recently exposed as web services) and this PO needs to find its way to its destination through a maze of business processes. It seems every one has a policy which says "if the PO is greater than some dollars then send it to big boss otherwise the little guy can do it as well".

So abstracting the use case out a bit, we are saying the PO is the input into a black box and some processing occurs and the PO changes the state of the black box and returns a zero or more messages saying so to the originator.

I have yet to hear someone question this use case in context of the vision of SOA enabled datacenter. I always wonder why the PO even has to even exist. After all in the world of SOA, multiple systems are now connected at the application lev…

SOA Patterns and AON Appliances

There is a lot of discussion around SOA patterns now-a-days. If you have used patterns in your past life, these SOA patterns are not really the same thing. It is not a reusable chunk of code that you can cut & paste. These are big chunks of functionality that needs to be deployed at various points in your network. From an AON perspective, almost every pattern in SOA can become an independent appliance on the network.

When the first appliances hit the market in 1997 timeframe, the pattern they followed was Linux + some server. An AON appliance is a dual plane appliance which has XML for data plane and a control plane which depending upon the pattern that the AON appliance is implementing can be Java or a scripting language or anything else. The performance of course comes from the data plane.

So if we survey the SOA landscape today, we can easily find references to Gateway Pattern, Governance Pattern, Broker Pattern, Router Pattern etc. Each one of these can be made into an appliance…

AON Device Programming

The fireside chat from a Cisco executive on SONA addresses a FAQ on AON devices's programming environment. If you have the time, I assure you this 1 hr+ presentation is worth the time.

As the presenter points out, AON devices are not programmed in the same way as the server side cousins. There is no IDE, SDK or APIs. The fundamental task of an AON device is to find the destination service and route the message to that service and perform any intermediary tasks that can be in done in the network. This message path is programmed rather differently than a server side implementation. For example, a message path which simply accepts a message from a synchronous http channel and dispatches that message to an SMTP channel would look like this.

Match => "SomePatternInAnyGrammar", WithThisPriority#, RunSomeProcessing
Catch => "ForTheSamePattern", ThisException, RunThisExceptionHandler
Include => SomeOtherContext, WithTheseConditions
Dispatch (Transfo…