RFID Virus

In a study, titled Is Your Cat Infected with a Computer Virus? researchers at the Vrije Universiteit in Amsterdam have proved that you can put a virus on an RFID tag and hence, possibly, break into back end systems using the hacker's second favourite exploit of Ye FLQ Injectione. Actually other RFID afficionados believe that Ye Olde Buffer Overflowe will also work well.

Should we all panic like Chicken Little? Perhaps. Consider this. I inject an RFID tag with a dirty little virus into my cat and then let it loose in a Wal Mart storeroom, where it runs around being read every time it passes an RFID reader. Pretty soon computers all over Wal Mart are infected, Wal Mart grinds to a halt and the Chinese economy goes into tail-spin. (Wal Mart, if you didn't know, takes 2 percent of China's exports).

Actually I don't believe this scenario. My cat's too lazy. It would just go to sleep somewhere. But more to the point, if I were going to attack Wal Mart or any RFID user, I would be more interested in creating false tags that fool the system into believing that goods have left the warehouse when they haven't, so I could steal the goods. Whichever way you look at it, there's a need for security on RFID tags.

The Mainframe

The CIO is sitting at his desk looking worried, when in runs desperate Debbie, the dizzy but dazzling departmental darling. “Oh woe,” she cries, “all my applications have fallen over, my desktop has died and the superserver is seemingly senseless.” The CIO goes white and tries to log on to GetMeANewJobFast.com to submit his resumé, but dammit, he's lost his Internet connection. “What shall we do?” he cries.

There's a flash of light, a cloud of smoke and suddenly a man in a camp cape and costume appears in the middle of the room. It's none other than the MightyMIPsMan with his Magic Mainframe. “Don't worry,” he says, smiling at Debbie, “I can give you all the up-time you've ever longed for.” We have to stop the fantasy here, for fear of descending into double entendres but, hopefully, you get the idea. The mainframe to the rescue...

The mainframe is undergoing a revival and has been doing so for about 5 years. It's a rather odd revival because, as far as I can tell, there's still a certain amount of mainframe attrition going on. Basically there are about 10,000 mainframe sites in the world. There used to be quite a few more than that, but the sites that weren't heavily plugged in to the mainframe migrated away. Very specifically, Sun Microsystems and Microsoft both ran mainframe replacement campaigns and picked off the ‘low hanging fruit’. The level of attrition on that side of the market has reduced to a slow trickle. Nowadays there are more people leaping onto the mainframe bandwagon than falling off it.

At the other end of the market, where the MIPs grow wild, the mainframe may well offer the best TCO you can hope to get—so long as you want very high availability, and as long as you run mainframe friendly apps. So what is mainframe friendly?
Here's a rough list:

• Transactional systems (think WebSphere plus the old Cobol CICS systems)
• Server-side BI and Data Warehouse (using DB2, mainly)
• Linux (in virtual partitions). Actually it is far cheaper than deploying cheap boxes if you have the volume. Makes sense for Linux server consolidation
• Packages (SAP and Seibel)
• In-house apps written in enterprise Java.

More ESP Rules

Last week, I took a look at AleriLabs who have entered the ESP market. They are genuine players with a product that is happy to manipulate and process multiple streams at once within a streaming architecture. Interesting - particularly useful in the area of risk management.

This is my final set of ESP rules.

Rule 8. ESP development products must be capable of accessing and using non-stream data sources effectively.

What we are saying here is that some ESP applications will need to access non-stream data sources, usually for comparison purposes. (How does this compare with last year, last month, last week, etc.). Clearly the use of such data sources will be slow (probably too slow) if the software regularly needs to make disk reads. This virtually mandates a caching strategy for access to such data and a deferred write capability for writing back to disk.

Rule 9. ESP software must be capable of producing consistent outcomes from identical streams of data.

Consistent outcomes are clearly important, but why would we not get consistent outcomes? Consider the following situation; a stream is sending an event record every tenth of a second. We are processing a one second window that contains 10 event records and looking at every group of three records to try to find a pattern. Every tenth of a second we lose one record and gain another. In that tenth of a second we need to process 36 groups of 3 (I think my mathematics is accurate here). But let's imagine that we simply don't have time—in which case we do as much as we can then move on, possibly missing some things. Now the computer itself has its own internal processes that have to run and these do not run regularly. We do not always have exactly the same amount of resource and thus sometimes we will miss more than at other times. In other words our outcomes may not always be consistent. This may be fine as regards the application we are running (we are trying to catch fish and if we don't catch every fish, it doesn't matter) but ESP software ought to be configurable so that it can guarantee outcomes.

How would that work? Well it would be possible to set a resource limit in some way and ensure that the software only tried to process within that limit.

Rule 10. ESP Software must be able to manage its own performance.

A really useful capability is for the ESP software to know how long it takes to do something and for it to keep measurements of its performance, given that the resources available to it may vary. The point here is that the software may be in a ‘race against time’. It may need to produce a result from processing a stream window in a second, say. If it takes longer than one second it must know that it is failing and it ought to be able to request further resource and configure them in, in order to manage its own performance.

So finally I ended up with 10 rules. I doubt if any ESP product obeys them all to the letter, but some products obey most of them. There's the possibility of adding other rules. Maybe there should be a separation of concerns rule for the ESP programming language (but there should be for all high level languages). Maybe there should be some rules about metadata. But right now, I think these are enough. We're done here.