LiteBytes from Lustratus Research

WS-Madness

OK, I think it is time to stop all the WS-Madness. Web services standards have become a complete joke. As far as I can see, there are now at least 70 (seventy) web services standards and drafts - more than anyone could humanly want, and enough to create chaos, and completely negate the advantages of standards in the first place. Standards are supposed to increase choice, but with so many the likelihood is it will actually REDUCE choice (do you support standards 27, 39 and 40? no, I support 23, 42 and 63 though, any good?).

So, who is to blame for this debacle? Well, the blame is pretty evenly spread. Perhaps the most obvious target is the vendors, who have unashamedly used WS standards as a battleground to try to create differentiation from competition. So, by creating a standard that fits in with ones own design, it is then possible to use this as a reason for rejecting other players. However, vendors are easy targets - but are they really the villains here? After all, you could argue that they are just doing what they have to do - trying to compete, to win business and pay their employees / shareholders. The next obvious choice is the standards bodies themselves. Sadly, there are many 'professional' standards body members who get intellectual kudos from defining standards - whether they are worth anything or not. But even this may be missing the point.

Perhaps, instead, blame should be turned on users. The vendors have stepped in because of two things - the opportunity created by the desire for standards in the SOA space, and the vacuum resulting from the failure of users to take an active role. Similarly, standards bodies have leapt into the void because in a way they have to generate standards to have any worth in the world. But the real accusation is that the standards are rubbish - most are immature, many are useless or pedantic. In other words, they do not add value for SOA users and implementers. And isn't this a case of users getting what they asked for? If users don't want to get involved to ensure the RIGHT standards are created, that really mean something to users, then they cannot complain when others jump in to fill the vacuum.

My advice to users on web services standards is to ignore all but the important ones - SOAP, WSDL, WS-Security, and maybe WS-Addressing although this is not as mature as the other three. Then take a more active role to ensure these standards mature into what you actually NEED.

Steve   

The sad state of SOA development tools

I think it is becoming generally accepted that SOA presents some pretty big issues outside of the technology domain in terms of skills and organisation.  Even before a new SOA developer in a particular organisation gets to dealing with cool new technology, he or she must understand the additional layer of process and operational knowledge in order to work within the SOA-based world. 

One example is ‘service discovery’ which for the developer means finding services which work for their task in hand and understanding how to work with them.  I use the term service discovery with caution as I do not mean automated discovery of the insidious WSDL that Steve referred to here. Rather I mean the task by which an individual developer gathers sufficient information to make the decision to use a service in his or her project.   At some point WSDL may well be needed but the task really requires search capabilities and lots of human-centric information that explains and motivates the use of each potential service.

Let’s now step back for a moment and think about SOA and infrastructure software in general:

• Infrastructure projects (whether SOA based or not) require an understanding of many aspects of both technology and business domain unlike business applications which for the most part require understanding of the business domain alone.  This raises the technical skills bar for infrastructure projects. 
• SOA is meant to reduce the cost of development and maintenance.  As there is a global shortage of highly skilled developers and these are concentrated in a smaller number of large organisations, it can only do that if it allows less expert developers be productive.  It will be of some use if it makes the job easier for the experts but this won’t help most business departments and SMEs.

How well are the current SOA enabling products are doing? In particular, have they made the task of developing SOA easier than using EAI products 5 years ago which were held to be too difficult and expensive to use by many organisations? My opinion is that there has been some maturing of development tools but in general too little has changed. This means that SOA risks running into the same skill shortages that EAI ran into.

I think there are probably a few reasons why there hasn’t been a radical improvement in development tools:

1. SOA stacks tend to focus on run-time capabilities (such as SOA run-time registries stuffed full of WSDL instead of knowledge management systems designed to guide the developer to the right service).  The reasons for this may well be that software architects recognise that run-time problems (such as lack of scalability) can’t be got over as easily as development problems: Development problems will increase the cost and failure rate, but they won’t bring down the business.
2. It is much harder to create good tools for less skilled developers than more code generation wizards that plug into eclipse that appeal to experts.  Hence if you look at most SOA stacks, they will include forms-based user interfaces which help the already knowledgeable programmer with some routine tasks.  They do not allow the newbie to focus on the business logic instead of the integration logic.  Unfortunately, this point is somewhat obscured when people say they don’t need yet more new technology for SOA – they really mean they don’t need more new run-time technology.  They certainly need more productive development tools.
3. Middleware has put the premium price on run-time software and development tools have traditionally been sold for low prices or even given away. This may be because developers in early adopting companies tend to be more technically skilled and put lower value on easy-to-use tools.  They also favour tools which augment their own skills – rather than tools which make it easy for somebody less skilful.  What this means is that it is hard to fund or build a business selling really good development tools.

All of which leaves a significant challenge for SOA adopters and vendors.  In order to be successful with SOA, significantly better development tools are needed.  For this to happen, end-users need to push their vendors and be willing to pay them when the tools are delivered. 

Ronan 

p.s. If any readers want to point me at some good SOA development tools, I would be delighted to take a look.