Definition
Service-oriented architecture or SOA is a software design approach allowing enterprises to focus on business processes in their application development, rather than focusing at a lower level on integration or application issues. An SOA is a collection of reusable networked services, communicating through well-defined, platform-independent interfaces. These services provide access to data, business processes, and IT infrastructure. They allow for service provision, consumption, and lifecycle management.
Benefits
Application integration is one of the most critical issues faced by enterprise information technology managers. Traditional application development and integration approaches have been inflexible and not standards-based; they have not, therefore, facilitated an agile enterprise IT environment that can support a dynamic organisation.
Three common application integration methodologies have been point-to-point integration, enterprise message bus or middleware integration (also known as enterprise application integration or EAI), and business process-based integration. These approaches can be complex, costly, inflexible, and do not support rapid adaptation to changing business needs. SOA-based application development and integration solves many of these problems.
SOA services are implemented on standards-based technologies. Most communication middleware systems, such as Remote Procedure Call (RPC), Common Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM), Enterprise JavaBeans (EJB), and Remote Method Invocation (RMI), rely on publish, describe and discovery patterns similar to SOA. None of these implementations is perfect; issues exist with interoperability as well as with defining acceptable standards. SOA attempts to eliminate these weaknesses. For example, each middleware system has a fixed granularity: functions for RPC, objects for CORBA, and so on. Services, however, can be defined as functions, objects, applications, or other things. This makes SOA adaptable to any existing system, and does not force the system to conform to any particular level of granularity.
SOA also helps information systems move toward a “leave-and-layer” architecture, meaning that instead of altering existing systems to provide a standards-based services interface, the applications and systems are wrapped with a service interface layer, transforming them into agile services without changing existing source code. SOA covers not only information from packaged applications, custom applications and legacy systems, but also the functionality and data from IT infrastructure such as security, content management, and search, etc. SOA-based applications are faster to build because they can reuse functionality from these infrastructure services.
Best Practices
SOA is conceptually simple, and its value is evident, but implementing SOA solutions within a distributed enterprise can still be challenging. Building the right architecture and adopting the following best practices can ease the transition, and help ensure short-term and long-term success.
Coupling: Tight, Loose, or Decoupled
Coupling refers to the relationship between two services – how much each one knows about the other’s location and implementation. For instance, how much does a service consumer know about how to find and invoke a service? How is the service provider implemented? Tight coupling can create better performance, but can also cause maintenance problems (for instance, if a service provider is moved to a new server, its consumers will need to be updated). Versioning can also create coupling problems between services.
· 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. This allows the service provider’s implementation to change as needed without impacting the rest of the system, as long as its interface remains the same.
· If a service consumer “knows” the location of a service provider, this introduces location dependency or coupling between the two. 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.
Binding: Static, Brokered, or Dynamic
Service binding is the connection between two services, and the definition of how they interact – whether one calls the other directly or through an intermediary. Obviously, decisions about service binding have consequences for performance, flexibility, and maintenance.
· 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 the request to one of the service providers that has published interfaces with it. The service consumer does not need to know where the provider is or how it is implemented.
· Dynamic binding assumes that the consumer calls the provider directly. It is also assumed that the provider’s service definition and interface change frequently. Hence for every call, the service consumer must contact a service directory to request the service definition. Based on the returned information, the consumer binds to the service provider. As dynamic binding performs a lookup and then a binding, it will not perform as well as static binding.
Granularity: Fine or Coarse
A fine-grained service accepts a small amount of data (native data types or objects) and accomplishes one or a few tasks at a time. A coarse-grained service accepts a document and can implement an entire business transaction at once. Fine-grained services require more service calls but allow tighter control of activity; coarse-grained services can provide better performance and a higher-level view of operations.
Invocation: Synchronous or Asynchronous
SOA supports two models of service invocation, synchronous (RPC) and asynchronous (document). The choice of synchronous or asynchronous service calls depends on the availability and performance capabilities of the service provider, and on the consumers’ needs.
· Use synchronous service calls when an immediate response is required. The service consumer blocks while waiting for the response.
· In the asynchronous model, consumers send requests and continue with other processing. The service provider responds when it has completed the service; the elapsed time depends on the server load.
· In most composite services, numerous applications will be involved. It is almost impossible to guarantee request/response times between many applications using synchronous service calls. In those cases, asynchronous publish/subscribe or point-to-point messaging model guarantees 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.
Shared or Common Services
SOA promotes software reuse, division of development and operational logic and tasks, and policy-based computing. These characteristics of SOA can be achieved by designing services for reuse and by externalising operational policies.
· Find services that are useful to more than one application and publish them. Promoting reuse and avoiding duplication depend upon sharing knowledge of the available services, and upon encouraging reuse within the organisation.
· Reusable services must be implemented carefully. Do not embed application-specific policies such as security (authentication and authorisation), Service Level Agreement (SLA), Quality of Service (QoS), and audit. Since policies are common across applications, policies should be configured and applied outside of the application.
Organisational Best Practices
· Get business buy-in.
· Establish an SOA Center of Excellence (COE), staffed with cross-functional architects and business analysts with strong technical, communication and business expertise. The COE:
· Enforces governance for reuse, standards, and IT policies.
· Fosters the business-technical feedback loop.
· Publishes design principles, guidelines, best practices, patterns, and templates.
· Centralises architecture and standards for federated implementation and management.
· Promotes Service-oriented Development for Applications (SODA).
· Manages assets, publishes services, and communicates across groups.
· Incrementally develop and deploy SOA-based solutions while developing the shared service infrastructure.
· Fund shared services infrastructure, remembering that Return on Investment (ROI) is realised long-term not short-term. SOA is a strategic solution that can also solve tactical problems. Business units share the infrastructure and leverage common investments.
· Plan for shared infrastructure cost recovery, metering and charging for services.
· Start with data services, and plan to encapsulate legacy systems as services.
· Use a business service perspective for selecting and implementing coarse-grained services. Business processes with high maintenance and operational costs are ideal candidates for the benefits of SOA.
· Plan for any necessary IT training; the network-centric, policy-based, distributed nature of SOA-based applications requires IT groups to understand the administrative and support differences between traditional applications and SOA-based applications.
Summary
Service-oriented architecture can provide many benefits to an organisation – reusable, platform-independent business services, standards-based development, and the ability to make changes quickly when necessary to keep up with the speed of business. Most of the challenges inherent in implementing an SOA are organisational rather than technical, and can be minimised by following the best practices recommended here. There are situations in which SOA’s pluses do not come into play – with homogeneous application environments, stand-alone applications, or short-lived applications, for example. But, for many enterprise application integration environments, SOA delivers a clear advantage.
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 him at soa@bea.com. |
