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).
Binding
The choice of service binding methodology—static, brokered, or dynamic—determines the flexibility and performance of the service invocation.
Static binding assumes that the service definition and interface do not change frequently. Static binding between service consumer and service provider tightly couples both participants of the service invocation.
In broker binding, a service consumer sends its request to a service broker, which routes that request to one or more of the service providers, based on its policies for that service. The service consumer needn't be aware of the service provider in this mode.
Dynamic binding assumes that the service definition and interface change frequently. Dynamic binding requires that, for every call, the service consumer contact a service directory or broker to request the service definition. Based on the information returned by the service broker, the consumer binds to the service provider. As dynamic binding performs a lookup followed by the binding, it will not perform as well as the static binding approach.
The choice of dynamic or static binding depends on the performance and flexibility requirements of the application. Dynamism of a Web service definition can be achieved by using a UDDI or Web services management (WSM) intermediary service.
Granularity
The number of service invocations made to the service provider by the consumer to complete a business operation determines granularity of a service. When many service calls need to be made, the service provider is implementing fine-grained services. If only one or very few calls need to be made, then that service provider is implementing coarse-grained services.
The number of service calls is related to the amount of information passed during each call. Although fine-grained services take few native type or object parameters, coarse-grained services take documents as parameters, which contain all the data to complete a business transaction.
Coarse-grained services can be created by composing or assembling fine-grained services; by using methods such as Tuxedo, Enterprise JavaBeans (EJBs), servlets, and Java Database Connectivity (JDBC); or by invoking services on back-end systems using an adapter, APIs, or Web services. Composing coarse-grained services using fine-grained services provides the same benefits as using SOA for the application. However, that doesn't mean exposing each method in an EJB as a Web service; this isn't required and may be inappropriate. For example, EJBs can be reused as controls in WebLogic Integration and used to compose coarse-grained services. Making all fine-grained services into Web services and accessing those services through a service interface would have performance overhead.
Choose coarse-grained, document-oriented services to match the higher-level business process requirement. Fine-grained services can be implemented using Web services, J2EE components, or controls. Coarse-grained services should be composed using fine-grained services as much as possible to take advantage of the overall services benefits. It is also recommended that a services management layer be applied for coarse-grained as well as fine-grained services.
Invocation
SOA supports two models of service invocation: synchronous and asynchronous (publish/subscribe). The choice of a synchronous or asynchronous service call depends on the availability and performance capabilities of the service provider and on the needs of the consumers.
Synchronous service calls should be used when an immediate response is required and the consumer is waiting for the response for a predetermined period. For this model to be successful, the service provider should be implemented to respond in real time for the maximum request loads. The service should always be available. Because the synchronous model is implemented to handle predetermined loads, it cannot handle unexpected, higher-priority requests. The server needs to be designed to handle all the requests simultaneously. If the service provider starts to respond more slowly, it will be unable to accept additional consumers. Such characteristics can be implemented by service management policies or using server virtualization techniques.
In the asynchronous model, consumers send requests to the server and continue to do other processing. The server returns the response whenever it completes the service, and the elapsed time depends on the server's load. The server should be implemented to queue the maximum expected number of requests, and it need not process all the service requests simultaneously.
If high-volume service requests are expected and the server can handle only a limited number of services simultaneously, then asynchronous service invocation is recommended. Asynchronous service can be easily scaled up or down by adjusting the request's queue length.
If real-time response is required, then the synchronous model is the obvious choice. However, the system should be implemented to handle a predetermined number of service requests. Adding more servers is the only way to scale up this implementation.
In most composite services, numerous applications will be involved. It is almost impossible to guarantee request/response between many applications in a synchronous service call. In such cases, asynchronous publish/subscribe or point-to-point messaging models guarantee delivery of messages and responses between multiple applications.
The asynchronous service invocation model is best suited for highly reliable, coarse-grained, document-oriented services. Synchronous service invocation is more suited for fine-grained, lightweight service calls. One drawback of asynchronous messaging is that the response order may not match the request order.
The WebLogic platform can support both synchronous and asynchronous service call models. Synchronous Web service calls use Simple Object Access Protocol (SOAP) over HTTP, and the asynchronous model uses SOAP over Java Message Service (JMS). WebLogic Integration supports synchronous, asynchronous, and WS-acknowledgement service invocation models.
Shared/Common Services
SOA promotes reuse, division of development and operational logic and tasks, and policy-based computing. These characteristics of SOA can be achieved only by designing services for reuse and by externalizing the operational policies.
Services that are useful to more than one application can be reused once they are identified, implemented, and published. Reusable services can be identified by finding commonly used services and must be implemented with special consideration for reuse. But promotion of reuse and duplication avoidance depends on sharing knowledge of the available services and on encouraging reuse within an organization.
To make services more easily reusable, don't embed application-specific policies such as security (authentication and authorization), service level agreements, quality of service (QoS), and audit information. Because policies are common across applications, policies should be configured and applied outside of the application.
WSM products provide common or shared infrastructure to manage services, policy configuration, and administration. To realize the full benefit of SOA, the appropriate WSM infrastructure could be used. Some examples of shared services:
- Shared utilities, such as security and business process orchestration (cross-company)
- Resource management, such as directory and broker
- Service management, such as provisioning, monitoring, QoS, and versioning
- Transport management, such as reliable messaging, metering, routing, and auditing
Integration/Interoperability
It is important to establish enterprise SOA standards for interoperability, data (common data model, metadata management), semantics, and security to ensure integration and interoperability between various SOA-based solutions. SOA-based solutions can be implemented using various technologies (J2EE or .Net) or using a combination of products from multiple vendors. Because SOA solutions are typically built by distributed groups specializing in their respective areas and consumed by other groups for consistency and reusability, it is essential that standards and technology are established among the groups to ensure interoperability between them. You should encapsulate legacy systems as services and adopt Service-Oriented Development for Applications (SODA).
SOA-based solution development enables enterprises to quickly share their existing legacy systems by wrapping them in services and sharing them. SOA does not require replacement systems to be built with service interfaces. A "leave and layer" approach—existing systems are first typically wrapped in services for reuse, then replaced with new systems and services—allows enterprises to choose and establish standards and guidelines on how to wrap different types of systems with a services layer.
SOA does not eliminate enterprise application integration (EAI); SOA requires integration to back-end systems. Using SOA principles for integration (Service-Oriented Integration [SOI]) allows organizations to implement flexible, reusable, standard, and shared integration. The characteristics we just discussed have different implementation choices. Each SOA-based solution requires careful analysis for choosing the best approach. Hopefully the information presented here will get you started on your way to building a successful SOA.
About the Author
Rag Ramanathan is an enterprise architect in the BEA Worldwide Enterprise Consulting group that focuses on developing SOA best practices guides for BEA consultants, partners, and customers, and delivering business value assessment for SOA. He has more than 12 years of industry experience with more than six years at BEA as a software engineer in R&D and professional services consultant. Contact Rag at soa@bea.com.
|