WebServices dot org

There is No Right or Wrong Way to Build SOA

Is there a “right” and a “wrong” way to build an SOA? Perhaps, but this is a question for end-users, not committees or vendors, to decide. At least that’s the working philosophy of the OASIS SOA Adoption Blueprints Technical Committee, which I am chair, as we seek to define best practices and build proof-of-concept models around SOA.

SOA Blueprints will start with business problem statements, and develop a detailed functional requirement document, which shows all the nitty-gritty that’s required to solve the problem, and then generate best-practice implementations.

To put it simply, our definitions of SOA are going to hinge upon people’s requirements. And we expect that some of those requirements are not going to be pretty, or even not real “macho,” SOA. Or, some weird implementer is going to come up with a weird way to do it using something weird. But that’s okay. But if it barks like a dog, it’s a dog. If it barks like a dog, we’re satisfied.

There are cases in which Web services may be the right answer, however. If someone requires interoperability, transparency, intermediation, and policy enforcement, then a Web services approach probably is the best answer. Trying to meet such requirements with other systems is probably going to be unnecessarily hard. Sure, certain functional requirements can be met using other means. However, contemporary best practices dictate that in order to meet the business requirement of intermediation policy enforcement, data format transparency and interoperability across multiple partners, you’re probably best bet is to use Web services.

But the goal of SOA Blueprints is not to promote or develop any new Web services specifications, per say. If anything, there are to many standards that start with “WS” out there already. In fact, a half-baked blueprint has a little bit more utility than a half-baked WS standard. A half-baked blueprint is our current best guess on how to meet functional requirements, and identify the current set of best practices. The blueprints will have a higher degree of understandability than the standards, because it always links back to what you’re trying to do. The journey is part of the destination.

Why have a committee build a proof of concept? First, there’s the benefit is collected wisdom, in which within a larger group of mutually interested parties, there are likely to be people who have considered elements of the problem you haven’t considered. Plus, SOA Blueprints will help apply the law of mass pressure on vendors. They won’t do free proof-of-concept projects for single blueprints; but if they know they have a global audience, it will be a different story. All vendors think that their products are “cool” and “good,” of course. And they’d rather do a proof of concept in front of everybody, rather than a closed proof of concept.