3.3  Impact of Service-Orientation on Technology Architecture

Service-oriented computing is fundamentally about attaining a specific target state. It asks that we take extra design considerations into account with everything we build so that all the moving parts of a service-oriented environment support the realization of this target state and foster its growth and evolution. This target state is attractive because it has associated with it a specific set of goals and benefits.

To fully understand service-oriented technology architecture requires knowledge of:

•     how these goals and benefits are achieved (the method)

•     what entails the attainment of these goals and benefits (the end-result)

This understanding allows us to assess what requirements and demands are placed upon technology architecture.

The Method of Service-Orientation

To realize the strategic benefits of service-oriented computing requires that each piece of solution logic be designed consistently and in a manner that fully supports the expected target environment. This is the role of service-orientation. It is the fundamental method by which service-oriented solutions are created.

There are eight distinct design principles that are part of the service-orientation design paradigm. Each addresses a key aspect of service design by ensuring that specific design characteristics are consistently realized within every service or that related design principles are consistently applied. When collectively realized to a meaningful extent, service-orientation design principles shape solution logic into something we can legitimately refer to as Òservice-oriented.Ó

Below are the eight service-orientation design principles together with their official definitions:

•     Standardized Service Contract – ÒServices within the same service inventory are in compliance with the same contract design standards.Ó

•     Service Loose Coupling – "Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment."

•     Service Abstraction – "Service contracts only contain essential information and information about services is limited to what is published in service contracts.Ó

•     Service Reusability – "Services contain and express agnostic logic and can be positioned as reusable enterprise resources."

á     Service Autonomy – "Services exercise a high level of control over their underlying runtime execution environment."

•     Service Statelessness – "Services minimize resource consumption by deferring the management of state information when necessary.Ó

•     Service Discoverability – "Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted."

•     Service Composability – "Services are effective composition participants, regardless of the size and complexity of the composition."

Figure 4.x (borrowed from Chapter 5 of ÒSOA: Principles of Service DesignÓ) provides some perspective as to how these principles affect the design of a service. The application of the principles on the right side tend to result in concrete design characteristics being added to a service, whereas the principles on the left usually act as regulatory influences, ensuring a balanced application of service-orientation as a whole.

Figure 3.23 – A recap of how service-orientation design principles relate to service design and to each other.

As just mentioned, a solution is considered service-oriented once 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.

Note: Design principles are referenced throughout this book but represent a separate subject-matter that is covered in SOA: Principles of Service Design. Introductory coverage of service-orientation is also available at SOAPrinciples.com.

The End-Result of Service-Orientation

Automated business communities and the IT industry have an endless bi-directional relationship where each influences the other. 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 the Internet is a good example of the latter.)

Figure 3.24 – The endless progress cycle establishes the dynamics between the business and IT communities.

The IT industry has been through the cycle depicted in Figure 3.x 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 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 following goals:

•     Increased Intrinsic Interoperability

•     Increased Federation

•     Increased Vendor Diversification Options

•     Increased Business and Technology Domain Alignment

•     Increased ROI

•     Increased Organizational Agility

•     Reduced IT Burden

It is the target state represented by 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 3.x shows 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 3.25 – 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 (green) represent the ultimate target benefits sought in a typical SOA initiative.)

Almost all of the design patterns in this book are specifically intended to support the application of service-orientation by solving common problems that may arise as a result of the impacts placed upon the different architecture types. This is an important perspective to keep in mind when working with SOA design patterns, as it is always helpful to understand that all patterns in this catalog share this common objective.

Ultimately, the successful implementation of service-oriented architectures will support and maintain the benefits associated with the strategic goals of service-oriented computing. As concluded by Figure 3.x, 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 3.26 – Ultimately, service-orientation and service-oriented technology architectures support the two-way dynamic between business and IT communities, allowing each to introduce or accommodate change throughout and endless cycle.

For those of you interested in how each of the strategic goals specifically influences the four types of service-oriented architecture, Chapter 12 documents the individual impacts and further provides references to related design patterns.