Delving into Service-Oriented Architecture
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.
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.
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.
Page 2 of 3