Changing the delivery of IT

Tony Bishop

Subscribe to Tony Bishop: eMailAlertsEmail Alerts
Get Tony Bishop: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Exclusive SOA Web Services Journal Briefing – Thomas Erl On SOA

The Principles of Service-Orientation

Services are Loosely Coupled
Coupling refers to a connection between two things. Within automation solutions, the extent of coupling is a measure of dependency in relation to the connection between units of automation logic. A tightly coupled relationship indicates a high degree of dependency, whereas a decoupled relationship indicates no dependency (and no connection).

A fundamental principle of service-orientation is that units of logic that are classified as services retain a minimal level of coupling. The underlying logic of a service and its requestor are therefore not tightly coupled nor are they decoupled. They ideally retain a level of coupling that is classified as "loose" by limiting dependencies between a service and its clients on an agreed-upon service contract.

See Figure 3

Services Share a Formal Contract
Units of automation logic that are classified as services must provide a contract in which the terms of engagement are defined. As a whole, service contracts can be composed of legal and technical information. This principle is primarily concerned with service description documents that comprise the technical service contract and provide published details about the service, such as its programmatic interface, communication requirements, constraints, properties, usage policies, and even preferences.

Software programs that request consumption of the service must adhere to the conditions of this contract. By restricting awareness of the service (as well as the scope of allowable communication) to what is documented in the service contract, a loosely coupled relationship is formed. The result is the consistent abstraction of a service's underlying logic.

Services Abstract Underlying Logic
Aside from what is published and described in the service contract, information regarding a service is hidden. This limits dependency (and coupling) to the service contract and essentially treats the service as a black box.

One of the primary benefits of service abstraction is that it allows for the mechanics of the service (development technology, deployment environments, etc.) to change with minimal impact to client programs that have become (loosely) dependent on it. The golden rule, of course, is that the service contract should remain immutable, so as to preserve established service-client relationships.

The Core Trio
In a nutshell, the targeted use of service contracts abstracts underlying service logic, thus limiting the extent of coupling. Applying the principles that implement these characteristics results in a predictable and consistent relationship between a service and its requestor, thereby establishing a fundamental dynamic of primitive service-oriented architecture.

There are, however, additional characteristics that distinguish both service-orientation and SOA. These build upon the foundation laid by the core principles and are what mould services into standardized units of automation logic capable of realizing specific benefits associated with SOA.

See Figure 4

Service Are Composable
Service abstraction imposes no limit on what a service can encapsulate. This includes encapsulation of other services. A service composition represents a set of aggregated services that are united to collectively perform a particular task. The principle of composability applies to individual services, and strongly encourages that services be designed in support of aggregated assembly as composition controllers, members, or both.

By ensuring that services are capable of participating in multiple compositions, an inventory of adaptive services can be accumulated. The introduction of new or augmented business requirements can then, to a larger extent, be addressed by the reorganization (or remodeling) of services into new composition configurations. Essentially, the modeling of these compositions can be viewed as a form of service reuse.

See Figure 5

Services Are Reusable
Regardless of the design approach taken, a well-established benefit to separating concerns is that individual concerns may not be specific to a particular activity or business task. The solution logic decomposed to address these crosscutting concerns can therefore become reusable. The reuse potential in SOA broadens because the scope of SOA itself can be extended beyond solution or even enterprise environments.

Attaining an effective level of reuse often requires that a service be stripped of solution and/or business process logic in order for it to become adequately generic. As a result, service reuse is a principle that is almost always realized through standardized design. Key service characteristics that support and help to foster reuse are autonomy, statelessness, and discoverability - each of which is addressed by a corresponding principle.

See Figure 6

Services Are Autonomous
It is preferred that services exist as independently as possible - both from each other as well as from other parts of the technical environment that may want to share the resources encapsulated by the service. Autonomy represents the governance a service has at the time of execution over the underlying application logic required to carry out the functions exposed by the service contract. The extent to which a service can control its underlying logic dictates the level of its autonomy.

Purely autonomous services have absolute ownership of their resources, which allows them to be better tuned for efficiency, reliability, and availability. However, attaining this level of autonomy can be challenging. For example, integration architectures where services encapsulate legacy system logic frequently require that resources be shared with existing legacy clients. Also, the autonomy of a service that is spearheading a composition will be dependent on the collective autonomy of all services involved.

Either way, services with a high level of autonomy are considered the best candidates for reuse, especially in environments in which usage patterns from multiple clients cannot easily be predicted. Note that although frequently discussed in tandem with reuse, autonomy in no way guarantees statelessness.

See Figure 7

Services Are Stateless
State information is data specific to a current activity or task. Its lifespan is generally associated with this task and therefore the manipulation and retention of state-related data typically must occur at runtime.

State management can consume considerable resources. Maintaining a condition of statelessness therefore benefits a service by increasing its scalability and availability. Furthermore, the processing of state information typically requires automation logic that is specific to the business task being executed. For services to maximize reuse potential, their context and underlying logic must be as generic (task-neutral) as possible. Emphasizing stateless design supports the reallocation of task-specific logic outside of the service or to dedicated, stateful services.

More Stories By Thomas Erl

Thomas Erl is a best-selling IT author and founder of Arcitura Education Inc., a global provider of vendor-neutral educational services and certification that encompasses the Cloud Certified Professional (CCP) and SOA Certified Professional (SOACP) programs from CloudSchool.com™ and SOASchool.com® respectively. Thomas has been the world's top-selling service technology author for nearly a decade and is the series editor of the Prentice Hall Service Technology Series from Thomas Erl, as well as the editor of the Service Technology Magazine. With over 175,000 copies in print world-wide, his eight published books have become international bestsellers and have been formally endorsed by senior members of many major IT organizations and academic institutions. To learn more, visit: www.thomaserl.com

Comments (3) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
erl 10/29/05 06:17:48 AM EDT

{{{ have yet to find a better means of explaining service-orientation than to reach back to that fundamental software engineering theory known as the "separation of concerns." }}}

I'd not heard this one before. Useful phrase.

queZZtion 10/29/05 05:36:51 AM EDT

||| technology architecture in support of service-orientation is making significant strides, and extending its reach into key realms of enterprise computing |||

The age of SOA will last much longer than the age of client/server. How long though?

Short&Sweet 10/29/05 05:32:53 AM EDT

Erl's book on this subject, Service-Oriented Architecture: Concepts, Technology, and Design has 792 pages - helpful to have this boiled down to just 3 pages here!