Chapter 4. Understanding SOA
4.1 The Four Characteristics of SOA
4.2 The Four Common Types of SOA
The focus of this chapter is to establish the link between service-orientation and technology architecture, establish distinct SOA characteristics and types, and raise key project delivery considerations.
Note
Several of the upcoming sections make reference to clouds and cloud computing in general. If you are new to cloud computing, you can find introductory content at www.whatiscloud.com and cloud computing patterns at www.cloudpatterns.org. More comprehensive coverage is provided in the Cloud Computing: Concepts, Technology & Architecture and Cloud Computing Design Patterns titles that are part of the Prentice Hall Service Technology Series from Thomas Erl.
Introduction to SOA
Let’s briefly recap some of the topics covered in Chapter 3 to clearly establish how they relate to each other and how they specifically lead to a definition of SOA:
• There is a set of strategic goals associated with service-oriented computing.
• These goals represent a specific target state.
• Service-orientation is the paradigm that provides a proven method for achieving this target state.
• When we apply service-orientation to the design of software, we build units of logic called “services.”
• Service-oriented solutions are comprised of one or more services.
We have established that a solution is considered service-oriented after service-orientation has been applied to a meaningful extent. A mere understanding of the design paradigm, however, is insufficient. To apply service-orientation consistently and successfully requires a technology architecture customized to accommodate its design preferences, initially when services are first delivered and especially when collections of services are accumulated and assembled into complex compositions.
• To build successful service-oriented solutions, we need a distributed technology architecture with specific characteristics.
• These characteristics distinguish the technology architecture as being service-oriented. This is SOA.
Service-orientation is fundamentally about attaining the specific target state we established toward the end of Chapter 3. It asks that we take extra design considerations into account with everything we build so that all the moving parts of a given service-oriented solution support the realization of this state and foster its growth and evolution. These design considerations carry over into the supporting technology architecture, which must have a distinct set of characteristics that enable the target state and inherently accommodate ongoing change within that target environment.
4.1 The Four Characteristics of SOA
Service-oriented technology architecture must have certain properties that fulfill the fundamental requirements for an automation solution comprised of services to which service-orientation design principles have been applied. These four characteristics further help distinguish SOA from other architectural models.
Note
As we explore each of these characteristics individually, keep in mind that in real-world implementations the extent to which these characteristics can be attained will likely vary.
Business-Driven
Technology architectures are commonly designed in support of solutions delivered to fulfill tactical (short-term) business requirements. Because the over-arching, strategic (long-term) business goals of the organization aren’t taken into consideration when the architecture is defined, this approach can result in a technical environment that, over time, becomes out of alignment with the organization’s business direction and requirements.
This gradual separation of business and technology results in a technology architecture with diminishing potential to fulfill business requirements and one that is increasingly difficult to adapt to changing business needs (Figure 4.1).
Figure 4.1 A technology architecture (A) is often delivered in alignment with the current state of a business but can be incapable of changing in alignment with how the business evolves. As business and technology architectures become increasingly out of sync, business requirement fulfillment decreases, often to the point that a whole new technology architecture (B) is needed, which effectively resets this cycle.
When a technology architecture is business-driven, the overarching business vision, goals, and requirements are positioned as the basis for and the primary influence of the architectural model. This maximizes the potential alignment of technology and business and allows for a technology architecture that can evolve in tandem with the organization as a whole (Figure 4.2). The result is a continual increase in the value and lifespan of the architecture.
Figure 4.2 By defining a strategic, business-centric scope to the technology architecture, it can be kept in constant sync with how the business evolves over time.
Vendor-Neutral
Designing a service-oriented technology architecture around one particular vendor platform can lead to an implementation that inadvertently inherits proprietary characteristics. This can end up inhibiting the future evolution of an inventory architecture in response to technology innovations that become available from other vendors.
An inhibitive technology architecture is unable to evolve and expand in response to changing automation requirements, which can result in the architecture having a limited lifespan after which it needs to be replaced to remain effective (Figure 4.3).
Figure 4.3 Vendor-centric technology architectures are often bound to corresponding vendor platform roadmaps. This can reduce opportunities to leverage technology innovations provided by other vendor platforms and can result in the need to eventually replace the architecture entirely with a new vendor implementation (which starts the cycle over again).
It is in the best interest of an organization to base the design of a service-oriented architecture on a model that is in alignment with the primary SOA vendor platforms, yet neutral to all of them. A vendor-neutral architectural model can be derived from a vendor-neutral design paradigm used to build the solution logic the architecture will be responsible for supporting (Figure 4.4). The service-orientation paradigm provides such an approach, in that it is derived from and applicable to real-world technology platforms while remaining neutral to them.
Figure 4.4 If the architectural model is designed to be and remain neutral to vendor platforms, it maintains the freedom to diversify its implementation by leveraging multiple vendor technology innovations. This increases the longevity of the architecture as it is allowed to augment and evolve in response to changing requirements.
Just because an architecture is classified as vendor-neutral doesn’t mean it is also aligned with current vendor technology. Some models produced by independent efforts are out of synch with the manner in which mainstream SOA technology exists today and is expected to evolve in the future and can therefore be just as inhibitive as vendor-specific models.
Enterprise-Centric
The fact that service-oriented solutions are based on a distributed architecture doesn’t mean that there still isn’t the constant danger of creating new silos within an enterprise when building poorly designed services, as illustrated in Figure 4.5.
Figure 4.5 Single-purpose services delivered to automate specific business processes can end up establishing silos within the enterprise.
When you apply service-orientation, services are positioned as enterprise resources, which implies that service logic is designed with the following primary characteristics:
• The logic is available beyond a specific implementation boundary.
• The logic is designed according to established design principles and enterprise standards.
Essentially, the body of logic is classified as a resource of the enterprise. This does not necessarily make it an enterprise-wide resource or one that must be used throughout an entire technical environment. An enterprise resource is simply logic positioned as an IT asset; an extension of the enterprise that does not belong solely to any one application or solution.
To leverage services as enterprise resources, the underlying technology architecture must establish a model that is natively based on the assumption that software programs delivered as services will be shared by other parts of the enterprise or will be part of larger solutions that include shared services. This baseline requirement places an emphasis on standardizing parts of the architecture so that service reuse and interoperability can be continually fostered (Figure 4.6).
Figure 4.6 When services are positioned as enterprise resources, they no longer create or reside in silos. Instead they are made available to a broader scope of utilization by being part of a service inventory.
Composition-Centric
More so than in previous distributed computing paradigms, service-orientation places an emphasis on designing software programs as not just reusable resources, but as flexible resources that can be plugged into different aggregate structures for a variety of service-oriented solutions.
To accomplish this, services must be composable. As advocated by the Service Composability (302) principle, this means that services must be capable of being pulled into a variety of composition designs, regardless of whether or not they are initially required to participate in a composition when they are first delivered (Figure 4.7).
Figure 4.7 Services within the same service inventory are composed into different configurations. The highlighted service is reused by multiple compositions to automate different business processes.
To support native composability, the underlying technology architecture must be prepared to enable a range of simple and complex composition designs. Architectural extensions (and related infrastructure extensions) pertaining to scalability, reliability, and runtime data exchange processing and integrity are essential to support this key characteristic.
Design Priorities
A valuable perspective of how service-orientation relates to SOA and of how the formalization of this relationship results in a set of design priorities was provided by the publication of the “SOA Manifesto.” Have a look at the following excerpt:
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
Business value over technical strategy
Strategic goals over project-specific benefits
Intrinsic interoperability over custom integration
Shared services over specific-purpose implementations
Flexibility over optimization
Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
It is evident how these design priorities are directly supported by the service-orientation design paradigm and the service-oriented architectural model. This is further explored in the “Annotated SOA Manifesto” that was published at www.soa-manifesto.com and is also provided in Appendix D of this book.
4.2 The Four Common Types of SOA
As we’ve already established, every software program ends up being comprised of and residing in some form of architectural combination of resources, technologies, and platforms (infrastructure-related or otherwise). If we take the time to customize these architectural elements, we can establish a refined and standardized environment for the implementation of (also customized) software programs.
The intentional design of technology architecture is very important to service-oriented computing. It is essential to establishing an environment within which services can be repeatedly recomposed to maximize business requirements fulfillment. The strategic benefit to customizing the scope, context, and boundary of an architecture can be significant.
To better understand the basic mechanics of SOA, we now need to study the common types of technology architectures that exist within a typical service-oriented environment:
• Service Architecture – The architecture of a single service.
• Service Composition Architecture – The architecture of a set of services assembled into a service composition.
• Service Inventory Architecture – The architecture that supports a collection of related services that are independently standardized and governed.
• Service-Oriented Enterprise Architecture – The architecture of the enterprise itself, to whatever extent it is service-oriented.
The service-oriented enterprise architecture represents a parent architecture that encompasses all others. The environment and conventions established by this parent platform are carried over into the service inventory architecture implementations that may reside within a single enterprise environment. These inventories further introduce new and more specific architectural elements (such as runtime platforms and middleware) that then form the foundation of service and composition architectures implemented within an inventory’s boundary.
As a result, a natural form of architectural inheritance is formed whereby more granular architecture implementations inherit elements from less granular ones (Figure 4.8). This relationship between architecture types is good to keep in mind as it can identify potential (positive and negative) dependencies that may exist.
Figure 4.8 The layered SOA model establishes the four common SOA types: service architecture, service composition architecture, service inventory architecture, and service-oriented enterprise architecture.
The following section explores the architecture types individually and concludes by highlighting links between these characteristics and common SOA design priorities.
Service Architecture
A technology architecture limited to the physical design of a software program designed as a service is referred to as the service architecture. This form of technology architecture is comparable in scope to a component architecture, except that it will typically rely on a greater amount of infrastructure extensions to support its need for increased reliability, performance, scalability, behavioral predictability, and especially its need for increased autonomy. The scope of a service architecture will also tend to be larger because a service can, among other things, encompass multiple components (Figure 4.9).
Figure 4.9 An example of a high-level service architecture view for the Accounts service, depicting the parts of the surrounding infrastructure utilized to fulfill the functional requirements of all capabilities. Additional views can be created to show only those architectural elements related to the processing of specific capabilities. Further detail, such as data flow and security requirements, would normally also be included.
Whereas it was not always that common to document a separate architecture for a component in traditional distributed applications, the importance of producing services that need to exist as independent and highly self-sufficient and self-contained software programs requires that each be individually designed.
Service architecture specifications are typically owned by service custodians and, in support of the Service Abstraction (294) design principle, their contents are often protected and hidden from other project team members (Figure 4.10).
Figure 4.10 The custodian of the Accounts service intentionally limits access to architecture documentation. As a result, service consumer designers are only privy to published service contract documents.
The application of design standards and other service-orientation design principles further affects the depth and detail to which a service’s technology architecture may need to be defined (Figure 4.11). For example, implementation considerations raised by the Service Autonomy (297) and Service Statelessness (298) principles can require a service architecture to extend deeply into its surrounding infrastructure by defining exactly what physical environment it is deployed within, what resources it needs to access, what other parts of the enterprise may be accessing those same resources, and what extensions from the infrastructure it can use to defer or store data it is responsible for processing.
Figure 4.11 Custom design standards and service-orientation design principles are applied to establish a specific set of design characteristics within the Accounts service architecture.
A central part of a service architecture is typically its API. Following standard service-oriented design processes, the service contract is generally the first part of a service to be physically delivered. The capabilities expressed by the contract further dictate the scope and nature of its underlying logic and the processing requirements that will need to be supported by its implementation (Figure 4.12).
Figure 4.12 The service contract is a fundamental part of the Accounts service architecture. Its definition gives the service a public identity and helps express its functional scope. Specifically, the WSDL document (A) expresses operations that correspond to segments of functionality (B) within the underlying Accounts service logic. The logic, in turn, accesses other resources in the enterprise to carry out those functions (C). To accomplish this, the WSDL document provides data exchange definitions via input and output message types established in separate XML schema documents (D).
This is why some consideration is given to implementation during the service modeling phase. The details documented during this analysis stage are carried forth into design, and much of this information can make its way into the official architecture definition.
Note
Many organizations use standard service profile documents to collect and maintain information about a service throughout its lifespan. Chapter 15 of SOA: Principles of Service Design explains the service profile document and provides a sample template.
Another infrastructure-related aspect of service design that may be part of a service architecture is any dependencies the service may have on service agents—event-driven intermediary programs capable of transparently intercepting and processing messages sent to or from a service.
Within a service architecture the specific agent programs may be identified along with runtime information as to how message contents are processed or even altered by agent involvement. Service agents may themselves also have architecture specifications that can be referenced by the service architecture (Figure 4.13).
Figure 4.13 A variety of service agents are part of the Accounts service architecture. Some perform general processing of all data whereas others are specific to input or output data flow.
A key aspect of any service architecture is the fact that the functionality offered by a service resides within one or more individual capabilities. This often requires the architecture definition itself to be taken to the capability level.
Each service capability encapsulates its own piece of logic. Some of this logic may be custom-developed for the service, whereas other capabilities may need to access one or more legacy resources. Therefore, individual capabilities end up with their own, individual designs that may need to be so detailed that they are documented as separate “capability architectures.” However, all relate back to the parent service architecture.
Service Composition Architecture
The fundamental purpose of delivering a series of independent services is so they can be combined into service compositions, fully functional solutions capable of automating larger, more complex business tasks (Figure 4.14).
Figure 4.14 The Accounts service composition from a modeling perspective. The numbered arrows indicate the sequence of data flow and service interaction required for the Add capability to compose capabilities within the Client and Invoice services.
Each service composition has a corresponding service composition architecture. In much the same way an application architecture for a distributed system includes the individual architecture definitions of its components, this form of architecture encompasses the service architectures of all participating services (Figure 4.15).
Figure 4.15 The same Accounts service composition from Figure 4.14 viewed from a physical architecture perspective illustrating how each composition member’s underlying resources provide the functionality required to automate the process logic represented by the Accounts service’s Add capability.
Standard composition terminology defines two basic roles that services can assume within a composition. The service responsible for composing others takes on the role of composition controller, whereas composed services are referred to as composition members.
A composition architecture (especially one that composes service capabilities that encapsulate disparate legacy systems) may be compared to a traditional integration architecture. This comparison is usually only valid in scope, as the design considerations emphasized by service-orientation ensure that the design of a service composition is much different than that of integrated applications.
For example, one difference in how composition architectures are documented is in the extent of detail they include about agnostic services involved in the composition. Because these types of service architecture specifications are often guarded—as per the requirements raised by the Service Abstraction (294) principle—a composition architecture may only be able to make reference to the technical interface documents and service-level agreement (SLA)-related information published as part of the service’s public contract (Figure 4.16).
Figure 4.16 The physical service architecture view from Figure 4.15 is not available to the designer of the Accounts service. Instead, only the information published in the contracts for the Invoice and Client services can be accessed.
Another rather unique aspect of service composition architecture is that a composition may find itself a nested part of a larger parent composition, and therefore one composition architecture may encompass or reference another (Figure 4.17).
Figure 4.17 The Accounts service finds itself nested within the larger Annual Reports composition that composes the Accounts Get History capability which, in turn, composes capabilities within the Client and Invoice services.
Service composition architectures are much more than just an accumulation of individual service architectures (or contracts). A newly created composition is usually accompanied by a non-agnostic task service that is positioned as the composition controller. The details of this service are less private, and its design is an integral part of the architecture because it provides the composition logic to invoke and interact with all identified composition members.
Furthermore, the business process the service is required to automate may involve the need for composition logic capable of dealing with multiple runtime scenarios (exception-related or otherwise), each of which may result in a different composition configuration. These scenarios and their related service activities and message paths are a common part of composition designs. They need to be understood and mapped out in advance so that the composition logic is fully prepared to deal with the range of runtime situations it may need to face (Figure 4.18).
Figure 4.18 A given business process may need to be automated by a range of service compositions in order to accommodate different runtime scenarios. In this case, alternative composition logic within the Annual Report’s Revenue capability kicks in to deal with an exception condition. As a result, the Notifications service is invoked prior to the Accounts service even being included in the composition.
Finally, the composition will rely on the activity management abilities of the underlying runtime environment responsible for hosting the composition members. Security, transaction management, reliable messaging, and other infrastructure extensions, such as support for sophisticated message routing, may all find their way into a composition architecture specification.
Service Inventory Architecture
Services delivered independently or as part of compositions by different IT projects risk establishing redundancy and non-standardized functional expression and data representation. This can lead to a non-federated enterprise in which clusters of services mimic an environment comprised of traditional siloed applications.
The result is that though often classified as a service-oriented architecture, many of the traditional challenges associated with design disparity, transformation, and integration continue to emerge and undermine strategic service-oriented computing goals.
As explained in Chapter 3, a service inventory is a collection of independently standardized and governed services delivered within a pre-defined architectural boundary. This collection represents a meaningful scope that exceeds the processing boundary of a single business process and ideally spans numerous business processes.
Ideally, the service inventory is first conceptually modeled, leading to the creation of a service inventory blueprint. It is often this blueprint that ends up defining the required scope of the architecture type referred to as a service inventory architecture (Figure 4.19).
Figure 4.19 Ultimately, the services within an inventory can be composed and recomposed, as represented by different composition architectures. To that end, many of the design patterns in this book need to be consistently applied within the boundary of the service inventory.
From an architectural perspective, the service inventory can represent a concrete boundary for a standardized architecture implementation. That means that because the services within an inventory are standardized, so are the technologies and extensions provided by the underlying architecture.
As previously mentioned, the scope of a service inventory can be enterprise-wide, or it can represent a domain within the enterprise. For that reason, this type of architecture is not called a “domain architecture.” It relates to the scope of the inventory boundary, which may encompass multiple domains.
It is difficult to compare a service inventory architecture with traditional types of architecture because the concept of an inventory has not been common. The closest candidate would be an integration architecture that represents some significant segment of an enterprise. However, this comparison would be only relevant in scope, as service-orientation design characteristics and related standardization efforts strive to turn a service inventory into a homogenous environment where integration, as a separate process, is not required to achieve connectivity.
Service-Oriented Enterprise Architecture
This form of technology architecture essentially represents all service, service composition, and service inventory architectures that reside within a specific enterprise.
A service-oriented enterprise architecture is comparable to a traditional enterprise technical architecture only when most or all of an enterprise’s technical environments are service-oriented. Otherwise it may simply be a documentation of the parts of the enterprise that have adopted SOA, in which case it exists as a subset of the parent enterprise technology architecture.
In multi-inventory environments or in environments where standardization efforts were not fully successful, a service-oriented enterprise architecture specification will further document any transformation points and design disparity that may also exist.
Additionally, the service-oriented enterprise architecture can further establish enterprise-wide design standards and conventions to which all service, composition, and inventory architecture implementations need to comply, and which may also need to be referenced in the corresponding architecture specifications.
Note
This section is focused on technology architecture. However, it is worth pointing out that a “complete” service-oriented enterprise architecture would encompass both the technology and business architecture of an enterprise (much like traditional enterprise architecture).
Furthermore, additional types of service-oriented architecture can exist, especially when spanning beyond a private enterprise environment. Examples can include interbusiness service architecture, service-oriented community architecture and various hybrid architectures that encompass IT resources from external cloud computing environments.
4.3 The End Result of Service-Orientation and SOA
Business communities and the IT industry have an endless bi-directional relationship where each influences the other (Figure 4.20). Business demands and trends create automation requirements that the IT community strives to fulfill. New method and technology innovations produced by the IT community help inspire organizations to improve their existing business and even try out new lines of business. (The advent of cloud computing is a good example of the latter.)
Figure 4.20 The endless progress cycle establishes the dynamics between the business and IT communities.
The IT industry has been through the cycle depicted in Figure 4.20 many times. Each iteration has brought about change and generally an increase in the sophistication and complexity of technology platforms.
Sometimes a series of iterations through this progress cycle leads to a foundational shift in the overall approach to automation and computing itself. The emergence of major platforms and frameworks, such as object-orientation and enterprise application integration, are examples of this. Significant changes like these represent an accumulation of technologies and methods and can therefore be considered landmarks in the evolution of IT itself. Each also results in the formation of distinct technology architecture requirements.
Service-oriented computing is no exception. The platform it establishes provides the potential to achieve significant strategic benefits that are a reflection of what business communities are currently demanding, as represented by the strategic goals and benefits previously described in Chapter 3.
It is the target state resulting from the attainment of these strategic goals that an adoption of service-orientation attempts to achieve. In other words, they represent the desired end result of applying the method of service-orientation.
How then does this relate to service-oriented technology architecture? Figure 4.21 hints at how the pursuit of these specific goals results in a series of impacts onto all architecture types brought upon by the application of service-orientation.
Figure 4.21 The common strategic goals and benefits of service-oriented computing are realized through the application of service-orientation. This, in turn, impacts the demands and requirements placed upon the four types of service-oriented technology architectures. (Note that the three goals on the right represent the ultimate target benefits sought in a typical SOA initiative.)
For those of you interested in how each of the strategic goals specifically influences the four types of service-oriented architecture, Chapter 23 in SOA Design Patterns documents the individual impacts.
Ultimately, the successful implementation of service-oriented architectures will support and maintain the benefits associated with the strategic goals of service-oriented computing. As illustrated in Figure 4.22, the progress cycle that continually transpires between business and IT communities results in constant change. Standardized, optimized, and overall robust service-oriented architectures fully support and even enable the accommodation of this change as a natural characteristic of a service-oriented enterprise.
Figure 4.22 Service-oriented technology architecture supports the two-way dynamic between business and IT communities, allowing each to introduce or accommodate change throughout an endless cycle.
Finally, to best understand how to achieve a technology architecture capable of enabling the two-way dynamic illustrated in Figure 4.22, we need to reveal how, behind the scenes, the supporting, formalized bodies of knowledge and intelligence comprise SOA as a mature field of practice (Figure 4.23).
Figure 4.23 The strategic goals of service-oriented computing represent a target state that can be achieved through a method provided by service-orientation. The successful application of service-orientation principles and supporting SOA design patterns helps to shape and define requirements for different types of service-oriented architectures, resulting in an IT automation model that is designed to fully support the two-way cycle of change through which business and IT communities continually transition.
4.4 SOA Project and Lifecycle Stages
Understanding how to realize service-oriented architecture also requires an understanding of how SOA projects are carried out. For the remainder of this chapter, we take a step away from technology to briefly summarize common SOA methodology and project delivery topics.
Note
This section provides a good transition to Chapter 5, which explores service definition as a foundational part of the service-oriented analysis project stage, and Chapters 6 to 9, which further delve into the service-oriented analysis stage and then cover considerations pertaining to the service-oriented design project stage.
Methodology and Project Delivery Strategies
Several project delivery approaches can be employed to build services. The bottom-up strategy, for example, is tactically focused in that it makes the fulfillment of immediate business requirements a priority and the prime objective of the project. On the other side of the spectrum is the top-down strategy, which advocates the completion of an inventory analysis prior to the actual design, development, and delivery of services.
As shown in Figure 4.24, each approach has its own benefits and consequences. Whereas the bottom-up strategy avoids the extra cost, effort, and time required to deliver services via a top-down approach, it ends up imposing increased governance burden because bottom-up delivered services tend to have shorter lifespans and require more frequent maintenance and refactoring.
Figure 4.24 Generally, the less time and effort spent on the upfront service analysis, the greater the ongoing, post-deployment governance burden. The approach on the left is comparable with bottom-up service delivery and the approach on the right is more akin to top-down delivery. SOA methodologies that attempt to combine elements of both approaches also exist.
The top-down strategy demands more of an initial investment because it introduces an upfront analysis stage focused on the creation of the service inventory blueprint. A collection of service candidates are individually defined as part of this blueprint to ensure that subsequent service designs will be highly normalized, standardized, and aligned.
Note
A top-down strategy needs to be applied to an extent to meaningfully carry out the service-oriented analysis and service-oriented design stages covered in Chapters 6 to 9. The scope of this effort is determined by the scope of the planned service inventory, as per the Balanced Scope pillar covered in Chapter 3.
SOA Project Stages
Figure 4.25 displays the common and primary stages related to SOA project delivery and the overall service delivery lifecycle. Although the stages are shown sequentially, how and when each stage is carried out depends on the methodology being used. Different methodologies can be considered, depending on the nature and scope of the overall SOA project, the size and extent of standardization of the service inventory for which services are being delivered, and the manner in which tactical (short-term) requirements are being prioritized in relation to strategic (long-term) requirements.
Figure 4.25 Common stages associated with SOA projects. Note the distinction between SOA project stages, service delivery project stages, and service lifecycle stages. These terms are used in subsequent chapters when referring to the overall adoption project, the delivery of individual services, and service-specific lifecycle stages, respectively.
Top-down SOA projects tend to emphasize the need for some meaningful extent of the strategic target state that the delivery of each service is intended to support. In order to realize this, some level of increased upfront analysis effort is generally necessary. Therefore, a primary way in which SOA project delivery methodologies differ is in how they position and prioritize analysis-related phases.
There are two primary analysis phases in a typical SOA project: the analysis of individual services in relation to business process automation, and the collective analysis of a service inventory. The service-oriented analysis phase is dedicated to producing conceptual service definitions (service candidates) as part of the functional decomposition of business process logic. The service inventory analysis establishes a cycle whereby the service-oriented analysis process is carried out iteratively (together with other business processes) to whatever extent a top-down (strategic) approach is followed.
The upcoming sections briefly describe these and other stages.
SOA Adoption Planning
During this initial stage is when foundational planning decisions are made. These decisions will shape the entire project, which is why this is considered a critical stage that may require separately allocated funding and time to carry out significant studies required to assess and determine a range of factors, including:
• Scope of planned service inventory and the ultimate target state
• Milestones representing intermediate target states
• Timeline for the completion of milestones and the overall adoption effort
• Available funding and suitable funding model
• Governance system
• Management system
• Methodology
• Risk assessment
Additionally, prerequisite requirements need to be defined in order to establish criteria used to determine the overall viability of the SOA adoption. The basis of these requirements typically originates with the four pillars of service-orientation described earlier in Chapter 3.
Service Inventory Analysis
The scope of a service inventory is expected to be meaningfully “cross-silo,” which generally implies that it encompasses multiple business processes or operational areas within an organization.
This service inventory analysis stage is dedicated to conceptually defining an inventory of services. It is comprised of a cycle (Figure 4.26) during which the service-oriented analysis stage (explained shortly) is carried out once during each iteration. Each completion of a service-oriented analysis results in the definition of new service candidates or the refinement of existing ones. The cycle is repeated until all business processes that fall within the domain of the service inventory are analyzed and decomposed into individual actions suitable for service encapsulation.
Figure 4.26 The service inventory analysis cycle. The highlighted step refers to the service inventory blueprint that represents the primary deliverable of this stage.
As individual service candidates are identified, they are assigned appropriate functional contexts in relation to each other. This ensures that services (within the service inventory boundary) are normalized so that they don’t functionally overlap. As a result, service reuse is maximized and the separation of concerns is cleanly carried out. A primary deliverable produced during this stage is the service inventory blueprint.
The scope of the initiative and the size of the target service inventory tend to determine the amount of upfront effort required to create a complete service inventory blueprint. More upfront analysis results in a better defined conceptual blueprint, which is intended to lead to the creation of a better quality inventory of services. Less upfront analysis leads to partial or less well-defined service inventory blueprints.
Here are brief descriptions of the primary analysis cycle steps:
• Define Enterprise Business Models – Business models and specifications (such as business process definitions, business entity models, logical data models, etc.) are identified, defined, and, if necessary, brought up-to-date and further refined. These models are used as the primary business analysis input.
• Define Technology Architecture – Based on what we learn of business automation and service encapsulation requirements, we are able to define preliminary technology architecture characteristics and constraints. This provides a preview of the service inventory environment, which can raise practical considerations that may impact how we define service candidates.
• Define Service Inventory Blueprint – After an initial definition that establishes the scope and structure of the planned service inventory, this blueprint acts as the master specification wherein modeled service candidates are documented.
• Perform Service-Oriented Analysis – Each iteration of the service inventory lifecycle executes a service-oriented analysis process.
The service inventory blueprint is incrementally defined as a result of repeated iterations of steps that include the service-oriented analysis.
Note
The scope of the service inventory analysis stage and the resulting service inventory blueprint directly relates to the Balanced Scope consideration explained in the The Four Pillars of Service-Orientation section in Chapter 3, as well as the possible application of the Domain Inventory [338] pattern.
Service-Oriented Analysis (Service Modeling)
A fundamental characteristic of SOA projects is that they emphasize the need for working toward a strategic target state that the delivery of each service is intended to support. To realize this, some level of increased upfront analysis effort is generally necessary. Therefore, a primary way in which SOA project delivery methodologies differ is in how they position and prioritize analysis-related phases.
Service-oriented analysis represents one of the early stages in an SOA initiative and the first phase in the service delivery cycle (Figure 4.27). It is a process that begins with preparatory information-gathering steps completed in support of a service modeling subprocess.
Figure 4.27 A generic service-oriented analysis process in which the first two steps collect information in preparation for a detailed service modeling subprocess represented by the Model Candidate Services step.
The service-oriented analysis process is generally carried out iteratively, once for each business process. Typically, the delivery of a service inventory determines a scope that represents a meaningful domain of the enterprise (as per the Balanced Scope pillar discussed in Chapter 3), or even the enterprise as a whole. All iterations of the service-oriented analysis then pertain to that scope, with each iteration contributing to the service inventory blueprint.
Steps 1 and 2 essentially represent information-gathering tasks that are carried out in preparation for the modeling process performed in Step 3.
Step 1: Define Business Automation Requirements
Through whatever means business requirements are normally collected, their documentation is required for this analysis process to begin. Given that the scope of our analysis centers around the creation of services in support of a service-oriented solution, only requirements related to the scope of that solution should be considered.
Business requirements should be sufficiently mature so that a high-level automation process can be defined. This business process documentation will be used as the starting point of a service modeling process.
Step 2: Identify Existing Automation Systems
Existing utility logic that is already, to whatever extent, automating any of the requirements identified in Step 1 needs to be identified. Although a service-oriented analysis will not determine exactly how Web services will encapsulate or replace legacy utility logic, it does assist us in providing some scope of the systems potentially affected.
The details of how Web services or REST services relate to existing systems are ironed out in the service-oriented design phase. For now, this information will be used to help identify utility service candidates during the service modeling process.
Note that this step is tailored toward supporting the modeling efforts of larger-scaled service-oriented solutions. An understanding of affected legacy environments is still useful when modeling a smaller amount of services, which does not require substantial research efforts.
Step 3: Model Candidate Services
A service-oriented analysis introduces the concept of service modeling, a process by which service operation candidates are identified and then grouped into a logical context. These groups eventually take shape as service candidates that are then further assembled into a tentative composite model representing the combined logic of the planned service-oriented application.
Note
Chapters 6 and 7 provide service modeling processes for Web services and REST services, respectively.
A key success factor of the service-oriented analysis process is the hands-on collaboration of both business analysts and technology architects (Figure 4.28). The former group is especially involved in the definition of service candidates within a business-centric functional context because they understand the business processes used as input for the analysis and because service-orientation aims to align business and IT more closely.
Figure 4.28 A look at how the collaboration between business analysts and technology architects changes with SOA projects. While the depicted collaborative relationship between business analysts and architects may not be unique to an SOA project, the nature and scope of the analysis process are.
Service-Oriented Design (Service Contract)
The service-oriented design phase represents a service delivery lifecycle stage dedicated to producing service contracts in support of the well-established “contract-first” approach to software development (Figure 4.29).
Figure 4.29 Unlike the popular process of deriving Web service contracts from existing components, SOA advocates a specific approach that encourages us to postpone development until after a custom designed, standardized contract is in place.
The typical starting point for the service-oriented design process is a service candidate that was produced as a result of completing all required iterations of the service-oriented analysis process (Figure 4.30). Service-oriented design subjects this service candidate to additional considerations that shape it into a technical service contract in alignment with other service contracts being produced for the same service inventory.
Figure 4.30 Subsequent to the analysis effort, services are subjected to a service-oriented design process.
As a precursor to the service logic design stage, service-oriented design is comprised of a process that ushers service architects through a series of considerations to ensure that the service contract being produced fulfills business requirements while representing a normalized functional context that further adheres to service-orientation principles. Part of this process further includes the authoring of the SLA, which may especially be of significance for cloud-based services being offered to a broader consumer base.
Service Logic Design
By preceding the design of service logic with the service-oriented design process, the service contract is established and finalized prior to the underlying service architecture and the logic that will be responsible for carrying out the functionality expressed in the service contract. This deliberate sequence of project stages is in support of the Standardized Service Contract (291) principle, which states that service contracts should be standardized in relation to each other within a given service inventory boundary.
How service logic is designed is dictated by the business automation requirements that need to be fulfilled by the service. With service-oriented solutions, a given service may be able to address business requirements individually or, more commonly, as part of a service composition.
Service Development
After all design specifications have been completed, the actual programming of the service can begin. Because the service architecture will already have been well-defined as a result of the previous stages and the involvement of custom design standards, service developers will generally have clear direction as to how to build the various parts of the service architecture.
Service Testing
Services need to undergo the same types of testing and quality assurance cycles as traditional custom-developed applications. However, new requirements introduce the need for additional testing methods and effort. For example, to support the realization of the Service Composability (302) principle, newly delivered services need to be tested individually and as part of service compositions. Agnostic services that provide reusable logic especially require rigorous testing to ensure that they are ready for repeated usage (both concurrently as part of the same service compositions and by different service compositions).
The following are examples of common Service Testing considerations:
• What types of service consumers could potentially access a service?
• Will the service need to be deployed in a cloud environment?
• What types of exception conditions and security threats could a service be potentially subjected to?
• Are there any security considerations specific to public clouds that need to be taken into account?
• How well do service contract documents communicate the functional scope and capabilities of a service?
• Are there SLA guarantees that need to be tested and verified?
• How easily can the service be composed and recomposed?
• Can the service be moved between on-premise and cloud environments?
• How easily can the service be discovered?
• Is compliance with any industry standards or profiles (such as WS-I profiles) required?
• If cloud deployed, are there proprietary characteristics being imposed by the cloud provider that are not compatible with on-premise service characteristics?
• How effective are the validation rules within the service contract and within the service logic?
• Have all possible service activities and service compositions been mapped out?
• For service compositions that span on-premise and cloud environments, is the performance and behavior consistent and reliable?
Because services are positioned as IT assets with runtime usage requirements comparable to commercial software products, similar quality assurance processes are generally required.
Service Deployment and Maintenance
Service deployment represents the actual implementation of a service into the production environment. This stage can involve numerous interdependent parts of the underlying service architecture and supporting infrastructure, such as:
• Distributed components
• Service contract documents
• Middleware (such as ESB and orchestration platforms)
• Cloud service implementation considerations
• Cloud-based IT resources encompassed by an on-premise or cloud-based service
• Custom service agents and intermediaries
• System agents and processors
• Cloud-based service agents, such as automated scaling listeners and pay-for-use monitors
• On-demand and dynamic scaling and billing configurations
• Proprietary runtime platform extensions
• Administration and monitoring products
Service maintenance refers to upgrades or changes that need to be made to the deployment environment, either as part of the initial implementation or subsequently. It does not pertain to changes that need to be made to the service contract or the service logic, nor does it relate to any changes that need to be made as part of the environment that would constitute a new version of the service.
Service Usage and Monitoring
A service that has been deployed and is actively in use as part of one or more service compositions (or has been made available for usage by service consumers in general) is considered to be in this stage. The ongoing monitoring of the active service generates metrics that are necessary to measure service usage for evolutionary maintenance (such as scalability, reliability, etc.), as well as for business assessment reasons (such as when calculating cost of ownership and ROI).
Special considerations regarding this stage apply to cloud-based services, such as:
• The cloud service may be hosted by virtualized IT resources that are further hosted by physical IT resources shared by multiple cloud consumer organizations.
• The cloud service usage may be monitored not only for performance, but also for billing purposes when its implementation is based on a per-usage fee license.
• The elasticity of the cloud service may be configured to allow for limited or unlimited scalability, thereby increasing the range of behavior (and changing its usage thresholds) when compared to an on-premise implementation.
This phase is often not documented separately, as it is not directly related to service delivery or projects responsible for delivering or altering services. It is noted in this book because while active and in use, a service can be subject to various governance considerations.
Service Discovery
To ensure that reusable services are consistently reused, project teams carry out a separate and explicitly defined service discovery process. The primary goal of this process is to identify one or more existing agnostic services (such as utility or entity services) within a given service inventory that can fulfill generic requirements for whatever business process the project team is tasked with automating.
The primary mechanism involved in performing service discovery is a service registry that contains relevant metadata about available and upcoming services, as well as pointers to the corresponding service contract documents (which can include SLAs). The communications quality of the metadata and service contract documents play a significant role in how successfully this process can be carried out. This is why the Service Discoverability (300) principle is dedicated solely to ensuring that information published about services is highly interpretable and discoverable.
Service Versioning and Retirement
After a service has been implemented and used in production environments, the need may arise to make changes to the existing service logic or to increase the functional scope of the service. In cases like this, a new version of the service logic and/or the service contract will likely need to be introduced. To ensure that the versioning of a service can be carried out with minimal impact and disruption to service consumers that have already formed dependencies on the service, a formal service versioning process needs to be in place.
There are different versioning strategies, each of which introduces its own set of rules and priorities when it comes to managing the backward and forward compatibilities of services. (Chapter 10 provides fundamental coverage of common service versioning approaches for Web services and REST services.)
Project Stages and Organizational Roles
Figure 4.31 revisits the SOA project stages and maps them to common organizational roles. These roles are described in the SOA Governance: Governing Shared Services On-Premise & in the Cloud text book.
