Issue October 2011 - Service Technology Magazine

Issue October 2011 - Service Technology Magazine



October 2011LV




Mapping Service-Orientation to TOGAF 9

Part IV: Applying Service Orientation to TOGAF's

Service Contracts

by Filippos Santas

Understanding Reuse and Composition:

Working with the Service Reusability and

Service Composability Principles

by Thomas Erl

$9.99USD $9.69CAD €6.99

Issue LV • October 2011








the Editor


Managing SOA-Cloud Risk - Part I

by Philip Wik, Senior Consultant, MSS Technologies

Mapping Service-Orientation to TOGAF 9

Part IV: Applying Service-Orientation to TOGAF’s

Service Contracts

by Filippos Santas, IT Architect, Credit Suisse Private

Banking in Switzerland, Certified SOA Trainer

Understanding Reuse and Composition:

Working with the Service Reusability and

Service Composability Principles

by Thomas Erl


Arcitura Education Inc.


Thomas Erl


Pamela Yau


Ivana Lee


Sachie Otobuchi


Philip Wik

Filippos Santas

Thomas Erl


Melissa Mok


Steve Wisner

Errol Ryland

49 Contributors

Copyright © Arcitura Education Inc.


Issue LV • October 2011

From the Editor

One of the primary focal points of the service-orientation paradigm is the

design and standardization of service contracts. It becomes a concern

during the early modeling stages when we conceptualize service

candidates individually and in relation to each other, and then carries

over into processes dedicated to the physical design of the technical

interface and the underlying logic required to fulfill the functionality

promised by the interface. When we study the application of principles,

such as Standardized Service Contract and Service Loose Coupling,

to the design of services that rely on a uniform contract (such as what

can be provided by HTTP), we need to understand and appreciate

how the contracts of individual service are based on overarching

uniform methods in addition to whatever resources and types are

accessible via these methods. We essentially end up with a baseline

level of standardization that can be leveraged throughout a service

inventory. We then build upon the baseline to further standardize and

architecturally position the other elements unique to different service

contracts. The principles continue to apply, but less so to what is

expressed in technical service contract definitions, and more so to what

is accessed via uniform contract methods used by the service contracts.

Studying service-orientation in this context helps further highlight just

how flexible this paradigm really can be.

Thomas Erl, Series Editor and Site Editor

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Thunder Clouds: Managing SOA-Cloud Risk - Part I

by Philip Wik, MSS Technologies

Abstract - This is the first article in a two-part article that discusses how we can manage risk while leveraging

emerging cloud technologies using service-oriented architecture (SOA).

Figure 1 – Thunder Clouds, Florida

Wikimedia Commons

The fog comes

on little cat feet.

It sits looking

over harbor and city

on silent haunches

and then moves on.

Carl Sandburg, 1916

Copyright © Arcitura Education Inc.


Issue LV • October 2011


Clouds in nature are both the wonder and the sorrow of humanity. White puffs drift across blue skies and

streaks of neon and gold at dusk are a sight of beauty and awe. But the days pass and we see the violence of

tornadoes, blizzards, and hurricanes. And even fog as gentle as cat feet can send trucks off cliffs and ships into


Commercial clouds provide leanness and savings, extend service-oriented principles, and represent a shift

in how we practice information technology (IT). But SOA-clouds (SOA-C) can also expose us to loss. The

purpose of this article is to explore why clouds are inevitable, where they can fail, and how we can mitigate

risk. We’ll discuss the following:

■■Clearing the Mists: Definitions, Drivers, and SOA

■■Thunder Clouds: Challenges and Solutions

■■Cloud Contracts: Trust and Consideration

■■Conclusion: Blue Skies

Clearing the Mists: Definitions, Drivers, and SOA

Information technology clouds are a figure of speech. Fog with cat feet conjures an image in the same way

that IT clouds conjure an image. We have a vague idea that our wattage comes from reactors, water, wind,

or diesel and have no control over the grid that transmits that power. The power company cares only that we

pay for that current and we care only that it’s reliable and cheap. Services that were once tangible are now

virtualized in the same way that electricity is a service. This metaphor speaks both to the goal of hiding the

operating of services from those who consume those services as well as to the haze and hype that surround

clouds. The internet delivers cloud services using virtual machines that abstract its delivery from the hardware.

The deployment of enterprise computing has changed only glacially since the days of the IBM System/360

when children were watching pre-industrial and futuristic cartoons on their rabbit ear television set.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 2 – Bedrock [REF-1]

Wikimedia Commons

Figure 3 – Orbit City [REF-2]

Wikimedia Commons

Pre-Cloud Deployment Model

Cloud Deployment Model

Figure 4 – Bedrock [REF-1]

Figure 5 – Orbit City [REF-2]

In Figure 4, Bedrock’s data centers have concentrations of hardware with rising fixed costs but little elasticity in

response to changing market conditions. Human resources consist of mole farms of on-site staff. In Figure 5,

Orbit City’s data centers share infrastructure, storage, and development just-in-time resources through clouds

as represented by the ovals. Personnel are largely offsite, contingent, and global. The principle of parsimony

is that entities shouldn’t be multiplied save out of necessity. Orbit City is a triumph of that principle where

Occam’s Razor has slashed redundant entities to produce bottom-line savings, as this chart suggests [REF-3]:

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Stategic Goals Functions Bedrock Orbit City

Increase Speed and Test Provisioning Weeks Minutes


Change Management Months Hours

Release Management Weeks Minutes

Service Access Administered Self-service

Standardization Complex Reuse/Share

Metering/Billing Fixed Cost Variable Cost

Reducing Costs Server/Storage Utilization 10-20 Percent 70-90 Percent

Payback Period Years Months

Table 1

Orbit City puts the savings that clouds realize into marketing, talent, mergers, expansion, and rewarding



The National Institute of Standards and Technology (NIST) defines clouds as a model for enabling convenient,

on-demand network access to a shared pool of configurable resources, such as networks, servers, storage,

applications, and other services, that can be rapidly provisioned with minimal management effort or service

provider interaction [REF-4]. There is a notion that we somehow deploy resources from the ether. Just as we

could theoretically realize SOA using smoke signals, so too we could realize clouds using a wheel barrow.

As the NIST definition implies, it isn’t the internet that defines clouds but the sharing of resources. The vision

of clouds is to shift commodities into services. It’s a utility service, similar to the Plain Old Telephone Service

where telephone lines and switching networks are rendered as a pay-as-you-go service. Clouds are available

to multiple tenants who enjoy peaceful co-existence with each other with no adverse interference from systems

or enterprises that use the same interfaces.

Clouds also overlap other definitions. Grid computing is a form of distributed computing using platform

virtualization. On-demand computing is computing that is service-based, such as cloud computing and utility

computing. Utility computing aggregates computer resources for supply on a metered basis, like electricity, or

on a time basis, like a newspaper subscription.

The intercloud is a theoretical construct of all public clouds. Like cloud federation and the semantic cloud, it

provides interoperability through virtualization that is application programming interface (API) and platform

neutral. Semantic clouds relate more to meaning than to execution. It accommodates unstructured data,

facilitates metadata and data transport, and supports joins and other operations across networks.

Types of clouds include public, private, and hybrid clouds.

Public Clouds

Public clouds are available to the general public or a large industry group. It’s owned by an organization

selling cloud services. Public clouds are for processes that are easily standardized and have a lower security

Copyright © Arcitura Education Inc.


Issue LV • October 2011

risk. A community cloud is a shared public cloud that is exclusive to several organizations and supports a

specific community that has shared concerns, such as mission, security requirements, policy, and compliance


Private Clouds

Private clouds are operated solely for an organization and are usually implemented on client premises. Thirdparty

