Iconic distributed systems research comes back around

Distributed systems research has been going on since the very first time someone decided to network multiple computers. Industry and academia have shared this burden and we're here today because of many different people and organisations. Some of this work is often referenced and built on, such as Lamport's paper on Time, Clocks and the Ordering of Events in a Distributed System, or RFC 707, concerning RPCs. But some of it, such as Stuart's work on Coloured Actions, or much work on weak consistency replication.

However, sometimes it's simply a matter of timing, with some research happening before it's really needed or truly appreciated. Case in point is a lot of the work that we saw produced during the mid 1990's on configurable distributed system and particularly that presented and documented by the IEEE Conference on Configurable Distributed Systems (there were other workshops and institutions doing similar work, but this conference was one that I had personal knowledge about since I had several papers published there over the years). Much of this work concerned autonomous systems that reacted to change, e.g., the failure of machines or networks, or increased work load on a given machine that prevented it from meeting performance metrics. Some of these systems could then dynamically adapt to the changes and reconfigure themselves, e.g., by spinning up new instances of services elsewhere to move the load, or route messages to alternative machines or via alternate routes to the original destination thus bypassing network partitions.

This is a gross simplification of the many and varied techniques that were discussed and developed almost two decades ago to provide systems that required very little manual intervention, i.e., they were almost entirely autonomous (in theory, if not always in practice). With the growing popularity of all things Cloud related, these techniques and ideas are extremely important. If Cloud (whether public or private) is to be differentiated from, say, virtualizing infrastructure in IT departments, then autonomous monitoring, management and reconfiguration is critical to ensure that developers can have on-demand access to the compute resources they need and that the system can ensure those resources are performing according to requirements. This needs to happen dynamically and be driven by the system itself in most cases because there should be little/no involvement by your friendly neighbourhood system administrator (in fact in some cases such an individual may not exist!)

I'm hoping that just because Cloud didn't exist as an identifiable concept back in the 1990's, people and organizations today don't overlook the fact that relevant R&D happened back then. Reworking and retasking some of this prior work could help save us a lot of time and effort, even if it's just to convince engineers today that certain paths or possible solutions aren't viable. For a start I know that I'll be getting my copies of those proceedings out again to refresh my memory!

Nice move by Sacha and Cloudbees

From Devoxx ...

"CloudBees, the new company from former JBoss CTO Sacha Labourey, today consolidated its position as the de facto source for Hudson-based continuous integration solutions, from on-premise to the cloud with the acquisition of InfraDNA, the company founded by Hudson creator Kohsuke Kawaguchi to provide software, support and services for Hudson. Kawaguchi joins CloudBees, and will continue to grow and lead the Hudson project. The first release today from the integrated company is Nectar 1.0, formerly InfraDNA’s Certified Hudson for Continuous Integration (ICHCI) offering, which has been enhanced with new features and rebranded for CloudBees. Enhancements include VMware Virtual Machine auto configuration and deployment; enhanced backup services; pre-bundled and configured plug-ins; and an auto-update service. Nectar annual subscriptions start at $3,000 and include free minutes on CloudBees DEV@cloud service, which is currently in beta."

Congratulations!

PaaS is language specific?

Recently I've been involved in some discussions with people on the subject of PaaS and specifically how the application language impacts it. I was surprised to hear (or read, since some of this was via email) several of the participants assume that you would need a PaaS implementation for each programming language. So that'd be a Java PaaS, a Ruby PaaS, presumably a C++ PaaS and maybe even a COBOL PaaS.

In my most diplomatic manner, I asked if certain individuals had missed the last 20+ years of middleware development; perhaps they had been stuck on some island somewhere, or maybe off on some rocket traveling close to the speed of light and while we experienced 20 years, for them only a few days have passed. See, I do like to give people the benefit of the doubt where possible!

The idea that we need to have a PaaS implementation for all possible programming languages out there (or at least those that may be used in the Cloud), is ridiculous. Think of it like this: if we can virtualize away the hardware, so it's really no longer a major issue in deployment, then we should be able to virtualize (abstract away) the infrastructure upon which the applications will rely. And yes, that infrastructure is middleware.

Oh wait ... we've done this before. Several times in fact! I won't cover them all, but let's just consider a couple of the obvious examples. First, CORBA, where services could be implemented in a range of different programming languages (e.g., C++, Java and even COBOL!) and made available to users that may be written in a completely different language. Second, Java, and specifically J(2)EE. Like it or not, despite the write once run anywhere message that came with Java, many vendors and users simply did not want to, or could not, discard their existing investments in other languages and so found ways to integrate services and components written outside of Java and often without the knowledge of the end users. For instance, there are non-Java transaction services that are integrated into application servers through the JTA. The same goes for JMS.

As an industry we have decades of experience in virtualizing the middleware layer. It doesn't matter if you're writing your applications and services in Java, Ruby or something else entirely: as long as someone provides a binding to the underlying middleware capabilities, you don't expect, and shouldn't be interested in, whether or not the middleware, or PaaS, is implemented in the same language. And in fact it shouldn't be. I'll keep saying this, but we simply cannot afford to stop the world and reinvent the middleware wheel for PaaS. We need to evolve, but we really don't need to start from scratch. I think I got my message across during the aforementioned conversations, but maybe next time I'll resort to drawing some diagrams, perhaps even with some timelines dating back to the 1960's!

Addendum: In case it wasn't clear in the above, of course there will need to be a language specific component to PaaS, but only that which is sufficient in order to allow the underlying implementations (written in whichever language is appropriate) to be interfaced with the application or service. Consider the JTA and JMS examples above.

JCP EC (re) election

The results are in...the 2010 JCP EC Elections have officially concluded, and final results are available on jcp.org. The 2010 JCP EC Election ballot closed at midnight pacific time on 1 November. Congratulations to the new and re-elected JCP EC Members!

SE/EE EC

Ratified seats: Apache Software Foundation, Red Hat
Open Seat Election: Eclipse, Google


ME EC
Ratified seats: Research in Motion (RIM), Samsung, TOTVS
Open Seat Election: Apix, Stefano Andreani

New and re-elected members will take their seats on Tuesday, 16 November.

JCP members did not ratify Hologic for the SE/EE EC. As the JCP process document prescribes, the PMO will hold an additional ratification ballot for the remaining SE/EE seat soon.

Complete results will be available at the JCP Election page and the JCP blog later today.

Personal versus company resources

A long time ago in a galaxy far far away ... OK, so maybe not necessarily that long ago and certainly not that far away, when work started to intrude on my personal love for computers, I made sure I had a separate machine for personal use (a desktop in those days) and one (or more) for work. That was fine for a while, but eventually it became too much of a hassle to synchronise email, source code etc. Plus, in those days there was very little distinction between my personal (for pleasure) efforts and my work. So multiple machines gave way to one machine. I also tried this with mobile phones (with one for personal use and one for work), but with much the same conclusion.

This situation existed for the best part of a decade and a half. However, in the past year I've been finding that work is intruding more and more on my leisure efforts around computing. Whether those are writing research papers or just playing around with new languages, I find it is harder to stop work (via email, IRC etc.) from distracting me. And the phone just makes it worse!

So recently I've reverted to the way things I used to do things, with a dedicated work machine that knows only about work related "stuff" (including email) and a dedicated personal machine, that knows nothing about work (and its emails). The phone problem is about to be fixed with a similar strategy. I wonder how long I'll be able to keep up this separation of concerns. But I'm looking forward to trying!

OSGi

Dear OSGi Alliance Members,

Thank you all for your votes in the 2010/2011 Board elections!

