Bick Group

David Linthicum

Subscribe to David Linthicum: eMailAlertsEmail Alerts
Get David Linthicum via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Coordination and Transactions Are Key to Building an Operational SOA

Secrets of SOA design

Building an SOA usually means leveraging a loosely coupled-type architecture. While the benefits of a loosely coupled SOA with many services are apparent, the operational characteristics can be a nightmare. However, with a bit of planning, and the use of some standards, your SOA will be both reliable and functional.

The key problem is to make many services, some you own and some you don't own, work and play well together. The objective is to leverage many services, and do it in a way that makes them appear like a single application, although the services could be running anywhere in and outside your organization. In short, making many appear as one.

Okay, now that we know what the problem is, how do we solve it? First, you need to remember that this is largely an architectural problem, and not something you can toss products and standards at. Indeed, you need to define the capabilities of your SOA based on the requirements of the domain, and back the appropriate solution set (standards, tools, technologies) into it. For instance, too many fine grained services and all of the technology and standards in the world won't help you.

What's key here, at least from an architectural perspective, is that you make the right calls in terms of what services are going to make up your SOA in support of critical business events. This is where most SOAs go off track, typically attempting to bind too many services, and at the wrong granularity. You can consider services that make up your SOA like links in a chain, each defining the reliability and performance.

Having stated that obvious problem, there are techniques, technologies, and standards that you can apply that provide your SOA with better capabilities to manage a loosely coupled and distributed SOA. Although they're just getting off the ground, I believe they're some of the most important emerging capabilities.

Look at Standards
Of course any weaknesses in Web services and SOAs always have a WS* standard associated with them, and this problem is no exception. For our purposes, the most relevant are: WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity. Note that the last two are dependent on the first, more on that below.

The WS-Coordination specification describes a framework for providing protocols that coordinate the actions of distributed services. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome; in other words, the ability to make many services function as a single service, and to do so through close coordination using standard communication and state mechanisms.

The WS-Coordination framework enables an application service to create a context needed to propagate an activity to other services. This is done through the registration of coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. This specification describes a definition of the structure of context and the requirements for propagating context between cooperating services.

The problem WS-Coordination is looking to solve is that Web services increasingly tie together a large number of participants, forming large distributed computational units that are known as activities. In many SOAs, the resulting activities often leverage a complex structure, with complex relationships between their participants. Therefore, the execution of such activities often takes a long time to complete due to business latencies and user interactions. The use of the coordination framework isn't restricted to transaction processing systems; a wide variety of protocols can be defined for distributed applications.

The WS-Coordination specification describes a framework for a coordination service (or coordinator) that consists of these component services: an Activation service, a Registration service, and a coordination type. An Activation service enables an application to create a coordination instance or context. A Registration service enables an application to register for coordination protocols. A coordination type specifies a set of coordination protocols to use in a distributed application instance.

The WS-AtomicTransaction specification defines an atomic transaction coordination type for use with WS-Coordination. It defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, a volatile two-phase commit, and a durable two-phase commit. Those building an SOA can use any or all of these protocols when building solutions that require consistent agreement on the outcome of short-lived distributed activities that either work or don't work - all or nothing.

The WS-BusinessActivity specification defines the business activity coordination type that leverages the WS-Coordination specification. The specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require agreement on the outcome of long-running distributed activities.

The essence of this problem, and the solutions, is the ability to make many different behaviors existing on all kinds of environments and at all locations appear to be a single, well structured, and reliable application. This is a problem we've been wrestling with for years, and have put specific types of technologies on it, such as transactional systems and state machines. There is really nothing new here, just new tools and standards.

With the advent of Web services we have both an opportunity and a problem. The opportunity is to build applications with reusable services that we may or may not have built ourselves. Thus you should end up with an IT infrastructure that's both adaptable and inexpensive through the notion of reuse. The management of distributed services carries its own set of issues, as discussed above. However, with a bit of good architectural forethought and the good use of standards and technologies, I think we can have our cake and eat it too.

More Stories By David Linthicum

Dave Linthicum is Sr. VP at Cloud Technology Partners, and an internationally known cloud computing and SOA expert. He is a sought-after consultant, speaker, and blogger. In his career, Dave has formed or enhanced many of the ideas behind modern distributed computing including EAI, B2B Application Integration, and SOA, approaches and technologies in wide use today. In addition, he is the Editor-in-Chief of SYS-CON's Virtualization Journal.

For the last 10 years, he has focused on the technology and strategies around cloud computing, including working with several cloud computing startups. His industry experience includes tenure as CTO and CEO of several successful software and cloud computing companies, and upper-level management positions in Fortune 500 companies. In addition, he was an associate professor of computer science for eight years, and continues to lecture at major technical colleges and universities, including University of Virginia and Arizona State University. He keynotes at many leading technology conferences, and has several well-read columns and blogs. Linthicum has authored 10 books, including the ground-breaking "Enterprise Application Integration" and "B2B Application Integration." You can reach him at david@bluemountainlabs.com. Or follow him on Twitter. Or view his profile on LinkedIn.

Comments (0)

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.