email article printer friendly

Designing a Better SOA
Employ best practices and the right architecture to ensure both short- and long-term success of shared services
by Rag Ramanathan

December 17, 2004

Although a Service-Oriented Architecture (SOA) is conceptually simple, and its value reasonably evident, realizing a shared services infrastructure within a distributed enterprise still can be difficult. Building the right architecture and adopting the best practices needed to achieve a shared services vision can ease the transition and help ensure both short- and long-term success.

Let's start with the broader picture. Organizations need to establish company-wide best practices for building successful SOAs. The organization-wide best practices that we use in enterprises are described in the sidebar "Organizational and Operational Best Practices." More specifically, we also have six technical and architectural best practices (see the sidebar "A Better Way to Build"). Now let's take a look at some key characteristics, design considerations, and implementation choices that both the organization and the technical team should consider when building an SOA.

Coupling
Coupling refers to the relationship (interrelatedness and dependency) between two software artifacts (applications, components, modules, methods, and services). Coupling can be categorized as tight, loose, or decoupled. The degree of coupling between two services mainly depends on two factors: the implementation and invocation of the service provider, and the consumer's knowledge of how to find and invoke the service. For services, location and interface definition (including datatype definition) forms the coupling. It is necessary to handle levels of coupling of different versions of services as well.

In computer or software systems it is practically impossible to have two related systems completely decoupled from one another. As long as one system depends on the other system for data, function, service, or connectivity at any level, they can't function when decoupled.

In loose coupling, a service provider defines and publishes its service interface, using a standard definition language. The interface defines the invocation contract between a service consumer and a service provider. A service provider's implementation can be modified as long as the service interface remains the same.

A consumer's knowledge of the location of the service provider also introduces coupling. If two services need to interact, they can't be decoupled, and have 100 percent location dependency. In contrast, if the consumer carries the exact location of the calling service, then it is tightly coupled by location. Because location decoupling is not possible (between two known entities, but possible in an event-driven architecture), and tight coupling of location is inflexible, an intermediate loose coupling of location is desirable.

Loose coupling of location can be achieved by using service intermediaries such as service brokers or directory services. Loose coupling for Web services is achieved by using Web Services Description Language (WSDL) for service definitions; Universal Description, Discovery, and Integration (UDDI); and WebLogic Integration service broker/service control.

Using network load balancers (hardware and software) and/or WebLogic clusters, you can achieve nonpolicy-based, simple location-based loose coupling without the use of an intermediary. As long as the service end point specified in the WSDL is a distributed name service (DNS) name and not an IP address, the Web service request can be redirected and proxied using standard HTTP mechanisms. The request could be serviced by any number of end points on any number of physical servers (including different data centers).