Lustratus LiteBytes

Archive for April, 2008

It looks like there is still some level of debate over the definition of an SOA service, according to the excellent Loraine Lawson’s recent post.

This was a topic covered in detail in a free Lustratus paper in 2007, entitled ‘What is an SOA Service?’ (catchy title). Now, I haven’t read the referenced article in Loraine’s post, but it seems a good time to take one more stab at this at a reasonably non-technical, simplistic level. I like to look at SOA not in isolation, which can result in the person with the loudest voice claiming the right definition, but in terms of its place in the evolution of IT.

People started with programs. Because they were hard to understand, particularly if you hadn’t written them yourself, structured program was introduced including things like subroutines. Then people realized that if these subroutines and other programs were put together in an encapsulated fashion, with clearly specified inputs and outputs, they became like little black boxes that could be used to build a bigger program – these reusable components were called Objects. But now users started to have multiple platforms and application environments, and the need arose to be able to get these components to talk to each other, so messaging was introduced to provide a communications pipe, usually asynchronous in nature to provide more flexibility. A value-add layer on the communications pipe dealt with issues of different components being based in different environments, for example, and EAI (Enterprise Application Integration) was born.

But all this was still at an IT level, and for years business executives had been pushing for better business alignment of IT. So the next development was to move the IT components onto business boundaries as opposed to technology ones, through SOA (service-oriented architecture). This helps provide a business-oriented view of both design and operations. Of course, being an evolution, SOA retained a lot of the other developments discussed above – so an SOA service is not only business rather than technically oriented, but is self-contained with clearly described inputs and outputs, reusable and accessible from anywhere through a communications pipe (often an ESB, Enterprise Service Bus) that offers value add services such as transformation and routing.

So, in summary, an SOA service

• represents a clearly defined business operation
• Is self-contained and reusable
• is accessible from anywhere
• responds to well-defined inputs with well-defined outputs

I realize this is a gross simplification, but I hope it is helpful.

Steve

Sometimes I get tired of being the guy in front of the train waving my flag and hoping I can stop or divert it.

I get called old-fashioned, blinkered, boring, misguided and a whole range of other names not suitable for printing here – but at the risk of getting another postbag of objections, I want to raise my flag again with respect to WOA (Web-oriented architecture).

I read Dion Hinchcliffe’s excellent article on WOA, discussing whether WOA was the future for SOA. The argument was essentially that SOA has not delivered the expected benefits, but WOA can. Essentially, WOA is all about arranging information in terms of resources that are accessed through HTTP in the same way as URLs. You have GET, PUT, POST and DELETE commands just like in most message-based SOA solutions. The resources are manipulated by components such as browsers etc, and it is the responsibility of the component to understand the representation and state changes of the information.

I have no problem at all with this – sounds great. My problem is the suggestion that this is the future of SOA – the implication that in some way SOA has failed and WOA, close cousin that it is, is the natural evolution. I have a couple of major grumbles here.

Perhaps the biggest is that WOA is all about a connectivity / integration architecture – a technical network really. The fundamental change with SOA from what people have done before is that SOA services are on business boundaries, not technical ones. Hence a SOA service is something that makes sense in business operations terms – eg Get Customer Details. Perhaps the implication is that in WOA the resources are also synonymous to business ops, but then how are they defined when the responsibility for understanding their representation and behaviour lies exclusively with the browser or other component accessing them?

Another particular gripe I have is that whereas SOA is based on a messaging bus to do the transfers, such as an ESB or a reliable messaging pipe like WebSphereMQ, in WOA all comms are done using HTTP, presumably with reliable delivery being provided through WSReliableMessaging ha ha. In fact, doing once and only once delivery of messages is really hard, and as we all know from the number of times we receive duplicate emails or none at all, HTTP is not brilliant at it. As for WSRM, as is often the case with standards developed to try to counter a dominant market de jure standard, the lowest common denominator approach required to get agreement across a range of parties renders the standard very questionable in terms of maturity.

Apart from that, I applaud WOA. As an analyst I am always delighted to see a new idea come to fruition, particularly with a new buzz word that has to be explained. After all, that is how analysts makes their businesses work! And to be serious, I see real value in WOA – but if people start looking at it as a replacement for SOA then I think users are in for a shock.

Steve

IBM certainly seems to see SOA as a key initiative, if its annual SOA show is anything to go by.

The IBM Impact 2008 even in Las Vegas attracted more than 6000 attendees, and they can’t all have gone just for the weather! But the most salient aspect of the event as far as I was concerned was the ‘event’ support – not the army of people ensuring the party ran smoothly, of course, but the addition of the WebSphere Business Events product.

Event handling has always been possible with WebSphere, but it was messy. Triggers could be set on different queues, and conditions could be detected in various ways, but the whole thing was pretty technical and complex. However, IBM’s new product, based around its acquisition of AptSoft technology, delivers exactly what business users are looking for; the ability to write business rules in their own language that can control operations.

One of the key characteristics of SOA is that it breaks monolithic application stacks into individual services, each executing a discrete piece of business functionality such as ‘Get Customer Details’ or ‘Book Delivery Date’. In addition, information flowing in and out of these services is cleanly architected in a standards-based fashion, and is therefore easily accessible. But this opens up a magnificent opportunity to deliver business control over operations through the use of business rules that implement corporate policy by changing execution and flow.

For example, if a bank wants to offer students the opportunity to make payments from their accounts with no charge, a business rule could be written that says ‘If account holder is a student, then skip the charge calculation step’. This is a simple example, but with the addition of a correlation capability IBM has ensured that much more complex rules can be put in place. Consider the type of rules needed to mitigate the risk of fraud, for instance, where multiple conditions from a range of different systems would need to be assessed to detect suspicious activity patterns.

The key is that these things can be achieved with the use of business rules that the business analyst can understand. This makes change quicker, and reduces the risk of misunderstandings between the analyst and IT technical staff.

With the addition of WebSphere Business Events support, IBM SOA has finally grown up. I guess the next step could now be a comprehensive BAM solution……we can but hope.

Steve