When SOA standards attack
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By David S. Linthicum
July 15, 2008 —
What happened to all the talk about SOA standards? You know, the whole WS* thing, and the 100-plus standards that everyone followed? Yes, I said “followed,” as in past tense.
Truth be told, SOA standards have a diminishing value, much like anything that floods the market. There were just too many standards to track, and many of them were redundant and not sincere. The fact of the matter is that interest in standards continues to fall off, and those who placed major bets on standards are starting to feel the stress.
The trouble came about when the creation of SOA standards moved from R&D to marketing. In essence, SOA technology companies found that it was a good way to sell technology. For instance, you create a standard that you drive, then create technology around that standard. After that, point to the fact that you are based on a “standard,” the one you created. It’s kind of silly when you think about it, almost like defining the ideal body type, which just happens to be your own body.
Thus, with standards driven by marketing and leveraged as a way to sell technology, the SOA technology vendors gave birth to over 100 SOA standards within several standards bodies. Typically, not much is behind most of these standards, and usually only one company may drive a standard, with few exceptions.
The problem with this approach is that those who consume SOA technology and want to leverage standards are, in many cases, left holding the bag as both the standard and the technology that support it become irrelevant. Thus, what you thought was a transactional service standard that insures portability turns out to be a standard that defines just one product, not a group of products. Therefore, the standard really brings no value to the table.
Even more popular standards such as BPEL are going through some rough times these days. In some instances, BPEL may be a good fit, but in most instances, SOA projects are opting for other types of service-binding technology (composites, workflow, etc.). Thus, if you invest in BPEL, there could be a day when that standard is replaced by something better and the code is quickly considered legacy. Moreover, with BPEL, as with many standards, the vendors have placed proprietary extensions into the technology to circumvent some of the limitations of the existing standard, and thus by leveraging those proprietary extensions, you (in essence) lock yourself into that vendor, and you might as well not leverage a standard at all.
So, how do you protect yourself? “Buyer beware” is the best advice that I have. I mean, use your head and do your homework; it’s really a matter of common sense. If there is a standard that’s driven by a single vendor, perhaps with a few other partners along for the ride, that’s really not a standard in the WSDL/SOAP sense of the word. You need to factor the value of that standard out of your buying decisions. Don’t get me wrong; the technology may be great and you should indeed use it if there is a fit. However, the standard won’t bring you the true value of leveraging a standard, since it’s really a standard created by a single vendor.
Moreover, you should also look at use cases around the standard, including projects where it’s currently employed. What’s working? What’s not? What’s the roadmap for the standard? How many technology providers will be following this roadmap?
Other things to consider include:
• Standards should be driven by three or more technology vendors that actually plan to employ the standard. Watch out for standards that include just one vendor and many consulting organizations.
• Standards should be well-defined. This means that the devil is in the details, and a true standard should be defined in detail all the way down to the code level. Conceptual standards that are nothing but white papers are really worthless.
• Standards should be in wide use. This means more than 100 projects are leveraging this standard and the technology using the standard, and they are successful with both. In many instances you’ll find that standards are still concepts, and not yet leveraged by technology consumers.
• Standards should be driven by the end users, not the vendors. While the vendors may have had a hand in creating the standards, the consumers of the technology should be the ones driving its definition and direction. If there is a common pattern, it’s that standards that are defined and maintained by vendors typically fail to capture the hearts and minds, while standards that are maintained by technology consumers typically provide more value for the end user and thus live a longer life.
I would not get too down on SOA standards; they continue to be important. But there is no way that the 100-plus WS* standards are going to be around in a few years. Thus, you need to make sure you’re not going to be stuck holding the bag.
Reach analyst David S. Linthicum at david@linthicumgroup.com.
Related Search Term(s): SOA & SaaS
Share this link: http://sdtimes.com/link/32416