Preparing to Implement a Service-Oriented Architecture

Whether you are choosing an implementation of service-oriented architecture or building your own implementation, it is useful to know some of the details about implementing service-oriented architecture. Web Services embody most of these practices:

Standardize the communication paths to achieve implementation transparency: Service-oriented architectures stress the ability to communicate with a service regardless of its implementation or location. In this sense, the service-oriented architecture is all about communication, not implementation. The more open the communication mechanism is, the more open the service-oriented architecture will be. For example, by implementing a simple XML communication protocol based on TCP/IP, you allow most languages, platforms, and architectures to participate in your service-oriented architecture without work. XML parsers are essentially ubiquitous, as is the TCP/IP communication stack.

Provide a standardized directory interface that can provide business information as well as programmatic information: Service-oriented architectures provide ideal platforms for implementing business processes. A well-implemented directory structure can allow a client to locate not only a suitable service, but also an ideal service for use. Unfortunately for programmers, more than just the interface of the service is necessary for choosing a proper implementation. The selection of a proper service may include the business name , the location of the business, the target market for the business, and more. This information must be standardized or " generally accepted" for it to be useful. For example, consider an enterprise IT shop ordering 1,000 development computers. You would not want to waste the time of the ordering process in locating a local computer repair store that also sells refurbished computers. Even if the programmatic interfaces match, the target business market for the local refurbished store is not the enterprise business.

Provide a mechanism for strong, standardized contracts and interfaces: Just like it is important to provide standardized information about business information, it is important to provide strong contracts and interfaces for services. Without a mechanism to fully define contracts and interfaces, a simple parameter such as name can be confusing when calling one service or another. For example, does the service require the first name, last name, or both? It seems trivial, but these are computers that cannot always interpret the context for a piece of information. For this reason, it is best to use standard business interfaces for individual business processes. The service-oriented architecture should provide a mechanism for defining and using a well-known interface.

The Web Service implementation of the service-oriented architecture illustrates most of these attributes. There is one glaring oversight in Web Services: the standardization of contracts and interfaces. Other architecture implementations do attempt this standardization, such as ebXML and CORBA. Unfortunately, ebXML and CORBA fall short in terms of other attributes and, especially , in mindshare. Creation of a standard cannot occur if you do not have mindshare and market presence to enforce the standard.