The middleware doughnut

Where has the “middle” of middleware gone? This week I attended a couple of the workshops at the Middleware conference, the main venue for the research community working on systems integration middleware. In particular I was an invited speaker at the Future of Middleware (FoME) workshop, which attracted a great bunch of people with views on where the field is going. Listening to all the talks, one of the things that jumped out was the diversity of concerns people were expressing. Those working at enterprise level were concerned with scaling-out systems to millions of users using cloud computing; at the other extreme were sensor networks people like me, worried about programming  low-powered sensor motes with at least a semblance of programming language support and software engineering process. That a group of people with this spread of interests can find useful things to talk about together says a lot about how broad a term middleware actually is. But if we compare this to years past, it was also clear that the concerns  asymmetrically affected the different groups. There were very few issues that really commanded broad interest. This led me to wonder: where has the “middle” gone from “middleware”? In the 1990s, middleware people (including me) were working with CORBA and the like. These systems were intended for broad application in integrating client and server components into single systems. In CORBA’s case this involved designing object-oriented domain models that could then be implemented using any chosen programming language and support interactions seamlessly, regardless of  implementation or distribution. CORBA provided (and indeed provides) a lot of supporting infrastructure, including dedicated wire protocols, a shared type system and object model, higher-level services, binding, call models and other groovy toys. It achieved enormous penetration into markets that value long-term interoperability and evolution, such as financial services. It also influenced a whole range of subsequent developments, including web services and service-oriented architectures that are, to some extent, defined by their similarity to, or differences with, CORBA. (For a discussion of these differences see Baker and Dobson. Comparing service-oriented and distributed object architectures. LNCS 3760. 2005.) As is pretty much apparent from this, CORBA sits resolutely in the middle of middleware. It is intended to integrate disparate systems and allow them to work together, and evolve somewhat separately, while managing the complexity of the overall architecture. It tries to avoid the problem, identified by Bertrand Meyer, that large systems exhibit non-linear behaviour in which the cost of making any change to them is proportional, not to the size of the change being made, but to the size of the system being changed. It doesn’t completely succeed in this, of course — no system does — but it provides a common centre around which to organise largely independent components. Another way of looking at CORBA is less flattering: that it was inherently compromised by conflicting, and in large part irreconcilable, goals. It was reasonably performant, but by no stretch of the imagination high-performance given the overheads of a complex and general-purpose wire format. It was reasonably portable, as long as one accepted the limits imposed by the single type system: no first-class functions or mobile code, for example. It was reasonably easy to port and to support new languages, but every new language binding did require considerable ingenuity both in terms of technical design and standardisation of interfaces. Sitting in the middle, in other words, was tricky and uncomfortable. The causes of, and justifications for, these compromises aren’t hard to find: what else can one do if one is trying to support the whole range of applications? Each piece of middleware sits at a particular point in the design space, trading-off performance against generality for example, or advanced typing against making bindings awkward or impossible for some languages. And it’s this generality that seemed to be missing from discussions of the future of middleware: no-one intends to support this range any more. Instead we’re seeing a division of the design space in which different application communities focus on one or two design dimensions that are undoubtedly the most important — and largely forget the rest. For Twitter, for example, the main design goal is lightweight interaction at clients so that Twitter clients are easy to writ. They have no concern whatever with typing or reliability: if tweets are lost, who cares? For the web services community — perhaps closest to the “spirit of the middle” — the issues are extensibility and use of standards, with no concern for protocols, performance or end-point complexity. It’s fairly easy to see that these design issues are simply too diverse to be spanned by a single middleware platform. I don’t think this necessarily spells the death of integrating middleware — and that’s just as well, given that we still have to integrate these systems despite their increasing heterogeneity. What it does do, though, is change the locus of innovation away from ever-larger, more complex and more general platforms towards more specialised platforms that can integrate as far as needed — and no further, so as not to over-burden applications or developers. Several speakers talked about using component-based approaches to build platforms as well as applications. In our talk we discussed similar ideas, removing the a priori assumptions underlying middleware platforms and focusing instead on how to optimise what hits the metal. (Dearle and Dobson. Mission-oriented middleware for sensor-driven scientific systems. Journal of Internet Services and Applications. 2011.) This will give rise to a whole range of further challenges — how do we guarantee the right features are available? How do we add (and remove) features on the fly? How do we find the features we need? —  that are radically different from those encountered for CORBA and similar systems. But the result will (hopefully) be to improve our ability to create, manage and evolve ever more sophisticated combinations of applications and  services, and make it easier to roll-out and scale-out the next generation of applications and scientific experiments.

Inaugural lecture

