MTOM/XOP/RRSHB

Finally these specs are done. For those unware of these specs, there is a good intro in this article.

The key questions for me remains if these specs finally enable code mobility across the network?

Code mobility is a big requirement in the embedded devices from switches to PDAs. It is also one of the key services that should be offered by a Grid.

Cisco Getting Into Web Services

Looks like Cisco is getting into web services and middleware.

This is not surprising at all. Just look at the history of Cisco and networking. Everytime the transfer syntax was standardized at a layer in the OSI stack the functionality of that layer migrated out of the server and into appliances like switches. XML and SOAP help standardize the transfer syntax at L6/L7 and now we should see a network at these levels as well.

The ramifications of having a network at these levels is quite profound.

We have to get used to new vocabulary like application overlay networks or service oriented networks. On these networks one can resolve among two components of an application and provide differentiated services to those components just like today's network resolves among two IP addresses and offers differentiated services to each. (Hopefully the guys defining the WS-Addressing specification are reading this).

Instead of a synchronous API call, a developer simply sends an asynchronous message. This message has to traverse a path across heterogenous systems, multiple transports and now-a-days multiple brokers as well. For this to work we would need switches/routers that offer a fast path based on middleware based control.

Applications themselves have to be choreographed instead of developed-- just like today's business process.

The guy who wrote the HBR article "Does IT matter?" is going to be quoted like IBM's CEO who said the world only need two or three of his mainframe computers ;)

An interesting article on web services standards that you can find here
Computer Magazine - Are Web Services Finally Ready to Deliver?

An interesting quote in that article is that web services' developers are not aware of which standards (defined by W3C/Oasis for interoperability) they are likely to support. Ironically, the whole point of web services is to remove the dependence of interoperability on software coding habits. So it is a good thing that the developers don't know!

The interoperability of components needs to be configured at deployment time not development time. Most of the business code today is written on some sort of container abstraction. It is the responsibility of the container to ensure interoperability of the code that it manages not the developer.

Now who hosts those containers is another debate. Today containers are hosted on some OS running on a GPS. Perhaps it is time to migrate these containers into some fabric which takes care of these low level details and offers fabric wide management functionality.

REST Debate

Anybody involved in web services is probably super familiar with the REST debate and probably figured out how to write the filters to filter out the emails to an appropriate folder for offline reading.

From a for-profit product company this debate adds absolutely no value. Customers are essentially resolving this dispute through their use cases. Having spoken to multiple of them albeit from one vertical it looks like the field is using XML over HTTP for presentation traffic (to and fro from a browser) and SOAP over HTTP or JMS for application to application traffic.

So if your product is anywhere close to the tier-1 of the datacenter be prepared for lots of XML coming down your HTTP pipe. If you device is in the second or third tier of the datacenter (like an app server for example), be prepared for majority of the traffic being SOAP.

Adaptive Systems Salient Features

Building a building block in the next generation adaptive enterprise is not easy to say the least. The most difficult part is not the complex mechanisms that constitute an adaptive system but the complex communication patterns that emerge that need to be controlled.

So I thought it would be a good idea to put together a list of salient features of any adaptive systems. Here they are..

1) Hierarchies: In any complex system, there is bound to be an hierarchy or multiple hierarchies. To make things even more difficult to implement, these hierarchies are based on loosely coupled entities which join/leave the network as and when they please. The biggest issue of this characteristic is in finding the best addressing scheme.

2) Aggregation: Aggregation or grouping is another characteristic. These groups are short lived or long lived and can form dynamically. Their boundaries need to be represented syntactically in the system and access in and out of this boundary needs to be controlled.

3) Communication: The foundation of any adaptive system lies in it's communication substrate. Communication in such systems is generally a conversation rather than a fire & forget type asynchronous communication or block & timeout type sychronous one.

4) Control: Control is the method to the madness. Unlike conventional systems, however, the control is not static and hardwired but dynamic and mostly embedded in the interaction.

5) Non-Linear Behavior: Unlike your SNMP type faults, faults in such a system cascade into really big blackouts. Fault control mechanisms are there not your traditional "call home or email admin" mechanism but more like circuit breakers. The ability to counter a cascading fault is the true gauge to robustness. It is not about 5 nines and MTBFs.

6) Finally, separation of form from function. I believe I blogged on this when I first started on this project.

Ok, now to implement such a system what has computer science given us? Well, so far just two concepts (a) abstraction (b) virtualization.