IBM WAS: Fast? Yes. Central to SOA? Only in marketing.

IBM recently issued a press release stating that "WebSphere Application Server, a key building block for services oriented architecture (SOA), shattered a popular industry benchmark for scalability and performance by more than 33 percent using technology that costs half the price of the competition".

First of all, Kudos to IBM for continuing to improve the performance of WAS. Anything that drives the performance of key bits of infrastructure has to be a good thing. However, that's not the thing that caught my eye about this article. Instead, my eye was drawn to the statement that WAS is a "key building block for services oriented architecture". Let's consider where IBM was coming from when they wrote this:

• IBM WebSphere Application Server forms the foundation of IBM WebSphere Process Server, IBM's middle of the road (as opposed to specialised) 'SOA Platform' offering.
• IBM WebSphere Application Server is the leading (in terms of sales, at least) J2EE platform.

Maybe this is where IBM were coming from. It's true that WPS has significant take up in the market, usually within SOA projects, so I guess you could argue that WAS is the foundation to something which acts as part of the integration infrastructure underlying SOA projects. Alternatively, perhaps they're considering WAS in its own right. It's certainly an excellent platform for building and deploying the business logic which drives the behaviour of service implementations.

But (and in my opinion, it's a big but) the key to SOA is hidden cunningly in the name. It's Service Oriented Architecture not service oriented application-server, service oriented platform or service oriented infrastructure. SOA is about structuring your solutions according to service oriented principles, governing these solutions to ensure that they all contribute to an enterprise-wide ecosystem of services. To me, a key SOA principle is to be globally independent of any one third part product, and understand before you start how you can migrate away from the platform in the future. Therefore, to state that a product is a central component of SOA as a whole is misinformation at best, and could if taken literally be very dangerous for the ongoing health of your company.

I know that sounds melodramatic, but there's method in my madness: If SOA really is The One True Way, then it'll outlive any product (and possibly several of the vendors) currently in the market. If you couple your SOA vision to an individual platform, then you risk creating yourself a huge migration issue, comparable to nothing you've seen previously when the market inevitably moves on to new products in the future.

Web Service Threats

I've been doing some work recently that involves enumerating the potential threats faced by SOA implementations. To help Google, here are a few of the resources I've found useful in doing so:

• ZapThink - XML Threat Management: As you'd expect of ZapThink, a good high-level description of XML threats in general, but no specific terminology for individual threats, and no categorisation of threats.
• Forum Systems - XML Threats: Forum Systems sell XML/web service security products, so as you'd expect they're hot on illustrating the risks associated with using Web Services to customers. Nothing like a rainstorm to sell umbrellas. This page provides a very high-level summary of the types of attack vectors used by malicious service consumers; a companion white paper, "Anatomy of a Web Service Attack" provides a lot of additional detail explaining these types of attack.
• ZDNet - Five things you need to know about Web services threats: A useful article by Scott Morrison, Director, Architecture and Security at web service security firm Layer 7. Gets away from talking about specific threats, and talks more about the goals and high-level approaches used by attackers. Well worth a 10 minute read.

Interestingly, there doesn't seem to be a consensus over a taxonomy (categorisation system) for these threats. Possibly the closest we get is in Scott's article, where he suggests that all web service threats can be put in three categories: API, Infrastructure and Transaction attacks. Sadly, Scott doesn't go so far as categorising the threats identified by the other vendors. Hopefully when this picture emerges, it'll represent industry wide consensus. This should allow vendors such as Layer 7, Forum Systems and IBM (with their DataPower range) to communicate with customers in a consistent manner, and allow them to sell their wares based on customer need and product capability, which after all is the key to long term relationships and repeat business.

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.

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?