Life mimics art so they say, but nowadays it is just as common to see technology mimic life. That is certainly one way in which last week’s acquisition by IBM of ApSoft can be seen. It is also by no means a unique example of  the technology that is required in SOA, as companies like iLog would no doubt happily testify. 

The `life’ that technology is mimicking in this circumstance is that of the living, breathing middle manager – the individual who was charged with running a piece of the overall business process and capable of taking quite complex, dynamically changeable decisions that depended upon, to quote Harold Macmillan, “events, dear boy, events.” 

I used the words `was charged’ quite deliberately because, by and large, such individuals have found their jobs rationalised out of existence by senior managers who believed the hype that technology had the answers. Well now, some 10 or more years late, it does look as though it might be getting close. 

The ApSoft addition to IBM’s software roster is called a Complex Event Processor (CEP), and in essence it accesses all the data held in applications that run individual process functions and all the process rules that they work to, and seeks out correlations between them all so that appropriate business decisions can be made in a timely fashion. 

One way to think about it would be as a hierarchy of rules engines, with simple, yes/no process rules being managed and controlled by the one rules engine to rule them all – now known as ApSoft CEP, in IBM’s case at least. 

The interesting part about this acquisition is that IBM has incorporated it as a core component of its SOA offering, a position iLog has also identified as an important role for a complex rules processing engine in the overall SOA infrastructure. In an SOA environment there are going to be many occasions when a service being provided to a user requires a contextual decision far beyond the capabilities of a simple yes/no of a standard rules engine. The correct decision, particularly if it is a business decision, will depend upon a dynamic mix of factors that are themselves in a dynamic state, depending upon the state of their individual processes when a decision needs to be taken. 

This is type of role that a CEP service can fulfil and is the type of service an SOA environment will require if it is to get close to fulfilling the `service’ part of its name, rather than just being a higher state of fundamentally dumb system. I’ll give you an analogy that springs to mind. I know of a swanky restaurant in a swanky hotel with a `name’ chef……except that the chef is virtual, having developed a menu and a set of precise ingredient measurements and cooking instructions for each dish that are then implemented by `process functionaries’.  

Here is a basic series of process steps which normally works but, as I have seen happen, can go horribly awry if the wrong quantity of an ingredient (a heavier piece of fish than specified, for example) is used. The result is a badly under-cooked meal.  

A trained chef would know what to do – and would probably have compensated on cooking times sub-consciously, from experience. A process functionary, however, merely messes up. This is one of the dangers with SOA if its application is not thought through properly.

Just a couple of weeks ago, IBM suggested that Intel’s Itanium processor has about five years of useful life left in it before it departs this world for good. It is an interesting hypothesis, but one where the evidence is at least a bit arguable.  

For a start, one has to look seriously at IBM’s own, increasingly huge, vested interest. It is already pushing hard on promoting its own Power 6 family of RISC processors, and is also starting the process of winding up the market in readiness for the appearance of the next processor generation, Power 7. In addition, figures from market researchers, Gartner, suggest it is not only growing high-end Unix server sales around 6% but is also taking customers away from both HP and Sun. HP, of course, owns the world’s largest commitment to Itanium and is now - according to researchers, IDC – the largest server vendor of all.  

IBM is also pushing Power 6 into low-end Unix boxes, offering the chance for greater server continuity across the infrastructure, which some users will certainly welcome. In addition some new mainframe systems to replace the z9 family are due to appear from IBM at the end of February. These are expected to use the new z6 processor, which is a 4-core, 4 GHz mainframe first cousin of the Unix-running Power 6 processor. As often happens at such times, current mainframe sales have fallen – by nearly a third according to some claims - as users opt to await the new machines.  

The basis of IBM’s case against Itanium in any of the server market sectors, according to reported comments by company Vice President, Scott Handy, is that the business case suggests there is not enough business to support the continued existence of Itanium. At the face value of the status quo this does look a reasonable supposition. The question is whether the status quo is the `face value’ the world can expect in five year’s time. 

To be sure, there is currently no role for Itanium at the low-end of the server market. This is all taken up systems based on x86 multicore processors. But as the number of processor cores per chip grows, the real issue then becomes whether the operating systems and applications can keep up so as to even partially exploit the performance potential. It is certainly not clear whether there will be an operating system that allows users to get some advantage by, say, running 16 different x86-based legacy applications on a near future, 16-core x86 processor.  

