Delving into Service-Oriented Architecture
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.
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.
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).