If your SOA ends up being just a bunch of web services, don’t blame the tool
A fascinating post on the Inside Architecture blog lambastes SOA tools for creating JaBoWS (just another bunch of web services).
Nick Malik writes:
Don’t get me wrong. I don’t hate tools. For one thing, there are some tools that support Enterprise SOA. Not many, but a few. Those tools understand that Enterprise SOA is not about building one service after another, but building the right services, and building them in a manageable and non-overlapping way.
Nick goes on to say that companies that companies that do not implement a “comprehensive Enterprise SOA transformational program” end up with “tripe.”
Have you ever violently agreed with some one’s conclusions but disagreed as violently with the premise? Well, that’s where we find ourselves after reading Nick’s very passionate (and well-written) post.
In short, when you build a SOA up of piece parts, you would tend to believe that service orchestrations — the actual applications — can be built from piece parts. And they just can’t. What’s good for the architecture isn’t good for the developer.
Developers — especially Java types who are creating web services willy-nilly and then running into a wall trying to use them — need something both familiar and holistic to actually get some value from those web services. They need a visual orchestration system which is complete, standards-based and familiar. Something that masks the complexity of long-running transactions, includes human tasks, eliminates hand-coding of XML, offers discovery of available services and, above all, makes testing and deploying services-based apps easy.
ActiveVOS can do all that, and more. Yet some people call us a “tool.” (I’d prefer SOA development system, but at the end of the day, if you are the tripe-buster, what do you care what people call you?)
Nick is exactly correct that the tools people have been using before VOSs yield little but JaBoWS. As long as developers have to put all the pieces together, you can’t get anything else. But there’s magic in making SOA development integrated and familiar.
Don’t blame the tools. Instead blame those who become captives of their own thinking, by extending the assumptions they made in building their SOA to the development of applications to run in that SOA.
Tags: BPM, enterprise architecture, SOA, web services
