By Michael Hawkins
Monday, March 07 2005 05:10 PM
URL: http://www.zdnetasia.com/insight/software/0,39044822,39220658,00.htm

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.

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.