Without that there is no advantage in the processor, unless there is a radical change in operating systems and applications – which fundamentally means a move to parallel processing architectures and a significant re-think (and not just re-write) of all applications architectures. Once that happens – and all the signs point to it being inevitable, certainly before IBM’s five-year death-sentence for Itanium – then all current bets are off; `face value’ will mean nothing as the `face’ will have changed drastically. 

At the other end of the spectrum there is the mainframe. This was, of course, supposed to have died as a machine type about 15 years ago – and the main lesson to be learned from its continued existence could simply be that `legacy’ software not only means `something bequeathed by a predecessor’ but, like a listed ancestral castle, something that is also damned difficult to get rid of. It would be reasonable for IBM to therefore view the mainframe marketplace as one where existing users are stuck with their commitment to the machines, and new markets or users are a merely a fond illusion.  

But that is not necessarily the case – and Itanium can certainly play a role in changing things. Last October, for example, DataDirect launched the latest, Version 7, of its mainframe integration tool, Shadow. This can now exploit direct SQL integration so that mainframe DB2 database applications can be integrated with any other SQL-compatible database or application. It can also now run, and integrate with, Java-based Business Process Execution Language (BPEL) applications. So developers can build a BPEL application once and pitch it at low-end x86 servers, mid-range RISC servers and high-end mainframe systems. These are capabilities that give mainframes the potential of a central, controlling role in online, event-driven, web-based systems – not something it would have been thought possible to suggest even a year ago. 

In fact, there is more and more integration technology coming along that links mainframes to the standards which lie at the heart of web-based services. This is, for example, where the likes of Platform Solutions Inc (PSI) now plays by providing technology that can run mainframe operating systems and applications on an Itanium-based server. IBM has recently launched a legal suit against PSI that revolves around this capability. 

Why would anyone want to run mainframe applications in that way? Well, for a start the fact that many of those applications have capabilities ideally suited to handling the high-throughput transactions that are inevitable with the web. The high bandwidth I/O and transaction management capabilities have the potential to make the `mainframe’ a far better option for real online trading management services than anything available now: except, of course, that `mainframes’ are deeply specialised boxes costing an arm and a leg in capital and operational investment.  

But if, as the runes now seem to be suggesting, the time is drawing near for the mainframe to come full circle and become central to the efficient running of business activities then the potential for a lower-cost, more flexible environment on which to run the applications and services could make it very attractive. An Itanium-based platform, especially if it could then also run Unix, Linux and/or Windows applications at a similar performance level to the x86, could change the value of the `face’ dramatically – and that could happen faster than anyone, certainly at IBM it would appear, would consider possible. 

It goes without saying, of course, that anything `green’ these days is sexy and hot news, especially for any business running a large datacentre or server farm. They, of course, are now the consumers of vast and ever-increasing amounts of energy, and are therefore intrinsically `bad’. So the semiconductor vendors struggle to reduce the power requirements of their chips, while the server vendors work to improve their power management tools and system cooling technologies. Yet still none of them look to the other side of the `green’ equation: better management of the tasks those servers are actually performing, and why they are doing it.  Up till now the server vendors could legitimately argue that it was not their problem; the mainstream operating systems and applications are the creations of other companies. True, but in at least one area of server activity – running web servers – there is now a way to manage server workloads so that server utilisation is improved, over-provisioning of redundant systems reduced, and revenue and operating margins improved for any online business that is conducted. 

