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
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.
-
News: 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.
-
Magazines: 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.)