Paul Freemantle: A new kind of (SOA) Registry

Forgive the misleading title; Paul isn't actually a new kind of SOA registry. But he does know a bit about them, it would seem. Especially the bad bits. Paul is proposing a REST-based registry implementation which completely sidesteps UDDI and friends. Paul's main accusation of the SOA Registry and Repository market is that it's very biassed towards commercial software, which is absolutely true. While I'm not convinced that this is UDDI's fault per-se, I do think there are plenty of things wrong with UDDI anyway, so am more than happy to see some alternatives on the scheme. What I love about the approach Paul's describing is its simplicity. Every other registry product I've looked at before (which isn't many, to be fair) has been almost defined by its complexity. Many even feel like they use it as a selling point. What Paul's describing does away with all that, relying instead on simple foundations (REST and ATOM), and then allowing the complexity to be built outside of the registry, just like in the blogging world. One to watch, I think. I'm off to download the code.

After Service_1.0: The Service Interface Version Adapter Pattern

Stellan recently wrote an excellent article about dealing with the versioning of service interfaces. I thought I'd chip in with a slick way of dealing with the versioning of the service implementations themselves. To summarise his approach, Stellan talked about including versioning information in the namespace of your service interfaces, which as he says:

• Means that clients already using the interface won't 'break' the service interface.
• Allows service implementations (and clients, potentially) to dynamically determine the service version based on a message.

