Java Reference
In-Depth Information
some way on vendor implementations, or you can succumb to proprietary extensions if you
aren't very careful. If that jeopardizes your interoperability efforts, you've defeated the whole
purpose.
So when you go to implement your SOAP/WS-* SOA, you face a couple of choices, neither
of which seems particularly appealing:
▪ Go with a stack vendor. Buy an ESB, SOAP engine, application server, BPEL, Re-
gistry/Repository, BAM (Business Activity Monitoring), and BPMN (Business Process
Management Notation) tools all from one company. This may reassure you that your own
complex service processes will work seamlessly together. But even within a single plat-
form these tools don't always integrate perfectly. That's because the big stack vendors of-
ten OEM a popular product, or buy an entire company or product because that company
has a piece of the stack they need, or they wrap an open source product and put a logo on
it. Now instead of trying to make Java interoperate with .NET, you're trying to make all
of these particular stripes across your SOA interoperate with your business partner, who
may have the same problem. The bottom line is that in order to decrease coupling from
one system (the one you're wrapping with a service), you may have increased coupling
with another one (the vendor implementation).
▪ Seeing the difficulties presented by the first choice, you may decide to go with best of
breed vendors. That is, instead of going with a single vendor, you get the best ESB, the
best orchestration and process engine, and so on, regardless of vendor. This is difficult
to manage, can be far more expensive, and can make it tough to get an answer when
something goes south. You soon realize you still have many of the problems presented by
the first choice. At least you still have throats to choke.
Of course, if you don't like these choices, you can always build your own. This raises an in-
teresting question. If you were going to start from a green field, and wanted to have machines
intercommunicate by exchanging platform-independent XML documents, how would you do
it? Would you define your business entities (Customer, Product, and so on) and then represent
them in a canonical way and exchange these documents over a well-understood, simple, clear,
and popular protocol? Or would you create a new idea, like SOAP, to wrap some functionality
on an existing system, and have that idea require an XML document of its own to represent
it, and require some software to hook that interface to your application, and then define the
entities, and then exchange them not directly on HTTP, but rather on another new idea for a
protocol, which also requires new software to run?
There's an answer there if you want to make your systems work together as simply and inex-
pensively as possible, and there's another answer if you are in the business of selling software.
