So, does testing change with SOA? You bet it does. Unless you're willing to
act now, you may find yourself behind the curve as SOA becomes systemic to
all that is enterprise architecture, and we add more complexity to get to an
agile and reusable state.
If you're willing to take the risk, the return on your SOA investment will
come back three fold...that is, if it is a well-tested SOA. Untested SOA
could cost you millions.
Truth be told, testing SOAs is a complex, disturbed computing problem. You
have to learn how to isolate, check, and integrate, assuring that things work
at the service, persistence, and process layers. The foundation of SOA
testing is to select the right tool for the job, having a well-thought-out
plan, and spare no expense in testing cycles or else risk that your SOA will
lay an egg, and have no creditability.
Organizations are beginning to roll... (more)
With the advent of Web services and SOA, we've been seeking to create
architectures and systems that are more loosely coupled. Loosely coupled
systems provide many advantages including support for late or dynamically
binding to other components while running, and can mediate the difference in
the component's structure, security model, protocols, and semantics, thus
This is in contrast to compile-time or runtime binding, which requires that
you bind the components at compile time or runtime (synchronous calls),
respectively, and also requires that changes ... (more)
There is a lot of talk about how SOA will significantly lower the need for
developers, thus the savings of SOA. This will be accomplished through the
promise of reuse that's driving many toward the SOA light. However, I'm not
sure we'll see a reduction in development with the advent of SOA, but perhaps
rather a redistribution of talent in the longer term. At the end of the day,
the reason for leveraging SOA is agility. Reuse and development savings are a
secondary benefit, if they happen at all.
Truth be told, we've been considering the demise of the developer during many
"hype ... (more)
Let's face it, WS-BPEL 1.1 was not a great standard, and left so much out
that many end users and vendors found it useless. In response, the vendors
put a ton of proprietary extensions in their BPEL 1.1-based products, thus
diluting its value to the point of "Why bother?" This was a dirty little
secret in the world of SOA. Considering that BPEL 2.0 is on the horizon, I
think it's time we began to talk about what's really there, how you can fix
it, and what you need to do to get from point A to point B.
What's most frustrating about the issues here is that orchestration is indeed ... (more)
Although a number of standards exist for information interchange and process
definition, industry standards have yet to emerge for defining common
integration server and B2B integration server services such as routing, rules
processing, and transformation. In the absence of such standards, individual
vendors have created proprietary approaches to these basic
information-processing services. As a result, we are confronted with features
that are not interchangeable, require specialized training, and do not
provide a common framework of services.
Even as we begin to implement stand... (more)