vendors manage private clouds. An enterprise will leverage off public clouds to justify its private clouds.

Because firms expect private clouds to export the same APIs as public clouds, they tend to build hybrid rather

than private clouds.

Hybrid Clouds

A hybrid cloud has private, community, or public clouds that remain unique entities but are bound together

by technology that enables data and application portability, such as cloud bursting for load-balancing. Cloud

bursting offloads additional work to a cloud on an on-demand basis after we have exhausted non-cloud


Testing-as-a-Service, Security-as-a-Service, Governance-as-a-Service, and Change Management-asa-Service

are all cloud components that can reduce the staffing, hardware, and software footprint of an

enterprise. But the most typical cloud components are Software-as-a-Service, Platforms-as-a-Service, and



Software-as-a-Service (SaaS) is a deployment model where a company licenses or makes available an

application to customers. Office productivity tools, social media, e-mail notification, business process

management, information sharing wikis, and enterprise resource planning suites are examples of SaaS. Users

typically access the software and associated data using a thin client web browser.


Infrastructure-as-a-Service (IaaS) is the delivery of storage, hardware, servers, facilities, telecommunications,

and networking components to support IT operations. IaaS cloud services include elastic computing, simple

storage services, metering and billing, elastic load balancing, and automatic scaling.


Platform-as-a-Service (PaaS) is the delivery of a computing stack, including application development,

interface development, database development, storage, security services, directory services, and testing.

PaaS providers offer API application and development and hosting services. PaaS is an extension of IaaS. It

provides another layer of abstraction on top of the computing backbone to allow us to regulate and execute the

systems that sit on that frame.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 6 – Enterprise Firewalls Separate Private/Hybrid and Public Clouds

Figure 6 depicts the PaaS, SaaS, and IaaS components of clouds that can support most enterprises. Clouds

consist of virtualized services, resources, and technologies. Virtualization services manage the control of

resource utilization and dynamic provisioning.

Virtualization technologies include hypervisors, parallelization, partitioning, emulators, virtual ethernets, virtual

input/output adapters, Internet Small Computer System Interfaces (iSCSI), virtual local area networks (VLAN),

Redundant Array of Independent Disks (RAID), and vendor specific technologies.

Cloud Business and Technology Drivers

The drivers for clouds are the same drivers that that sends IT talent onshore and into our best universities and

corporations and software development offshore. Capital is in a global search for efficiencies and capitalism’s

invisible hand exposes those efficiencies. Anyone who nurtures a backyard garden knows that the real cost of

that head of lettuce isn’t the $1.48 that we would pay in a grocery store. It’s more like $148 per head when we

consider the true costs. That cost come from a lack of scale, a lack of skills, and a lack of standard operating

procedures. Under the cloud paradigm, providers absorb those sunk costs and shares the risks with its

consumers. To use the garden analogy, the cloud provider supplies the land, tools, seed, and skills to allow

sufficient production to get the price of the lettuce under the cost of the rent of all services.

We can underestimate the scale needed to achieve profitability. The United States Homestead Act of 1862

attracted immigrants from Europe with the lure of 160 acres. But most came to see that patch of land would

make dire living a fact of existence. Only about forty percent of homesteading pioneers gained title. A century

Copyright © Arcitura Education Inc.


Issue LV • October 2011

and a half later, satellite-guided combines harvest grain on farms that are tens of thousands of acres.

Megastores, megamalls, planned communities, and the rise of the European Union have emerged to deliver

cost-driven efficiencies. Such a model doesn’t ensure profit, but it does reduce overhead to create earnings,

growth, and the ability to raise prices without losing customers.

Patterns of technology decades in the making are driving cloud adoption. Resource sharing isn’t new with

time sharing computers that date back to the early 1970s. The use of data warehousing brought distributed

computing and the grid. Increasing network speed and bandwidth with falling prices of chips allowed us to

consider computing as a single computational and storage device. These breakthroughs allowed enterprises

to realize strategic goals of reducing energy costs, increasing efficiency, and enhancing business agility. The

cloud model also flattens the project development bell curve, where effort is expended disproportionately

throughout the project lifecycle while the cost of effort remains constant.

Clouds are the result of the cost of digital communication falling to close to zero and the demand for digital

storage climbing close to infinity. Computing power doubles every 18 months under Moore’s law, driving

down the cost of a transistor from about ten dollars in 1965 to less than one millionth of a dollar at present.

The amount of data stored doubles each year and grows exponentially under the Law of Mass Digital

Storage. From 1990, hard disk drive capacity for personal computers accelerated at a compounded rate of

65 percent each year. The value of a telecommunications network is proportional to the square of the number

of connected users of the system under Metcalf’s Law. The number of network users is about 1.5 billion and

rising. On average, 70 percent of an IT budget is spent on maintaining its current infrastructure rather than

adding new capabilities. Data centers are underutilized about 85 percent of the time. The United States federal

government’s data centers have over 150,000 servers and had an average utilization rate for those servers

from five to fifteen percent. It spends over $75 billion annually on IT and is now making an effort to embrace

clouds, as are the governments of many other modern nations [REF-5].

SOA and Clouds

SOA is a design pattern that advocate loose coupling to compose business objects. It’s a model that doesn’t

restrict who is the consumer. SaaS and similar cloud components is a consumption model. Technical

components of a SOA may include multi-tier distribution and XML messaging and web services. Web oriented

architecture (WOA) exposes SOA services over internet using HTTP/S as the protocol for transport and

Representation State Transfer (REST) and web services for invocation and messaging. We can deploy SaaS

into the cloud and implement it using web services. Cloud clients are then exposed through a browser for

metered consumption or can be consumed by non-web client by application programming interface (API)


The focus of SOA is on application reuse tied to business processes. The focus of clouds is on the on-demand,

dynamic use of physical resources. The SOA-cloud (SOA-C) symbiosis features optimum orchestration of

services combined with optimum elastiticity of resources, such as processing power, storage, and number

of instances. A well-designed SOA must not be limited in resources. SOA-C is the best way to house those

resources. Given the pressure on operating budgets, IT leadership teams will look with increasing favor on

marrying SOA and clouds.

SOA enables present-day cloud computing. Cloud computing is an extension of SOA. The SOA framework

integrates into the cloud framework. Cloud computing in nowise replaces SOA. They both complement each

other and we can pursue SOA and clouds independently or concurrently. Although SOA and clouds can be

autonomous, the best practice is to consider clouds as a subset of SOA, as SOA middleware can help in

modeling, managing, and monitoring of cloud as well as web services. For clouds and like SOA, the physical

infrastructure must be discoverable and decoupled.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

We should determine what services should reside in clouds and what cloud services we can abstract in SOA.

With clouds, the cost of reuse shifts to providers. Once a sufficent number of legacy-wrapped components

exist, the can be reassembled to solve other problems. The overlap between cloud computing and SOA

is application layer components and services, network dependency, wide area network (WAN) services

invocation, leveraging and reusing IT assets, and the producer/consumer model.

Figure 6 – Enterprise Firewalls Separate Private/Hybrid and Public Clouds

Figure 7 depicts the PaaS, SaaS, and IaaS components of clouds on a SOA bus sufficient to support most

enterprises. Applications, data, and mobile endpoint devices are dispersed in the presentation layer. Services

reside in non-cloud environments and also in private, hybrid clouds, or public clouds as suggested by the

ovals. We could place account payable and account receivable services in a private cloud that pulls in SaaS,

PaaS, and IaaS resources that the bus orchestrates. Public clouds could deliver less secure mash ups, such

as a cartographic service and a podcast service.


Knowledge and resources from outside the enterprise triggers quantum leaps in progress. The broad sweep

of history shows that progress waxes and wanes depending on how people connect with dispersed sources of

