InfoQ Article: Top 8 SOA Adoption Pitfalls

Despite being very popular and free, there are more performant and less verbose extensible data serialization formats. (e.g XER/PER)

Secondly - one needs to realise that the main purpose for the existence of vendors is to vend. Therefore they have a vested interest in making all the WS-* layers require their tools. However its totally possible to avoid a lot of complexity by simply not using vendor products, and doing "the simplest thing that could possibly work".

Jetty A Servlet XStream can get you off the ground very quickly - not a vendor tool in sight...

This is a very unfair characterization of vendors, and I would also say a somewhat idealistic stance.

Firstly, the XML verbosity argument is often irrelevant; the web is built on a very verbose markup language called HTML and seems to be doing just fine. There are many use cases that require a more compact form, but they tend to be the exception.

Secondly, Why XML? Let me pose an alternative question: Why is broken English the most widely communicable form of language, even though there are other more efficient languages like Esperanto?

There are plenty of contexts where an alternative to XML is applicable, such as JSON with AJAX. But one must recognize the serious economic tradeoff in making such an architectural decision. One shouldn't focus overly heavily on technological mechanisms when building an SOA; XML is not mandatory, but a whole lot more people will understand you than if you speak first century Aramaic.

Third, vending supposes there is "need" out there. One can argue whether that need is manufactured or is real. I would say it's likely a combination of both. Clearly, there are many use cases that WS-* covers that you can't point to in nearly another other standard, save rarely implemented CORBA services.

Some large customers happen to have tremendous clout with large vendors

Looks like I got truncated there.

Some large customers happen to have tremendous clout with large vendors. Large vendors have clout with standards bodies. Thus a reflexive process occurs, where communities of practice think alike and guide a standard down a particular path, which guides client perceptions, which guides vendors, etc.

Many clients want WS-*, even though URIs, HTTP and SSL would likely suffice for most use cases. They have their reasons - some legitimate, some not. But if they're willing to pay millions for an enterprise deal, it's hard for a vendor to at least be a "fast follower" of such standards, regardless of their actual success or value.

I am merely challenging the assumption that either xml or vendor is absolutely required to have a SOA. It depends on what floats your boat.

While disagreeing, you simultaneously agree, by saying vendors are sometimes brought in "regardless of their success or value", and that xml is good "except in the extreme cases" - of which I can think of a lot.

The need for these things should be decided upon by a rational decision process, rather than assumption. (as is the case with everything)

I agree that one can certainly have a valid SOA without XML. But it seems that many performance-oriented critics of SOAP/WS-* SOA are treating the proposition as if it were an application programming model and not an integration model.

Let me add my 2 cents in support of vendors, since I represent one.

The point of spending the last decade pushing for the widest possible standards ever has been to get as many people as possible "on the bus" (not the ESB, the metaphorical "lets all go in the same direction bus"). The point of that is to offload common, crosscutting concerns that app developers have been baking into systems themselves. The "openness" of wire protocol, metadata and policy supports a high degree of automation and composability of various vendor products.

Obviously you need to be the judge of what automation and proucts you should compose but its a tremendous opportunity we have to raise the level of software development 1 notch.

I often wonder what this means to people. Establishing a SOA council to adopt patterns and practices sounds like standardization. So does defining a common XML data model for an enterprise or even industry. But those efforts seem to be really hard to do. Try to get a bank to agree on the data model of a contact/person/organization/trading partner/entity etc. Then if and when you have standardized how do you evolve?

Does standardizing at a low level stifle future innovation? Once you have that in place is there ever a chance of moving ahead?

XML can be a challenge but it?s difficult if not impossible to avoid using. Even if you don?t want to use XML your business partners will likely force you to. There are also great tools for authoring and storing (repository) XML and there are XML accelerators if performance becomes a problem.

See this post for more tips on XML and SOA.

blogs.ittoolbox.com/eai/business/archives/xml-s...