One further advantage that Stellan doesn't directly allude to is the co-existence of multiple versions of the same interface in the same runtime environment, which can be exceedingly useful, as I'm about to explain. Stellan explains in his article that the namespaced interfaces can be used on the server to route the message to either the latest and greatest or original versions of the service. Unfortunately, the side effect of that is that you have to keep maintaining two versions of the service, which is made even worse when you have some kind of underlying data store which has to be shared by both versions, because any structural change to that database will require you to modify the data access layer of every version of the service you currently have deployed. A little while ago, I came up with what I think is a nifty solution to this issue, which I called the Service Interface Version Adapter pattern. The pattern allows you to maintain total backward compatibility with clients, while only keeping one version of the service live. I'm sure I'm not the only one to arrive at the same answer, but I've never seen it documented anywhere. Basically, the pattern makes the assumption that version N+1 of your service is backward compatible from a functional point of view with version N. The interface can have changed beyond all recognition, providing it still possible to achieve the same result. Instead of keeping the old version of the service around, we introduce a transformation between the old version of the service and the new. If the transformation is simple, it could be implemented as an XSLT stylesheet, for more complex cases, bespoke Java/.NET/Python might be required, but it's complexity will be far simpler than the original service in the vast majority of cases. What's more, since there's now only one implementation of the service, clients calling the old version of the service will automatically benefit from bug fixes with no extra effort. Okay, so we now have one service implementation, but two working interfaces. What happens when we need to release version N+2? Easy: We add another interface version adapter which converts between version N+1 and version N+2. We could have achieved the same result by modifying the original transform to target version N+2, and introducing a new one between N+1, but if we had done that, we'd have to maintain an ever increasing list of transformations - back to square one. By just adding one new transform, the effort for each new version is the same: one new transformation. Clients of version N and version N+1 can continue to benefit from bug fixes, no matter how long they take to upgrade. Obviously, it'd be right to consider the performance implications of this. In reality however, most of the transformations involved will be so simple (add a default value here, move an attribute there) that even an XSLT based implementation will be fast (as long as you don't use DOM based transforms), so unless you're supporting 100s of versions, I don't believe it'll be a problem, and consider the alternative: 100s of fully fledged service implementations to maintain. If you're really worried about performance, and your budget can stretch to it, you could even consider implementing the whole pattern using an XML appliance like the 1U IBM DataPower which will do most of the heavy lifting in hardware. I have it on good authority that they are faster than an a flock of exceptionally fast things.

SOA Rules of Engagement

Many organisations struggle to get their SOA off the ground. The reasons vary, but mostly stem from getting the very simple things wrong at the start. The following are my 8 simple rules for a successful SOA implementation:

• Don't forget the constructive tension. For SOA to be a success, there needs to be a tension between the desire to do things now, and the desire to do things right. This means setting up a governance function to complement (note: complement, not obstruct) your delivery function.
• Don't forget to deliver something useful early. SOA business cases are notoriously hard, because many (not all) of the benefits arrive in the longer term, and will only be realised if other projects behave as expected. By far the best way to get on in this world is to deliver some business benefit early. Your sponsors will thank you, and it's not as hard as you think - SOAs are all about managing change afterall, so you can do a lot just by delivering a sequence of relatively small incremental projects.
• Don't boil the ocean, the fish won't like it. Many many SOA projects try and 'SOA-enable' huge swaithes of their technical architecture in one foul swoop. It's a well established near-fact that it's difficult or impossible to achieve. I've only worked on one project where this worked, and that was because it was a spin-off from a large company, and so had only a small amount of 'heritage' (nee legacy) systems to contend with - most of the services were built from the ground up.
• Don't worry about the technology. Technology is usually far from the biggest risk to a large SOA programme. Weak benefits cases, poor governance, poor expectation management or a changing political/economic environment are far more likely to be your downfall.
• Do worry about the technology. Having said that technology is not the biggest risk, it is a significant risk. Keep it simple. Implement just the functionality and infrastructure you need in the first instance. Don't believe people or companies that tell you that SOA is a product, or is simply a technical problem that they can solve for you.
• Do get strong project management, but keep them in their box. As I've alluded to above, there are tons of risks waiting to consign your SOA aspirations to the great ESB Gateway in the Sky, so you'll need an excellent project manager to manage them for you. By excellent, I don't mean they're a dictator, I mean they're an enabler for your team, and a black belt in motivation, reporting, and risk management. Whatever you do: If they're running the delivery of a project, do not allow them to become responsible for your organisation's SOA governance. There be dragons.
• Do get an all star cast (at least initially). The nature of SOA is such that there is a lot of opportunity for working smarter rather than harder, which will get you to market faster, make your SOA easier to maintain, and cost you less. Get yourself a team of technical people who really know their bananas; quality is vastly more important than quantity. Seriously consider going outside your organisation to secure at least part of your core team - the people in the next room might be brilliant, but experience is everything in the SOA world. Architects, business/system analysts, developers and testers are all important, and you'll need them to work in perfect harmony for your SOA to really take off.
• Do make sure you're involved. It might be tempting at times to bury your head in the sand, and allow someone else to 'do SOA to you', but don't let this happen. While it's important to get that all star cast, it's also critical that your organisation learns from any 'outsiders', and will be capable of taking the reigns in the long term. That said, do consider keeping outsiders in the mix for the long haul - the world is changing rapidly, and keeping people who've seen other organisations make mistakes close to you will enable you to dodge the pitfalls that consume your competitors.

Comments and your rules, as ever, welcome.

IBM WebSphere Process Server and Apache Tuscany: Not in love. Yet.

I've just spotted a post on Bobby Wolfe's blog discussing the relationship between Apache Tuscany and WebSphere Process Server. He has confirmed that WPS will not be based on the Tuscany runtime.

I've been using Process Server since before it went GA way back in late 2005, and at the time, Tuscany was more embryo than fully fledged citizen of the SOA world. It drew my attention even then, because WPS - despite being a brand new product - was flying the SCA flag without actually being capable of implementing the 1.0 standard. Unfortunately for IBM, the last point release of the standard had made some fairly significant changes to the way code was structured into modules, which might have made it hard for IBM to implement the 1.0 standard on their existing architecture.

The combination of these inherent limitations, and IBM's bundling of Tuscany within the (snappily titled) IBM WebSphere Application Server Version 6.1 Feature Pack for SOA meant that we always assumed IBM would ultimately migrate Process Server across to the Tuscany, with the value add coming from IBM's established process, mapping and rules engines. Since the feature pack was out for 6.1, we had hoped (perhaps beyond hope) that this would happen as part of the WPS 6.1 release, which it would seem now is not the case.

This is something of a disappointment for me, as our architecture was being made significantly more complex than it needed to be because of the lengths we had to go to to re-use 'service capabilities' (more on these another day) across services.

I'm still 99% sure IBM will make this transition at some stage - they'd be crazy not to in my opinion, since there is plenty of value add IBM can provide in the components that sit on top of the SCA runtime, and every dollar they save working on the runtime they can use to add new glossy features to the remainder of the product.

My money is on WPS 7.0. How about you?

Next time you have brain surgery...

...it might be best to avoid:

• Rhode Island Hospital
• Muhimbili Hospital, Tanzania

In the former case, the hospital is "re-evaluating its training and policies". Perhaps they should start by investing in surgical gowns with "Left" and "Right" stitched into the seams.