information. “Human technological advancement depends not on individual intelligence but on collective idea

sharing, and it has done so for tens of thousands of years,” Matt Ridley notes [REF-6]. SOA asks the question:

how can we replace redundant functions? It seeks to de-silo departments with common services. Clouds

ask the same question but looks for the answer in SaaS. It seeks to de-silo the enterprise from solutions

available anywhere. SOA might construct a common reservations service, for example, while SaaS provides

a reservation service that other enterprises use. Just as SOA exposes collaborative services and just as data

Copyright © Arcitura Education Inc.


Issue LV • October 2011

warehouses store collaborative data, so too can clouds provide collaborative resources. We can deploy these

services, data, and resources to not just expand existing markets but to create new markets. But with these

rewards from clouds come risks. These include concerns about security, performance, availability, integration,

customization, regulatory compliance, and cost. The second part of this article that will be published in the

November 2011 issue of The Service Technology Magazine will discuss these issues and their resolution.


[REF-1] Fair use rationale: For critical commentary as fair use under United States copyright law. See http:// Source:

[REF-2] Fair use rationale: For critical commentary as fair use under United States copyright law. See http:// Source: Uploader used a capture device to create this

screenshot from a broadcast of “The Jetsons” on the Boomerang Channel (station logo removed with paint


[REF-3] Christopher Ensey ,”Security and Cloud Computing”, IBM Institute for Advanced Security, 2010.

[REF-4] Peter Mell and Tim Grance, “The NIST Definition of Cloud Computing”, National Institute of Standards

and Technology. October, 7, 2009, Version 15.

[REF-5] Brand Niemann, “Semantic Cloud Computing With Open Linked Data Using Resource Description

Framework (RDF) in Lieu of XML Technical or Capability Pattern”, October 29, 2009, United States

Environmental Protection Agency (Draft).

[REF-6] Matt Ridley, “From Phoenecia to Hayek to the Cloud”, The Wall Street Journal, September 24-25,

2011, A15.


Government cloud initiatives include the following:

United States


■■Federal Chief Information Officers Council

■■ and IT Dashboard

■■Defense Information Systems Agency (DISA)

■■Rapid Access Computing Environment (RACE)

■■US Department of Energy (DOE)


■■General Services Administration (GSA)

■■Department of the Interior

■■National Business Center (NBC) Cloud Computing

■■NASA Nebula

Copyright © Arcitura Education Inc.


Issue LV • October 2011

■■National Institute of Standards and Technology (NIST)

United Kingdom


European Union

■■Resources and Services Virtualization without Barriers Project (RESERVOIR)


■■Canada Cloud Computing

■■Cloud Computing and the Canadian Environment


■■The Digital Japan Creation Project (ICT Hatoyama Plan)

■■The Kasumigaseki Cloud


I wish to thank the following individuals who reviewed and critiqued my paper: Steve Wisner, Director, IT,

Genworth Financial and Errol Ryland, Director, MSS Technologies, Inc.

Copyright © Arcitura Education Inc.


Take Charge of Your AITCP Profile

Your AITCP profile has important new settings. Use the new AITCP Member and

Training Partner Management Systems to track your history and keep your AITCP

profile information and status current and active.

AITCP Member Management System

AITCP Training Partner Management System


the IT education company

Issue LV • October 2011

Mapping Service-Orientation to TOGAF 9

Part IV: Applying Service-Orientation to TOGAF’s

Service Contracts

by Filippos Santas, Credit Suisse Private Banking in Switzerland

In this series of articles we examine the correspondence and synergies of service-orientation and The

Open Group Architecture Framework. In parts I and II of this article we went through the phases related to

architecture definition, service design and implementation, architecture adoption and vision, the main roles,

and the implementation and governance of multiple service inventories using hierarchies of the TOGAF ADM.

In the process, we also examined the synergies between the two methodologies.

In the last article of this series we examine the level of abstraction that is necessary to apply service contracts

in TOGAF, using service-orientation principles and patterns.

Service Contracts in SOA and TOGAF

One of the primary focal points of the service-orientation paradigm is the design and standardization of service

contracts. In TOGAF and in SOA, the contracts are important in communicating and enforcing functionality,

policy/structure requirements, and constraints between different pieces of heterogeneous software. The

favorite metaphor used for describing the ability of service contracts to provide a healthy provider/consumer

relationship, is the way in which business contracts establish an agreement and maintain trust in a commercial

relationship between parties. The difference between service-orientation and TOGAF is how detailed this

agreement is, and how the provider and consumer interact.

Service-orientation recommends a high level of abstraction for the information provided in the contract. This is

because one service should be used by many different kinds of consumers (Service Reusability principle). In

order to accomplish the desired level of abstraction without compromising the precision or usefulness of the

information in the contract, service-orientation applies principles such as the Standardized Service Contract

and the Service Loose Coupling early in the analysis process.

On the other hand, TOGAF considers contracts to be unique to a specific provider/consumer relationship, and

they act as the container for both formal policies, as well as agreements that are unique to the parties. This

implies that the contract published by the service provider is coupled to the consumer.

Technical Interfaces, SLAs and Capabilities

In service-orientation the technical interface is the part of the service contract. The technical interface provides

the following:

■■meta information about the service

■■requirements (used by service consumers) for interacting with the service.

A technical interface includes a set of service capabilities (or operations). Each capability offers a subset of the

functionality of the service. Service consumers invoke the capabilities in order to gain access to the desired


Additionally, the service contract includes a Service Level Agreement (SLA) with quality-of-service features,

behaviors, limitations and potentially other human-readable documents.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

TOGAF distinguishes between two kinds of contracts:

■■Operational contracts which specify the actual communication protocols and message formats.

■■Governance contracts between two business entities. These specify what interaction is needed, inputs,

outputs, SLAs, OLAs, and KPIs. Governance contracts are the main concern at architectural level.

An important observation is that the operational contract in TOGAF corresponds to the requirements for

interacting with the service in service-orientation. The technical contract in SOA also includes information about

input and output structures, policies and operations. That is, the technical contract combines operational and

governance aspects.

Furthermore, the technical contract is not restricted to apply only between two business entities: the technical

contract specifies the required interaction, inputs, outputs and policies for many consumers of the service.

Something similar can be said for the SLA and other human readable documents. In service-orientation, the

SLA provided by the service applies to more than one consumer.

Service-Orientation Principles for Service Contracts

The application of service-orientation principles on the contract design ensures that service contracts (and

services) can be used by many consumers, resulting in service reuse. There are eight design principles [REF-

1, REF-2]

1. Standardized Service Contract: Services within the same service inventory are in compliance with the

same contract design standards.

2. Service Loose Coupling: Service contracts impose low consumer coupling requirements and are

themselves decoupled from the surrounding environment.

3. Service Abstraction: Service contracts only contain essential information and information about services is

limited to what published in service contracts.

4. Service Reusability: Services contain and express agnostic logic that can be positioned as reusable

enterprise assets.

5. Service Autonomy: Services exercise a high level of control over their underlying runtime execution


6. Service Statelessness: Services minimize resource consumption by deferring the management of state

information when necessary.

7. Service Discoverability: Services are supplemented with communicative meta data by which they can be

effectively discovered and interpreted.

8. Service Composability: Services are effective composition participants, regardless of the size and

complexity of the composition.

All of these principles, except for the Service Statelessness principle, contribute to the formation of the service

contract. In particular, the two first principles, help to standardize and decouple the technical contract of each

service, allowing for the “Contract First” design.

In the following sections we will see how they can be applied in the service contracts in TOGAF.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Service Profiles

Detailed analysis and design specification about a service is provided in standardized service profiles. Each

service has one service-level profile and one capability profile for each of its capabilities. The attributes that

correspond to these two profiles are provided in Tables 1 and 2.

Service Profile



Service Name -

Purpose Description


Purpose Description


Service Model





A concise, one sentence description of the service context and purpose.

A full explanation of the service context and its functional boundary with as many

details as necessary.

Entity, Utility, Task, Orchestrated Task, or a custom variation.

Words ideally taken from an official service inventory-level taxonomy or vocabulary.

The version number of the service currently being documented

The development status of the service is expressed in this field using standard

terms identifying a project lifecycle stage, such as “analysis,” “contract design,”

“development,” or “production.”

How to reach the official service custodian or owner, as well as others that

contributed to this documentation.

Table 1 – Service Profile Attributes

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Capability Profile



Capability Name -

Purpose Description


Logic Description


Composition Role

Composition Member






A concise explanation of the capability’s overall purpose and functional context

(short description)

A step-by-step description of the logic carried out by the capability.

Definitions of a capability’s allowable input and/or output value(s) and associated


The execution of capability logic can place a service into various temporary runtime

roles, depending on its position within service composition configurations.

A list of service capabilities composed by the capability logic. This provides a

cross-reference to other service capabilities the current capability has formed

dependencies on.

Similar to Service Keywords

Capabilities may be versioned with a number or with the version number appended

to the capability name.

Same lifecycle identifiers used for services

Usually (but not always) this is (one of) the service custodian(s)

Table 2 – Capability Profile Attributes

Much of the information available in a service profile should remain hidden from potential service consumers,

in order to avoid undesirable coupling of the consumers to the service design and implementation. Therefore

service contracts typically contain only a subset of the data in a service profile.

More specifically, the attribute:

■■Detailed Purpose Description

...of the service profile, and the attributes:

■■Logic Description

■■Composition Role, and

■■Composition Member Capabilities

...of the capability profile (marked with red in the above tables) violate the Service Abstraction and Service

Loose Coupling principles, and therefore should not be included in the service contract.

Furthermore, certain considerations should be made for choosing the appropriate values for the following

attributes in service and capability profiles:

Copyright © Arcitura Education Inc.


Issue LV • October 2011

■■Service Name

■■Purpose Description (Short)


■■Capability Name

Typically these attributes are parts of a service contract, and therefore they should respect the Service

Abstraction and Service Loose Coupling principles, and they should facilitate the discoverability of services.

Guidelines for putting appropriate values in the above attributes should be provided by applying the

Standardized Service Contract principle.

Concluding the discussion about Service and Capability Profiles it is important to note that service-orientation

recommends the use of Centralized Schemas for describing the types and structure of input and output

messages. Centralized Schemas have direct impact on the following attributes:



A new version of the schema may result in new versions for the service contracts. The propagation of versions

from the schema to the contracts should be consistent (Service Standardization). Additionally, the Input/Output

attribute references the required objects from the centralized schema, therefore, the Service Abstraction,

Service Loose Coupling and Standardized Service Contract principles should apply to the schema as well.

Generic Attributes for All Meta Model Objects in TOGAF

The service contract template includes all the attributes that TOGAF defines for service contracts in a SOA

[REF-3]. The attributes of the service contracts are also defined in the TOGAF content meta model [REF-3]. All

objects in the meta model, including service contracts have a common set of attributes. These attributes are

provided in Table 3.

The same considerations discussed previously for attributes of service profiles apply also to the attributes of

the service contract template. Although among the common attributes there are no forbidden attributes, the

values for the attributes:




...must satisfy the requirements of the following principles:

■■Service Abstraction

■■Standardized Service Contract

■■Service Loose Coupling

■■Service Discoverability

Copyright © Arcitura Education Inc.


Issue LV • October 2011


Although not specific to Service Contacts, the selection of the type of the service should not describe its

implementation. For example, a service type “Entity” is proper, but service types such as “Java” or “My

Vendor Platform” violate both the Service Abstraction and the Service Loose Coupling principles in the

contract, and therefore should be avoided.

TOGAF Attribute

ID (or Reference)


Type (or Category)




A unique identifier within the architecture information for crossreference,

clarity, and differentiation from other similar artifacts.

The name of the service should indicate in general terms what it

does, but should not be the only definition. The description is a

narrative of what the artifact is, what it does, and its relevance to

the architecture.

The type of the service to help distinguish it in the layer in

which it resides; e.g., data, process, functionality, presentation,


The source of the artifact, which may be a person or a

document, along with a date to support traceability of the


The owner of the artifact is the name (person or group) who

validates the details of this artifact; the person/team in charge of

the service.

SOA Profile



Purpose Description


Service Model


Table 3 – Common Attributes for all Metamodel Objects and Mapping to SOA

Other General and Business Attributes

The Business attributes in the service contract demonstrate that service contracts are between two entities in

TOGAF. That is, if a service provider is used by N consumers, then it may have N contracts.

Service-orientation considers this approach the exception, rather than the rule. Agnostic Services should serve

multiple consumers with the same contract. Nevertheless, the Concurrent Contracts pattern enables one body

of service logic to expose multiple service contracts. This pattern is often used to accommodate different types

of service consumers without having to convolute a single service contract.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

TOGAF Attribute


SOA Profile


Version The version of the service contract. Version

RACI Responsible/Accountable/Consulted/Informed. Custodian

Service Name


Service Name




Importance to the


Quality of



Contract Control


Result Control


Name of the consuming service.

Name of the provider service.

The functionality in specific bulleted items of what exactly this

service accomplishes. The language should be such that it

allows test cases to prove the functionality is accomplished.

What happens if the service is unavailable.

Accuracy and Completeness of information. The quality that is

expected from the service consumer in terms of input, and what

quality is expected from the service provider in terms of output.

Level of governance and enforcement applied to the contractual

parameters for overall service.

Measures in place to ensure that each service request meets

contracted criteria.


Composition Role

Purpose Description


Capability: Logic





Quality of Service Allowable failure rate. -

Service Level


Amount of latency the service is allowed to have to perform its



Table 4 – Business Attributes for TOGAF Service Contracts and Mapping to SOA

Another observation is that in TOGAF the service contract resembles a combination of service and capability

profile. It includes much information that often violates the Service Abstraction and Service Loose Coupling

principles. In particular the values of the attributes:



■■Functional Requirements,

■■Importance to the Process

...describe either run-time roles or are specific to a particular process. Agnostic services do not know anything

about the processes in which they are invoked, and therefore, cannot provide the information required in these


Additionally, detailed description of the functional requirements in the service contract introduces undesirable

Copyright © Arcitura Education Inc.


Issue LV • October 2011

coupling between the service contract and the functions defined within the service. A better approach is to list

the capabilities provided by the service, along with a short description for each of them, instead of describing

the functional requirements.

The control requirements are part of the overall requirements for the service and should probably be

standardized across the entire service inventory. The Domain Inventory pattern is here preferable instead of

providing such information in the service contract.

Handling of the attributes Quality of Service and Service Level Agreement will be discussed in the following


Attributes for Non-Functional Requirements

In order to satisfy non-functional requirements similar to those in Table 5, service designers usually apply

the Service Autonomy principle. If the service is agnostic, then all non-functional requirements should be

considered and the implementation should support the load predicted in the future and during the peak periods.

If the service cannot satisfy these requirements, then it cannot support the Service Reusability principle.

However, quality of service information needs to be reduced to reasonable levels by applying the Service

Abstraction principle. Making promises on unrealistic levels such as availability close to “ may result in

implementations that do not allow for the service to evolve.

TOGAF Attribute


SOA Profile


Throughput Volume of transactions estimated; e.g., 100,000

Throughput Period


Growth Period

Service Times

Peak Profile Short


Peak Profile Long




(or Security




The period in which those transactions are expected, e.g.,

100,000 per day.

The growth rate of transactions over time

The period in which the growth is estimated to occur; e.g.,

10,000 per year.

The available hours/days the service is needed; for example,

daily, 9 to 5 (excluding Holidays).

The profile of the short-term level of peak transactions; for

example, 50% increase between hours of 10 to 12 am.

The profile of the long-term level of peak transactions; for

example, 50% increase at month end.

Can execute this service in terms of roles or individual partners,

etc. and which invocation mechanism they can invoke.

The level and type of response required. Response times that

the service provider must meet for particular operations.

Purpose Description


Typically found in

an SLA

Table 5 – Attributes for Non-Functional Requirements

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Attributes for Technical Information

Attributes with technical information correspond to elements of a technical interface. In more detail:

The different invocation mechanisms provided for a single service are supported by the Concurrent Contracts

pattern. The invocation mechanism is always part of the technical interface.

On the other hand, strict invocation preconditions may result in services that cannot be reused in many

contexts. Such preconditions are typically not adequate for agnostic services, but can be enforced by

compositions or validation at the orchestration level. The Service Abstraction principle should be applied in

order to eliminate validations that may be restrictive for the reusability of the service.

The Business Objects attribute can refer to the centralized schemas and is a mandatory attribute for every

service contract.

Finally, the attribute Behavior Characteristics violate the Service Abstraction and Service Loose Coupling

principles: the contract depends on the implementation. This attribute should not be part of the contract for an

agnostic service. On the other hand, architectures may put a limit on the depth of service compositions in order

to satisfy Service Autonomy. In such case, it may be necessary to know if the invoked service is a composition.

TOGAF Attribute





This includes the URL, interface, etc. There may be multiple

invocation paths for the same service. There may be the same

functionality for an internal and an external client, each with a

different invocation means and interface.

Any pre-conditions that must be met by the consumer

(authentication, additional input, etc.)

SOA Profile


Part of the Technical



Business Objects Business objects transferred by the service. Input/Output



The criteria and conditions for successful interaction and any

dependencies (on other service interactions, etc.). This should

include any child services that will be invoked/spawned by this

service (in addition to dependencies on other services).




Table 6

Other Attributes

The content meta model in TOGAF [REF-3] defines additional attributes for service contracts. These attributes

involve primarily non-functional requirements and can be classified in three groups:

■ ■ Group 1: Service quality characteristics, Availability characteristics, Manageability characteristics (control

of state information), Serviceability characteristics, Performance characteristics, Reliability characteristics,

Recoverability characteristics,

Copyright © Arcitura Education Inc.


Issue LV • October 2011

■■Group 2: Localability characteristics (Ability of a system to be found when needed),

■■Group 3: Privacy characteristics (data protection), Integrity characteristics, Credibility characteristics,

Localization characteristics, Internationalization characteristics, Interoperability characteristics, Scalability

characteristics, Portability characteristics, Extensibility characteristics, Capacity characteristics.

The requirements of Group 1 are typically satisfied by applying the Service Autonomy and Service

Statelessness principles. As mentioned earlier, application of the Service Abstraction principle is mandatory in

order to allow more room to the service for evolvement.

The Localability attribute in Group 2, is accomplished by the Service Discoverability principle.

The attributes in Group 3 are not specific to service-orientation, but their satisfaction by the service

implementation contributes to the Service Reusability.


In this document we reviewed the attributes of the service contracts and profiles in service-orientation and

TOGAF 9. The principles of Service Abstraction and Service Loose Coupling need to be applied to several

attributes in TOGAF’s service contracts. Some of the attributes do not respect service-orientation, and couple

the service contract to other contexts.


[REF-1] SOA Principles of Service Design”, Thomas Erl, Prentice Hall/PearsonPTR,

[REF-2] Understanding Service-Orientation - Part II: The Principles.

[REF-3] TOGAF Version 9. The Open Group, 2009.

Copyright © Arcitura Education Inc.


SOA .NET Developer



.NET Developer

Partial and Complete Self-Study

Kit Bundles Now Available for

Pre-Order with Special Pricing


the IT education company

Issue LV • October 2011

Understanding Reuse and Composition:

Working with the Service Reusability and Service

Composability Principles

by Thomas Erl, Arcitura Education Inc.


This article is a modest collection of excerpts from three books [REF-1, 2, 3] in the Prentice Hall Service-

Oriented Computing Series, combined to provide a concise overview of what lies at the very core of the

service-orientation paradigm and the service-oriented architectural model: the identification and aggregation

of agnostic logic into reusable and composable units. These units represent the foundational moving parts

that collectively define and enable service-oriented solutions. Understanding how they are realized and then

subsequently (and repeatedly) utilized is the most essential requirement to successfully benefiting from

anything that SOA has to offer. The upcoming sections explore this topic area by focusing on the Service

Reusability and Service Composability principles, as they are applied to the early stages of service modeling

and design, and how they are further supported by key design patterns.

Breaking Down the Problem: Service Reusability and the Separation of Concerns

The SOA design patterns catalog establishes a set of foundational service patterns responsible for identifying

and defining the scope of functional service contexts and boundaries, as well as service capabilities. As shown

in Figure 1, the majority of these patterns pertain and lead to the definition of agnostic logic suitable for reuse

and therefore subject to the Service Reusability principle.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 1 – These foundational service patterns can be combined to establish a primitive service modeling

process that results in the definition of service candidates and service capability candidates.

As explained in the upcoming sections, the combined application of these patterns essentially carries out the

separation of concerns in support of the service-orientation paradigm.

Functional Decomposition

The separation of concerns theory is based on an established software engineering principle that promotes the

decomposition of a larger problem into smaller problems (called concerns) for which corresponding units

Copyright © Arcitura Education Inc.


Issue LV • October 2011

of solution logic can be built. The rationale is that a larger problem (the execution of a business process, for

example) can be more easily and effectively solved when separated into smaller parts. Each unit of solution

logic that is built exists as a separate body of logic responsible for solving one or more of the identified,

smaller concerns (Figure 2). This design approach forms the basis for distributed computing and is essentially

embodied by the Functional Decomposition pattern.

Figure 2 – On its own, Functional Decomposition results in the decomposition of the larger problem into smaller

problems. The actual definition of solution logic units occurs through the application of subsequent patterns.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Service Encapsulation

When assessing the individual units of solution logic that are required to solve a larger problem (carry out a

business process), we may realize that only a subset of the logic is suitable for encapsulation within services.

This identification of service logic is accomplished via the application of the Service Encapsulation pattern

(Figure 3).

Figure 3 – Some of the decomposed solution logic is identified as being not suitable for service encapsulation.

The highlighted blocks represent logic to which this pattern was successfully applied.

Agnostic Context

After the initial decomposition of solution logic we will typically end up with a series of solution logic units that

correspond to specific concerns. Some of this logic may be capable of solving other concerns, but by grouping

single-purpose and multi-purpose logic together, we are unable to realize any potential reuse. By identifying

what parts of this logic are not specific to known concerns, we are able to separate and reorganize the

appropriate logic into a set of agnostic contexts (Figure 4).

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 4 – Decomposed units of solution logic will naturally be designed to solve concerns specific to a

single, larger problem. Units 1, 3, and 6 represent logic that contains multi-purpose functionality trapped

within a single-purpose (single concern) context. The application of this pattern results in a subset of the

solution logic being further decomposed and then distributed into services with specific agnostic contexts.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Agnostic Capability

Within each agnostic service context, the logic is further organized into a set of agnostic service capabilities. It

is, in fact, the service capabilities that address individual concerns. Because they are agnostic, the capabilities

shaped by this pattern are multi-purpose and can be reused to solve multiple concerns (Figure 5).

Figure 5 – A set of agnostic service capabilities is defined, each capable of solving a common concern.

Utility Abstraction

The application of the Utility Abstraction pattern results in the separation of common cross-cutting functionality

that is neither specific to a business process nor a business entity. This establishes a specialized agnostic

functional context limited to utility logic. The resulting type of service is referred to as a utility service and the

repeated application of this pattern within a service inventory results in the creation of a logical utility layer

(Figure 6).

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 6 – The application of Utility Abstraction restricts the agnostic context of the service to utility logic.

Entity Abstraction

Every organization has business entities that represent key artifacts relevant to how operational activities are

carried out. The application of Entity Abstraction shapes the functional context of a service so that it is limited to

logic that pertains to one or more related business entities. As with Utility Abstraction, the repeated application

of this pattern establishes its own logical service layer (Figure 7).

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 7 – The application of Entity Abstraction restricts the agnostic context of the service to entity logic.

The Inventory Analysis Cycle

When viewing the preceding set of patterns, one can see there are steps within a service-oriented analysis

process. It is important to realize that this process (and its steps) is preferably carried out iteratively, as part of

a cycle that identifies, defines, and also refines agnostic service contexts and agnostic capabilities.

This is commonly accomplished by decomposing a set of business processes that belong to a given domain

within the IT enterprise. This domain represents the boundary of a planned service inventory. By iterating

through a separate analysis and functional decomposition of each business process, agnostic service

candidates and their capabilities can be continually refined until they reach a state where their reuse potential

has been fully determined before they are physically designed and developed. This takes the guesswork out

of applying the Service Reusability principle in that the reuse of each service is pre-determined based on the

current state of the business. Future business change is naturally accommodated by leveraging the inherent

characteristics and flexibility established by this and other principles.

Each of these service candidates is added to a collection that eventually results in a blueprint of the service

inventory, as illustrated in Figure 8. The depicted analysis cycle is one of several ways to incorporate serviceoriented

analysis within an SOA methodology. A key consideration here is that the extent to which the cycle

needs to be iterated is directly related to the scope of the planned service inventory. When applying Domain

Inventory within an IT enterprise, multiple service inventories can co-exist and can be independently planned

and defined with different approaches, each iterating through their own cycles within manageable boundaries.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 8 – The cycle begins with the definition of business models (such as entity relationship models and

business process definitions) and takes practical considerations into account via a step dedicated to the ongoing

definition of the required technology architecture that corresponds to the scope of the planned service

inventory. As service candidates are produced or refined through repeated iterations of the service-oriented

analysis (and service modeling) phase, required business models are defined or updated, the technology

architecture is accordingly augmented, and the service inventory blueprint is gradually populated.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Building Up Solutions: Service Capability Composition and Recomposition

One of the fundamental characteristics that distinguish service-oriented technology architecture from other

forms of distributed architecture is composition-centricity, meaning that there is a baseline requirement to

inherently support both the composition and re-composition of the moving parts that comprise a given solution.

In this section, we cover some fundamental aspects of composition in relation to service-orientation by briefly

describing relevant principles and patterns.

Service-Orientation and Service Composition

A baseline requirement for achieving the strategic goals of service-oriented computing, is that services must

be inherently composable. As a means of realizing these goals, the service-orientation design paradigm is

therefore naturally focused on enabling flexible composition.

This dynamic is illustrated in Figure 9, where we can see how the collective application of service-orientation

principles share software programs into services that are essentially “composition-ready,” meaning that they

are interoperable, compatible, and composable with other services as part of the same service inventory. The

scope of this service inventory can vary, as long as it is meaningfully cross-silo (as per Domain Inventory).

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 9 – Service A is a software program shaped into a unit of service-oriented logic by the

application of service-orientation design principles. Service A is delivered within a service

inventory that contains a collection of services to which service-orientation principles were

also designed. The result is that Service A can participate initially in Composition X and,

more importantly, can be pulled into additional service compositions, as required.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

What is being illustrated in Figure 9 is not just that services can be aggregated. All distributed systems are

comprised of aggregated software programs. What is fundamentally distinct about how service-orientation

positions services is that they are repeatedly composable, allowing for subsequent recomposition.

This is what lies at the core of realizing organizational agility as a primary goal of adopting service-oriented

computing. By have a set of services (again, within the scope determined by the service inventory only)

naturally interoperable and design for participation in complex service compositions, we are able to fulfill new

business requirements and automate new business processes by augmenting existing service compositions

or creating new service compositions with reduced effort and expense. This target state is what leads to the

Reduced IT Burden goal of service-oriented computing.

Service Composability

Among the eight service-orientation design principles, there is one that is specifically relevant to service

composition design. The Service Composability principle is solely dedicated to shaping a service into an

effective composition participant. All other principles support Service Composability in achieving this objective

(Figure 10). In fact, as a regulatory principle, Service Composability is applied primarily by ensuring that the

design goals of the other seven principles are realized to a sufficient extent.

Figure 10 – A common objective of all service-orientation design principles

is that they shape services in support of increasing composability potential.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Capability Composition and Capability Recomposition

Fundamental service identification and definition patterns can be assembled into an application sequence

that forms a primitive service modeling process. However, those patterns result only in the separation of logic

into individual functional contexts and capabilities. The application of these fundamental patterns need to be

followed by patterns that reassemble the separated logic into aggregates. This is the purpose of Capability

Composition and Capability Recomposition (Figure 11).

Figure 11 – Capability Composition is one of two patterns applied subsequent to

the application of service identification and definition patterns. The relevance of

the Capability Recomposition pattern is explained in the following section.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Capability Composition

Capability Composition represents a pattern that is applied to assemble the decomposed service logic together

into a specific service composition capable of solving a specific larger problem (Figure 12).

The importance of this pattern, beyond forming the basis for the basic aggregation of service functionality, is

that it reinforces fundamental patterns, such as Logic Centralization and Service Normalization. It does so by

preserving the functional boundaries established by service contexts in that it requires a service that needs

access to logic outside of its context to access this logic via the composition of another service.

Figure 12 – Although generally referred to as service composition, services that compose each

other actually do so via their individual service capabilities, hence the name of this pattern.

Capability Recomposition

As previously mentioned, the recomposition of services is a fundamental and distinctive goal of serviceoriented

computing. This pattern specifically addresses the repeated involvement of a service via the repeated

composition of a service capability. The patterns relationship diagram shown in Figure 13 highlights how

service identification and definition patterns, together with Capability Composition, essentially lead up to

opportunities to apply Capability Recomposition.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

A very important consideration here is that the application of Capability Recomposition has a different purpose

and different requirements than Capability Composition. As covered earlier, service-orientation design

principles are geared specifically toward enabling the application of Capability Recomposition. And, as further

shown in Figure 13, most other SOA design patterns solve their respective design problems in support of

enabling the application of this pattern.

Figure 13 – Because of how core the repeated composability of services is to service-orientation

and SOA, Capability Recomposition has many relationships with other SOA design patterns.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Composition Roles

With the potential for Capability Recomposition to be applied frequently, a given service can find itself

participating in different ways within a given service composition. Therefore, in order to better identify and

describe the interaction between services within a service composition architecture, a set of runtime roles exist:

■■composition controller – The service with a capability that is executing the parent composition logic required

to compose capabilities within other services.

■■composition member – A service that participates in a service composition by being composed by another


■■composition initiator – The program that initiates a service composition by invoking the composition

controller. This program may or may not exist as a service.

■■composition sub-controller – A variation of the composition controller role that is assumed by a service

carrying out nested composition logic (within a capability that is composing one or more other service

capabilities while itself also being composed).

Services assume composition roles within the context of different service compositions, depending on the logic

executed by service capabilities. In other words, a service’s capabilities will automatically enlist the service in

one or more composition roles.

Service Layers

The entity and utility service models correspond to the Entity Abstraction and Utility Abstraction patterns

respectively. These service models represent the two most common agnostic functional contexts for services

(in other words, they represent the two popular means of further applying the Agnostic Context pattern).

When we abstract common types of logic into collections of services based on the same underlying service

model, we end up establishing service layers. These logical layers are the result of the application of the

Service Layers pattern, which provides us with an opportunity to organize and classify all services within a

given service inventory.

Service Layers requires that at least two layers exist, and these layers are generally based on a fundamental

separation of agnostic and non-agnostic service logic. Therefore, we typically end up with a task service layer,

followed by a service layer based on one or more agnostic service models, as shown in Figure 14.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 14 – At minimum, Service Layers requires that two logical

layers of services be established within a service inventory.

The Three-Layer Inventory compound pattern essentially indicates that the most common application

of Service Layers is via the combined application of Entity Abstraction, Utility Abstraction, and Process

Abstraction. This establishes a logical layered architecture that tends to encompass the natural hierarchy

formed by most service compositions (Figure 15).

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 15 – A composition of services that forms a hierarchy that spans the three

service layers represented by the Three-Layer Inventory pattern. The top layer is

defined via the application of the Process Abstraction pattern (explained shortly).

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Non-Agnostic Context

The fundamental service identification and definition patterns established earlier in this article focused on the

separation of multi-purpose or agnostic service logic. When decomposing business process logic as part of

a service-oriented analysis, what remains after multi-purpose logic is separated is logic that is specific to the

business process. Because this logic is considered single-purpose in nature, it is classified as non-agnostic.

The encapsulation of non-agnostic logic within a service is the basis of the Non-Agnostic Context pattern

(Figure 16).

Figure 16 – By revisiting the decomposition process, we can now apply Non-Agnostic

Context to establish a service context for the separated non-agnostic logic.

Process Abstraction and Task Services

Common types of agnostic services are generally (but not always) dependent on the existence of abstracted,

non-agnostic business process logic that is encapsulated in task services (Figure 17). This is the result of the

combined application of Non-Agnostic Context and Process Abstraction.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Figure 17 – Each task service represents is part of a parent service layer and

is responsible for encapsulating logic specific to parent business process logic.

The runtime role is most commonly associated with the task service model is the composition controller

because the functional scope of these services is typically focused on a parent business process. A variation of

the task service model, called the orchestrated task service, is discussed shortly.


Orchestration builds upon service composition by aiming to establish a physical environment capable of

centrally executing and governing multiple automated business processes. The Orchestration compound

pattern represents such an environment via the co-existent application of a set of specific patterns (Figure 18).

Figure 18 – The Orchestration compound pattern.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Process Abstraction, Process Centralization, and Orchestrated Task Services

The Process Abstraction pattern is fundamental to orchestration because an orchestration platform is designed

specifically to house and execute parent business process logic. Process Centralization is equally fundamental

because an orchestration platform enables the centralized hosting, execution, and governance of the same

parent business process logic.

The application of Process Abstraction alone results in the creation of task services, as explained earlier.

However, it is the combined application of Process Abstraction and Process Centralization that defines the

orchestrated task service model. This is because orchestrated task services are distinguished from regular

task services by the fact that they are hosted within an orchestration platform.

In other words, although they logically still abstract the same non-agnostic service logic into a separate layer

(Figure 19), they are different in how they are physically implemented and administered.

Figure 19 – Orchestrated task services appear identical to task

services when viewed from a logical service layers perspective.

Orchestrated task services are built within and upon the specific features and architectural components that

comprise an orchestration environment. This changes the baseline complexion of the task service architecture

to such an extent that a separate service model classification is warranted.


Service Reusability is concerned with the identification of reusable logic as well as ensuring that the service

architecture itself is capable of real world reuse. Several foundational service identification and definition

patterns can be applied during iterations of the service-oriented analysis phase in order to identify, define,

separate, and refine agnostic logic suitable for reuse.

Copyright © Arcitura Education Inc.


Issue LV • October 2011

Service Composability is focused on the effective and repeatable composition of service capabilities, as well as

ensuring the agile incorporation of service architectures within multiple service composition architectures. Key

patterns that relate directly to enabling service composition in support of the Service Composability principle

include Capability Composition, Capability Recomposition, Non-Agnostic Context, and Process Abstraction.

Other service-orientation design principles and many other SOA design patterns directly contribute to and

support the goals of the Service Reusability and Service Composability principles, as do numerous service

technologies and platforms. However, it is important to understand that the foundation upon which we reuse

and compose services is established when we first identify and define agnostic units of logic.


[REF-1] SOA Design Patterns, ISBN: 9780136135166, Prentice Hall,

[REF-2] SOA Patterns Catalog,

[REF-3] SOA Principles of Service Design, ISBN: 9780132344821, Prentice Hall,

[REF-4] SOA Principles,

[REF-5] SOA with.NET and Windows Azure: Realizing Service-Orientation with Microsoft Technologies, ISBN:

978013158231, Prentice Hall,

[REF-6] SOA Glossary,

Copyright © Arcitura Education Inc.



SOA Analyst Certification

October 24-28, 2011

Chicago, IL, USA

Cloud Technology Professional

Oct 31- Nov 2, 2011

San Francisco, CA, USA

SOA Architect Certification

Oct 31- Nov 4, 2011

Fairfax, VA, USA

SOA Governance Specialist

November 14-16, 2011

Stockholm, Sweden


the IT education company

Certified SOA Architect

November 14-18, 2011

Sydney, Australia

SOA .NET Developer

November 21-23, 2011

Utrecht, Netherlands

Certified SOA Architect

November 21-25, 2011

Ottawa, ON, Canada

Australia Workshop

Arcitura Education is

pleased to announce two

new SOA and Cloud

Computing workshops in

Sydney, Australia this

November. As a one-time

promotion, participants

that register for one

workshop will receive a

$1,000 USD credit toward the other.

Contact for more details.


SOA Architect Certification

November 7-9, 11, 12, 2011 • Mexico

City, Mexico

SOA Consultant Certification

November 7-10, 12, 2011 • Mexico City,


SOA Analyst Certification

November 7, 9, 10, 14, 15, 2011

Mexico City, Mexico

Cloud Technology Professional


November 14-16, 2011 • Fairfax, AZ,


SOA Consultant Certification

November 15-19, 2011 • Brasilia, Brazil

Cloud Technology Professional


November 21-23, 2011 • Sydney,


SOA .NET Developer Certification

November 21-23, 2011 • Utrecht,


Cloud Technology Professional


December 5-7, 2011 • Charleston, SC,


SOA Governance Specialist


December 5-7, 2011 • Las Vegas, NV,


SOA Architect Certification

December 5-9, 2011 • Stockholm,


SOA Architect Certification

December 5-9, 2011 • Miami, FL, USA

Cloud Technology Professional


December 12-14, 2011 • Miami, FL,


SOA Architect Certification

December 12-16, 2011 • Las Vegas, NV,


Cloud Technology Professional


January 16-18, 2012 • Las Vegas, NV,


SOA Architect Certification

January 9-13, 2012 • Kolkata, India

Cloud Technology Professional


January 16-18, 2012 • Kolkata, India

SOA Architect Certification

January 16-20, 2012 • Utrecht,


SOA Architect Certification

January 16-20, 2012 • Chennai, India

Cloud Technology Professional


January 19-21, 2012 • Chennai, India

Cloud Technology Professional


January 23-25, 2012 • Pune, India

SOA Consultant Certification

January 23-27, 2012 • Vancouver, BC,


Cloud Technology Professional


January 26-28, 2012 • Delhi, India

Cloud Technology Professional


January 30-February 1, 2012 • Fairfax,


SOA Architect Certification

January 30-February 3, 2012 • Toronto,

BC, Canada

SOA Architect Certification

February 6-10, 2012 • Las Vegas, NV,


SOA Architect Certification

February 7-11, 2012 • Brasilia, Brazil

SOA Analyst Certification

February 7-11, 2012 • Brasilia, Brazil

SOA Consultant Certification

February 13-17, 2012 • Pune, India

SOA Architect Certification

February 20-24, 2012 • Sydney,


SOA Consultant Certification

February 20-24, 2012 • Delhi, India

SOA Architect Certification

February 20-24, 2012 • Singapore,


SOA Governance Specialist


February 22-24, 2012 • Stockholm,


SOA Consultant Certification

February 20-23, 25, 2012 • Bogota,


SOA Architect Certification

February 20-22, 24, 25, 2012 • Bogota,


SOA Analyst Certification

February 20, 22, 24, 27, 28, 2012 •

Bogota, Columbia

SOA Security Specialist Certification

February 27-29, 2012 • Vancouver, BC,


Cloud Technology Professional


February 27-29, 2012 • London, UK

Cloud Technology Professional


February 27-29, 2012 • Boston, MA,


SOA Architect Certification

February 27-March 2, 2012 • Kuala

Lumpur, Malaysia

SOA Analyst Certification

March 5-9, 2012 • Vancouver, BC,


SOA Consultant Certification

March 5-9, 2012 • Bangkok, Thailand

SOA Architect Certification

March 5-9, 2012 • Dubai, UAE

Cloud Technology Professional


March 6-8, 2012 • Singapore,


Cloud Technology Professional


March 9-11, 2012 • Kuala Lumpur,


SOA Governance Specialist


March 12-14, 2012 • Las Vegas, NV,


SOA Quality Assurance Specialist


March 12-14, 2012 • Vancouver, BC,


SOA Architect Certification

March 12-16, 2012 • Frankfurt,


Cloud Technology Professional


March 13-15, 2012 • Bangkok, Thailand

Cloud Technology Professional


March 19-21, 2012 • Charleston, SC,


Cloud Technology Professional


March 19-21, 2012 • Dubai, UAE

SOA Consultant Certification

March 19-22, 24, 2012 • Quito, Ecuador

SOA Architect Certification

March 19-21, 23, 24, 2012 • Quito,


orkshop Calendar

Issue LV • October 2011


Philip Wik

Philip Wik is a Senior Consultant for MSS Technologies. Philip has worked for JP Morgan/

Chase, Wells Fargo, American Express, Honeywell, Boeing, Intel, and other companies in a

variety of applications development, integration, and architectural roles. He has published two

books through Prentice-Hall: How to Do Business With the People’s Republic of China and

How to Buy and Manage Income Property.


■■Thunder Clouds: Managing SOA-Cloud Risk - Part I

■■Service-Oriented Architecture and Business Intelligence

■■Confronting SOA’s Four Horsemen of the Apocalypse

■■Machiavelli’s SOA: Toward a Theory of SOA Security

■■Effective Top-down SOA Management in Efficient Bottom-up Agile World - Part II

■■Effective Top-down SOA Management in Efficient Bottom-up Agile World - Part I

Filippos Santas

Filippos is an IT Architect for Credit Suisse Private Banking in Switzerland and a SOASchool.

com Certified SOA Trainer, Analyst, Architect, Consultant, and Security Specialist. Additionally,

he is certified by The Open Group on TOGAF 9 and by IBM on the Rational Unified Process

V7.0. In the last 10 years, Filippos has been the lead for the analysis and architecture of

a number of successful SOA projects and for transforming legacy architectures to serviceoriented

architectures, primarily in the financial sector. His achievements include the

conceptual and physical design of the international insurance claims service network that

connects insurance policies, customer companies and state authorities in 44 countries across

the globe, combining legislation, business processes, business rules, business objects,

knowledge bases and different platforms.

Filippos recent work with Credit Suisse has been as an SOA Architect, combining the

profitable and established functionality of legacy systems with centralized business process

services, decentralized business rule services, domain specific BOMs and entity services and

end-to-end traceability to business requirements and processes.


■■Mapping Service-Orientation to TOGAF 9 - Part IV: Applying Service-Orientation to

TOGAF’s Service Contracts

■■Mitigating Service-Orientation Risks with RUP

Copyright © Arcitura Education Inc.


Issue LV • October 2011

■■Mapping Service-Orientation to TOGAF 9 - Part III: SOA Governance Models for Service

Inventories in TOGAF

■■Mapping Service-Orientation to TOGAF 9 - Part II: Architecture Adoption, Service Inventories

and Hierarchies

■■Mapping Service-Orientation to TOGAF 9 - Part I: Methodology, Processes, Steps, Principles

Thomas Erl

Thomas Erl is a best-selling IT author and founder of ® and . Thomas has been the world’s top-selling SOA author for over five years

and is the series editor of the Prentice Hall Service-Oriented Computing Series from Thomas

Erl (, as well as the editor of the Service Technology Magazine

( With over 140,000 copies in print world-wide, his seven published

books have become international bestsellers and have been formally endorsed by senior

members of major IT organizations, such as IBM, Microsoft, Oracle, Intel, Accenture, IEEE,

HL7, MITRE, SAP, CISCO, HP, and others.

Three of his books, SOA Design Patterns, SOA Principles of Service Design, and SOA

Governance, were authored in collaboration with the IT community and have contributed to

the definition of the service-oriented architectural model and service-orientation as a distinct

paradigm. Thomas is currently working with over 20 authors on several new books dedicated

to topic areas such as cloud computing, modern service technologies, and service-orientation.

As CEO of Arcitura Education Inc. and SOA Systems Inc. and in cooperation with ® and , Thomas has led the development of curricula

for the internationally recognized SOA Certified Professional (SOACP) and Cloud Certified

Professional (CCP) accreditation programs, which have established a series of formal,

vendor-neutral industry certifications.

Thomas is the founding member of the SOA Manifesto Working Group and author of the

Annotated SOA Manifesto ( He is the co-chair of the Arcitura

Education Committee, and he further oversees the and

initiatives, which are dedicated to the on-going development of master pattern catalogs for

service-oriented computing and cloud computing.

Thomas has toured over 20 countries as a speaker and instructor for public and private

events, and regularly participates in international conferences, including SOA + Cloud

Symposium and Gartner events. Over 100 articles and interviews by Thomas have been

published in numerous publications, including the Wall Street Journal and CIO Magazine.

Copyright © Arcitura Education Inc.


Arcitura IT Certified

Professionals (AITCP)


Join the thousands of members of the growing international

Arcitura community. Launched for the first time in mid-2011,

Arcitura Education made official social media communities

available via LinkedIn, Twitter, and Facebook. These new

communities join the already existing memberships of

LinkedIn, Twitter, and Facebook platforms for the Prentice Hall

Service-Oriented Computing Series from Thomas Erl and the

International SOA + Cloud Symposium Series.

The Service Technology Magazine is a monthly online

publication provided by Arcitura Education Inc. and

officially associated with the “Prentice Hall Service-

Oriented Computing Series from Thomas Erl.” The

Service Technology Magazine is dedicated to publishing

specialized articles, case studies, and papers by industry

experts and professionals in the fields of serviceoriented

architecture (SOA), cloud computing, semantic

Web technologies, and other areas of services-based

technology, innovation, and practice.

Copyright © Arcitura Education Inc.

More magazines by this user
Similar magazines