SOA do's and don'ts

expert's view A service-oriented architecture is commonly acknowledged as the most cost-effective and efficient way to integrate disparate information systems together, as well as bridge the gap between sliced or heterogeneous systems.

A properly designed architecture helps you leverage existing equipment and software systems. It also reduces transaction costs, while improving visibility and control of business processes. The right solution also lifts several burdens from the IT department--like excessive maintenance activities, hard-coding integration efforts and manual information retrieval.

Why SOA?
The term "Service Oriented Architecture", or SOA, has come into widespread use over the last two years. XML and Web Services technologies are perhaps not absolutely necessary to implement SOA, but they greatly facilitate the task. On the other hand, the Web Services technology landscape is quite unstable, with new specifications being proposed by different vendors and organizations almost every month. So what can real-world business developers do or not do to maintain some sanity while all this technology matures?

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

1. DO begin with realistic expectations
It is important to understand the problems that Web Services are designed to address before beginning an SOA project. Begin by asking what you hope to achieve and make sure that Web Services and SOA can realistically offer it. While there are numerous benefits that can be derived with the implementation of Web Services, the three below are the most realistic:

1. The ability for software to access both new and legacy IT services over the Web;
2. The ability to do this across hardware and software platforms in a vendor-neutral way;
3. The ability to do this quickly and cheaply by leveraging the "network effect" created by common standards.

2. DON'T get too close to the bleeding edge
The core standards supporting Web Services are robust, and they have brought real interoperability of systems between enterprises--and within internal systems--much closer to reality than ever.

There is also a family of rapidly evolving specifications defined by an informal consortium, including such notables as Microsoft, IBM, BEA and Sun Microsystems. This family of standards includes WS-Security, WS-ReliableMessaging, WS-Coordination, WS-Addressing, WS-Eventing, BPEL4WS and others.

Here is where enterprises should take caution, because only a few of these newer standards have been turned over to formal standards organizations. IT managers and developers should be aware of the newer technologies and proposed standards built on top of them, but remain wary of them until more solid success stories exist and best practices have been clarified.

3. DO expose existing enterprise functionality as services
Perhaps the greatest short-term benefit from an SOA approach comes from re-using trusted legacy software in new ways and from different clients. Building SOAP Web Services interfaces and describing them with Web Services Description Language (WSDL) allows legacy code to be accessed from any platform, using any modern computer language, and in a way not tied to a particular system or software vendor.

This can offer businesses significant cost savings. Exposing existing enterprise functionality as services also helps mitigate the risks of a new development project--whether by a new or existing vendor--and still enable organizations to enjoy the advantages of using modern and standardized technology.

Achieving this, however, is not just a matter of applying XML technology. It is about applying the concept of a service to some existing software.

But how do organizations go about creating new services out of existing functionalities? One point to note is that services provide some value to those who know how to request and consume them, but not necessarily how to do what they do. Service orientation is an approach to designing systems in which each component knows how to request and consume the services provided by other components, but not about their internal algorithms, data formats, etc. The trick to exposing existing functionality as a service is to figure out how to package the existing code in a way that it can be used by those who know as little as possible about how it works.

4. DON'T perpetuate fine-grained, tightly coupled interfaces
Not every piece of tried-and-true legacy software is suitable to be exposed as a Web Service. While the guiding principles of SOA, such as "loose coupling", "information hiding" and "stateless interaction", have been textbook development practices for quite some time, real-world software does not always adhere to them.

For many organizations, additional work will be needed. It may take some wrapping and repackaging of the legacy code to make it suitable to be used as an autonomous service, which should perform some substantial piece of valuable work when given a specific and discrete request. Some enterprise systems may be made up of components that are simply too inter-dependent to be used effectively as Web Services. In this case, a good approach may be to create wrappers that expose a very large chunk of business process as a long-running service--rather than try to expose the discrete components.

5. DO design services to be used from any language or platform
Even organizations that currently standardize on a single vendor or platform would be well advised to make sure that their service architecture is open to service consumers and service suppliers that use different ones. The most obvious reason is that customers may not have made the same choices: even services initially designed for internal use may prove useful for customer self-service in the future.

A more profound reason is that service architectures allow one to move from a single-supplier environment of integrated suites to a more heterogeneous environment of specialized and cost-efficient components.

A good example would be the monolithic Enterprise Resource Planning products that became widespread in the 1990's. And one reason why such integrated suites became so popular a decade ago is that integrating best-of-breed products were expensive and required continual maintenance by experts. The rise of standardized XML and Web Services technology may well change that equation because these tools are designed to inter operate. Likewise, knowledge of XML and Web Services is a commodity, not something that can be obtained only from specialized and expensive consultants.

Michael Hawkins is the general manager, business development, Asia Pacific, Software AG. Look out for part II of this article next week.