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. This routing is based on metadata that is part of the payload. This single function differentiates it from a standard router which only looks at packet level information to route a flow. Using a network appliance, one can create a VLAN which is SOAP 1.1 only. One could create a load balancer which distributes load based on transaction identity and not just sessions. A network appliance is sold to a network manager.

I have heard folks say network managers are not knowlegeable about SOA and its protocols of communication. Well, they were not aware of HTTP and web protocols in 1995. But they are well versed in it now. The reason these folks are not interested in talking to vendors, is vendors keep taking a server appliance to them and try to sell that as if it were a network appliance.

Cisco's SONA

Cisco announced its SONA (Service Oriented Network Architecture) www.cisco.com/application/pdf/en/us/ 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 routers in the form of MOM middleware but nothing that can remotely be classified as infrastructure.

The top two layers in the application networks deal with business logic and processes respectively. IMHO, these are the easiest of the layers to build as they are the most application specific.

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.