Untitled Document
One thing we've learned over the last year is that SOA is here to stay - both in
terms of enterprise architecture and in vendor marketing messages.
Those of us in the "trenches" of integration efforts have learned
that SOA and its various components mean different things to different people
and in fact one person's SOA may be someone else's Web Services, EAI, ESB or
other acronym. Terminology confusion aside, many enterprises are beginning to
realize the benefits of SOA and the modular approach to enterprise architecture.
The big question for enterprises is "what is the right SOA approach for
my environment?" At the highest level, the fundamental challenges are the
same. It's tough to get data to and from different systems in different formats.
It's tough to migrate large volumes of data from legacy systems onto new systems
without service disruption. And it's tough to juggle the ongoing churn of legacy
applications and new services that need to be wired together.
What I find concerning about the SOA market hype is that there have been some
gross oversimplifications propagated about "the right" approach. Just
like with all integration challenges, finding the right fix is a matter of breaking
down the existing technologies in the environment and weighing the implications
of going different routes.
Web Services: Not the Silver Bullet
Web Services have commonly been pitched as the cure-all for solving interoperability
issues that organizations face across different environments and platforms.
This sort of pie-in-the sky integration silver bullet vision for Web Services
has in fact caused a lot of folks in the market to view Web Services as being
synonymous with SOA.
However - as most large scale enterprise developers would attest - the problem
with Web Services is that the user often faces a big performance hit when they
wrap all their messages in XML headers. Often (and certainly in financial services
institutions) they can't afford that overhead of passing that message and trying
to figure out where to send it next. Typically the routing message has to be
stored outside of the message for performance reasons. There are numerous other
practical performance hits that one must take into consideration before using
Web Services for SOA messaging. There was an excellent article
on InfoQ by Stefan Tilkov recently if you seek further information.
-1-