Tip

The principles of service-orientation part 6 of 6: Principle interrelationships and service layers

Now that we've covered the common principles of service-orientation individually, we can study new aspects of their application. In this final part of our series, we discuss how principles can relate to and affect each other. These interrelationships are very specific and establish dynamics that are unique to the service-orientation paradigm. We conclude with a brief look at how certain principles can be applied beyond the service level through the use of abstraction layers.

How principles interrelate

To achieve an in-depth understanding of service-orientation, it is important to be aware of the cause and effect of applying each of the common principles. By exploring principle interrelationships we not only realize how each service supports or is supported by others, but we also gain an appreciation for what distinguishes service-orientation from other design paradigms.

Let's take the fundamental principle of service reusability as an example. In Figure 3 you'll notice the principles represented by oval symbols and the relationships illustrated by arrows. The service reusability principle is positioned in the center because its relationships are what we are currently interested in. The arrows pointing toward that principle represent the influence of other principles. The one arrow pointing away from the symbol indicates how implementing reusable automation logic can affect the realization of another principle.

What is immediately

    Requires Free Membership to View

evident in this diagram is how many of the other principles shape and support the measure of reusability a service is able to realistically attain. Realizing reusability not only in design, but also in a service's real world implementation is a core goal of service-orientation and key to achieving many of the significant benefits associated with SOA. Several of the other principles therefore emerged in support of this goal.

Let's take a closer look at each of these relationships:

  • Service autonomy establishes an execution environment that facilitates reuse because the service achieves increased independence and self-governance. The less dependencies a service has, the broader its reuse applicability.
  • Service statelessness supports reuse because it maximizes the availability of a service and typically promotes a generic service design that defers state management and activity-specific processing outside of the service boundary.
  • Service abstraction fosters reuse because it establishes the black box concept. Proprietary processing details are hidden and potential consumers are only made aware of an access point represented by a generic public interface.
  • Service discoverability promotes reuse as it allows those that build consumers to search for, discover and assess services offering reusable functionality.
  • Service loose coupling establishes an inherent independence that frees a service from immediate ties to others. This makes it a great deal easier to realize reuse.
  • Service composability is primarily possible because of reuse. The ability for new automation requirements to be fulfilled through the composition of existing services is feasible when those services being composed are built for reuse. (It is technically possible to build a service so that its sole purpose is to be composed by another, but reuse is generally emphasized.)

The study of cross-principle relationships can be involved and complex. It's not just a matter of whether a principle is applied, but also the extent to which it is applied.

As we learned during the previous articles in this series, every principle can be implemented to a certain degree. This can make it challenging to measure the actual level of realization of a principle and the extent to which it does in fact affect others. However, I can tell you from first-hand experience that repeatedly going through the service-oriented analysis and design processes builds up familiarity with service-orientation and, eventually, sound judgment as to the levels at which principles interrelate.

Abstraction, loose coupling and service layers

Studying these relationships makes us take considerations into account that go beyond the application of individual principles for a given service. However, to successfully apply service-orientation across the enterprise, certain principles need to be explored even further, beyond the actual service boundary.

Service models were introduced in Part 2 of the six-part Business Analysis and SOA series. In a nutshell, service models establish templates for common types of services with pre-defined design characteristics. In the Business Analysis and SOA article we focused on service models with a business context, which included:

  • Entity-Centric Business Service
  • Task-Centric Business Service
  • Process Service

Another model we should briefly introduce is one that is intentionally not business-centric. We refer to this as the application or infrastructure service, which generally represents utility processing logic associated with addressing crosscutting concerns. Common examples include notification, event logging, exception handling and data format conversion.

Figure 4 illustrates a scenario involving three service layers, the bottom of which refers to the previously described service model as the utility application service.

The use of service models allows us to realize the concept of functional abstraction on a large scale. A group of services based on the same model share common characteristics and can therefore collectively abstract a domain within an enterprise. This effectively establishes a service abstraction layer.

These layers do not need to be limited to the service models we listed previously. An organization can define its own set of service models, each of which may be specific to how it prefers to partition logical enterprise domains. For example, a business service model can be created specific to a company business division (such as HR or sales). Services based on this model would have functional boundaries limited to that part of the organization and would collectively encapsulate a domain that corresponds to this division. All of this takes the principle of service abstraction to a whole new level because we are applying abstraction beyond a single service boundary to represent collections of services, it is referred to as domain-level abstraction.

The use of domain-level abstraction allows us to also apply loose coupling well beyond service boundaries. Service layers that encapsulate domains represent logical bodies of functionality within the enterprise that will need to interact in order to automate common business processes and tasks. As we know, loose coupling benefits an SOA by allowing services to be evolved relatively independently. Once applied on an enterprise-level, service abstraction layers establish a loose coupling between entire segments of an organization, thereby allowing domains to be evolved with increased independence while still supporting effective, cross-domain interaction.

Conclusion

With so much ambiguity surrounding the use of the term "SOA" in the current marketplace, it is more important than ever to acquire an understanding of what it truly means for something to be considered "service-oriented." A sound knowledge of the service-orientation design paradigm and its principles will give you this understanding. It will empower you with the clarity required to assess the legitimacy of "service-oriented" products and platforms and the ability to leverage what service-oriented computing has to offer in support of your strategic goals.

I hope you've enjoyed our brisk tour of the service-orientation paradigm. For more details regarding the principles we discussed, I would encourage you to visit www.serviceorientation.org.

This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.

About the author

Thomas Erl is the world's top-selling SOA author and Series Editor of the "Prentice Hall Service-Oriented Computing Series from Thomas Erl" ( www.soabooks.com). Thomas is also the founder of SOA Systems Inc., a firm specializing in strategic SOA consulting, planning, and training services ( www.soatraining.com). Thomas has made significant contributions to the SOA industry in the areas of service-orientation research and the development of a mainstream SOA methodology. Thomas is involved with a number of technical committees and research efforts, and travels frequently for speaking, training and consulting engagements. To learn more, visit www.thomaserl.com.


 

This was first published in July 2006

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.