Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In many respects, SOA is an evolution of the fundamental tenets governing component-based development (CBD). It also represents a quantum leap in bringing business and information technology into closer alignment through a set of SOA services grounded in business goals in support of business processes. While SOA services are visible to the service consumer, their underlying components are transparent. For the service provider, the design of components, their service exposure and management reflect key architecture and design decisions that enable services in SOA. Making these decisions requires an understanding of an SOA’s components and SOA modeling to identify, classify, specify, and structure service-enabled components. In this article we briefly discuss the relationship between CBD and SOA, followed by a discussion of SOA architecture and design decisions. We describe the basic SOA components and building blocks, and a prescriptive technique for performing SOA modeling, analysis, and design for services, where services are realized using components.
Introduction
A brief review of object-oriented (OO) development and CBD will help you understand the evolution of SOA for service-oriented development. The world of objects started with the introduction of object-oriented programming languages and matured into modeling, later adding techniques for design and then maturing into OO analysis and design (OOAD) methods. Infrastructure services, tools, development platforms, patterns, and reference architectures followed.
Component-based development (CBD) ensued, offering a new approach to the design, construction, implementation, and evolution of software applications. Applications are assembled using components from a variety of sources and the components are written in different programming languages and different development environments, and run on different platforms. Just as with OO development, infrastructure services, tools, development platforms, and patterns matured to make CBD a reality.
Both OO and CBD address software economies of scale that require reuse in software development. The achievement economies of scale in software production and deployment have been elusive. Object-oriented development is an enabler, component-based development mandatory. CBD provides an opportunity for greater reuse than what is possible with OO development. SOA, with the underpinnings of both OO development and CBD, provides an even greater opportunity for reuse. SOA becomes a new mandate for achieving economies of scale in software engineering.
Evolution of SOA
The Internet and XML standardization efforts gave way to the need for a service definition and description published by a service provider (SP) that can be located and invoked by a service consumer (SC). The service description can be implemented by a number of service providers, each offering various choices of qualities of service (QoS) based on technical requirements in the areas of availability, performance, scalability, and security. The invocation can be across Internet or intranet in a distributed object connotation and standards such as WSDL and SOAP have been created.
The roles of the SC and the SP are illustrated in Figure 1. Web services standards and technologies pave the way and breathe life into the architectural style of SOA. Infrastructure services in areas of service management and service security are required, along with new technologies to make the economies of scale made possible by SOA a reality.
Figure 1.
SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions. The inherent, salient advantage of today’s service descriptions is the decoupling of the SP and SC through open standards and protocols, and the deferment of implementation decisions from the SC to the SP. Moreover, individual or collections of services that enjoy various levels of granularity can be combined and choreographed to produce “new” composite services that not only introduce new levels of reuse but also allow the dynamic reconfiguration of business systems.
Hence, service-oriented development, which SOA enables, is an evolutionary software engineering approach enabled by component-based and object-oriented development. However, the incredibly potent fusion of business and IT is a quantum leap. The flexibility of binding an SC to a new SP, based on changing QoS needs and the stability of interactions through SD publication, and its invocation through standard protocols is a prerequisite for an architecture where flexibility and economies of scale are the primary movers.
SOA encourages the closure of the business-IT gap by emphasizing the reuse of rationalized, normalized services and introducing flexibility that allows end-to-end business process modeling and implementation. This flexibility arises through the ensuing ability to choreograph existing composite services at near real time, i.e., “right-time”, using business analyst tools, such as IBM’s WebSphere Business Integration (WBI) BPEL modeler.
Component-Based Development and Service-Oriented Architecture
The concepts and disciplines of OO development and CBD should be applied to provide the appropriate frameworks guiding the design and development of SOA services.
Multiple, possibly competing, service providers often realize a service description. The services, in turn, need to be “powered” by a functional piece, or pieces, of software that lends itself to a component-based view of the world. Within components we can find the design principles of object-orientation defining the internal structures of components. Thus, service modeling is about identifying the right services, organizing them in a manageable hierarchy of composite services (smaller grained often supported larger grained), choreographing them together for supporting a business process. On the provider side, these services are either allocated directly to component-based containers for realization of their functionality, or realized by adapting existing legacy functionality.
This is the fundamental evolution in service-oriented software engineering: the service consumer doesn’t have to be concerned with the implementation or realization of the service, as long as it supports the required functionality and quality of service. This is called the Consumer View. Alternatively, the Provider View offers a perspective on how to design the realization of the component that offers the services; its architectural decisions and designs.
One key differentiation with more traditional OO is in the fact that we are no longer creating large object models, but rather designing the internals of larger-grained, business-aligned component boundaries, through finer-grained object-orientation.
SOA introduces two views on components and services: the service consumer and the service provider (see Figure 2).
Figure 2.
Components are of no concern to service consumers as long as their service-level agreements and contracts on functional and non-functional requirements are fulfilled. Service providers need to design a service realization that will meet those requirements through decisions on how they contain, manage, and implement the service description. The inward view is that of a user or consumer who sees only the service available through the provider, and the outward view where the services provider creates components that provide the services through their interfaces. In order to so, they require an internal set of finer-grained, or peer, components that will participate in the collaborations needed to fulfill the services. Thus, within the service provider components, we will have domain-level components that correspond closely to domain object models in the traditional object-oriented sense and are implemented through standard component container mechanisms such as application servers.
The SOA model is fractal. That is, a service can be composed of finer-grained services such as those providing technical utility such as logging, security, or authentication. This fractal granularity is illustrated in Figure 3.
Figure 3.
In addition to services that provide technical utility, there are services that may be created in the context of a project, or services that are created for utility by a business line or line of business. Each of these services can be used to fulfill a business process or a business transaction. The components that are integral to services are also fractal. This requires that both services and components be designed with the appropriate level of granularity, which is a key SOA design decision.
SOA Architectural and Design Decisions
Several architecture and design decisions are essential for SOA to meet its stated goals and benefits. The SOA architectural decisions generally relate to the choice of technologies and products necessary to meet the quality of service attributes required of a business process. Design choices focus on choices that must be made about services using the technique described later on service-oriented analysis and design. Some of the key decisions are:
- Service identification design decisions are essential for SOA success. Just as the proliferation of objects did not allow organizations to realize economies of scale as reuse is limited largely because of the lack of business utility for object proliferation the same is true if services are proliferated. Many early adopters of SOA and Web services realized quickly that the proliferation of Web services does not make for a sound SOA model. These design choices are made during the service-oriented analysis and design described later in this article.
- Container design and realization architecture and design decisions are critical for a service to provide the critical qualities for extensibility and maintainability.
- Granularity design choices about services must be matched to the level of reusability and flexibility required given the context. Larger-grained services can help encapsulate changes in finer-grained technical services that can tend to change more frequently than the higher-level business- level service interface. Factors of flexibility will be key criteria for encapsulation rather than merely the encapsulation of function.
- State of service often requires both architecture and design decisions on the stateless nature of services, yet state must be maintained. This is often addressed by making architectural decisions on choreography engines (e.g., a BPEL engine) and design choices on the stateless nature of a proposed business service.
- Loose coupling and dynamic reconfiguration are a design decision that requires the decoupling of interfaces from implementation and protocol realization via open standards. The connection between service consumers and service providers needs to be stable and well structured and yet flexible and readily reconfigurable. Re-configurable means that existing service consumers and service providers can be re-assembled with their functionality intact to obtain business solutions in different technical environments and with different operational constraints with new business partners across a value chain. Therefore, integration alone is no longer adequate; dynamic reconfiguration is the name of the game and needs to be pervasive along a spectrum of support in areas of infrastructure (i.e., the enabling software infrastructure), tools, development platforms, reference architectures, patterns, methods and industry-specific reference models.
SOA Layers: The Components of an SOA
So far we’ve explored the relationship between services and components and have said that components can be large-grained enterprise or business-line components and can be used to realize the functionality and management of exposed services as interfaces. That is, we have discussed components used to realize services. Now we will look at SOA components, not the components used to realize services in SOA.
The major components of an SOA are:
- Services portfolio: Describes the business services in SOA. This includes a list, classification and hierarchy of services defined through the technique of service-oriented analysis and design described later.
- Components: Provide the functional realization of the services.
- Service providers, service consumers, and optionally, the service broker(s): With their service registries where service definitions and descriptions are published.
- SOA layers: Where components and services reside.
Figure 4 illustrates the SOA layers. For each of these layers, there are design and architectural decisions to be made.
Figure 4.
Layer 1, the bottom layer, describes operational systems. This layer contains existing systems or applications, including existing CRM and ERP packaged applications, legacy applications, and “older” object-oriented system implementations, as well as business-intelligence applications. The composite layered architecture of an SOA can leverage existing systems, integrate them using service-oriented integration.
Layer 2, the component layer, used container based technologies and designs in typical component-based development.
Layer 3 provides for the mechanism to take enterprise-scale components, business unit-specific components, and in some cases project-specific components and provides services through their interfaces. The interfaces get exported out as service descriptions in this layer, where services exist in isolation or as composite services.
Level 4 is an evolution of service composition into flows or choreographies of services bundled into a flow to act as an application. These applications support specific use cases and business processes. Here, visual flow composition tools can be used for design of application flow.
Layer 5, the presentation layer, is usually out of scope for an SOA. However, it is depicted because some recent standards such as Web Services for Remote Portlets version 2.0 may indeed leverage Web services at the application interface or presentation level. It is also important to note that SOA decouples the user interface from the components.
Level 6 enables the integration of services through the introduction of reliable and intelligent routing, protocol mediation, and other transformation mechanisms, often described as the enterprise service bus.
Level 7 ensures quality of service through sense-and respond mechanisms and tools that monitor the health of SOA applications, including the all-important standards implementations of WS-Management.
Service-Oriented Modeling, Analysis, and Design
So far we’ve spoken about the end result of SOA, architecture with a composite set of business-aligned services. To create SOA, we need to identify, specify, and design services and their choreography from the angles of consumer and provider. The modeling, analysis, and design of services are not quite the same as the world of OO. There are additional activities that need to be done.
Major activities of a service-oriented modeling approach were described in an IBM Redbook. Also, Zimmerman et al. (see References) describe a case for, and context of, service-oriented analysis and design (SOAD). In this section we describe these key-differentiating activities and provide a technique for the modeling, analysis and design of SOA services. Specifically, we examine how the services of an SOA are identified, specified, and realized.
An SOA does not start only from the bottom-up as is often the case with a merely Web services based approach. There are a number of important activities and decisions that influence not just integration architecture but enterprise and application architectures as well. They include the activities from both the consumer and provider views described in Table 1.
Table 1.
Service identification consists of a combination of top-down, bottom-up, and middle-out techniques. In the top-down view, a blueprint of business use cases provides the specification for business services. This top-down process is often referred to as domain decomposition, the decomposition of the business domain into its functional areas and subsystems, including its flow or process decomposition into processes, sub-processes and high-level business use cases. These use cases are often very good candidates for business services exposed at the edge of the enterprise.
In the bottom-up portion of the process, or existing asset analysis, existing systems are analyzed and selected as viable candidates for providing lower-cost solutions to the implementation of underlying service functionality that supports the business process. In this process, we analyze and leverage APIs, transactions, and modules from legacy and packaged applications. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality.
The middle-out view consists of goal service analysis to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. It ties services to goals and sub-goals, key performance indicators, and metrics.
Service classification is launched once services have been identified. It is important to start service classification in a service hierarchy, reflecting the composite or fractal nature of services: services can and should be composed of finer-grained components and services. Classification helps determine composition and layering as well as coordinates building of interdependent services base don the hierarchy. Also, it helps alleviate the service proliferation syndrome in which an increasing number of small-grained services get defined, designed, and deployed with very little governance, resulting in major performance, scalability, and management issues. More importantly, service proliferation fails to provide services that are useful to the business, which would allow for the economies of scale to be achieved.
Subsystem analysis takes the subsystems found above during domain decomposition and specifies the interdependencies and flow between the subsystems, and puts the use cases identified during domain decomposition as exposed services on the subsystem interface. The analysis of the subsystem consists of creating object models to represent the internal workings and designs of the containing subsystems that will expose the services and realize them. The design construct of “subsystem” will then be realized as an implementation construct of a large-grained component realizing the services in the following activity.
Component specification is the next major activity; the details of the component that will implement the service(s) are specified: data, rules, services, configurable profile, and variations. Messaging and Events specifications and management definition occur at this step.
Service allocation is the process of assigning services to containers that will realize their published functionality. Structuring of components occurs when we use patterns to construct enterprise components with a combination of mediators, facade, rule objects, and configurable profiles and factories. Service allocation also consists of assigning the services and the components that realize them to the layers in your SOA. Allocation of components and services to layers in the SOA is a key task that will require the documentation and resolution of architectural decisions that relate not only to the application architecture but also to the technical operational architecture designed and used to support the SOA realization at runtime.
Service realization recognizes that the software that realizes a given service must be selected or custom built. Other options that are available include integration, transformation, subscription, and outsourcing of parts of the functionality using Web services. Here you decide which legacy system module will be used to realize a given service and which services will be built from the “ground-up.” Other realization decisions for services outside of business functionality include: security, management and monitoring of services.
Conclusions
SOA extends CBD into the realm of ubiquity and pervasive access through extending the reach of callable components by using non-proprietary, interoperable protocols, service descriptions that separate of interface from implementation. SOA will have a more profound impact on software engineering than what we have been accustomed to with object-oriented and component-based development. Executing a sound service-oriented analysis and design technique will be a critical success factor to make this promise a reality as SOA itself has components and layers that need to be defined and designed.
References
- Endrei, M.; Ang, J.; Arsanjani, A.; Chua, Sook; Comte, Philippe; Krogdahl, Pal; Luo, Min; and Newling, Tony. (2004) Patterns: Service-oriented Architecture and Web Services. IBM Redbook, ISBN 073845317X. www.redbooks.ibm.com/redbooks/SG246303/ wwhelp/wwhimpl/java/html/wwhelp.htm
- Levi, K.; Arsanjani, A. “A Goal-oriented Approach to Enterprise Component Identification and Specification.” Communications of the ACM, Oct 2003.
- Arsanjani, A. “The Enterprise Component Pattern.” Proceedings of Pattern Languages of Programming, 2000.
- Zimmerman, O.; Korgdahl,P.; and C. Gee, C. “Elements of Service-oriented Analysis and Design”, IBM developerworks. June 4, 2004.
- Keen, Martin; Bishop, Susan; Hopkins, Alan; Milinski, Sven; Nott, Chris; Robinson, Rick; Adams, Jonathan; and Verschueren, Paul. ( 2004) Patterns: Implementing an SOA with the Enterprise Service Bus. IBM Redbook ISBN SG24-6346-00.
