Home

The following are tentative conclusions about the SOA industry. I recognize that some them quite debatable ( except for those outlined in the XML Inferno section ). In any case, I would be interested to hear other opinions on the subject, even if it is only to say how easy XML is to learn and use in solving common info problems ( I will make large allowances for the sanity of the poster ).

Deja Vu

Sometimes when reviewing the literature of SOA, one gets a nagging feeling of having 'been there, done that'. One gets a sense that nothing is new under the sun, that the core technologies being sold by new wave of SOA proponents are identical to the last six 'paradigm shifts' which grip the computer industry every few years. Sometimes SOA just looks like a repackaging of old technology in a new form.

On the other hand, the sense of deja vu one gets from 'new' SOA technology may be one of its strengths. The business rule industry repackaged rule based systems developed the 1980s into business rules technology in the 1990s and that lead to the proliferation of business rules applications in the 2000s. The situation for SOA technology may be similar to that of business rules in the 1990s - web technology of 2000s will evolve into SOA in the 2010s.

In a sense, the SOA reovultion is following a typcial pattern of technological prograss.  The distance that must be traveled from existing, but inefficient technology to a more streamlined and efficient technology is far less than a giant leap from no technology to an efficient technology. Technological progress tends to stumble along in fits and jerks.

The Upscale Market

Most of the existing SOA literature is oriented to the upscale market - big corporate applications. There are few counter-examples such as the SOA PHP Project, which develops good light-weight components for the open source code hackers, generally under the auspices of the Open Source Initiative. I am sure that there are many others I have not discovered.  But, the primary focus of SOA technology seems to be on the Fortune 1000s of the world, not on what is often called "agile applications" ( what ever the marketing brochures might suggest ).  Agile applications are very different from massive infrastructure.

Provider Lag

Different SOA providers are developing an SOA vision at different rates. IBM, for example, has been massively supportive of web standards since the mid-1990s and is certainly at the forefront of SOA.

Other providers, such as Oracle who one might expect to be at the forefront of SOA, do not seem to have made the leap quite yet. One explanation may be that their existing product line is already well-suited to SOA and the 'jump' for Oracle is not great enough to create a sense of a 'new' SOA outlook It may be that the database part of the SOA model is regarded simply as an Oracle server with a Service Data Object ( SDO ) wrapper around it. It might also be a reflection of different organizational perspectives within Oracle. Nonetheless, the non-data services part, the components of SOA, seems to get subsumed into their Java Server technology and that may not be an SOA-friendly move in the long run. This is all very debatable, but I think it does indicate a question mark for companies looking for enterprise-level SOA solutions from Oracle.

Standards Proliferation

SOA probably suffers from too many standards rather than too few. It is difficult to believe that all of these new standards will survive the test of time. While some standards are well established, such Model Driven Architecture (MDA) and Web Services Description Language (WSDL), others are not so established and may be modified or incorporated into other standards or might even completely disappear over time. In addition to the usually questions about how well a particular implementation conforms to a standard, one also needs a sense of the survivability of the standard in the "Battle of the Standards" likely to emerge in the next few years. There may be a flurry of "XYZ-Lite" standards, similar to the simplified OWL-Lite standard.

XML Inferno

One of the enabling technologies for SOA is the self-describing data structures of XML and their transformations via XSLT. There are both stable and well-known interchange standards, but they are not a quick and easy fix for incompatible data. In fact, XML and XSLT have been characterized in many ways, but none of the characterizations I've ever heard are complementary about the simplicity of learning and using them. By common consensus, XML and XSLT are difficult to learn and hard to use, except perhaps for textbook examples. In the real world, they can be very tricky. XML training and tool building must be a major part of a successful SOA migration.