This is a classic example of why managing not only server workload but also what constitutes that workload can make a difference in `green’ terms. To accommodate peaks in traffic it is now quite common for web services server farms to be significantly over-provisioned, just in case there is a peak in brute traffic that needs to be accommodated. And this means a good deal more than a spare server or two – it can amount to 50% or more servers than needed for a typical workload – just in case.  To be of real value in a fast-moving online business, they also have to be on, wasting more energy – just in case. 

And behind the just-in-case issue is the problem that there has been no way to manage who gets onto a web site and what they do there. Web applications tend not to discriminate for or against the intentions of any visitor. For example, are site visitors just browsing the website – window-shopping in effect – or are they a real customer keen to pay money for a product or service?  Making that distinction is the target of NetPrecept, a small UK company that has taken some web traffic management technology originally developed in the USA and turned it into a package of tools called iPEP. These can perform a number of functions now, from providing the tools needed to allow online businesses to discriminate between types of visitors and offer different levels of service accordingly, through to traffic management capabilities that can spot, and trap, Denial of Service attacks and stop them even getting on to the server farm. 

Being able to identify the behaviour patterns of individual site visitors so that the most valuable get preferential service and the malicious are stopped before they ever get on to the servers to cause havoc is obviously useful in business management terms But it also carries with it a by-product that is extremely useful in `green’ infrastructure terms. If it is possible to manage and control the traffic hitting websites in qualitative rather than brute quantitative terms, then the infrastructure requirement switches to one of servicing that quality rather than trying to meet the (theoretically infinite) upper reaches of potential quantity demands. That may seem a subtle distinction, but in practice it means, in the words of NetPrecept CEO, Iain Fraser, “putting servers out of work”. In `green’ terms, that means the ability to switch off more servers, reduce or even remove the need to buy more, and cut the energy bill while creating the scope for generating more revenue per unit of energy consumed.  

And in the end, producing more revenue for each unit of energy is a far more valuable component of the green equation than simply getting more (possibly pointless) work per unit of energy. One of the problems with the growth of farms and datacentres of x86-based Windows and Linux-running servers is the fundamental of such systems’ ancestry. They all started life pitching at the single user running a single task. They have grown like Topsy, and have succeeded masking that weakness by the use of ever more power and resources. It is only now, when the energy costs of those resources have started to bite hard, that the sound of a penny dropping can be heard. This is an architecture that will consume significant amounts of energy doing increasing amounts of“work’ that achieves little or nothing. In the time spent waiting for the server vendors to cross the Rubicon of a move to parallel computing architectures, there is a need for tools like iPEP to come along and start applying some level of control over what work the servers do, and why.

Far be it from me to throw buckets of cold water around willy nilly, but I can’t help feeling a strong urge to put a bit of a dampener on the current excitement surrounding the arrival of SPECpower_ssj2008. This is the new `green’ benchmark for servers that has been developed by the Standard Performance Evaluation Corporation (SPEC) with support and participation from AMD, Intel, Dell, Fujitsu-Siemens, HP, IBM and Sun Microsystems. 

All things `green’ are, of course, extremely sexy just at the moment. The industry has woken up to the fact that, despite most individual chips only consuming a few Watts each, a rack of servers still contain enough of them (and attendant fans, power supplies and associated materiel) to hoover up 10kW or more of electricity supply with remarkable ease. Anything they can do to cut back on this is obviously a good thing. Anything they can do to be seen to be cutting back on energy consumption (which may not necessarily be the same thing) is equally good. 

The arrival of the SPECpower_ssj2008 benchmark sets out to provide a tool that allows server makers to show that they are cutting back on energy consumption or, more relevant in a way, that they are at least providing the best possible performance `bang’ for each performance `buck’ consumed. But, honourable as this idea most certainly is in theory, I have some doubts as to whether it gets too close to achieving it in practice.  

It must be acknowledged that it is a good start to addressing the important issue of providing some form of meaningful measurement of something we know is important but is also surrounded by emotional rhetoric, hype and significant black holes in understanding. But the tests sets out in the benchtest have some weakpoints, not least of which is that they do not really exercise the I/O side of a server system. In addition, the workload is measured by using a specifically developed `standard’ software routine that currently only exercises server-side Java. The real world of datacentres involves a lot more than that.   

I’ve seen the benchmark described as being like MPG measurement in a car – divide the number of miles driven by the number of gallons used to get a useful measure. But, this assumes that a mile is a mile is a mile. In the world of IT, the actual question should be – are we talking Welsh miles, perhaps? Are we talking (worse still) Irish miles? Who hasn’t pondered the apparent flexibility of standard measurements when told “it’s only a mile further down the road.” 

This is a start, but much more is needed to help users determine what the real power/performance ratios are with their current systems and what makes the best alternative. For example, while I can see this benchmark becoming the latest hypemark target for hardware manufacturers, it may do little to demonstrate a far more important and unstated factor – that their current applications and operating environments are stupendously energy inefficient.  

In addition, as many business applications are in practice more dependent on fast and reliable I/O capabilities than shear brute power – the speed of the processor and the disk drives is often less important than the bandwidth of the comms channel between them, particularly when the disk is in a NAS or SAN and not in the same box as the processor. There lies a can of worms that not only impacts energy consumption but could have a huge effect – for good or ill – on performance. 

That alone, ironically, could be a component of a future benchmark which shows that the mainframe is, in fact, still the best option.