The adoption of SOA often comes with an expectation that many of the benefits commonly associated with service-oriented technology platforms will be realized simply through their successful implementation. However, some of the longer-term and more strategically significant goals of an SOA transition (such as the attainment of increased business agility) can really only be achieved to their full potential by applying a consistent approach to how automation logic is designed.
Before a service-oriented solution can be built, it needs to be understood what makes an individual service suitable for SOA in support of its strategic goals. In other words, the question of how services can be created to be truly service-oriented needs to be asked early on in the project lifecycle.
The answer lies in a design paradigm that has emerged to uniquely distinguish the service-oriented architectural model from its predecessors. This paradigm is service-orientation and its approach to modeling business automation logic has resulted in a set of commonly accepted principles that, when applied, position and shape the primitive components (services, descriptions, messages) found in a typical service-oriented environment.
Service-Orientation and the Separation of Concerns
Service-orientation has had many influences, but its roots lie in a software engineering theory known as the "separation of concerns." This theory is based on the notion that it is beneficial to break down a large problem into a series of smaller, individual problems or concerns. This allows the logic required to solve the larger problem to also be decomposed into a collection of smaller, related pieces. Each piece of logic addresses a specific concern.
The theory has already been implemented through established paradigms, such as object-orientation and component-based approaches. Service-orientation can be viewed as a distinct (and more recent) manner in which to realize a separation of concerns. More specifically, though, key service-orientation principles provide a unique approach to how the separation is performed. In doing so, these principles establish a foundation paradigm for SOA. If you study the common characteristics associated with contemporary implementations of SOA, you will notice that several are linked to how concerns have been separated.
The Common Principles of Service-Orientation
There are many opinions, originating from public IT organizations to vendors and consulting firms, about what constitutes service-orientation. As part of an on-going industry analysis initiative by SOA Systems Inc., I have been researching and assessing perspectives of service-orientation for quite some time. The purpose of this project is to identify and describe a set of common principles that are supported by all major SOA platforms, thereby establishing a real-world definition of the service-orientation paradigm. Our focus in this series is therefore centered around those principles that have become commonly accepted in the SOA industry and supported by corresponding vendor platforms.
The most recent results establish the following eight principles:
· services share a formal contract
· services are loosely coupled
· services abstract underlying logic
· services are composable
· services are reusable
· services are autonomous
· services are stateless
· services are discoverable
Of these eight, autonomy, loose coupling, abstraction, and the need for a formal contract can be considered core principles that form a baseline foundation for SOA. Although each of the eight principles support or are supported by the others, these four directly enable the realization of the remaining principles. The study of inter-principle relationships is quite interesting and provides a deeper perspective of the unique dynamics introduced by service-orientation.
It is also worth noting that Web services naturally support a subset of these principles, which provides an indication as to why the Web services technology platform is considered so suitable for building service-oriented solutions. Later in this series we will discuss some of the relationships between principles as well as how some are intrinsically realized through the use of Web services. These principles are "common" in that they represent an industry-level perspective of service-orientation as determined by research conducted by SOA Systems Inc.
| |
|
An aspect of service-orientation that ties directly into our previous discussion of service contracts and loose coupling is that of abstraction. It is through abstraction that we can control what parts of the underlying service logic are exposed to the outside world. By ensuring that these parts are designed in a generic manner so as to accommodate multiple potential service requestors, we can strive to position the service as a reusable IT asset. In this article we will explore different levels of abstraction and then move on to a discussion of how reuse supports the overall strategic goals associated with SOA.
Abstracting functionality and technology
Also referred to as service interface-level abstraction, it is this principle that encourages us to establish services as black boxes, intentionally hiding their underlying details from potential consumers. Abstraction is accomplished through the disciplined use of service contracts. By limiting what is made public about a service to what is documented in the service contract, a high degree of separation can be achieved between what becomes private (hidden) and public (consumable). This is desirable because it supports the loosely coupled relationship.
There is no limit to the amount of logic a service can represent. A service may be designed to perform a simple task or it may be positioned as a gateway to an entire automation solution. There is also no restriction as to the source of automation logic a service can draw upon.
For example, a single service can expose logic from multiple different underlying systems. In fact, as we move toward the standardization of service models that establish a functional context associated with a business entity or task, it is expected that in environments with numerous legacy solutions, one service will commonly expose functionality that relies on a variety of different systems.
Service interface-level abstraction is one of the inherent qualities provided by distributed platforms, such as component and Web services-based architectures. The use of Web services are especially synergetic because they elevate the level of attainable abstraction beyond just functionality. Web services abstract the proprietary implementation details of the underlying automation logic, which frees potential consumers of the service from having to interface with specific vendor technologies. Even though we refer to abstraction as a characteristic of the service, it is actually the individual operations that collectively abstract the underlying logic. Services simply act as containers for these operations. The level of abstraction of any given service is therefore determined to large extent by the collective levels of abstraction attained by each of its service operations.
This puts a great deal of emphasis on the design of the service contract. The more that is expressed in the service contract, the less details we end up abstracting. The more generic we make the service contract, the less process or consumer-specific the service becomes. This then determines the reuse potential of what we choose to expose (to not abstract) through the service contract.
Fostering agility through reuse
Service-orientation encourages reuse in all services, regardless of whether immediate requirements for reuse exist. This fundamental principle forces us to pay extra attention to each delivered unit of automation logic we want to call a "service."
The primary strategic goal associated with reuse is to position each service as an IT asset with "repeatable value." As the amount of reusable assets accumulate, the chances increase to fulfill new business automation requirements by building less and using more of what we already have.
This is expected to reduce the time it takes to build automation logic, thereby improving an organization's overall responsiveness to change. By decreasing the associated effort, the fulfillment of automation requirements is also anticipated to become more cost-effective, leading to the significant potential of streamlining IT development environments. This may sound like a tall order, but many organizations are investing heavily in the creation of a highly reusable service inventory to attain these very benefits.
This principle facilitates all forms of reuse, including inter-application interoperability, composition and the creation of cross-cutting or utility services. As we established earlier, a service is simply a collection of related operations. It is therefore the logic encapsulated by the individual operations that must be deemed reusable to warrant representation as a reusable service.
The emphasis on far reaching reuse also highlights the suitability of Web services as an implementation option for services. By making each service available via an industry standard communications framework, reuse potential can broaden dramatically because the logic encapsulated by a service now becomes accessible to service requestors built with different underlying technologies.
It all comes down to the service contract
Both of these principles bring us back to the required use of the service contract. It is the content of this contract that determines what is and is not abstracted. It is through the design of this content that we can determine how generic and reusable the non-abstraced parts actually are. This raises the need to truly view the design of a service as an investment. Building service-oriented solution logic is almost always more expensive and more time consuming because considerations need to be taken into account that go beyond immediate tactical requirements. An appreciation of what service-orientation is intended to accomplish is therefore useful in justifying this investment.
|
|
|
Continuing our exploration of service-orientation, we now focus on two principles that tend to receive much less attention than they deserve. When it comes to service design, so much of the spotlight is on enabling design characteristics most commonly associated with SOA marketing terminology, namely loose coupling and reuse. While certainly important, if not critical to achieving the long-term goals of SOA transition projects, there is more to consider. Abstraction and the strategic use of service contracts represent two additional principles that, to a large extent, support the realization of reusable, loosely coupled services. But, even the most reusable service is not useful if it cannot be found by those responsible for creating potential consumers. Furthermore, even the most loosely coupled services will have limited reuse potential if they cannot be assembled into effective compositions. This is where the principles of service discoverability and service composition come into play.
Service discoverability
The characteristic of discoverability essentially helps avoid the accidental creation of redundant services or services that implement redundant logic. Because each service operation provides a potentially reusable piece of automation logic, the metadata attached to a service needs to sufficiently describe not only the service's overall purpose, but also the functionality offered by its individual operations.
This service-orientation principle is related to, but distinct from, discoverability on an architectural level, in which case service discoverability refers to the technology architecture's ability to provide a discovery mechanism, such as a service registry or directory. These extensions effectively become part of the overall infrastructure in support of SOA implementations.
On a service level, the principle of discoverability refers to the design of an individual service so that it becomes as discoverable as possible, regardless of whether a discoverability product or extension actually exists in its surrounding implementation environment.
The reasoning behind this is that even if there's no need for a service registry because there simply isn't enough of a service inventory to warrant one, services should still be designed as highly discoverable resources. That way, when a service portfolio grows in size, the evolutionary governance of those services can be better managed because each service is equipped with sufficient metadata to properly communicate its purpose and capabilities.
Service composition
As service portfolios grow in size, service compositions will become an unavoidable and increasingly important design aspect of building service-oriented solutions. The main reason this particular principle is so important is because it ensures that services are designed in such a manner so that they can participate as effective members, or controllers, of these compositions.
The requirement for any service to be composable also places an emphasis on the design of service operations. Composability is simply another form of reuse and therefore operations need to be designed in a standardized manner (and with an appropriate level of granularity) to maximize composition opportunities.
A common SOA extension that underlines the relevance of composability is orchestration. Here, a service-oriented business process can be expressed through a composition language, such as WS-BPEL, essentially classifying the process itself as a service composition represented by a parent process service. Either way, the need for a service to be highly composable is irrespective of whether immediate composition requirements exist.
Composition discoverability
Each of the principles we explain in this series has relationships with others. Service composability, for example, is a characteristic that is influenced by the extent to which several other principles are collectively applied.
Even discoverability ties into effective composition. A fundamental rule of service abstraction is that a service can represent any range of logic from any types of supported sources, including other services. If services encapsulate others, we have a composition. To build an effective composition, the service designer will need a means of finding the most suitable services to act as composition members. Furthermore, once the composition is completed and deployed, potential consumers of the service representing the composition will benefit from an awareness of its existence, purpose, and capabilities.
Discovery supports and enables both of these scenarios, thereby furthering the cause of service-orientation.
ref:
Principles of Service Oriented Design - http://msdn.microsoft.com/en-us/library/bb972954.aspx
SOA Principles - http://www.soaprinciples.com/
Principles of Service Orientation - http://searchsoa.techtarget.com/tip/0,289483,sid26_gci1165286,00.html