I will be giving my inaugural lecture on the topic of “The computer is the new microscope.” It’s traditional when appointed a full professor in the UK (strictly speaking, when appointed full prof for the first time) to give an open lecture on a topic of your choice. Because the lecture is open to anyone, they have to be very accessible (well, as accessible as the academic can make it, which often diverges from the normal meaning of “accessible”). My choice of topic follows on from a subject I’ve been thinking about for a while, that computers change both the way we do science and the science we do, and that this needs to be more fully understood within both communities. Date: 7 December, 2011 Time: 1715 Venue: Lecture theatre, Medical and Biological Science Building, University of St Andrews, North Haugh, St Andrews, Fife Followed by a reception in the School of Computer Science next door. [UPDATE 16Dec2011: the slides are now available.]

Funded research studentships available in St Andrews

We are looking for world-class students to come and work with us. This is open to individuals of any nationality, not just UK or EU citizens. I’m especially interested in people wanting to work on programming languages, but I’d welcome inquiries in any research areas that align with mine.

Funded PhD Research Studentships

University of St Andrews - School of Computer Science

The School of Computer Science at the University of St Andrews has funding for students to undertake PhD research in any of the general research areas in the school: http://www.cs.st-andrews.ac.uk/research We are looking for highly motivated research students with an interest in these exciting research areas. Our only requirements are that the proposed research would be good, we have staff to supervise it, and that you would be good at doing it. We have up to 6 funded studentships available for students interested in working towards a PhD. The studentships offers costs of fees and an annual tax-free maintenance stipend of about £13,590 per year for 3.5 years. Exceptionally well qualified and able students may be awarded an enhanced stipend of an additional £2,000 per year. Students should normally have or expect at least an upper-2nd class Honours degree or Masters degree in Computer Science or a related discipline. For further information on how to apply, see our postgraduate web pages (http://www.cs.st-andrews.ac.uk/prospective-pg). The closing date for applications is March 1st 2012 and we will make decisions on studentship allocation by May 1st 2012. (Applications after March 1st may be considered, at our discretion.) Informal enquiries can be directed to pg-admin-cs@st-andrews.ac.uk or to potential supervisors.

Studentships in wireless sensor networks in Leuven

A number of PHD positions are available with Danny Hughes in the Netherlands. Wireless Sensor Networks are expected to play a key role in future Internet architectures and the Internet of Things. The DistriNet research group of the Katholieke Universiteit Leuven wishes to expand its Wireless Sensor Network (WSN) research team. You will play a key role in a highly integrated team, which has a strong and growing research profile in the area of middleware and software development support for WSN. Three positions are available, starting immediately. Possible Research Topics: • System-level support for realizing WSN applications that are reliable and reconfigurable from the lowest-levels of the network stack to the application layer. • Development-time support for building autonomic and reconfigurable applications for networked embedded systems and sensor networks. • Distributed component based software engineering approaches for networked heterogeneous networked embedded systems such as sensors, smart phones and web pads. Profile & Skills: • The student must demonstrate significant enthusiasm for, and knowledge of the subject area based upon their previous education, work and research experience. • A master degree in Computer Science or Informatics with previous experience in: Distributed Systems, Middleware, Embedded Systems or related areas. • A team player with the capability to work in an international research team. • Proficiency in English and excellent communication skills, both oral and written. About DistriNet: DistriNet is an international research group with extensive expertise in secure and distributed software – obviously including middleware . Research on software engineering techniques is performed in both domains on a wide range of topics such as middleware for cloud computing, internet architectures, network and software security, embedded systems and multi-agent systems. Embedded in the department of Computer Science of the K.U.Leuven, DistriNet has a headcount of over 70 researchers of which 9 professors and 15 Post-Docs. DistriNet has a tradition of application driven research often in close collaboration with industry partners. Currently DistriNet is actively involved in about 35 national and international research projects, ranging from fundamental over strategic-basic to applied research. More information on projects and publications can be found at the IBBT-DistriNet web pages: http://distrinet.cs.kuleuven.be. The three open positions are situated within a team that has been established to provide software development support for Wireless Sensor Networks. Key words: Internet of Things (IoT), Networked Embedded Systems, Wireless Sensor Networks (WSN), Middleware, Component Based Softwa Latest application date: 2011-12-31 Financing: available Type of Position: scholarship Source of Funding: IWT Duration of the Project : 4 years Link: http://distrinet.cs.kuleuven.be Research group: Department of Computer Science Remarks: To apply you should send your: • Curriculum Vitae • Motivation • Relevant research experience • Study curriculum with rankings • English proficiency (for foreign students) • Pdf of diploma and transcripts (translation if necessary) • Names (and e-mail) of 2 reference persons and the nature of contact with them By e-mail to Danny Hughes: danny.hughes at cs.kuleuven.be Informal inquiries: Danny Hughes (danny.hughes at cs.kuleuven.be) Start date Between 2011-11-01 and 2012-31-04

