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.

Missing Masterpiece

When I'm at work, I use Microsoft Windows as my primary operating system. As anyone who routinely uses a Mac will tell you, this is something of a frustrating experience. Things that should just work just don't. Don't get me wrong, this isn't Microsoft's fault, and it's not even Microsoft's software causing the problem at the moment. It just seems to me sometimes that there's just a general apathy about the platform. Developers of software don't necessarily think carefully before they act.

Case in point, I've just been writing a blog post in Ecto on the train. Of course, working in the IT industry, I'm a wily old goat, and I'm thinking: "Ah ha, much safer to write it offline, no danger of losing the post half way through because of a shaky Internet connection! Oh how clever I am..." ... not, as it would turn out. It would appear that Ecto has a few subtle bugs around posting that means if your internet connection is flaky, it sometimes looses the post that's being uploaded. This has just happened to me twice in as many attempts. I think it's because it thinks it has uploaded successfully, so it then refreshes its local article list, but sadly my masterpiece isn't on the server.

Being a wily old goat, I thought I'd have a bit of a whine about it. Now, doesn't that feel better?

Eclipse Process Framework

So, the other week, I'm beavering away at work, and we're talking about how nice it would be to be able to document our SOA methodology in a way that allows newbies and old hands alike to learn it, implement it and most importantly, feed back and refine it, because anyone who tells you their process is perfect is missing the point.

Someone (rather helpfully, as it turns out) pointed out the Eclipse Process Framework. They'd dabbled with it in the past, and found it to be a rather clever piece of kit. You'll have to forgive any slip-ups in terminology or accuracy; I'm the new boy in EPF's playground. As I understand it, EPF allows you to:

• Document activities and work flows in an extensible way.
• Document the roles involved in your process (Project Manager, Tester, Tea-boy), and what they are responsible for.
• Document the purpose, structure for artefacts, as well as managing their templates.
• Document the concepts and general purpose content to help people who are just starting out with your process.

All of this content is packaged up into re-usable 'process libraries' that allow you to combine different processes together (so, for example, you could create an OpenUP and SCRUM version of your SOA methodology, simply by pulling together the 'SOA', 'OpenUP', and 'SCRUM' libraries into two different processes.

Once you've done all of this, EPF lets you create publishing configurations to define how your process is published for others to read (either in a static web site, or as a .war file for deployment to your favorite Servlet Spinner). Interestingly, EPF also apparently allows you to publish your content to a Wiki, allowing the poor buggers who actually have to work with your process to feed back and tweak the content as they learn.

As if to prove the point, the EPF boys have document two popular methodologies for your reading pleasure:

• OpenUP
• SCRUM

Take a look, see what you think. I'd be interested to hear your comments...

100% True (honest) SOA Facts

A colleague helpfully provided me with the following link yesterday, thinking I could do with some enlightenment.

http://soafacts.com/ 

Despite his assurance that they're 100% verified and accurate my Spidey Senses are still tingling...

Good morning and welcome...

So, I'm sat on a train, watching the morning slide by on my way to work. I'm trying to set up a blog. I'm waiting for the signal on my 3G card, entering then name for the blog. Signal check? Check. Go! Oh wait, it's gone again. Rinse, repeat. 27 minutes later, and I have the beginnings of a new blog. One day, we'll all communicate through telepathy. Until then, there's GPRS. Anyway, welcome to the dawn of yet another new blog. I work in the IT industry as a technical architect, primarily on SOA solutions. For anyone who doesn't know their SOA from their Sushi, SOA stands for Service Oriented Architecture. If you're still in the dark (you lucky things), I'll explain another day. When I'm not working, I indulge myself by taking photos, listening to music and watching the world slide by at 7:33am. Good morning, and welcome.