Along with many returning board companies, we would like to extend a warm welcome to RedHat (Mark Little and David Bosschaert) as a new BoD member. Mark is currently CTO of JBoss, a division of Red Hat. Prior to this he was Technical Development Manager for the JBoss SOA Platform and lead of the JBossESB and JBossTS projects. David is currently Principal Engineer at JBoss, a division of Red Hat working on Open Source OSGi products. Before joining Red Hat, David was a Fellow at Progress Software and Distinguished Engineer at IONA Technologies.


The 2011 Board of Directors will be composed as follows –

Deutsche Telekom AG – Hans-Werner Bitzer
IBM - Dan Bandera
NTT - Ryutaro Kawamura
Oracle - Anish Karmarkar
RedHat – Mark Little
Progress Software – Jamie Merrit
ProSyst Software GmbH - Susan Schwarze
SAP AG - Karsten Schmidt
Software AG - Prasad Yendluri
Telcordia Technologies - Stan Moyer
VMWare (SpringSource) - Peter Cooper-Ellis

We are looking forward to a productive year 2011!

Paper reviews

After a fairly hectic week, this week begins with no company email (don't ask!) So this gives me a bit more time to do my paper reviewing for the Workshop on Engineering Service-Oriented Applications. I've got a couple of work on and they appear interesting at first glance. A happy alternative to the last few weeks.

Timezone issues

The past couple of weeks have been hectic. First I was at JavaOne, then I spent time around the west coast visiting customers and partners (talking a lot about Cloud, funnily enough). Then it was a red-eye to Boston and meetings for the rest of the week, before getting home in time for the weekend. Several timezones over two weeks played havoc with me and I missed a few calls due to my forgetting where in the world I was!

This week is slightly better, with meetings in Paris tomorrow, then Berlin for the SOA Symposium (where I'm giving a couple of presentations) and JUDCon (no planned sessions for me to give, though I may do a lightning talk). Back home in time for the weekend again. The next couple of weeks should be in and around our Newcastle offices! And maybe in between all of this I'll get a chance to do some coding!

Blast from the past

I had no idea the University was scanning in old theses. I haven't seen this one for almost 20 years!

Cloud and multitenancy

Over the past year or so I've been doing a lot of thinking about various aspects of cloud. One of the ones I keep coming back to is the issue of multi-tenancy. Many years ago, when I was formulating the categorization of transactional replication strategies, we found that splitting up the object server (methods) from the state and allowing each to be replicated independently, gave the ability to express everything necessary to cover the range of replica consistency protocols from passive through active. Sharing of the executable versus sharing of the state is based on aspects such as determinism of execution (passive is the only option in some cases) and speed of fail-over (active tends to do much better).

So what has this to do with multitenancy? Well I've been thinking about what it means to have a true multitenant application and hence PaaS. Some people seem to suggest that multitenancy is somehow new, complex or the domain of a new breed of engineers and vendors. But if you think about it, we've been using multitenant environments for years. Your operating system is multitenant, with multiple applications resident and often running concurrently, perhaps modifying shared data structures as a result. Even your modest Web server can be considered multitenant. And there are a range of strategies for achieving multitenancy based on a similar server/state split. Therefore, whether you're a SaaS implementer or a PaaS architect, the same factors come into play. And critically for SaaS implementers, if your PaaS doesn't support these things then you're going to have to!

In terms of PaaS, there are really 3 components that can be played with in terms of multitenancy and application and data deployment. These are the VM, the application server (container of business logic) and the data (database, file system etc.) For instance, you could have each tenant in a separate application server but running on the same VM, with data split between different database instances. Or you could have each tenant in the same application server on the same VM, with data in the same database, perhaps split on different tables. (Other options and configurations exist, of course.)

Now all of these various combinations have more or less been around before, as I said earlier. The big problem though has been around ease of use. I've written enough Unix kernel services before, for instance, to know most of the ins-and-outs of sharing state without causing the operating system to crash, and the best way to use pthreads or memory mapped files in a shared environment, but it's not always intuitive or based on well documented processes. This is precisely where a PaaS fits in: it must support the widest range of approaches and in a way that does not require the SaaS developer to have to worry about them. We can learn a lot from what's been done in the past around the intricacies of achieving multitenancy, but we do need to make it far more consumable than has perhaps been the case so far.

Interesting new paper on transactions

I met Daniel Abadi at HPTS 2009 last year, where he presented on HadoopDB. Very interesting and a good presenter. So it's good to see his latest paper on determinism and transactions in database systems. It's a good read and particularly for me because it mixes the two areas that have always been my interests: transactions and replication. The authors have some good things to say about NoSQL, but specifically around relaxing ACID semantics, the trade-offs that incurs and how perhaps there is an alternative. Again, this is an area I've had a bit to do with over the past few decades. I'll have to think about how and whether this is applicable to some of the work we're doing at the moment in large scale data grids.

Coming of age?

Thousands of years ago the coming of age ritual involved hunting and killing (e.g., mammoths or dinosaurs, depending upon which film you believe). Due to changes in a range of things, including society and the fact that mammoths (as well as dinosaurs) died out (maybe related to hunting, strangely enough) the rite of passage changed.

In our household one aspect of our version of this ritual is introducing the kids (my 8 year old now) to the all time great movies. Several weeks ago it was Lord of the Rings, which went down really well. This weekend we started into Star Wars. Of course the first question was which order to play them? Against my better judgement we went with the chronological order, i.e., Episode 1 first. The first two movies went down well with him, though the third was more of a slog, but of course the best movies are yet to come.

However, I realised that although it's been about 8 years since I've watched the movies, two things remain a constant for me: the midichlorian rubbish detracts from the story (what was George Lucas thinking?!) and I still can't stand Ja Ja Binks! But my son loved him! If he loves the Ewoks then all is lost and I think I'll fail him on this rite of passage!

Long weekend coming up

It's a national holiday here on Monday, so this is a nice long weekend. Unlike my 2 week vacation which only ended at the start of last week, I've decided to not touch anything remotely work related until Tuesday (that holiday turned out to be > 50% work!) Well that's the theory at least. I know there may be some pressure to bend that rule slightly, so we'll wait and see!

CloudBees

It's been 18 months since Sacha left JBoss and I took over. He said he was going to take time off to enjoy being with his family and (then) new baby daughter. However, I think many of us knew that at the time it wouldn't be long before he was back doing something interested. So it's really good to be able to announce that that effort is called CloudBees and they've officially launched! Hudson as a Service (HaaS) is a really good idea! Coincidentally it's something that JBoss and Arjuna separately considered at one time or another with their/our Distributed Test Framework.

Good luck Sacha and team!

BBC Micro making a comeback?

I loved this article! It brought back a lot of memories from when I was programming in BBC Basic. I upgraded my machine to support Metacomco's Pascal and C as well. Lots of fun and I like to think the "hardships" that the students of today mentioned helped to make me appreciate what it takes to write code in less than 32K of memory!

Classic C++ textbook

Every now and again I have to go through my cache of books and box some of them up for storage. This time it was some of my old text books from university, but while going through the process I went through all of my C++ related books. One of the best I've ever read is Barton and Nackman. I got this book just after it came out (I think I got it just after visiting Graeme at Transarc.) It's a wonderful book and reading the Amazon comments afterwards it's good to see that I'm not alone in thinking that. If you're a C++ programmer then you should definitely check it out.

Private Clouds?

I've known Werner Vogels for several decades, ever since we were both doing our PhDs. Like all good friends and scientists, we don't always agree on everything. Case in point is that Werner doesn't believe Private Clouds are clouds and I think his arguments against are artificial and short sighted. Now of course you could say that he and I take our perspectives on this debate precisely because of our employers. However, that's wrong, at least where I'm concerned.

As I said earlier this year, I think that today's definition of Cloud is limiting and emphasizes Public Cloud precisely because that's what most people have access to. But I also believe that Public Clouds are not going to be as important in the future. Cloud is a natural evolution of hardware and software (middleware) but if you liken the roadmap for Cloud to that of cars, today's Cloud's are like the Model T: showing everyone the potential, but not available to the masses. We should be looking at the equivalent of the next hundred years of evolution in automotive technologies as far as Cloud is concerned, bringing their benefits to the masses (of people and workloads).

This development has to include Private Clouds (which, contrary to what Werner states, don't necessitate corporations having to buy more hardware), but so much more. The true cloud is the collection of processors that exist virtually everywhere you turn, including mobile devices and sensors. That's where the definition of Cloud must go. In many ways it's returning Cloud to one of its progenitors, ubiquitous computing. By that point there won't be a Public, Private or Personal Cloud, there'll be "just" Cloud (or maybe some other term). Where your application is hosted will still remain important, but not because of any artificial reasons due to words such as 'private' or 'public'.

Why JeAS?

I've been saying for a while that the last thing the industry needs is a return the days of vendor lock-in or somehow resetting the clock on the past 40+ years of middleware and rediscovering it all again. That's why I believe we have to leverage what we've got. Yes, it needs to morph and evolve, but we should start using (reusing) existing investments. Furthermore, I believe that if the ideals behind Cloud are to be realised then they must start by tackling existing workloads.

This is why the application server (no formal definition in this article) is the right vehicle for applications. It doesn't matter whether you just consider this to be Tomcat or your favourite application server (JBoss, of course!), whatever is hosting your important applications today and which your developers are comfortable with, that's the basis of your own PaaS requirements. Therefore, that has to be the basis for PaaS wherever you may want to deploy in the future. But even today you often find that your application server may be providing more functionality than you need, at least initially. Just considering Java Enterprise Edition for a moment, that's one of the reasons behind the introduction of profiles (which always reminded me of the Core Services Framework Bluestone/HP pushed back in 2000, driven by my friend and co-author Jon Maron).

So this is where I come from when I mention Just Enough Application Server: when deploying into a PaaS you really need support from your underlying application server to ensure that just enough is deployed and no more. Ideally this should be done automatically as your appliance is generated, but static is OK too. Throw in a bit of autonomous monitoring and management in case things change on the fly (application and object migration is a distinct possibility, so the underlying infrastructure/application server needs to be able to cope), and you've got yourself one super sleek PaaS.

JeAS

First there was JeOS, which makes sense for IaaS. So what's the equivalent for PaaS? Well I reckon it's Just Enough Application Server (JeAS perhaps?) More on this subject soon!

JCP Award Nominations are open

Cross linking to the award notification.

Has Java reached a point of inflection?

I've been wondering about this for a while. As far as languages go, Java has experienced a good run, remaining in the number 1 or 2 spot for the better part of a decade. The language came along as the Web was really growing from its fairly basic roots as it's arguable that Java influenced the development of it more than many languages. It certainly took over from the likes of Pascal and C/C++ in universities and as a result most new software developers have more than a passing knowledge of the language. Of course it's never been a perfect language (I'm not sure such a thing will ever exist, except for very domain-specific languages); it's also never been my favourite language (C++ still holds that position.) However, I think that Java has had an overall positive affect on the industry.

The Java platform (formerly known as J2EE) took a few years to emerge after the first releases of Java (aka Oak) and initially competed with CORBA in the non-Microsoft camp. Once it was clear that J2EE would dominate, CORBA tried to embrace it more closely (the CORBA Component Model, for instance) but was never quite the force it once was. However, J2EE wasn't perfect and a lot of that could be traced to its CORBA roots. It wasn't really until EE5 and EE6 that it managed to escape those shackles, but even despite those problems it dominated the industry. Of course it's precisely because of some of these issues that frameworks such as Spring sprang (!) up, but even then a lot of those deployments ran on J2EE to simplify development.

During its life Sun was a pretty good custodian of the language and the platform. Yes there were issues, particularly when Sun moved from being a neutral party to one that competed in the vendor landscape. But when you think about how one other company in a similar position handled a similar position in the 80's and 90's, things could have been a lot less open. In fact I'm certain that the success of both the language and the platform is due in no small part to this relative openness that Sun managed to juggle, despite their conflicts of interest. Towards the end of their life as an independent company, with the likes of the Apache License issue, it was obvious that Sun couldn't quite make the necessary leap that was/is required to continue the dominance of the language/platform (and you could argue to revitalize it).

And of course that brings us to the present and Oracle. If Java was at a point of inflection prior to their acquisition of Sun, it continues to be there today many months afterwards. Myself and others have argued that this is a good opportunity for Oracle to "do the right thing" and make good on their previous statements in that regard. To continue without such change risks pushing us over that tipping point, with fragmentation, vendor specific options and the end of the world as we know it. (OK, that last point is unlikely to happen!) As I've been saying around Cloud, we really shouldn't be looking at turning back the clock: it won't do anyone, including Oracle, any good.

Now maybe Oracle are considering making some positive announcements at the forthcoming JavaOne. I hope so. Continuing to make Java open and fast moving will benefit everyone, customers and vendors alike. And hopefully Oracle can make the leap that Sun never seemed to be able to make. What's that they say about Nixon and China?

Red Hat/Newcastle University research day

Just back from the first official research day with Newcastle University and it was good. We covered a lot of short and long term research areas, including fault tolerance, scalability, event processing and policy definition/management. It all had a very heavy practical slant to it, which is event better given that we're hoping to see a lot of this come through into various JBoss/Red Hat projects and products eventually. All in all it was a good day and hopefully next time we'll take a couple of days so we can delve into things in much more detail. But for now I've got to go through my notes and start working on getting these R&D efforts underway!

JUDCon Europe 2010

I've mentioned JUDCon before, and it's only been a couple of weeks since we had the very first event in Boston, which went very well. However, no time to relax since it was always our intention to have a couple of these a year and it's surprising how much lead time you need to make it happen. So we've decided on the dates and location for the European event: 7th and 8th of October in Berlin. Next up is figuring out the themes for the tracks and then we'll open up the call for presentations.

Cloud-TM project

We're involved with a new EU Research project called Cloud-TM. Should be some good opportunities for long term research and development, whilst at the same time having strong industrial relevance. I'm looking forward to the kick-off meeting next week in Portugal!

DO'h!!

I've given countless presentations at many different events over the years and usually I'll either be on time or run slightly over time. On a few occasions I've finished early, but never have I finished 20 minutes early thinking that I was over time! I started my first JBoss World presentation this year at 10:20am and got into my stride. I think I got too caught up in what I was saying because at some point I looked down at my watch and noticed it was 10:50am. I obviously forgot what time I'd started because the only thought that ran through my mind was "Oh sh*t, where did the time go, I've only got 10 minutes left!" I managed to get through the remaining 10 slides or so by skipping some (fortunately they'll all be available on the web) and got into Q&A time, still blissfully unaware that I still had 20 minutes remaining. In fact it wasn't until I was walking away that someone pointed it out! So, if you were in that session I definitely apologise for rushing needlessly!

MW4SOC CFP

CALL FOR PAPERS
===============

+--------------------------------------------------------+
| 5th Middleware for Service-Oriented Computing (MW4SOC) |
| Workshop at the ACM/IFIP/USENIX Middleware Conference |
+--------------------------------------------------------+

Nov 29 Dec 3, 2010
Bangalore, India
http://www.dedisys.org/mw4soc10/

This workshop has its own ISBN and will be included in the ACM digital library.

Important Dates
===============
Paper submission: August 1, 2010
Author notification: September 15, 2010
Camera-ready copies: October 1, 2010
Workshop date: November 30, 2010

Call details
============
The initial visionary promise of Service Oriented Computing (SOC) was a world of cooperating services being loosely coupled to flexibly create dynamic business processes and agile applications that may span organisations and heterogeneous computing platforms but can nevertheless adapt quickly and autonomously to changes of requirements or context. Today, the influence of SOC goes far beyond the initial concepts of the original disciplines that spawned it. Many would argue that areas like business process modelling and management, Web2.0-style applications, data as a service, and even cloud computing emerge mainly due to the shift in paradigm towards SOC. Nevertheless, there is still a strong need to merge technology with an understanding of business processes and organizational structures.

While the immediate need of middleware support for SOC is evident, current approaches and solutions still fall short by primarily providing support for only the intra-enterprise aspect of SOC and do not sufficiently address issues such as service discovery, re-use, re-purpose, composition and aggregation support, service management, monitoring, and deployment and maintenance of large-scale heterogeneous infrastructures and applications. Moreover, quality properties (in particular dependability and security) need to be addressed not only by interfacing and communication standards, but also in terms of actual architectures, mechanisms, protocols, and algorithms. Challenges are the administrative heterogeneity, the loose coupling between coarse-grained operations and long-running interactions, high dynamicity, and the required flexibility during run-time. Recently, massive-scale and mobility were added to the challenges for Middleware for SOC.

These considerations also lead to the question to what extent service-orientation at the middleware layer itself is beneficial (or not). Recently emerging "Infrastructure as a Service" and "Platform as a Service" offerings, from providers like Amazon, Google, IBM, Microsoft, or from the open source community, support this trend towards cloud computing which provides corresponding services that can be purchased and consumed over the Internet. However, providing end-to-end properties and addressing cross-cutting concerns like dependability, security, and performance in cross-organizational SOC is a particular challenge and the limits and benefits thereof have still to be investigated.

The workshop consequently welcomes contributions on how specifically service oriented middleware can address the above challenges, to what extent it has to be service oriented by itself, and in particular how quality properties are supported.

Topics of interest
==================
* Architectures and platforms for Middleware for SOC.
* Core Middleware support for deployment, composition, and interaction.
* Integration of SLA (service level agreement) and/or technical policy support through middleware.
* Middleware support for service management, maintenance, monitoring, and control.
* Middleware support for integration of business functions and organizational structures into Service oriented Systems (SOS).
* Evaluation and experience reports of middleware for SOC and service oriented middleware.

Workshop co-chairs
===============
Karl M. Göschka (chair)
Schahram Dustdar
Frank Leymann
Helen Paik

Organizational chair
====================
Lorenz Froihofer, mw4soc@dedisys.org

Program committee
=================
Paul Brebner, NICTA (Australia)
Gianpaolo Cugola, Politecnico di Milano (Italy)
Walid Gaaloul, Institut Telecom (France)
Harald C. Gall, Universität Zürich (Switzerland)
Nikolaos Georgantas, INRIA (France)
Chirine Ghedira, Univ. of Lyon I (France)
Svein Hallsteinsen, SINTEF (Norway)
Yanbo Han, ICT Chinese Academy of Sciences (China)
Valérie Issarny, INRIA (France)
Mehdi Jazayeri, Università della Svizzera Italiana (Switzerland)
Bernd Krämer, University of Hagen (Germany)
Mark Little, JBoss (USA)
Heiko Ludwig, IBM Research (USA)
Hamid Reza Motahari Nezhad, HP Labs (USA)
Nanjangud C. Narendra, IBM Research (India)
Rui Oliveira, Universidade do Minho (Portugal)
Cesare Pautasso, Università della Svizzera Italiana (Switzerland)
Fernando Pedone, Università della Svizzera Italiana (Switzerland)
Jose Pereira, Universidade do Minho (Portugal)
Florian Rosenberg, Vienna University of Technology (Austria)
Giovanni Russello, Create-Net (Italy)
Regis Saint-Paul, CREATE-NET (Italy)
Dietmar Schreiner, Vienna University of Technology (Austria)
Bruno Schulze, National Lab for Scientific Computing (Brazil)
Francois Taiani, Lancaster University (UK)
Aad van Moorsel, University of Newcastle (UK)
Roman Vitenberg, University of Oslo (Norway)
Michael Zapf, Universität Kassel (Germany)
Liming Zhu, NICTA (Australia)

JBossWorld and JUDCon

Off to Boston tomorrow for JBossWorld and JUDCon. The former is always a good event, but it's really the latter that I'm looking forward to the most, since it's the first ever one and it's taken us a while to organize. I'm already working on the European version that'll be coming in a few months time so hope to get some constructive feedback from the people to attend in the coming few days. And for my long flight to Boston I'm having a complete break and finishing reviewing someone's PhD thesis.

Classic paper

I came across this paper in my pile of printed materials from when I was doing my PhD. Great paper at the time and still applicable today. Well worth a read.

One of the best books I've ever read ...

I didn't realise that To Kill A Mockingbird was almost 50 years old! It's definitely one of the best books I read (while a teenager at school) and I go back to it every few years. It surprised me how much I loved the book from the start given that at the time sci fi and fantasy were the mainstays of my library. But from the age of 13 or 14 to the present day it's definitely something that I recall in vivid detail. And of course Gregory Peck makes a great (if not quite old enough) Atticus Finch. If you haven't read it then you should definitely do so!

When did we decide lock-in was good?

Many years ago the number of standards bodies around could be counted on the fingers of one hand. Back then, vendor lock-in was a reality and most of the time a certainty. But our industry matured and customers realised that sometimes being tied to a single vendor wasn't always a good thing. Over the next 20 years or so standards bodies have sprung up to cover almost every aspect of software. It's arguable that we now have too many standards bodies! Plus standards only work when they are based on experience and need: rushing to a standard too early in the cycle can result in something that isn't useful and may inhibit the real standard when it's needed eventually.

But I think, or at least thought, that most people, including developers and end-users, understand why standards are important. The move towards DCE, CORBA and J2EE illustrated this. Yes sometimes these standards weren't necessarily the easiest to use, but good standards should evolve to take this sort of thing into account, e.g., the differences between EE6 and J2EE 1.0 are significant in a number of areas not least of which is usability.

Furthermore a standard needs to be backed by multiple independent vendors and ideally come from an independent standards body (OK Java doesn't fit this last point, but maybe that will change some day.) So it annoys me at times when I hear the term open standard used to refer to something that may be used by many people but still only comes from a single vendor, or perhaps a couple, but certainly doesn't fit any of the generally accepted meanings of the term.

And yes this rant has been triggered by some of the recent announcements around Cloud. Maybe it's simply due to where we are in the hype curve, because I can't believe that developers and users are going to throw away the maturity of thought and process that have been built up over the past few decades concerning standards (interoperability, portability etc.) Or have the wool pulled over their eyes. Of course we need to experiment and do research, but let's not ignore the fact that there are real standards out there that either are applicable today or could be evolved to applicability by a concerted effort by many collaborating vendors and communities. You don't want to deploy your applications into a Cloud only to find that you can't get them back or can't integrate them with a partner or customer who may have chosen a different Cloud offering. That's not a Cloud, that's a prison.

Reading and not understanding

I can't remember when I first read The Innovator's Dilemma, but it was only a few years back when I first read The Tipping Point. Both are good books and compliment each other. However, some interesting conversations over the long weekend here made it clear to me that some people who say they've read them either haven't or have failed to understand them. Now it's one thing when friends fall into this category, but it's a completely different thing when it's business leaders quoting them as gospel to back up dubious choices. No individual's names and no company names, but it turns out it's quite common in our industry. Probably elsewhere too. Maybe there are some texts (books, papers etc.) where you should be forced to pass a test before being allowed to refer to them.

TweetDeck

Many of the folks at the Thinking Digital conference I'm attending are using Macs and running TweetDeck. So while sat here listening to yet another great talk, I decided to install it. Wow! I've been dabbling with twitter for a while but now I can see that others have been tweeting at me and I've not seen them until now. Apologies to everyone to which that applies! Now I may start using twitter more.

My next phone?

Last October I decided to upgrade my phone. At the time the iPhone wasn't available through my provider, so I went with the HTC Hero, running Android. It got good write-ups and I've had an interest in Android for a while. Since getting it I've enjoyed it, but it's not a match for the iPhone. The hardware is too slow, it's not as responsive, the store isn't as good, you can't (couldn't) store apps on the SD card, and there are a few other minor issues.

But I like the phone, so am glad I got it. That is until recently. My phone is running Android 1.5, and over the past 6 months we've seen 2.1 and now 2.2 come out. Now of course I could go and install these on my phone, but the "preferred" route is to get the official release from HTC, which would include their SenseUI, which is a great selling point over other Android phones and the iPhone. Yet to date there is still no official release from HTC for 2.1 and there may never be a 2.2 release for it.

Now I understand that technology can get dated and old things can't always run the new stuff. But just over 6 months after I got it I refuse to believe that my phone is outdated! Maybe this is an HTC specific issue and they really just need to get their act together. But it appears that Google would disagree and that fragmentation is inevitable. If it is then I am concerned for the future of Android.

For now I'll wait to see what comes from HTC. But when my contracts up I will likely move to an iPhone and mark my journey with Android down to experience.

Paul on PaaS

It's been a while since Paul Fremantle and I caught up, but it's good to see that we're still thinking along similar lines on a number of topics. This time it's PaaS and vendor lock-in. In fact there's a growing concern that this is something that may not be obvious to users given the amount of hype that's builing in the atomosphere.

Interesting Cloud announcement

It's another week and we have another announcement around Cloud, this time from Google. Quite interesting but the underlying message is pretty much what I said in an earlier entry: if you want to move to this type of cloud then you'd better be expecting to re-code some or all of your application. Oh joy. Here we go again! Even the tag line of "... write once, deploy anywhere" is a lot of smoke-and-mirrors. "Deploy to any one of four vendor specific Clouds, but don't forget about the lock-in potential there" would be more appropriate.

Come on guys. We really cannot afford to reinvent the world again. So as a prospective user, unless you really aren't interested in leveraging your existing investments in software and people, this looks like another non-starter. Maybe 2 out of 10 for marketing buzz, but 0 for effort.

Duane tells it like it is

I've known Duane "Chaos" Nickull for many years. He's a great guy, a good friend and knows his stuff on a range of technical and not so technical (excellent musician, for instance). His most recent post made me laugh out loud! A good entry to say the least.

Rich Frisbie

I met some really great guys when Bluestone acquired Arjuna Solutions. It was a great culture and family, one with which I'm pleased to have been involved. It's therefore very sad to hear that one of the friends I made during those years, Rich Frisbie, has passed on so suddenly and at such a young age. I wish his family all the best and will have a silent toast to Rich. 'nuff said.

The Chewbacca Defense

I use it all the time when I run into things that just don't make sense. It's a light-hearted way of telling people they need to think more!

Philip K Dick Journals

Very interesting! Though my favourite book of his has to be Now Wait For Last Year.

Plan 9 operating system

While reading about cult movies I was suddenly reminded about the Plan 9 operating system. It came out while we were deep into the original Arjuna development and a heavy user of Sun Sparcs, so naturally it was something we had to investigate (along with the Spring operating system)! It had some interesting ideas, and with distribution at its heart it was very relevant to what we were researching (the University was the home of the Newcastle Connection, with some similar aims from many years before.)

Anyway, it was an interesting time and I'm pleasantly surprised to learn that there's still work going on into Plan 9, twenty something years after it began. Very cool!

Cloudy days ahead for applications?

I've been thinking a lot recently about the Cloud and its potential as a disruptive technology. I got to wondering about how we arrived at where we are today, and one of my favourite books sprang to mind as a way of articulating that, at least to myself.

To misuse HG Wells ever so slightly, "No one would have believed in the last years of the first decade of the twenty first century that the world of enterprise software was being watched keenly and closely by intelligences greater than man's and yet as mortal as his own; that as men busied themselves about their various concerns they were scrutinised and studied, perhaps almost as narrowly as a man with a microscope might scrutinise the transient creatures that swarm and multiply in a drop of water. With infinite complacency men went to and fro over this globe about their little affairs, serene in their assurance of their empire over middleware. It is possible that the infusoria under the microscope do the same. No one gave a thought to some of the relatively new companies as sources of danger to their empires, or thought of them only to dismiss the idea that they could have a significant impact on the way in which applications could be developed and deployed. Yet across the gulf of cyberspace, minds that are to our minds as ours are to those of the beasts that perish, intellects vast and cool and unsympathetic, regarded enterprise applications with envious eyes, and slowly and surely drew their plans against us."

Of course the rise of Cloud practitioners and vendors was in no way as malevolent as the Martians, but the potential impact on the middleware industry may be no less dramatic (or drastic). Plus there was a level of ignorance (arrogance) on behalf of some middleware vendors against the likes of Amazon and Google just as the Victorians believed themselves unassailable and masters of all they surveyed.

But there are still a number of uncertainties around where this new wave is heading. One of them is exactly what does this mean for applications? On the one hand there are those who believe applications and their supporting infrastructure (middleware) must be rewritten from scratch. Then there are others who believe existing applications must be supported. I've said before that I believe as an industry we need to be leveraging what we've been developing for the past few decades. Of course some things need to change and evolve, but if you look at what most people who are using or considering using Cloud expect, it's to be able to take their existing investments and Cloudify them.

This shouldn't come as a surprise. If you look at what happened with the CORBA-to-J2EE transition, or the original reason for the development of Web Services, or even how a lot of the Web works, they're all examples of reusing existing investments to one degree or another. Of course over the years the new (e.g., J2EE) morphed away from the old, presenting other ways in which to develop applications to take advantage of the new and different capabilities those platforms offered. And that will happen with Cloud too, as it evolves over the next few years. But initially, if we're to believe that there are economic benefits to using the Cloud, then they have to support existing applications (of which there are countless), frameworks (of which there are many) and skill sets of the individuals who architect them, implement them and manage them (countless again). It's outsourcing after all.

SOA metrics post

I wrote this a while ago and someone forgot to let me know it had finally been published. Better late than never I suppose.

A Platform of Services

Back in the 70's and 80's, when multi-threaded processes and languages were still very much on the research agenda, distributed systems were developed based on a services architecture, with services as the logical unit of deployment, replication and fault containment. If you wanted to service multiple clients concurrently then you'd typically fire off one server instance per client. Of course your servers could share information between themselves if necessary to give the impression of a single instance, using sockets, shared memory, disk etc.

Now although those architectures were almost always forced on us by limitations in the operating systems, languages and hardware at the time, it also made a lot of sense to have the server as the unit of deployment, particularly from the perspectives of security and fault tolerance. So even when operating systems and languages started to support multi-threading, and we started to look at standardising distributed systems with ANSA, DCE and CORBA, the service remained a core part of the architecture. For example, CORBA has the concept of Core Services, such as persistence, transactions, security and although the architecture allows them to be colocated in the same process as each other or the application for performance reasons, many implementations continued to support them as individual services/processes.

Yes there are trade-offs to be made between, say, performance and fault tolerance. Tolerating the crash of a thread within a multi-threaded process is often far more difficult than tolerating the crash of an individual process. In fact a rogue thread could bring down other threads or prevent them from making forward progress, preventing the process (server) from continuing to act on behalf of multiple clients. However, invoking services as local instances (e.g., objects) in the same process is a lot quicker than if you have to resort to message passing, whether or not based on RPC.

However, over the past decade or so as threading became a standard part of programming languages and processor performance increased more rapidly than network speeds, many distributed systems implementations moved to colocating services as the default, with the distributed aspect really only applying to the interactions between the business client and the business service. In some cases this was the only way in which the implementation worked, i.e., putting core infrastructure services in separate processes and optionally on different machines was simply no longer an option.

Of course the trade-offs I mentioned kicked in and were made for you (enforced on you) by the designers, often resulting in monolithic implementations. With the coining of the SOA term and the rediscovery of services and loose coupling, many started to see services as beneficial to an architect despite any initial issues with performance. As I've said before, SOA implementations based on CORBA have existed for many years, although of course you need more than just services to have SOA.

Some distributed systems implementations that embraced SOA started to move back to a service-oriented architecture internally too. Others were headed in that direction anyway. Still others stayed where they were in their colocated, monolithic worlds. And then came Cloud. I'm hoping that as an industry we can leverage most of what we've been implementing over the past few decades, but what architecture is most conducive to being able to take advantage of the benefits Cloud may bring? I don't think we're quite there yet to be able to answer that question in its entirety, but I do believe that it will be based on an architecture that utilises services. So if we're discussing frameworks for developing and deploying applications to the cloud we need to be thinking that those core capabilities needed by the application (transactions, security, naming etc.) will be remote, i.e., services, and they may even be located on completely different cloud infrastructures.

Now this may be obvious to some, particularly given discussions around PaaS and SaaS, but I'm not so sure everyone agrees, given what I've seen, heard and read over the past months. What I'm particularly after is a services architecture that CORBA espoused but which many people overlooked or didn't realise was possible, particularly if they spoke with the large CORBA vendors at the time: an architecture where the services could be from heterogeneous vendors as well as being based on different implementation languages. This is something that will be critical for the cloud, as vendors and providers come and go, and applications need to choose the right service implementation dynamically. The monolithic approach won't work here, particularly if those services may need to reside on completely different cloud infrastructures (cf CORBA ORB). I'm hoping we don't need to spend a few years trying to shoehorn monoliths in to this only to have that Eureka moment!

The lack of standards in the area will likely impact interoperability and portability in the short term, but once standards do evolve those issues should be alleviated somewhat. The increasing use of REST should help immediately too though.

Some things really shouldn't be changed

There are some things that shouldn't change, no matter how good an idea it may seem at first glance. For instance, the original Coke formula, the name of Coco Pops, and remaking the Searchers. Then again there are some things that really do benefit from a revision, such as Battlestar Galactica or the laws of gravity.

So it was with some trepidation that I heard they were going to remake The Prisoner. The original is a classic of 1960's TV that stood the test of time. I remember watching it at every opportunity while growing up (in the days when we only had 4 TV channels, so repeats were few and far between). Patrick McGoohan was The Prisoner and while the stories were often "out there", the series had this pulling power that made it unmissable.

I wondered how anyone could remake it and capture the essence of the original show? But I decided to be open minded and sat down the other night to watch the first episode of the new series. Afterwards the first thought I had was "I'll never get that hour back again!" As a remake, it was terrible. As a stand-alone series, it was probably passable.

It looks like another good idea bites the dust. I'll be taking the series off my Sky+ reminder now and if I'm stuck for something to do at that time I'll either watch some wood warp or maybe watch some paint dry: both would be far more stimulating activities!

Volcano activity spoils conference

I was an invited speaker as the first DoD sponsored SOA Symposium last year and really enjoyed it. I got invited to this year's event and was going to speak on SOA and REST. I think it would have been as good as last year (will be as good as last year), but unfortunately a certain volcano in Iceland has meant that my flights have been canceled. So I'll have to watch from afar and hope that the troubles in the sky clear up soon. My best wishes go to the event organizers and I hope that next year presents an opportunity to attend for a second time.

A sad day

I just heard that Robin Milner has died. I met him a couple of times and found him approachable, very articulate and friendly. A great loss. My sympathies to his family.

Meetings and work

Irresective of whatever title(s) I may have, I'm a software engineer. For well over 30 years I've been cutting code; whether it's games (my very first program was battleships on a paper-tape machine) or transaction systems, I get a lot of enjoyment out of it. I also love learning new programming languages (something that strangely enough doesn't translate to human languages, where I'm not so strong.) I don't think I'm happier than when I'm coding.

Now over the years I've spent a lot of time in various meetings, including standards efforts, project planning, customer engagements, architecture discussions etc. Some of them are also implicit, e.g., Stuart and I would talk a lot, often while coding, because we shared an office for over a decade. But most of them are explicit and you don't get a chance to code at the same time (paying customers tend to want your full attention, for instance!) I've been at a project planning meeting today in Brussels and although I could code on the evenings while in the hotel, it's not a lot of time to spend.

In general the majority of my days revolve around talking and writing documents. Most days I'll spend in meetings, either physically in a room with others or on a phone with them. Time for coding is limited during the day, so again it tends to happen late evenings, very early in the morning, weekends and on holiday. At times I believe I need to do it to keep myself grounded (and sane). And it doesn't have to be work coding that lets me energize my batteries (I think all engineers have their pet projects!)

When I was coding full-time it was easy for me to look back and see what I'd been doing with my time. These days it's not quite so easy as there is often no concrete evidence of what's been done on a daily basis. Of course that's a very short sighted view and when I look across the months/years and see the results those meetings generated it's very different. But for an engineer who has been coding for 75% of his life, it's hard at times when I'm sat in yet another meeting with a terminal, emacs and a programming language calling to me from a few inches away. Yes, meetings are important for what I have to do today, but my heart will always be elsewhere. Now back to some coding!

Dr Professor or Professor Dr?

Since I officially left The University I've been a Research Fellow (I was in my late 20's when the photo was taken), along with Stuart. The role involves a range of things such as being on PhD thesis committees, helping with research, co-authoring papers etc. It's something from which I've received a lot of enjoyment and satisfaction, and I think it's an important counterpoint to my normal day job.

It's a position that I think is a privilege. So you can imagine how I felt today when they made me a Professor! Despite the number of years I spent at The University it's a position I never thought I'd achieve, particularly after I left to pursue a career path through the likes of Arjuna (x2), Bluestone, HP, JBoss and Red Hat. I definitely need to thank Santosh, who over the past 20+ years has been my boss, colleague and friend. He's also epitomised for me what it means to be a Professor, something which I think has positively impacted who I am to this day.

QCon London slides on line

I just got confirmation that the QCon slides are on line now, with mine available at this location.

Every Cloud has a silver lining

I've already stated that I think there's a lot Cloud can learn from the past and yet there is also more evolution of current approaches to come where Cloud is concerned. However, that doesn't mean that adding a little bit of Cloud pixie dust to everything immediately makes it better or more relevant.

I'm one of the reviewers for a special journal issue on Engineering Middleware for Service-Oriented Computing. Unfortunately several of the papers I've read seemed to be under the assumption that adding the words/terms 'Cloud' or 'SOA' to their works would make them relevant, when in fact it had almost the opposite effect. It didn't work with other technological waves such as Web Services or Java. If your work is relevant to a specific technology or a range of technologies then it should be obvious from the start and attempts to artificially push the reader into joining mental dots or making "intuitive leaps" reflect poorly on the author.

QCon London 2010 update

I mentioned earlier that I was presenting at QCon London. Well I had a good time at QCon giving a presentation which was basically about lessons learnt while developing, using and selling transaction systems. Hopefully the slides will go up soon, but it seemed to go down well. According to the organizers, it has the second highest audience for the track, which given that people were sitting on the floor, didn't surprise me. Everyone seemed to enjoy the talk and I hope they got as much out of it as I got putting it together.

What I did realise as I was giving the session was that I really have enough material for 4 or 5 presentations. Therefore, I may do some deep dives into specific aspects of the current presentation. I may even realise these as blog entries as well.

QCon London 2010

I'm going to QCon London again and speaking about one of my favourite subjects. If you're around then come by and say hello. Which reminds me ... I need to write the presentation!

Red Hat and Newcastle University

It's taken a while to get all of the pieces of the puzzle together, but we've now got a formal relationship with the University. As one of my friends would say: Onward!

JUDCon

We've been working on this for a while. I'm really pleased with the way it's starting to shape up.

Cloud as the death of middleware?

Over the last few months I've been hearing and reading people suggesting that the Cloud ([fill in your own definition]) is either the death of middleware, or the death of "traditional" middleware. What this tells me is that those individuals don't understand the concepts behind middleware ("traditional" or not). In some ways that's not too hard to understand given the relatively loose way in which we use the term 'middleware'. Often within the industry middleware is something we all understand when we're talking about it, but it's not something that we tend to be able to identify clearly: what one person considers application may be another's middleware component. In my world, middleware is basically anything that exists above the operating system and below the application (I think the fact that these days we tend to ignore the old ISO 7 Layer stack is a real shame because that can only help such a definition.)

But anyway, middleware has existed in one form or another for decades. There are obvious examples of "it" including DCE, CORBA, JEE and .NET, but then some other not so obvious ones such as the Web: yes, the WWW is a middleware system, including most of the usual suspects such as naming, addressing, security, message passing etc. And yes, over the past few years I've heard people suggest that the Web is also the death of middleware. For the same reasons that Cloud isn't its deathknell, neither was the Web: middleware is ubiquitous and all but the most basic applications need "it", where "it" can be a complete middleware infrastructure such as JEE or just some sub-components, such as security or transactions. Now this doesn't mean that what consitutes middleware for the Cloud is exactly what we've all been using over the past few years. That would be as crazy a suggestion as assuming CORBA was the ultimate evolution of middleware or that Web Services architecture would replace JEE or .NET (something which some people once believed). Middleware today is an evolution of middleware from the 1960's and I'm sure it will continue to evolve as the areas to which we apply it change and evolve. I think it is also inevitable that Cloud will evolve, as we decide precisely what it is that we want it to do (as well as what 'it' is) based upon both positive and negative experiences of what's out there currently. (That's why we have the Web today, after all.)

Implementations such as Google App Engine are interesting toys at the moment, offering the ability to deploy relatively simple applications that may be based on cut-down APIs with which people are familiar in a non-Cloud environment. But I'm fairly sure that if you consider what consistutes middleware for the vast majority of applications, the offerings today are inadequate. Now maybe the aim is for people who require services such as security, transactions, etc. to reimplement them in such a way that they can be deployed on-demand to the types of Cloud infrastructures around today. If that is the case then it does seem to solve the problem (bare minimum capabilities available initially) but I take issue with that approach too: as an industry we simply cannot afford to revisit the (almost) NIH syndromes that have scarred the evolution of middleware and software engineering in general over the past 4 decades. For instance, when Java came on the scene there was a rush to reimplement security, messaging, transactions etc. in this new, cool language. The industry and its users spent many years revisiting concepts, capabilities, services etc. that existed elsewhere and often had done so reliably and efficiently for decades, just so we could add the "Java" badge to them. OK, some things really did need reimplementing and rethinking (recall what I said about evolution), but certainly not as much as was reworked. This is just one example though: if you look back at DCE, CORBA, COM/DCOM, .NET etc. you'll see it has happened before in a very Battlestar Galactica-like situation.

Therefore, if we have to reimplement all of the core capabilities that have been developed over the years (even just this century) then we are missing the point and it really will take us another decade to get to where we need to be. However, don't read into this that I believe that current middleware solutions are perfect today either for Cloud applications or non-Cloud applications. We've made mistakes. But we've also gotten more things right than wrong. Plus if you look at any enterprise middleware stack, whether from the 21st or 20th centuries, you'll see many core capabilities or services are common throughout. Cloud does not change that. In my book it's about building on what we've done so far, making it "Cloud aware" (whatever that turns out to mean), and leveraging existing infrastructural investments both in terms of hardware and software (and maybe even peopleware).

Of course there'll be new things that we'll need to add to the infrastructure for supporting Cloud applications, just as JEE doesn't match CORBA exactly, or CORBA doesn't match DCE etc. There may be new frameworks and languages involved too. But this new Cloud wave (hmmm, mixing metaphors there I think) needs to build on what we've learned and developed rather than being an excuse to reimplement or remake the software world in "our" own image. That would be far too costly in time and effort, and I have yet to be convinced that it would result in anything substantially better than the alternative approach. If I were to try to sum up what I'm saying here it would be: Evolution Rather Than Revolution!

Code coverage

This may sound strange, but one of the things I really liked doing back when we were starting Arjuna, which was written in C++, was writing the code coverage tests using Pure Coverage (in fact we had all of the Purify suite back in those days.) I found it fun to do, trying to come up with tests that covered as much of the code as possible and there were times when I could get so immersed in writing tests, compiling, checking the coverage and cycling through again, that I'd forget my PhD work!

So it was with some excitement (yes, I know, it's sad!) that I discovered that the JBossTS team had configured in Emma to the builds. So guess what I did this past weekend? Yes, before I knew it the weekend was over and I'd added a few more tests to the build. Sweet!

Don Box interview

A pretty interesting interview with Don Box. Worth watching all the way through.

Cosmos revisited

I'm sure everyone has their own list of TV programs, books, films etc. that influenced them when growing up. One of mine was Carl Sagan's Cosmos and I was 14 when it was first shown. That's a pretty influential age for any child, but especially one whose head was already in all things science (fiction and fact). My memories of that time often have a Cosmos link, whether it's walking along the beach contemplating that they are more stars in the universe than grains of sand on all of the beaches in the world or where we would be if Library of Alexandria hadn't been destroyed.

I can trace many of the things I did in my career back to Cosmos, including taking astrophysics at University and continuing to consider myself a scientist no matter what I do. However, apart from the first ever screeing of the program and maybe a repeat early on, I haven't seen it for well over twenty years. I've got the book and pretty much every other book he wrote, but I always longed to see the program again. So when it became available on DVD I snapped it up, and recently began to watch it again. Well time certainly hasn't diminished it's power and relevance; I'm finding it just as compelling a watch as I did almost thirty years ago. If you haven't seen it before, or it's been many years since you did watch it, I can thoroughly recommend another viewing: you won't be disappointed and maybe it'll instill a sense of wonder at the universe in to you, as it did (and does) with me.

Sad

If I get time I may blog on my own experiences with Sun over the years, but for now I found this kind of sad. Farewell Sun.

Congratulations Andrew

Congratulations to Andrew for his OBE! It's been a while since I've caught up with him, but apart from being a critical part of Ansa when we were starting on Arjuna, more importantly he was also the external examiner for my PhD thesis! We did some work with him when he started Digitivity and during his stint at Citrix, and it's always been stimulating to talk with him about this or that, even if the topics aren't work related. Congratulations again Andrew. Now maybe I should nominate Santosh for next year.

A quick look back over 10 years

It's been an interesting decade as far as I'm concerned. Going from co-creating Arjuna Solutions through the Bluestone acquisition and the Bluestone-Arjuna Labs, then the HP acquisition and the HP-Arjuna Labs, spinning out and co-creating Arjuna Technologies, then the move to JBoss, followed by the Red Hat acquisition, a lot of work around SOA (which dates back to at least JBoss) and finally my new role with the departure of Sacha.

Very busy and despite a few ups and downs, very interesting and a lot of fun. It's not a period where I'd change anything professionally. However, I hope the next decade has somewhat less company movement than the previous! But I'm sure the interest and fun will continue.

Where does the time go?

There are only a few days left in 2009 and that means just a few more until I'm officially back to work. Although I have managed to find time (make time?) to work on a few things, as usual there hasn't been as much time as I'd expected (hoped?) Family life and seasonal activities impacting (as they should?) But it's better to have a longer list of things to do and not get to them than sit twiddling my thumbs watching TV.

Over the next few days I expect to finish off some more work related things but it's quite possible that drink and merriment will have to take priority: after all, once I'm officially back to work they won't get much chance for the next 12 months!

It's spooky when people know you too well

It's Christmas day and we've had family and friends come from across the country. Lots of good times and good food. But the spooky thing for me was when I started to unwrap gifts from people who hadn't coordinated their giving and yet they had a common theme: Star Trek. I've mentioned before that I'm a fan, but it's not something that comes up day-to-day. So it was all a complete surprise, particularly when the gifts came from so many different and disconnected individuals. My inner child is happy today. Merry Christmas!

JBoss in the Cloud

It's nice to see Bob, Marek, Mic and the team release StormGrind. There's a lot of interesting things going on in the Cloud and how open source in particular can influence it. Fortunately we've got some of the best people to help us keep pushing ahead with defining the Cloud. I think 2010 is definitely going to be a good year for JBoss and the Cloud.

Dan O'Bannon

I can't believe I missed the news of the death of Dan O'Bannon! It's sad to see it hidden away in the corner of the news, given how influential he was. I suppose the first time I ran into his sphere of influence was Dark Star: if you've never seen the film then I definitely recommend it. Not many films can say they managed to combine an orange beachball-alien and a surfing astronaut so well! Of course Alien was more successful and probably more influential, but I think I'll always associate him more with Dark Star. It's a sad day, but I'm sure that wherever he is now he'll be teaching them about phenomenology.

Christmas is coming and ...

... I'm on vacation until January, but the next few days will be tying up some loose ends from work, catching up on a few things (work related) that I haven't had a chance to get to recently and then the rest of the holidays are mine ... all mine!! So I plan to get back to some pet projects that have been languishing for the past few months, finish some reading and maybe, just maybe, finish a paper I've been working on for a while.

JBossWorld 2010

The Call For Papers has been announced. So if you're interested in presenting or just meeting up with JBoss engineers or users, get submitting! It's a great event to attend. Now I've just got to make sure I can present something technical again next year as I did this year: Keynotes are good, but I love the feedback you get from presenting papers, work in progress etc.

One of the first Web sites

While talking with some of my friends from Arjuna today, Stuart reminded me that we started playing with the Web in 1991/1992, when we created a Web site with one of the first releases of the CERN HTTP code for the original Arjuna Project. As Stuart recalled, it was so early in the evolution of the Web that one of the original CERN pages which maintained a list of available Web servers around the world (I suppose you could say a precursor to Google in that regard) had our site on the very first page for a long time. It's a shame the Internet Archive does not go back that far.

I know we often hear people ask "Where were you when Kennedy was shot?" or "Where were you when the Wall came down?", but I suppose in our industry a similar question would be "Where were you when the Web was started?" Well for me I was in the office I shared with Stuart, working on my PhD and playing with HTTP and HTML. Sometimes I'm surprised we got any real work done :-) !

VSS Enterprise

Something to dream about!

RESTful transactions round two

I've been working on a second draft of the RESTful transactions work that I've mentioned before. This time I'm doing it for Bill and his REST-* effort. I revised the original for JavaOne but didn't get a chance to use it in our presentation. So I'm taking this opportunity to apply some standards boiler-plate and bring it up to date. Plus it's always good to revisit something you did almost a decade ago and use the benefit of those intervening years and the experience gained.

Enterprise OSGi: two is obviously better than one

I think OSGi is important for several reasons. I think Enterprise OSGi is an interesting approach, particularly as it leverages JEE. I've even contributed to some of the work, for example around the transactions component. JBoss is doing a lot of implementation work around OSGi too.

I have to admit that I haven't been paying close attention to OSGi for a few months. However, I had heard about the new Apache Aries project. Unfortunately I just heard from a friend about the Eclipse Gemini project. Now I've been involved with standards long enough to have experienced first hand the political games that rivals play with each other. It's unfortunate because it rarely benefits users, tending to obscure the reasons for choosing one approach over another, confuse people, and ultimately delaying the uptake of the standard or technology involved.

Maybe I'm missing the underlying reasons why Oracle and SpringSource decided that Aries wasn't the right project for them. However, I really wish that as an industry driven primarily by technologists we could leave the politics behind and try to work far more collaboratively, and particularly where open source is concerned! As a slight aside, that's one of the things I really like about HPTS: it doesn't matter which company you're from, people talk and interact freely to try to better our collective understanding of problems and lessons learnt.

Update: I should point out that in the paragraph above I wasn't siding with Aries over Gemini, simply that Aries started first.

The future of Java

For one reason or another I've been thinking about the future of Java for a while; more the language than the platform (JEE). I think that the JEE platform will continue to evolve over the coming years, more likely into a series of specific vertical solutions. But this entry isn't about the platform, it's about the language.

Although I've been using Java since it was known as Oak and have written a fair amount with it (for example, I wrote the first ever Java transaction implementation over Christimas 1996), it's never been my favourite programming language. There are some things that I liked about the language from the start, such as threading, but others, such as garbage collection (yes, I like the control of a good delete) and lack of multiple inheritance, that I didn't. The Java language has certainly evolved over the past decade, mostly for the better (garbage collection is a lot better now and we have templates), but in general the language still takes a lowest common denominator approach. And it has got rather bloated.

Ignoring several assembly languages, over the years I've learnt many high level languages including Pascal, Mesa, Smalltalk-80, Lisp, Prolog, C/C++, Simula, D, Forth and of course Java. My favourite is still C++ though. Yes I know it has its flaws and yes I know it's not the most forgiving of languages. I can't quite put my finger on precisely why I still prefer C++. I remember when we were testing the first pre-releases of Cfront for AT&T back in the mid 1980's and wondering along with Graeme and Stuart as to whether we could port it to our Atari's using Metacomco C. I seem to recall us making some progress, but Linux came on the scene bringing with it gcc. But none of this explains why I prefer C++. Maybe it's the level of direct control it gives you (as with C). Or maybe it's something else. Whatever, I'm sure it's all subjective.

Anyway, I digress. Where does this leave Java? Well I think if you look back over the past 40+ years of high level programming languages one thing is very obvious: change happens. Our ability to reason about complex algorithms and the best way of putting them into code evolves, whether it's declarative, procedural, object-oriented or something else. I think it's fairly clear that Java's dominance in the industry will wane. Yes it'll be legacy for many years to come; the 21st Century COBOL, so it will continue to be important. But something new is coming. Maybe not today and maybe not tomorrow. But it's coming nonetheless.

ArchiteCloud 2010

I have the pleasure of bring on the ArchiteCloud 2010 program committee. If you've any papers hiding in your "to do" lists then get them in, as this promises to be a great event! Maybe I can use this as an excuse to visit Australia next year too!