A convert to tablet computing

I’m definitely a convert to tablet computing. Many computer scientists can’t see the point of tablet computers, and indeed I was one of them. They’re too large to be truly personal devices (like smartphones); too small to be usable as “real” computers (like laptops); and don’t really support many of the functions and activities people like me spend a lot of their time doing (like coding and writing). Given all that, what’s the point? Having taken the plunge with a Samsung Galaxy 10.1, I can safely say that all the above are true — and that that’s not the point at all. What tablets are great for is consuming, be that papers, photos, videos, news, web pages, and any and all other information. In fact they’re so good for it that I can’t see me using a laptop for these sorts of activities again.

Home screen with fish

It’s hard to explain why tablets seem so much better: it’s probably the naturalness of the interface. That may not sound too surprising, but for a computer scientist a keyboard is basically as natural as breathing, and I’ve never felt that a keyboard is a barrier — indeed, I often find keyboards more natural and powerful than GUIs. So I’m surprised that I find a touch screen so much better than a mouse. It’s interesting to compare the Galaxy with the Kindle (the ordinary one, not the new tablet). Kindles are fantastic for reading books, especially outdoors, and have the other great feature that they isolate you from the internet and other distractions while you’re reading. The e-ink display is very restful, too. What they’re not as good for is reading PDF files (and annotating them), as the screen resolution and size are both “off” for most paper formats: if the document you’re reading doesn’t re-flow, forget it. That makes Kindles less useful for academics than they could be, given we spend so much time consuming papers. I have to say that I also like the ability to jump out of a book and onto the web, or into linked content. Despite the arguments over the impact of linking, it’s hard to argue that restricting access to information improves understanding. I always made do with reading off my MacBook Air, but for some reason that’s never been very effective. So I was surprised to discover that reading PDFs on a tablet is actually extremely easy and restful: more so than the laptop, even though the screen resolutions and pixel densities are comparable. My only suggestion for why this is so is that a tablet can be moved more easily, like a book: you constantly change the angle at which you view it, to conform to your reading position, how alert you feel, and so on, in a way that you can’t with a laptop. (If this hypothesis is correct, it’s a really good example of the subtleties involved in designing mobile and pervasive and their interfaces.) Given that I’ve had the tablet for less than a week I certainly haven’t found all the apps I want to, but here are my favourite so far:
  • TaptuNews: Taptu. The tablet comes with Pulse, but I think Taptu is better: it seems to be more aggressive about downloading the articles it lists, which means it’s more effective to read on the train.
  • PDF: Adobe PDF Reader. Good display capabilities but no annotation: apparently ezPDF allows annotation, so might be worth buying.
  • Books: Kindle Reader. The only choice, really.
  • A sample Zinio magazineMagazines: Zinio. Subscribe to or buy single issues of a wide range of glossy magazines covering virtually all topics (from Maxim to National Geographic to Shutterbug).
  • Game: Air Attack HD Part 1. Basically a clone of the old console/arcade game “1942” — blow up everything in sight with no sign of strategy. Way better graphics, of course, and I don’t think the Nazis actually used airships or had big electric-spark-generating towers for destroying marauding aircraft, but great fun!!! (Fruit Ninja comes a close second.)
What the tablet doesn’t do well is anything to do with typing. Soft keyboards have no “give” and no tactile feedback, so typing on one is a lot like drumming your fingers on the table. This isn’t something I could do for any length of time, so writing anything longer than a quick email is going to be problematic. (Before you ask, I’m writing this on the Air.) But this limitation is massively outweighed by the advantages. Even the little things are challenging to the status quo. A tablet is pretty much always-on (since it sleeps by default rather than shutting down), and instant boot. Why can’t “real” computers do that? Of course, they can — and indeed did, 30 years ago — but we’ve accepted a different approach as normal. There are reasons for this — it maximises flexibility to load everything off disc through a flexible boot process — but once you see an instant boot it’s hard to make the argument that it shouldn’t be replicated on all devices. I feel about tablets the same way I feel about the first laptop I encountered: it’s game-changing. But in fact they’re more game-changing than laptops ever were, because they open information up to an enormous new user population who’d never use a traditional computer effectively. Using one for even a few days sparks off all sorts of ideas about what should be the future of books, the future of programming languages, rich information linkage, the ways we educate and the ways we make information available. Tablets are easily the most exciting new piece of kit I’ve seen in the past decade, and I can’t wait to see where we can take them.