SOA do's and don'ts, part II

This article presents the 10 "do's" and "don'ts" that perhaps best summarize the most important best practices that are emerging in this field.

The first part of this article can be read here. This is part two on how you can achieve rapid, pragmatic results when implementing SOA:

6. DON'T succumb to proprietary technology
It is all too easy in a commercial software development environment to build services that can only be used by consumers that share some non-standard technology with the service provider. And as noted in part I of this article, many bleeding edge Web Services specifications that are loosely called "standards" are not really widely deployed.

Likewise, it is important to distinguish standard interfaces such as Java Message Services (JMS) from other interoperable protocols. Your challenge would be to ensure that the products and technologies used in your SOA project can really work together to form a platform, language and vendor-neutral services infrastructure.

7. DO the simplest thing that work.
This is a key principle of agile software development methodologies and a good rule of thumb for dealing with the complex and rapidly changing world of SOA technologies. Start small, test thoroughly, keep the "customer" who is supposed to benefit from an SOA project in the loop and learn from mis-steps. Gradually rebuild systems as service networks of independent services. The real benefits will be seen over the long run.

Another reason to keep things simple is the fact that many specifications such as XML Schema Definition (XSD) have numerous bugs and ambiguities that can lead to interoperability issues, as well as features that are not widely implemented.

For many situations, simply exchanging XML over the Web can achieve many of the touted benefits for web services. Sticking to the simple core of the XML and Web Services technologies maximizes the probability that each feature one uses was well thought out, carefully tested and debugged--and likely to interoperate.

The Web Services Interoperability Organization (WS-I) Basic Profile offers helpful guidance on which features of the various specifications are truly interoperable.

From the business perspective, simplicity encourages re-use: the simpler a web service is to use, the more it will be re-used. Indeed, the cheapest way to develop software is to NOT develop it, but re-use that which has already been purchased, tested and deployed. That has been one of the key value propositions for systems built of objects, components, and now, services. The SOA approach is likely to finally realize the dream of widespread software re-use, but only if the interfaces are kept simple enough so that developers will find it much easier to learn how to re-use an existing service than to write a new one.

8. DON'T just press the 'make this a web service' button to expose ordinary objects as services.
A good service is not the same as a good programming class. A service does one thing well when given a simple request. It should not expose its "construction' to the user or force the user to worry about cleaning up once the service has been performed. A programming class encapsulates a set of related functions and data, and usually requires a "chatty" invocation and explicit state management, management of references, etc.

Similarly, programming language objects are usually designed to communicate by high-speed mechanisms such as method calls and shared memory. And these mechanisms are not really available across networks. Of course, one can use remote procedure calls and shared files or databases to communicate between objects, but these are orders of magnitude slower and less reliable. There was an attempt--exemplified by the CORBA and DCOM technologies of the 1990's--to minimize the differences between local and remote objects. Likewise, early Web Services toolkits made it very easy to generate a SOAP wrapper and a Web Services Description Language (WSDL) description of any class to make it usable as a web service.

However, the industry seems to have reversed this trend. Modern distributed architectures such as Microsoft Indigo explicitly recognize system boundaries and encourage a different style of design and programming depending on whether an object is intended to be invoked directly by a another local object.

9. DO design with evolution in mind.
Diversity and change is inevitable, so learn to accommodate them.

Adopting widespread industry standards such as XML is one way to do this. With XML, even if a vendor goes out of business or drops support for a certain product, XML data produced by that application or service will most likely remain usable by the rest of the system. Not so proprietary formats and protocols, which while might offer some cost or performance benefits, must be balanced against the possibility of having to scrap an entire architecture if fundamental assumptions are changed.

Coding in a dynamic environment, it is important to learn the lessons of those who tried to address a particular problem, even if they fail. For example, those who choose to avoid the extended Web Services stack (often called WS-* because so many of the specifications begin with "WS-") should be careful to understand the problems that they address and the approaches they try.

Starting simple is good advice, but one may find oneself revisiting the challenges of reliability, security, transaction integrity and others--which may be handled by more complex approaches. An immense amount of work has gone into extending SOAP and WSDL to support reliable messaging, transaction processing, many aspects of security, business process orchestration and more. Be prepared to accommodate these if it becomes clear that the simplest thing no longer works.

Finally, DON'T try to design everything in advance
Avoid a big design phase at the beginning of a project. This simply accepts the reality that business requirements, technology and cost structures change very rapidly. Design constraints that seemed immutable at the beginning of a project may be erased by a technological breakthrough. Or budgets might be slashed to a fraction of what was initially assumed to be available. Either situation can make a careful design produced by competent professionals essentially worthless.

Web Services amplify these considerations--that technologies and cost structures changing rapidly--but they also place new demands on enterprise infrastructures. So be flexible, hedge your bets and above all, take the fundamental advice that evolution offers: keep doing what works, and kill off the ideas that do not.

Michael Hawkins is the general manager, business development, Asia Pacific, Software AG. You can read part I of this article here.