Skip to main content


Showing posts from 2005

AON Devices - Server Appliances or Network Appliances

Ever since Cisco announced its AON and now SONA strategy, every SOA appliance vendor has embraced the TLA "AON". The definition of AON however is still as ambiguous as its server side counterpart ESB. IMHO, the answer lies in answering the question "Are AON devices server appliances or network appliances? "

A server appliances is a network attached closed server that performs one function i.e. offload the server. All the devices from SOA appliance vendors available today do exactly this. They offload security processing from the server. Some of the ambitious ones will offload business process orchestration from the server. All of this is to optimize the performance of an application that adhers to SOA principles. A server appliance is sold to a server system administrator.

A network appliance is a "in-line" network device. It does not offload processing from a server. It simply redirects, routes application flows to servers which are attached to the network…

Cisco's SONA

Cisco announced its SONA (Service Oriented Network Architecture) guest/netsol/ns477/c643/cdccont_0900aecd8039b324.pdf.

When implemented correctly, a SONA like architecture will allow an administrator to login into a network services router and run "show http peers" which will list all the web services that are exposed using http binding in the network. Replace "http" with your favorite protocol and you should be able to see web services exposed on your favorite binding. If you type "show some_peer_webservice", you should be able to see its various bindings, its "EPR", its grouping and almost everything you get from WSDL of the service (without the annoying angle brackets).

Moving web services network management away from developers into the hands of operations personnel is the true promise of SOA and SONA delivers on that promise better than any application server centric (open or otherwise) service bus.

Development vs. Deployment

The industry has spent the last five years or so to get a conceptual, architectural buy-in for web-services. The standards related to web services, generally referred to as WS-*, too have gone beyond proprietary workshops to standard bodies' technical commitees. Surprisingly all of this effort was driven by developers, for developers and of developers. Web Services have a reached a point where if they don't cross over from the developer domain to deployment domain, there is a very real chance that this whole effort will be for nothing. A key stumbling block towards deployment of web services is lack of real products which embody the technology developed in standards and employ the principles behind web services. While every vendor has a web services marketing program, very few have real web services products. No wonder the few customers who had the resources and implemented web services as pilots are being claimed as the reference customers by every major vendor.

ESB vs. Application Networks

The article by Dave Chappel provides a good description of what ESB is and its roadmap. However there is one critical architectural flaw in ESB. In trying to scale ESB, one has to scale the container. This is very difficult task as we all know from trying to scale other industry standard containers such as J2EE.

IMHO, application networks are better choice for scalable services that ESB offers. The reason is that in a network it is not the control but the data path that is scaled. From networking, we know scaling a data path is far easier than scaling a control. A highly scalable data path with distributed control across the service network can provide all the services of an ESB without the concomittant headaches for IT of having to integrate another layer of middleware on top of already difficult middleware landscape.

Application Networks

There is a lot of buzz on application networks where applications are stitched together using the functionalities exposed by today's large enterprise systems as web services. Before we start to dream about such application networks we may want to put on our systems engineering hats and ask if we even have the underlying infrastructure to support such networks.

Starting at the lowest layer which is all about computing horsepower and storage capacity. With all the efforts around virtualization and on demand everything, we still don't have a compute or storage grid on which such applications can run.

While Grids find their afficionados in the distributed computing field, the Grid as such is more a network related field. In fact, Grid computing is about decomposing a compute problem into a networking problem. This brings us to the next higher level layer in application networks i.e. the messaging fabric. There is no such thing today. All we have today is a few isolated bridges and r…


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 mess…
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 detai…

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.