Home

Having given SOAP a REST along comes MEST

REST has rapidly been displacing SOAP as the pragmatic choice for accessing and interacting with resources over HTTP.

The SOAP protocol is too unwieldy and cumbersome for all but the most heavily engineered situations. (The S in SOAP was originally supposed to stand for simple, but was changed to service as it was considered to be misleading).

So just as we are all getting used to using REST to implement web-services along comes a new acronym MEST.

MEST stands for MESsage Transfer or Message Exchange State Transferand is to service oriented architectures what REST is to resource oriented architectures. REST enables you to interact with the objects and properties that make up resources, while MEST enables you to send messages and invoke services. The people behind the MEST do not make any more claims for it than this, it's a message to a service in the same way that that a REST operation is just access to and manipulation of a resource.

I don't think it's rocket science, and most of us have probably been doing this kind of thing all along, but sometimes it's useful to attach a label just because it makes it easier to talk about and explain.

Software Systems Compared to Cities

[Earlier versions of this essay have previously appeared online.]

Why should a system that is working well need to be replaced? Successful software systems are like cities. There are cities in Europe that have been continuously inhabited for thousands of years. London or Rome today would be unrecognizable to Julius Caesar, yet the old cities were never abandoned and replaced - they were just continuously re-developed over the centuries. Although we like to discuss replacing major software systems because their quirks annoy us, perhaps we should think of these as limitations that must be lived with, just as in these days of the automobile, we still deal with streets in Boston that were engineered for horses and wagons, but we have no intention of razing and rebuilding downtown.

The prospect of "big-bang" conversions of large mission critical software systems gives CIOs ulcers just the way that the prospect of razing and rebuilding downtowns gives city fathers ulcers. [The exceptions are when cities are destroyed by war or natural disasters.]

In the not too distant future, a school of thought will likely develop to the effect that large software systems will not only not be replaced, but also that we should not plan to replace them. Just as we may tear down buildings and build highways, perhaps we should not think in terms of replacing large software systems, but in terms of a process of continuous modernization and renewal (with the software equivalent of urban decay resulting if money is not spent on upkeep when it is needed).

Instead of asking what the life expectancy is of a mission critical software system, perhaps the first lesson is that it is more meaningful to ask what it takes to keep it healthy and contemporary on an ongoing basis.

Cities evolve. With a few notable exceptions of seats of Government, cities are not greenfield creations. They start small, and grow, and what they are good at changes over time.

So the second lesson for software is probably that mega projects that try to do everything are almost certainly doomed from the start. The history of large software projects is not encouraging, and the growing popularity of agile methods speaks to the higher success rate of evolving software in a series of many small steps versus giant seven-league strides.

Rome was not built in a day.

A third lesson from the analogy is that, since large applications evolve, they will always have aspects that are obsolete and awkward. If we love them, we must love them warts and all.

So, while this brave new always-on networked world does not obsolete our software systems, it does give them an opportunity to evolve or stagnate into obsolescence.

Do not panic

So, there's been another outbreak of Foot and Mouth disease, this time near Egham. Fortunately, our venue, Brooklands, is just outside the current 3 km protection zone. Egham is actually about 10 km away but it seems that, as a precaution, the zone has been extended eastwards to cover the area between Egham and Woking.

There's no need to panic. Brooklands is a very urban area, there are no farms or livestock nearby so I don't imaging there will be any disruption to transport or access.

Obviously, if you live on a farm or are coming from a rural area then you may want to take this into consideration and take appropriate precautions.

The official DEFRA site which provides maps and details of the current status is here.

Abstracts

Abstracts for all the presentations are now available for viewing here.

There's a really interesting range of topics. At one end we have commentary on what kind of technologies you'll be needing to develop the application solutions of the future (George and Rob), while at the other end there are some quite meaty technical presentations about tools and techniques that you can use today (Bhaskar, John and Pasi).

There are several presentations that have a health care flavour (Jon, Pasi, Adrian and Chris), covering integration solutions, national IT initiatives, and views from both a practicing GP and the Royal Marsden Hospital.

There's several talks that have an open source angle. Adrian will be talking about how Open Source might be a better solution for health care IT than monolithic national programmes. Bhaskar will be talking about GT.M which has a GPL version and George looking at the emergence of Open Data.

Inevitably web-technologies are covered in one-way or another by many of the talks with both Rob and George looking at how to get data into and out of the Internet. While Pasi and Bhaskar will be looking at web standards from either end of the process.

Integration is an important subject these days with John, George and Pasi all covering different aspects of what is needed to provide web-services, protocols and solutions that can help disparate systems work together in unison.

Finally, there's a good International showing with Bhaskar representing Pennsylvania and bringing a US perspective, Jon discussing experiences with Nictiz the Dutch National ICT Institute for Healthcare, and Pasi talking about the low budget approach taken by the Finnish eHealth programme.

Combining these presentations together with the common underlying theme of the technology we all use in our day-to-day work has created a nicely rounded programme that will have plenty of interest for everyone. The synergy of each of the different perspectives will generate a lot of good ideas and should stimulate some healthy discussion in the networking parts of the conference. I'm really excited by the content and can't wait...

Syndicate content