Advances in Computer Science: an International Journal - CiteSeerX

Advances in Computer Science:

an International Journal

Vol. 2, January 2013

© ACSIJ PUBLICATION www.ACSIJ.org

ZDB-Number: 2688359-4

ACSIJ Editorial Board 2013 Dr. Seyyed Hossein Erfani ( Chief Editor ) Azad University Tehran, Iran Dr. Indrajit Saha Department of Computer Science and Engineering, Jadavpur University India Mohammad Alamery University of Baghdad Baghdad, Iraq

ACSIJ Reviewers Committee

• Prof. José Santos Reyes, Faculty of Computer Science, University of A Coruña, Spain • Dr. Dariusz Jacek Jakóbczak, Technical University of Koszalin, Poland • Dr. ANANDAKUMAR.H, PSG College of Technology (Anna University of Technology), India • Dr. Mohammad Nassiri, Faculty of Engineering, Computer Departement, Bu-Ali Sina University,

Hamedan, Iran • Dr. Indrajit Saha, Department of Computer Science and Engineering, Jadavpur University, India • Prof. Zhong Ji, School of Electronic Information Engineering, Tianjin University, Tianjin, China • Dr. Heinz DOBLER, University of Applied Sciences Upper Austria, Austria • Dr. Ahlem Nabli, Faculty of sciences of Sfax,Tunisia • Dr. Ajit Kumar Shrivastava, TRUBA Institute of Engg. & I.T, Bhopal, RGPV University, India • Mr. S. Arockiaraj, Mepco Schlenk Engineering College, Sivakasi, India • Prof. Noura AKNIN, Abdelmalek Essaadi University, Morocco

ACSIJ Published Papers are Indexed By: 1. Google Scholar 2. EZB, Electronic Journals Library ( University Library of Regensburg, Germany) 3. DOAJ, Directory of Open Access Journals 4. Academic Journals Database 5. Bielefeld University Library - BASE ( Germany ) 6. AcademicKeys 7. WorldCat (OCLC) 8. Technical University of Applied Sciences ( TH - WILDAU Germany) 9. University of Rochester ( River Campus Libraries _ USA New York)

TABLE OF CONTENTS

1. Service Registry: A Key Piece for Enhancing Reuse in SOA– (pg 1-8) Juan Pablo García-González, Verónica Gacitúa-Décar, Dr. Claus Pahl 2. Caching in the Distributed Environment– (pg 9-16) Abhijit Gadkari 3. Is SOA Being Pushed Beyond Its Limits?– (pg 17-23) Grace A. Lewis 4. Key management in heterogeneous wireless sensor networks using Voronoi diagrams– (pg 24-29)

5. On Distributed Embedded Systems– (pg 30-39) Arvindra Sehmi 6. Evaluating Application Architecture, Quantitatively– (pg 40-47) V. Gnanasekaran 7. Software Architecture in the Agile Life Cycle– (pg 48-52) Diego Fontdevila, Martín Salías

Ronak Tahmasbi, H.Haj seyed javadi, M.E.Shiri, Ahmad Allahyari

Service Registry: A Key Piece for Enhancing Reuse in SOA

Juan Pablo García-González1, Verónica Gacitúa-Décar2, Dr. Claus Pahl3

1 DATCO,Chile S.A. 2,3 Software Engineering Research Centre, Dublin City University & Lero, Irish

Abstract

One of the promises of adopting a service-oriented

approach in organizations is the potential cost savings that

result from the reuse of existing services. A service

registry is one of the fundamental pieces of service-

oriented architecture (SOA) for achieving reuse. It refers

to a place in which service providers can impart

information about their offered services and potential

clients can search for services. In this article, we provide

advice for implementing an enterprise-wide service

registry. We also discuss open issues in industry and

academia that affect the management of service- repository

information.

1. Introduction

The reuse of services greatly depends on the ability to

describe and publish the offered functionality of the

services to potential consumers (clients). A service registry

allows you to organize information about services and

provide facilities to publish and discover services.[1]

Universal Description Discovery and Integration (UDDI)

and the Web Services Description Language (WSDL)—

together with SOAP— are standards for describing

services and their providers, as well as how services can be

consumed:

WSDL [2] provides a model and XML format for

describing what a Web service offers. A service

description in WSDL separates abstract-service

functionality from details such as how and where

the service is offered. While the abstract-service

description includes types and an abstract

interface, concrete details include bindings, a

service element that includes all available

implementations of the abstract interface at

endpoints.

UDDI[3], [4] provides an infrastructure that

supports the description, publication, and

discovery of service providers; the services that

they offer; and the technical details for accessing

those services. A core aspect of UDDI is how it

organizes information about services and the

providers of services. Information entities (UDDI

data) are organized in a data model and stored in

a UDDI service registry. Inquiring (search and

lookup entries) and publication (publish, delete,

and update registry–related information) are core

APIs.

Figure 1 illustrates some relationships between a WSDL

service description and information that is stored in a

UDDI service registry.

Figure 1. Relationships between WSDL and UDDI

Originally, UDDI was conceived to cover both publicly

exposed services and services that were available within

an organization. Currently, most existing implementations

ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org

2 January

1

are internal to organizations. Service publication,

discovery, and (finally) reuse of services is more

complicated in an inter-organizational scenario; for

example, additional legal and commercial agreements are

often needed among parties.

Dedicated (public) UDDI service registries were criticized

for their limitations (among other reasons) during service

inquiry/ discovery. Recently, however, Web search

engines—which could be crawling publicly available

WSDL documents—have raised promising expectations

for discovering publicly available services.[5]

2. Designing an Enterprise Service Repository

This section proposes some design guidelines to develop

an enhanced enterprise service repository. The focus is on

improving the reuse of services over time in different IT

projects. The aim is to increase service visibility to domain

experts (often, this refers to a business-analyst role) and

enhance service descriptions with practical information for

architects. Business analysts, who have a less technical

background but strong knowledge of the business domain,

are frequently the early designers of new initiatives for

incorporating or modifying the software support at

companies; they play a key role with regard to the reuse of

services.

2.1 Enterprise Services

Enterprise service–based solutions involve different types

of service. Following the separation of concerns that is

addressed by the service-virtualization pattern, [6] services

can act as an intermediate layer between the client and

provider applications of the services. The virtualization

pattern focuses on the abstraction of technical details—

such as service-endpoint location, policy enforcement,

service versioning, and dynamic service-management

information from service consumers— which access an

intermediate service level. Technical concerns are

managed at an implementation level, at which the actual

business logic is implemented.

Based on SOA initiatives in several companies, we can

identify three types of service:

A business service (BS), which client applications

use for accessing the functionality that is

implemented in provider applications.

An application service (AS), which can be

consumed by a BS to access the functionality of

the provider applications.

A business-service extension (BSE), which can

be consumed by a BS to operate on different AS

responses and consolidate a single answer that is

sent to a BS. In turn, the BS delivers the

consolidated response to the client application.

The aggregator pattern [7] is core to the design of

a BSE.

Figure 2 illustrates the main static relations among

elements of an enterprise service–based solution, as well

as their relationship to elements from the virtualization

pattern. A service registry organizes the description of the

three different types of service and their relationships.

Client and provider applications interchange messages that

are mediated by BS, BSE, and AS. The service registry

manages (at the configuration level) the information that

relates the different types of service. The information is

persisted in a service repository and used at runtime by a

BS to answer client requests.

Figure 2. Service-based architecture and its relation to virtualization-

pattern roles

2.2 Example 1

Let us consider a simplified BS that is used for calculating

the total sales that are related to the life-insurance and

group-insurance products of an insurance company. The

total sales that are associated with life-insurance products


2 January

2

are obtained from a life-insurance legacy application.

Analogously, the total sales that are associated with group-

insurance products are obtained from the group-insurance

legacy application. Each legacy application exposes an AS

(lifeInsurance and groupInsurance, respectively) that

provides the total sales for each type of insurance product.

A BS receives requests from clients who are asking for the

total sales; afterwards, it calls the service registry that has

the information that is required to enforce specific policies

on messages and dependencies to an AS and a BSE.

A BSE operates on the answers of an AS and provides a

single answer to the BS that contains the total sales of the

company. The BS, in turn, delivers this response to the

client application. Figure 3 illustrates the described

interaction.

Figure 3. Main interaction among elements of the service-based solution

from Example 1

2.3 Enterprise Service Registry

The enterprise service registry (ESR) is a core element that

organizes service information and supports the interaction

among enterprise applications that provide and consume

services.

Basic functionalities of an UDDI-based ESR can be

enhanced by using:

Service-dependencies management.

Runtime-policy enforcement.

Service versioning.

Service-history data (logs) management.

A service repository persists the information and

documentation that are logically managed by the service

registry. Figure 4 illustrates the main information that is

organized in an ESR, persisted in a service repository, and

provided to end users through a Web-based user interface.

Figure 4. Enterprise service registry (ESR)

2.4 Services Descriptions

Services descriptions are core to the service registry. They

determine how services can be discovered and

subsequently reused:

A BS is described at a high level—often, via

textual descriptions in natural language and

examples that facilitate understanding by business

analysts.

A BSE and an AS contain more technical details.

A BS is implemented by at least one AS and also

might involve a BSE. To associate a BS to one or

more AS(s) and/or BSE(s), a dependency

mapping is created and managed by the service

registry.

Table 1 describes in more detail the information that is

managed by the service registry:

The main attributes that describe a BS are shown

at the beginning of Table 1. A BSE and an AS

share attributes (see middle of Table 1). The end

of the table describes binding information that

relates a BS to a BSE and an AS.

Information that describes services and is

independent of any registry implementation is

shown in the Service information column, while

information that is managed by the service


2 January

3

registry is shown in the Registry information

column. If information in the Service

information and Registry information columns

is the same, an X appears in the Replicated

information column.

The remaining columns indicate information that

is relevant to different roles. [8] Business analysts

and solution architects manage information about

business and technical concerns, respectively.

Both roles work at a project or business-unit

scale. Enterprise and infrastructure architects

manage service information from a global

(enterprise-wide) perspective. While enterprise

architects might be interested in managing (for

instance) service versions, infrastructure

architects care about providing the required

infrastructure support to keep services running

with the adequate quality of service (QoS), as

defined in service-level agreements (SLAs).

Table 1. Main service information at the ESR

2.5 Using the Enterprise Service Registry to Improve Reuse of Services

Based on our experience in a range of projects, providing

simple descriptions about a BS, facilitating its access, and

managing services dependencies have been key to improve

reuse. For this purpose, an ESR was a core element.

Business analysts who trigger new requirements

for software support can improve their

communication with solution and enterprise

architects by referring to a BS that is described in

the ESR. Based on the descriptions of the BS and

its dependencies to an AS and a BSE, domain

experts become aware of available functionality

at back-end applications. From our experience,

this has facilitated a shift from requirements that

are specified in a vague manner to initial solution

blueprints that comprise orchestrated services

(created by business analysts). Long meetings

between architects and business analysts can be

reduced to short meetings or even telephone calls

that refer only to information at the service

registry.

Software architects can refine orchestrations that

are depicted in the initial blueprints that are made

by business analysts. Subsequently, they can

agree with enterprise and infrastructure architects

on service versions and infrastructure support.

Again, information at the ESR was central during

the agreement.

Information about service dependencies helped

infrastructure architects to analyze the impact of

binding new consumers to application services.

This is critical for maintaining SLAs.

Runtime policy–enforcement configurations at

the service registry allowed specialized treatment

for different client-application requests that were

associated with a single BS—for example,

applying particular validations with regard to

formatting, security, and parameterization.

In the case of new requirements triggering

modifications to existing services:

Often, extensions or modifications involved

changes only at the BSE level.

If an AS or BSE was modified and new versions

were deployed, the version of the associated BS

remained unchanged. (Service versioning is

discussed in more detail in the “Impact of Service

Versioning on Service Registries” section.)

Only incompatible changes that modify the

business functionality could trigger new BS

versions (in general, a BS is designed with

forward compatibility in mind).


2 January

4

Among the lessons that were learned from different

projects, we can emphasize the following:

Decoupling of a BS from an actual

implementation (by using AS(es) and a BSE) is

an effective way of keeping domain experts

separated from technical information, which

facilitates service discovery at the business level.

BS discovery support is key to enable the reuse of

services beyond a single solution or project—

allowing their use across projects and at an

enterprise-wide scale.

In practice, when only an AS is presented to

domain experts, it remains almost untouched; that

is, it is rarely reused in further developments.

Even when new requirements involved

modifications to existing service solutions, the

reuse of a BS has still been strong. This was

facilitated by addressing the required

modifications at the BSE level.

During legacy-application migration, client

applications kept consuming the same BS.

Changes mostly occurred at the AS level. At the

ESR, AS descriptions and service dependencies

were updated. New projects could reuse a BS

independently when a migration had occurred.

3. Open Issues in Industry and Academia

This section discusses a number of observations in

industry and academia with regard to enhanced service

descriptions, organization of service information in a

service registry, and the role of such a registry to enhance

the reuse of services.

3.1 Strategies for Organizing and Finding Services in Registries

If service information in an enterprise service registry is

difficult to distinguish because of inadequate organization

or ineffective search mechanisms, the value of that registry

is reduced.

Services categorization can help to distinguish services

and classify them according to one or more categories.

UDDI registries support this through the tModel. The

categorization schemas of UDDI refer to taxonomic

classifications. Taxonomies organize concepts in a

hierarchical structure; multiple taxonomies can apply to a

single UDDI entity. Standard classification schemas are

suggested, such as the United Nations Standard Products

and Services Code (UNSPSC [9]); however, other

standards or internally created taxonomies can also be

used. The UDDI Inquiry API supports different forms of

query, such as browse pattern, drill-down pattern, and

invocation pattern. Queries can refer directly to services,

as well as to service categories.

Similarly to a Web search engine, the browse pattern

allows one to find registry elements by matching

keywords. Although this mechanism automates part of a

service search, the results are limited to the coding

system’s value set and direct value matching. Services

whose description includes similar or related concepts, but

different syntax, cannot be retrieved by using this

approach. Also, during use of different categorization

schemas, the management of overlapping categories can

become expensive. [10] Taxonomy maintenance is an

added load that must be considered during the

implementation of a service registry. Classification

schemas that are not updated can affect the quality of the

discovery results. [11]

The semantic research community has proposed

alternatives to enrich service descriptions semantically and

enhance classification schemas in services registries. Basic

taxonomies can be enriched or replaced by ontologies.

Ontologies structure concepts within a domain and define

their meaning. Axioms constrain possible interpretations

of concepts and reasoning mechanisms that support

inferences from existing data.

According to Küster et al., [12] although semantic

enrichment of services descriptions can improve service

discovery, several issues still must be addressed, such as

reducing the computational cost of reasoning, maintaining

the ontologies, and refining search results to improve

effectiveness.


2 January

5

3.2 Impact of Service Versioning on Service Registries

When a service has been implemented, changes can

occur—from the implementation itself to parts of the

service description in a service repository. Changes might

aim to improve reuse:

Implemented services that follow a bottom-up

approach [13] often fulfill particular project

requirements within a domain. When any of these

services becomes a candidate for reuse in a

different context, it usually requires modifications

or extensions.

Analogously, services that follow a top-down

approach often must be changed (specialized) to

fit in particular contexts.

Different versioning strategies address different

requirements. A single solution is not likely to be

satisfactory for all situations. WSDL and UDDI

do not define guidelines for versioning services.

Some authors have proposed strategies for service

versioning; most of them relate to backward and

forward compatibility: [14]

A backward-compatible version refers to the

ability to support consumers of older versions of

a service.

A forward-compatible version refers to the ability

to adapt to unknown future requests that are

intended for newer versions of the service. This

type of compatibility involves not only a service-

versioning strategy, but also a service-design

strategy that is related to changeability.

Often, new service versions are replications of a previous

version that have additional or modified elements. New

versions are named differently (by using some naming

convention), and their description is stored in the registry

as a new entry. Juric et al. [15] propose extensions to

WSDL and UDDI for service versioning. The approach

addresses run-time and development-time versioning.

Efficiency at the code level is addressed by allowing

multiple versions of a service to refer to the same

codebase. Additionally, notifications about new and

deprecated versions are communicated to consumers.

Traceability support is provided to track changes. This

academic research promotes the reuse of services and

keeps the complexity of a service registry manageable.

3.3 Service-Usage Information for Enhancing Service Description and Discovery

The history of service usage can be an interesting source

of information—not only to re-create the actual behavior,

[16] but also for service discovery. Stored service usage–

history (logs) can help to categorize services according to

the user or how services have behaved over time. Let us

consider a service description that indicates a specific

performance level in its contract; however, the actual

measured performance in a given timeframe (extracted

from logs) is lower. This information could be used during

service discovery; a service that had lower-than-expected

performance levels would be discarded from the search.

Statistically extracted information about how services

behave against historic interactions can help to build less

biased rankings and make service discovery more precise;

however, an infrastructure for the constant monitoring of

services and storing of the history information must be

provided. Based on the service history, probabilities can be

assigned to quantify uncertainty. Clark et al. [17] consider

uncertainty with regard to the configuration of a service-

based system, the rate parameters of system components,

and the duration of events. An uncertainty model is used to

predict system performance under increased demand. This

type of analysis is fundamental when one is dimensioning

the service support infrastructure. Historical data about

individual services helps to predict the performance of an

entire system.

Offer and demand in an inter-organizational scenario are

subject to how much parties trust one another. “Trust in

others” is one of several criteria for assigning reputation—

witness reputation [18] —to publicly available services. If

company X knows that a service is being used or was

positively rated for company Y, whom X trusts, the

reputation of that service would increase from the point of

view of X. One associated problem is the eventual bias for

positive ratings, unfair ratings, and the variations of

quality between ratings. [19]

3.4 Sufficiency of WSDL Descriptions to Find Services for Composition Efficiently

Services are reused not only by client applications, but

also by other services in a service composition. A service

composition can provide a more coarse-grained


2 January

6

functionality and be closer to a business need. One

problem when finding a service (useful in a service

composition) is the need to verify if the services that are

involved are able to “talk” to one another—that is, if the

associated message-interchange protocol among them is

compatible. A basic requirement for compatibility is

deadlock-freeness. Moreover, the message syntax and

semantics should be compatible.

Figure 5 illustrates a typical example of incompatibility at

the protocol level between two parties. In the figure, a

Buyer party offers a buyProduct service, and a Seller party

offers a sellProduct service.

Figure 5. Example of incompatibility at protocol level between two

parties

To automate a hypothetical sale process, the message-

interchange protocol between buyProduct and sellProduct

should be compatible. However, Figure 5 illustrates that

the Seller expects a payment before sending the product,

and the Buyer expects the product before sending the

payment.

When more and more services are offered and advertised

in repositories, there are more chances of satisfying a

service demand by composing existing services. However,

mediation at the protocol level might be required.

Matchmaking conflicts at the message and/or conversation

level(s) can be solved—to a certain degree— by a

mediator component. [20], [21] However, verifying and

solving compatibility among services at the behavioral

level is expensive; it involves the (expensive) exploration

of possible states of the services during interaction. To

increase reuse here, we need efficient mechanisms for

finding compatible services.

For instance, instead of directly publishing the behavior of

a service in a repository, a provider can publish a

“summarized description” of the expected behavior of all

compatible services to service (compatibility refers to

deadlock-freeness). The “summarized description” is

called an “operating guideline [22]” and allows the hiding

of implementation details, while exposing enough

information to find compatible partners. Checking if a

service can be composed with others is reduced to

checking if a graph-based representation of the potential

partner is a sub graph of the “operating guideline,” which

is less expensive than exploring all possible states of the

services.

4. Conclusions

To improve the reuse of services at the enterprise level,

architects must define a strategy for publishing and

providing facilities to access services information. For this

purpose, an enterprise service registry is a key piece.

Information about services can be organized at the

registry, and basic functionality can be enhanced—

including, for instance, functionality for service

versioning, management of service dependencies, and

enforcement of runtime policy. In this article, we have

provided some design guidelines for enhancing an

enterprise service registry to improve the reuse of

enterprise services. We have also discussed some open

issues in industry and academia with regard to the design

and implementation of service registries and associated

aspects that are required to describe and organize services

information.

Resources

1. Pijanowski, Keith. “ Visibility and Control in a

Service-Oriented Architecture.” MSDN, May 2007.

2. W3C.org. Web Services Description Language

(WSDL) Version 2.0 Part 1: Core Language.

3. UDDI.org. UDDI Version 3.0.2. UDDI Spec Technical

Committee Draft, October 19, 2004.

4. Microsoft Corporation. “ UDDI Specification Index

Page.” MSDN, July 2009.

5. Al-Masri, Eyhab, and Qusay H. Mahmoud. “

Investigating Web Services on the World Wide Web.”

WWW 2008: Web Engineering— Web Service

Deployment Track, April 21–25, 2008, 795–804.

6. Madrid, Chris. “ SOA Realization Through Service

Virtualization.” SOA Magazine, September 3, 2007.


2 January

7

7. Hohpe, Gregor, and Bobby Woolf. Enterprise

Integration Patterns. Boston: Addison-Wesley, 2004.

8. Cardinal, Mario. “ The Hidden Roles of Software

Architects: The Three Types of Architect.” MSDN,

March 2008.

9. UNSPSC.org. “ UNSPSC Codeset.” (Managed by the

Electronic Commerce Code Management Association

(ECCMA).) August 2007.

10. Klein, Michel. “Combining and Relating Ontologies:

An Analysis of Problems and Solutions.” Proceedings

of Workshop on Ontologies and Information Sharing at

17th International Joint Conference on Artificial

Intelligence (IJCAI-01), 2001, 53–62.

11. Hepp, Martin, Joerg Leukel, and Volker Schmitz. “A

Quantitative Analysis of eClass, UNSPSC, eOTD, and

RNTD: Content, Coverage, and Maintenance.”

Proceedings of IEEE International Conference on e-

Business Engineering (ICEBE’05), 2005, 572–581.

12. Küster, Ulrich, Holger Lausen, and Birgitta König-

Ries. “Evaluation of Semantic Service Discovery: A

Survey and Directions for Future Research.” Emerging

Web Services Technology. Volume II, 2008, 41–58.

13. Erl, Thomas. Service-Oriented Architecture: Concepts,

Technology, and Design. Prentice Hall Service-

Oriented Computing Series from Thomas Erl, 2004.

14. Parrish, Allen, Brandon Dixon, and David Cordes. “A

Conceptual Foundation for Component-Based

Software Deployment.” Journal of Systems and

Software. Vol. 57, Issue 3, July 2001, 193–200.

15. Juric, Matjaz B., Ana Sasa, Bostjan Brumen, and Ivan

Rozman. “WSDL and UDDI Extensions for Version

Support in Web Services.” Journal of Systems and

Software. Vol. 82, Issue 8

(doi:10.1016/j.jss.2009.03.001), August 2009, 1326–

1343.

16. van der Aalst, W. M. P., and A. J. M. M Weijters.

“Process Mining: A Research Agenda.” Computers in

Industry. Vol. 53, Issue 3 (doi:

10.1016/j.compind.2003.10.001), April 2004, 231–244.

17. Clark, Allan, Stephen Gilmore, and Mirco Tribastone.

“Quantitative Analysis of Web Services Using

SRMC.” SFM. Vol. 5569, 2009, 296–339.

18. Huynh, Trung Dong, Nicholas R. Jennings, and Nigel

R. Shadbolt. “An Integrated Trust and Reputation

Model for Open Multi-Agent Systems.” Journal of

Autonomous Agents and Multi-Agent Systems. Vol. 13,

Issue 2, March 2006, 119–154.

19. Jøsang, Audun, Roslan Ismail, and Colin Boyd. “A

Survey of Trust and Reputation Systems for Online

Service Provision.” Decision Support Systems. Vol. 43,

Issue 2, March 2007, 618–644.

20. Dustdar, Schahram, and Wolfgang Schreiner. “A

Survey on Web Services Composition.” International

Journal of Web and Grid Services (IJWGS). Vol. 1,

Issue 1, 2005, 1–30.

21. Li, Xitong, Yushun Fan, Jian Wang, Li Wang, and

Feng Jiang. “A Pattern-Based Approach to

Development of Service Mediators for Protocol

Mediation.” Proceedings of the Seventh Working

IEEE/IFIP Conference on Software Architecture

(WICSA 2008), February 2008, 137–146.

22. Kaschner, Kathrin, Peter Massuthe, and Karsten Wolf.

“ Symbolic Representation of Operating Guidelines for

Services.” Petri Net Newsletter. Vol. 72, April 2007,

21–28.

Juan Pablo García-González is a senior software developer and chief architect at DATCO Chile S.A. He has been involved in numerous software projects involving service-based solutions. In addition to their regular projects, he and his team are working on the creation of innovative service-centric mobile solutions for the banking industry. Veronica Gacitua-Decar is a postgraduate researcher at the School of Computing, Dublin City University, and Lero - the Irish Software Engineering Research Centre. Her research is focused on the development of tools and methods for designing process-centric service architectures. Previously, she worked as an IT architect in a large mining company. Dr. Claus Pahl is a senior lecturer at the School of Computing, Dublin City University, where he is leader of the Software and Systems Engineering group. He is also involved in Lero - the Irish Software Engineering Research Centre, as well as the Centre for Next Generation Location (CNGL).


2 January

8

Caching in the Distributed Environment

Abhijit Gadkari

Information Science Dept., Claremont Graduate University, Claremont, CA

Abstract The impact of cache is well understood in the system-

design domain. While the concept of cache is extensively

utilized in the von Neumann architecture, the same is not

true for the distributed-computing architecture. For

example, consider a three-tiered Web-based business

application running on a commercial RDBMS. Every time

a new Web page loads, many database calls are made to

fill the drop down lists on the page. Performance of the

application is greatly affected by the unnecessary database

calls and the network traffic between the Web server and

the database server.

1. Introduction

In production, many applications buckle down because

they treat the database as their cache. Web server-based

application-level cache can be effectively used to mitigate

this problem. An effective caching mechanism is the

foundation of any distributed-computing architecture. The

focus of this article is to understand the importance of

caching in designing effective and efficient distributed

architecture. I will discuss the principle of locality of

cache, basic caching patterns like temporal and spatial

cache, and primed and demand cache, followed by an

explanation of the cache replacement algorithms.

ORM technologies are becoming part of the mainstream

application design, adding a level of abstraction.

Implementing ORM-level cache will improve the

performance of a distributed system. I will explain

different ORM caching levels such as transactional cache,

shared cache, and the details of intercache interaction. I’ll

also explore the impact of ORM caching on application

design.

2. Distributed Systems

A distributed system is a heterogeneous system. Diverse

system components are connected to each other via a

common network. Applications using TCP/IP-based

Internet are examples of open distributed systems.

Figure 1 shows a typical distributed architecture:

Figure 1. Distributed architecture

In the distributed environment, different activities occur

in concurrent fashion. Usually, common resources like the

underlying network, Web/application servers, database

servers, and cache servers are shared by many clients.

Distributing the computing load is the hallmark of

distributed systems. Resource sharing and allocation is a

major challenge in designing distributed architecture. For

example, consider a Web-based database-driven business

application. The Web server and the database server are

hammered with client requests. Caching, load-balancing,

clustering, pooling, and time-sharing strategies improve

the system performance and availability. I’ll focus on

caching in the distributed environment.

Any frequently consumed resource can be cached to

augment the application performance. For example,

caching a database connection, an external configuration

9


2 January

file, workflow data, user preferences, or frequently

accessed Web pages improve the application performance

and availability. Many distributed-computing platforms

offer out-of-the-box caching infrastructure. Java Caching

System (JCS) is a distributed composite caching system.

In Microsoft .NET Framework, the

System.Web.Caching API provides the necessary

caching framework. The Microsoft project code-named

“Velocity” is a distributed-caching platform [1].

The performance of a caching system depends on the

underlying caching data structure, cache eviction strategy,

and cache utilization policy. Typically, a hash table with

unique hash keys is used to store the cached data; JCS is a

collection of hash tables [2]. The .NET cache

implementation is based on the Dictionary data structure.

The cache eviction policy is implemented in terms of a

replacement algorithm. Utilizing different strategies such

as temporal, spatial, primed, and demand caching can

create an effective caching solution.

3. Cache and the Principle of Locality

The word “cache” comes from the French word meaning

“to hide.” [3]. Wikipedia defines cache as “a temporary

storage area where frequently accessed data can be stored

for rapid access.” [4] Cached data is stored in the

memory. Defining frequently accessed data is a matter of

judgment and engineering. We have to answer two

fundamental questions in order to define a solid caching

strategy. What resource should be stored in the cache?

How long should the resource be stored in the cache? The

locality principle, which came out of work done on the

Atlas System’s virtual memory in 1959 [5], provides good

guidance on this front, defining temporal and spatial

locality. Temporal locality is based on repeatedly

referenced resources. Spatial locality states that the data

adjacent to recently referenced data will be requested in

the near future.

4. Temporal Cache

Temporal locality is well suited for frequently accessed,

relatively nonvolatile data—for example, a drop-down list

on a Web page. The data for the drop down list can be

stored in the cache at the start of the application on the

Web server. For subsequent Web page requests, the drop

down list will be populated from the Web server cache

and not from the database. This will save unnecessary

database calls and will improve application performance.

Figure 2 illustrates a flow chart for this logic:

Figure 2. Temporal locality flow chart

When a resource is added to the cache, resource

dependencies can be added to the caching policy.

Dependencies can be configured in terms of an external

file or other objects in the cache. An expiration policy

defines the time dependency for the cached resource.

Many caching APIs provide a programmatic way to

synchronize the cache with the underlying database.

Figure 3 is sample C# code to populate the temporal

cache:

10


2 January

Figure 3. C# code example to populate temporal cache

5. Spatial Cache

Consider an example of tabular data display like a

GridView or an on-screen report. Implementing efficient

paging on such controls requires complex logic. The logic

is based on the number of records displayed per page and

the total number of matching records in the underlying

database table. We can either perform in-memory paging

or hit the database every time the user moves to a different

page; both are extreme scenarios. A third solution is to

exploit the principle of spatial locality to implement an

efficient paging solution. For example, consider a

GridView displaying 10 records per page. For 93 records,

we will have 10 pages. Instead of fetching all records in

the memory, we can use the spatial cache to optimize this

process. A sliding window algorithm can be used to

implement the paging. Let’s define the data window just

wide enough to cover most of the user requests, say 30

records. On page one, we will fetch and cache the first 30

records. This cache entry can be user session specific or

applicable across the application. As a user browses to the

third page, the cache will be updated by replacing records

in the range of 1–10 by 31–40. In reality, most users

won’t browse beyond the first few pages. The cache will

be discarded after five minutes of inactivity, eliminating

the possibility of a memory leak. The logic is based on the

spatial dependencies in the underlying dataset. This

caching strategy works like a charm on a rarely changing

static dataset.

Figure 4 illustrates the spatial-cache logic that is used in

the GridView example:

Figure 4. Spatial-cache sequence diagram

The drawback of this logic is the possibility of a stale

cache. A stale cache is a result of the application

modifying the underlying dataset without refreshing the

associated cache, producing inconsistent results. Many

caching frameworks provide some sort of cache

synchronization mechanism to mitigate this problem. In

.NET, the SqlCacheDependency class in the

System.Web.Caching API can be used to monitor a

specific table [6]. SqlCacheDependency refreshes the

associated cache when the underlying dataset is updated.

6. Cache Replacement Algorithms

A second important factor in determining an effective

caching strategy is the lifetime of the cached resource.

Usually, resources stored in the temporal cache are good

for the life of an application. Resources that are stored in

the spatial cache are either time-dependent or place-

dependent. Time-dependent resources should be purged as

per the cache expiration policy. Place-specific resources

can be discarded based on the state of the application. In

11


2 January

order to store a new resource in the cache, an existing

cached resource will be moved out of the cache to a

secondary storage, such as the hard disk. This process is

known as paging. Replacement algorithms such as least

frequently used resource (LFU), least recently used

resource (LRU), and most recently used resource (MRU)

can be applied in implementing an effective cache-

eviction strategy, which influences the cache

predictability [7]. The goal in implementing any

replacement algorithm is to minimize paging and

maximize the cache hit rate. The cache hit rate is the

possibility of finding the requested resource in the cache.

In most cases, LRU implementation is a good enough

solution. JCS and ASP.NET caching is based on the LRU

algorithm. In more complex scenarios, a combination of

LRU and LFU algorithms such as the adaptive

replacement cache (ARC) can be implemented. The idea

in ARC is to replace the least frequently and least recently

used cached data. This is achieved by maintaining two

additional scoring lists. These lists will store the

information regarding the frequency and timestamp of the

cached resource. ARC outperforms LRU by dynamically

responding to the changing access pattern and continually

balancing workload and frequency features [8]. Some

applications implement a cost-based eviction policy. For

example, in Microsoft SQL Server 2005, zero-cost plans

are removed from the cache and the cost of all other

cached plans is reduced by half [9]. The cost in SQL

Server is calculated based on the memory pressure.

A study of replacement algorithms suggests that a good

algorithm should strike a balance between the simplicity

of randomness and the complexity inherent in cumulative

information [10]. Replacement algorithms play an

important role in defining the cache-eviction policy,

which directly affects the cache hit-rate and the

application performance.

7. Primed Cache vs. Demand Cache: Can We Predict the Future?

Data-usage predictability also influences the caching

strategy. The primed-cache pattern is applicable when the

cache or part of the cache can be predicted in advance

[11]. This pattern is very effective in dealing with static

resources. A Web browser cache is an example of primed

cache; cached Web pages will load fast and save trips to

the Web server. The demand-cache pattern is useful when

cache cannot be predicted [12]. A cached copy of user

credentials is an example of demand cache. The primed

cache is populated at the beginning of the application,

whereas the demand cache is populated during the

execution of the application.

7.1 Primed Cache

The primed cache minimizes the overhead of requesting

external resources. It is suitable for the read-only

resources frequently shared by many concurrent users.

Figure 5 illustrates the typical primed cache architecture:

Figure 5. Primed-cache example

The cache server cache is primed in advance, and the

individual Web/application server cache is populated from

the cache server. Each Web/application server can read,

write, update, and delete the cache on the cache server.

The cache server in turn is responsible for synchronizing

the cache with the resource environment. Because the

primed cache is populated in advance, it improves the

application response time. For example, reports with

static, fixed parameters can be populated and stored in the

cache. This way, the reports are available almost

instantly. In .NET, the ICachedReport interface can be

used to store the prepopulated reports in the cache.

Updating the primed cache mostly results in updating

existing cached resources. The cache is refreshed based on

a routine schedule or a predictable event-based

12


2 January

mechanism. The primed-cache results in an almost

constant size cache structure [11].

7.2 Demand Cache

The demand cache is suitable when the future resource

demand cannot be predicted. The resource environment

acquires the resource only when it is needed. This

optimizes the cache and achieves a better hit-rate. As soon

as the resource is available, it is stored in the demand

cache. All subsequent requests for the resource are

satisfied by the demand cache. As soon as it is cached, the

resource should last long enough to justify the caching

cost.

Figure 6 illustrates a class diagram for implementing the

demand cache [12]:

Figure 6. Demand cache

For example, a user can have many roles and one role can

have many permissions. Populating the entire permissions

domain for all users at the start of an application will

unnecessarily overload the cache. The solution is to store

the user credentials in the demand cache on a successful

log-in. All subsequent authorization requests from the

application for already authenticated users will be fulfilled

by the demand cache. This way the demand cache will

only store a subset of all possible user permissions in the

system.

In the absence of a proper eviction policy, the resource

will be cached forever. Permanently cached resources will

result in memory leak, which degrades the cache

performance. For example, as the number of authenticated

users grows, the size of the demand cache increases and

the performance degrades. One way to avoid this problem

is to link resource eviction with resource utilization. In

our example, the cache size can be managed by removing

the credentials of all logged-off users.

Figure 7. Demand-cache example

Predicting the future is a difficult business. In a dynamic

environment, adaptive caching strategies represent a

powerful solution, based on some sort of application usage

heuristics. However, adaptive caching strategies are

beyond the scope of this article.

8. Caching in the ORM World!

Object relational mapping is a way to bridge the

impedance mismatch between object-oriented

programming (OOP) and relational database management

systems (RDBMS). Many commercial and open-source

ORM implementations are becoming an integral part of

the contemporary distributed architecture. For example,

Microsoft Entity Framework and Language Integrated

Query (LINQ), Java Data Objects (JDO), TopLink,

Hibernate, NHibernate, and iBATIS are all popular ORM

implementations. The ORM manager populates the data

stored in persistent storages like a database in the form of

an object graph. An object graph is a good caching

candidate.

The layering principle, based on the explicit separation of

responsibilities, is used extensively in the von Neumann

architecture to optimize system performance. N-tier

application architecture is an example of the layering

principle. Similar layering architecture can be used in

implementing the ORM caching solution. The ORM

cache can be layered into two different categories: the

read-only shared cache used across processes,

applications, or machines and the updateable write-

enabled transactional cache for coordinating the unit of

work [13].

13


2 January

Cache layering is prevalent in many ORM solutions—for

example, Hibernate’s two-level caching architecture [14].

In a layered-caching framework, the first layer represents

the transactional cache and the second layer is the shared

cache designed as a process or clustered cache.

Figure 8 illustrates the layered-cache architecture:

Figure 8. Layered-cache architecture

9. Transactional Cache

Objects formed in a valid state and participating in a

transaction can be stored in the transactional cache.

Transactions are characterized by their ACID (Atomicity,

Consistency, Isolation, and Durability) properties.

Transactional cache demonstrates the same ACID

behavior. Transactions are atomic in nature; each

transaction will either be committed or rolled back. When

a transaction is committed, the associated transactional

cache will be updated. If a transaction is rolled back, all

participating objects in the transactional cache will be

restored to their pretransaction state [15]. You can

implement this behavior by using the unit of work pattern

[13].

Thrashing, cache corruption, and caching conflicts should

be strictly avoided in implementing the transactional

cache. Many caching implementations offer a

prepackaged transactional cache solution, including the

TreeCache implementation in JBoss. TreeCache is a tree

structured, replicated, transactional cache based on the

pessimistic locking scheme [16].

10. Shared Cache

The shared cache can be implemented as a process cache

or clustered cache [14]. A process cache is shared by all

concurrently running threads in the same process. A

clustered cache is shared by multiple processes on the

same machine or by different machines. Distributed-

caching solutions implement the clustered cache; for

example, the project code-named “Velocity” is a

distributed-caching API [1]. The clustered shared cache

introduces resource replication overhead. Replication

keeps the cache in a consistent state on all the

participating machines. A safe failover mechanism is

implemented in the distributed-caching platform; in case

of a failure, the cached data can be populated from other

participating nodes.

Objects stored in the transactional cache are useful in

optimizing the transaction. As soon as the transaction is

over, they can be moved into the shared cache. All read-

only requests for the same resource can be fulfilled by the

shared cache; and, because the shared cache is read-only,

all cache coherency problems are easily avoided. The

shared cache can be effectively implemented as an

Identity Map [13].

As shown in Figure 9, requests for the same shared-cache

resource result in returning the same object:

Figure 9. Shared-cache example

You can use different coordination techniques to manage

the interaction between the shared and transactional cache

[15]. These techniques are explained in the following

section on intercache interaction.

11. Managing the Interaction

The interaction between the shared cache and the

transactional cache depends on the nature of the cached

14


2 January

data. Read-only cached data will result in infrequent

cache communication. There are many ways to optimize

intercache communication [15].

One solution is to populate the object graph

simultaneously in the shared and transactional cache.

This saves the overhead of moving objects from one cache

to the other. On completion of the transaction, an updated

copy of the object in the transactional cache will refresh

the shared cache instance of the object. The drawback of

this strategy is the possibility of a rarely used

transactional cache in the case of frequent read-only

operations.

Another solution is to use the just-in-time copy strategy.

The object will be moved from the shared cache to the

transactional cache at the beginning of a transaction and

will be locked for the duration of the transaction. This

way no other thread, application or machine can use the

locked object. The lock is released on completion of the

transaction and the object is moved back to the shared

cache (see Figure 10).

Figure 10. Intercache interaction

It is important to minimize the possibility of a stale or

corrupt cache and maximize resource utilization. The data

copying between the transactional and shared cache

should also be minimized in order to increase the cache

hit rate. Because locks are effectively managed in the

database, there are some concerns in implementing the

same at the application level. This discussion is important

but beyond the scope of this article.

Caching domain-specific dependencies is an essential but

difficult task. As illustrated in Figure 7, caching the

combination of all roles and corresponding permissions

for the logged-on user will populate a large object graph.

Application patterns like Domain Model and Lazy Load

can be effectively applied in caching such domain

dependencies [13]. One important consideration in

designing a caching strategy is the cache size.

12. Chasing the Right Size Cache

There is no definite rule regarding the size of the cache.

Cache size depends on the available memory and the

underlying hardware viz. 32/64 bit and single-

core/multicore architecture. An effective caching strategy

is based on the Pareto principle (that is, the 80–20 rule).

For example, on the ecommerce book portal, 80 percent of

the book requests might be related to the top 10,000

books. The application’s performance will greatly

improve if the list of top 10,000 books is cached. Always

remember the principle of diminishing returns and the

bell-shaped graph in deciding cache size. (See Figure 11.)

Figure 11. Cached data versus performance

How much data should be cached depends on many

factors such as processing load patterns, the number of

concurrent connections/requests, and the type of

application (real-time versus batch processing). The goal

of any caching strategy is to maximize the application

performance and availability.

15


2 January

13. Conclusion

Small caching efforts can pay huge dividends in terms of

performance. Two or more caching strategies and design

patterns like GOF [17], PEAA [13], and Pattern of

Enterprise Integration (PEI) can be clubbed together to

implement a solid caching platform. For example, shared

demand cache coupled with a strict time-based eviction

policy can be very effective in optimizing the performance

of a read-heavy distributed system like the enterprise

reporting solution.

Forces like software transactional memory (STM),

multicore memory architecture such as NUMA (Non-

Uniform Memory Access), SMP (symmetric

multiprocessing architectures), and concurrent

programming will influence the future of caching

platforms. In the era of cloud computing, caching will

play a pivotal role in the design of distributed systems. An

efficient caching strategy will differentiate a great

distributed architecture from the good. Let your next

design be a great one.

Acknowledgments

I would like to thank Gita Gadgil for reading the draft

material and providing invaluable feedback and

suggestions.

References

[1] http://code.msdn.microsoft.com/velocity [2] http://jakarta.apache.org/jcs/getting_started/intro.html [3] http://dictionary.reference.com/browse/cache [4] http://en.wikipedia.org/wiki/Cache [5] Peter J. Denning, “The Locality Principle, Communications of the ACM,” July 2005, Vol 48, No 7. [6]http://msdn.microsoft.com/en-us/library/system.web.caching.sqlcachedependency.aspx [7] Michael Kircher and Prashant Jain, “Caching,” EuroPloP 2003. [8] Nimrod Megiddo and Dharmendra S. Modha, “Outperforming LRU with an Adaptive Replacement Cache Algorithm,” IEEE Computer, April 2004. [9] Kalen Delaney, Inside Microsoft SQL Server 2005: Query Tuning and Optimization, Microsoft Press, 2007. [10] L.A. Belady, “A Study of Replacement Algorithms for Virtual Storage Computers,” IBM Systems J. 5, 2 (1966), 78–101.

[11] Octavian Paul Rotaru, “Caching Patterns and Implementation,” Leonardo Journal of Sciences LJS: 5:8, January-June 2006. [12] Clifton Nock, Data Access Patterns: Database Interactions in Object-Oriented Applications, Addison-Wesley, 2003. [13] Martin Fowler, Pattern of Enterprise Application Architecture (P of EAA), Addison-Wesley, 2002. [14] Christian Bauer and Gavin King, Java Persistence with Hibernate, Manning Publications, 2006. [15] Michael Keith and Randy Stafford, “Exposing the ORM Cache,” ACM Queue, Vol 6, No 3, May/June 2008. [16]TreeCache(http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/1.4.0/TreeCache/en/html_single/index.html#introduction) [17] Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994.

Abhijit Gadkari is an Enterprise Architect with AMG-SIU. Abhijit’s background includes an M.S. in IS from Claremont Graduate University, and post graduation in computer science from DOE, India. He has 10 years of software design and development experience. His work and research focuses on building SaaS-based IT infrastructure.

16


2 January

Is SOA Being Pushed Beyond Its Limits?

Grace A. Lewis

Software Engineering Institute, Carnegie Mellon University, United States

Abstract This article presents some of the characteristics of future

service-oriented systems. Also, it focuses on a set of architecture

and design drivers for these future service- oriented systems that

can help meet new expectations without sacrificing the loosely

coupled, stateless, standards-based characteristics that have

driven SOA adoption in many contexts. The article concludes

with thoughts on the key role of the architect in the service-

oriented systems-development process.

Keywords: service-oriented systems

1. Introduction

It is clear that service-oriented architecture (SOA) is

having a substantial impact on the way in which software

systems are developed. According to a 2007 Gartner

Group report, 50 percent of new mission-critical

operational applications and business processes were

designed in 2007 around SOA, and that number will be

more than 80 percent by 2010. Despite recent news that

SOA adoption rates are falling and that “SOA is dead,”

Forrester Group recently reported that SOA adoption is

increasing across all of its vertical-industry groups. The

reality is that SOA is currently the best option available for

systems integration and leverage of legacy systems.

SOA is a way of designing, developing, deploying, and

managing systems, and it is characterized by coarse-

grained services that represent reusable business

functionality. Service consumers compose applications or

systems by using the functionality that services provide

through standard interfaces.

At a high level:

- Services provide reusable business functionality.

- Service consumers are built by using the functionality

from available services. Service-interface definitions are

first-class artifacts.

- There is a clear separation between the service interface

and service implementation that come from the legacy

systems, external systems, or code that was built

specifically for this purpose.

-An SOA infrastructure enables the discovery,

composition, and invocation of services.

-Protocols are predominantly, but not exclusively,

message-based document exchanges.

From a more technical point of view, SOA is an

architectural style or design paradigm; it is neither a

system architecture nor a complete system. As an

architectural style, it is characterized by a set of

components and connectors, situations in which the style

is applicable, and benefits that are associated with

implementing the style.

If it is implemented correctly, SOA adoption can provide

business agility, reuse of business functionality, and

leverage of legacy systems for an organization. Many

organizations recognize these potential benefits and are

adopting SOA—some more successfully than others. SOA

has indeed “crossed the chasm,” [1] according to a recent

Software AG user survey in which 90 percent of the

respondents claim to have made some commitment to

SOA adoption [2].

However, as with any technology, as SOA is adopted

within organizations and becomes a mainstream paradigm

for systems development, the requirements and

expectations that are placed on service orientation

increase. What was initially an approach for asynchronous

document-based message exchanges now has

performance, availability, reliability, security and other

expectations of traditional distributed systems. As a result,

the loosely coupled, stateless, standards-based nature of

the relationship between service consumers and service

providers in service-oriented systems is changing, so as to

meet these new requirements. In addition, global

enterprises and the emerging market of third-party services


2 January

17

that are being made available through the Cloud are also

placing expectations on service-oriented system

architecture and design.

The first part of this article presents some of the

characteristics of future service-oriented systems. The

second part focuses on a set of architecture and design

drivers for these future service-oriented systems that can

help meet new expectations without sacrificing the loosely

coupled, stateless, standards-based characteristics that

have driven SOA adoption in many contexts. Finally, the

article concludes with thoughts on the key role of the

architect in the service-oriented systems-development

process.

2. Future Service-Oriented Systems

Between 2005 and 2007, multiple surveys were conducted

by organizations such as Forrester, Gartner, and IDC that

showed that the top drivers for SOA adoption were mainly

internally focused: application integration, data

integration, and internal process improvement. This fact is

changing. A recent survey published by Forrester shows

that the number of organizations that are currently using

SOA for external integration is approximately one third of

the surveyed organizations [3]. While the percentage of

externally focused SOA applications is still a minority,

this percentage has been growing, and the trend will

continue as organizations look at SOA adoption for

supply-chain integration, access to real-time data, and cost

reduction through the use of third-party services via the

Cloud or Software as a Service (SaaS). As organizations

expand their systems to cross organizational boundaries,

the requirements on their systems also expand—from

consumer, provider, and infrastructure perspectives. What

follows are some requirements that will be typical of these

future (or even current) service-oriented systems.

2.1 Security

The security threats for service-oriented systems are not

new or different; it is the level of exposure that is greater.

Service-oriented systems have an unknown and dynamic

attack surface. Attack surface refers to the set of ways in

which an adversary can exploit vulnerabilities and

potentially cause damage. An attack surface can be

measured in terms of three kinds of resources that are used

in attacks on the system: methods (for example, an API),

channels (for example, sockets), and data (for example,

input parameters). The greater the number of resources

that are accessible for attack, the greater the attack surface

and, therefore, the more insecure the software environment

[4]. From a more global perspective of security, issues

such as identity management, dynamic secure-service

composition, and trust in third-party services become

important requirements in this type of system.

2.2 Runtime Monitoring and Adaptation

Runtime monitoring of systems is a common practice for

determining the health of a system. SOA infrastructures

can be configured to gather certain measures during

system execution, and tools can be integrated into the

system to produce reports and alerts if measures cross

certain thresholds. Runtime adaptation refers to the

capability of the system to adjust itself at runtime when

these thresholds are crossed, so as to continue to meet

quality requirements. For example, a system might start an

additional instance of a service under particular load

conditions or restrict access to a service if there is a

suspicion that the security of the system has been

compromised. These actions are possible when there is full

control over a system; however, when services belong to

third parties, there is much less control, and it becomes

difficult to weave and consolidate the different logs that

are emitted from different sources to paint an overall

picture of the system.

2.3 Dynamic Binding

The word dynamic is often used to describe the binding

between service consumers and services. There are various

degrees of dynamism. At the lower end of the spectrum is

late binding of a proxy service to a specific service

instance that depends on user context or load-balancing

policies. At the higher end of the spectrum is fully

dynamic binding in which service consumers are capable

of querying service registries at runtime, selecting the

“best” service from the list of returned services, and

invoking the selected service—all at runtime, and without

human intervention. Late binding is a common, out-of-the-

box feature of many commercial and open-source SOA

infrastructures, such as an enterprise service bus (ESB).

Fully dynamic binding, on the other hand, requires

semantically described services that use an ontology that is


2 January

18

shared between service consumers and service providers.

Semantic Web Services represent an active area of

research, as well as an unsolved problem that is not yet

ready for large-scale deployment.

2.4 Multiple Consumers and Consumer Devices

As service-oriented systems start crossing organizational

boundaries, the variety of service consumers will increase.

Services will have to deal with heterogeneous service-

consumer development and computing platforms. The

proliferation and increasing power of handheld devices,

along with the need for access to real-time data, are

driving business applications to run on resource-

constrained devices such as handheld devices, PDAs, and

cell phones. In the case of third-party service providers,

the fact that service consumers might be unknown adds an

additional requirement of anticipating potential consumer

profiles and usage patterns.

2.5 Coexistence with Other Architectural Paradigms and Technologies

Because Web Services are the main standards-based

technology that is available today for implementation of

service-oriented systems, a common misconception is that

Web Services and SOA are the same. In fact, Web

Services are only one potential approach to SOA

implementation. In a traditional Web Services

environment, service consumers interact with services via

XML-messages that are encoded by using SOAP over

HTTP in a request/response manner. While this is

appropriate in many contexts, especially in enterprise

contexts, it might not be appropriate in other contexts of

high-performance or real-time requirements. For example,

certain business processes or real-time workflows might be

too dynamic and complex to be modeled by traditional

sequential processing methods. In this case, event-driven

SOA provides a potential solution by combining the

traditional SOA request/response paradigm with the event-

driven architecture (EDA) event publish/subscribe

paradigm.

Another example is high-performance and real-time

systems that are usually tied to requirements for higher

information bandwidth, as well as much lower latencies or

delays on the information. As demands become more real-

time, the need for performance, predictability, and load

balancing tips the scale towards point-to-point (P2P),

tightly coupled architectures, as opposed to more loosely

coupled architectures. Common SOA implementations that

are based on HTTP, such as Web Services, might not be

acceptable, because HTTP is not reliable, has limited

bandwidth, introduces very high latencies, and cannot

buffer, queue, and deliver messages to systems that are

either temporarily unavailable or will join at a later time.

For this reason, real-time support in SOA environments

focuses on EDAs and publish/ subscribe systems as a way

to support real-time requirements, yet maintain the loosely

coupled nature of service-oriented systems.[5], [6]

As service-oriented systems depart from what is currently

standardized—mainly, Web Services (whether WS* or

REST)—there will be trade-offs. For example,

maintainability of the system becomes more difficult when

there are multiple architecture paradigms and when tool

availability decreases.

2.6 Governance

The requirement for governance will not come as an

explicit requirement; however, as systems start to cross

organizational boundaries, the need for governance

becomes even more important. SOA governance is the set

of policies, rules, and enforcement mechanisms for

developing, using, and evolving service-oriented systems,

as well as for analysis of their business value. It includes

policies and procedures, roles and responsibilities, design-

time governance, and run-time governance [7], [8], [9].

Design-time governance includes elements such as rules

for strategic identification of services, development, and

deployment of services; reuse; and migration of legacy

systems. It also enforces consistency in the use of

standards, SOA infrastructure, and processes. Run-time

governance develops and enforces rules to ensure that

services are executed only in ways that are legal, and that

important run-time data is logged. From a life- cycle point

of view, design-time governance applies to early activities

such as planning, architecture, design, and development.

Run-time governance applies to the deployment and

management of service-oriented systems. In a multi

organizational environment, governance has to be

extended to include policies and procedures for the

identification and binding to external services and the

establishment and monitoring of service-level agreements

(SLAs) between service providers and consumers.


2 January

19

3. Architecture and Design Drivers for Future Service-Oriented Systems

The requirements for future service-oriented systems

present a challenge to system architects. Ideally, the goal is

to meet new expectations without sacrificing the loosely

coupled, stateless, standards-based characteristics that

have driven SOA adoption in many contexts. What follows

are some architecture and design drivers that will have to

be embedded into these systems.

3.1 Context Awareness

In a context-aware SOA environment, services can be

selected and adapted every time in accordance with the

user and invocation- context requirements and profiles—

for example, provision of a service that:

-Has different performance, reliability, or security

characteristics, according to who invokes the service and

from where it is invoked.

-Returns information that is based on the language, time

zone, and invocation environment of the user.

-Returns different views of data, depending on the

characteristics of the device from where it is invoked.

To enable loose coupling between service consumers and

services, the system architecture will have to abstract the

complexity and multiplicity of implementation options.

Architects will have to make trade-offs, such as whether

services will expose a single standardized interface and a

robust infrastructure will handle all of the necessary

transformations and routing, or whether multiple service

interfaces are exposed, which places fewer requirements

on the infrastructure (probably, at the expense of

maintainability). From a technology perspective, there is

currently no standard for representing user context, which

means that design decisions must be made to determine

when and how user-context information is obtained [8].

3.2 Instrumentation for Runtime Monitoring and Adaptation

If a service-oriented system includes runtime monitoring

and adaptation, all system elements must be instrumented

so as to gather the right measures and receive the proper

“orders” on what to do when thresholds are crossed. From

an architecture and design perspective, this translates into

architectural constructs for measurement and

instrumentation in the SOA infrastructure, services, and

even service consumers. Ideally, these constructs should

be highly configurable so as to accommodate SLA

changes and changes in service providers. For example,

recent research shows that to design self-adaptive systems,

the feedback loops that control self-adaptation must

become first-class entities at the expense of added

complexity [9].

3.3 Service Usability

In a growing market of third-party service brokers and

providers, the aspects that can make a service more or less

attractive include functionality, attached SLAs, and

usability. Characteristics that make a service more usable

or less usable can include interface design, options in

messaging protocols, add-ons (such as test cases and test

instances), and any other metadata that can tell consumers

more about the service. Therefore, the task of service-

interface design extends beyond simply defining the

messages that are exchanged between providers and

consumers. For example, architectural constructs would

have to be put in place to support advanced service

registries, multiple messaging options, test instances, SLA

monitoring, and any other characteristic that contributes to

the perception of service usability.

3.4 Federation

As service-oriented systems grow in size, the

centralization of certain aspects might become a

bottleneck. Federation can be a solution to this problem. In

this context, federation refers to predefined agreements on

aspects of the system that allow the autonomy of

individual components.

Some aspects of service-oriented systems that might

require federation in large-scale settings are:

-Identity management. This is the aspect that is most

commonly associated with federation in SOA

environments. Federated identity management means that

there is a cooperative contract that has been set up among

multiple identity providers and uses a decentralized

approach, so that an identity in one of the identity

providers is recognized by other identity providers in the

federation [12]. From a consumer perspective, this means

not having to log in to every single system that is involved


2 January

20

in the execution of a particular business process or

workflow. Some of the challenges of federated identity

management include trust, translation among multiple

standards, and synchronization.

-SOA infrastructures. In large-scale service-oriented

systems that span multiple organizations, it is unlikely that

all organizations will have the same SOA infrastructure. In

this case, federation would allow participating

organizations to maintain their SOA infrastructures, while

shared aspects such as policy management and governance

mechanisms are agreed upon, propagated throughout the

system, and implemented locally.

-Service registries. Federated service registries allow

registries to appear as a single, virtual registry and

individual organizations to retain local control over their

own registries.

Regardless of the aspect of the system that is federated,

there will need to be architectural constructs for

establishing agreements, virtualization, and

synchronization upon changes.

3.5 Automated Governance

The key to governance implementation is adding control to

a system without creating a lot of extra work to its

developers and users.

The approach is governance automation. The burden of

ensuring compliance and enforcement gets pushed to the

SOA infrastructure. There are tools and SOA

infrastructures in which some governance automation is

built in; in the end, however, the goal is the ability of an

organization to ensure that development and deployment

adhere to its own policies and standards, which might not

be what is codified in existing tools.

Some aspects of governance that can be automated are:

-Workflows for service identification.

-Service-deployment procedures.

-Compliance with regulations such as the Health Insurance

Portability and Accountability Act (HIPAA) and Sarbanes-

Oxley.

-Compliance with internal security policies.

-Runtime measurements and logging.

-SLA management.

Architectural constructs will need to be developed for

aspects of SOA governance that are critical for SOA

implementation and are not covered (or are implemented

differently) by the existing SOA infrastructure and SOA

governance tools. In multiorganizational settings, the

challenge is how to deal with conflicting policies and

procedures among organizations.

3.6 Specialized SOA Design Patterns

In software engineering, a design pattern is a general

reusable solution to a commonly occurring problem in

software design. Gamma et al. produced a set of design

patterns for object-oriented systems that triggered the

usage of the term in software design [10].

Since then, design patterns have been produced for

different types of systems, including service-oriented

systems [11].

Given the expectations that are being placed on service-

oriented systems, architects will have to build and research

patterns to address the expectations of future service-

oriented systems. This includes patterns for:

Service orientation in multi organizational

environments.

Embedding system qualities into SOA

infrastructures.

Service-interface design.

Integration with other technologies.

4. Conclusions

SOA is potentially being stretched beyond its limits. What

was initially an approach for asynchronous document-

based message exchanges now has performance,

availability, reliability, security, and other expectations of

traditional distributed systems. To solve this problem,

multiple specifications and standards have been proposed

and created, middleware products are becoming more

robust, and the community has started to embrace terms

such as event-driven SOA and real-time SOA. Therefore,

the loosely coupled, stateless, standards-based nature of

the relationship between service consumers and service

providers in service-oriented systems is changing, so as to

meet these new requirements. In addition, global

enterprises and the emerging market of third-party services

that are being made available through the Cloud are

placing new expectations on service-oriented system

architecture and design.

SOA is not a “one-size-fits-all” solution. As an

architectural style, SOA is an appropriate solution in some

situations; however, there are situations in which it is not


2 January

21

appropriate or it has to be used in conjunction with other

technologies to meet service qualities. The architect of

future service-oriented systems is going to play a crucial

role in determining what expectations can or cannot be met

by SOA adoption, and where trade-offs can be made for

the benefit of the organization and the accomplishment of

system qualities.

- Early, contextual technology evaluation — As the use

of SOA for external integration and the expectations of

SOA adoption increase, many promises will be made on

the benefits of SOA in these scenarios that will probably

not be validated until implementation. The role of the

architect is to perform early, contextual technology

evaluation and continuous technology scouting that can

lead to more informed decisions on what parts of the

system will benefit from SOA technologies [13].

- Architecture trade-off analysis —It is well known that

trade-offs must be made in systems, because the

accomplishment of a certain quality is often at the expense

of another quality. Common examples of trade-offs are

performance versus modifiability, availability versus

safety, security versus performance, and interoperability

versus cost.14 The use of service orientation in systems

that have high system-quality requirements will require

architectural trade-offs at the expense of loose coupling

and flexibility. If the added overhead for a service-oriented

system to meet quality requirements comes at the expense

of the characteristics for which SOA is known, the

decision to use service- oriented concepts should be

reevaluated. An architecture analysis and evaluation

method that is guided by business drivers and performed

via scenarios in which the usage of SOA technologies is

key can also help an architect make better, early, and

informed decisions.

Finally, as service-oriented systems start to cross

organizational boundaries, architects will have to

reevaluate the use of SOA as an architectural style in these

systems or to architect their systems in such a way that

qualities are met without having to sacrifice the

characteristics that have made SOA a worthwhile

technology to adopt.

References

[1] This term was coined by Geoffrey A. Moore in his

book Crossing the Chasm: Marketing and Selling High-

Tech Products to Mainstream Customers (Rev. ed. New

York: Collins Business Essentials, 2006) and refers to the

chasm that exists between visionaries (early adopters) and

pragmatists (early majority) from a technology-adoption

perspective.

[2] Softwareag.com. Software AG, Summer 2008.

[Accessed July 13, 2009.]

[3] Forrester.com. Forrester, February 2009.

[4] Manadhata, Pratyusa K., Kamie M. C. Tan, Roy A.

Maxion, and Jeannette M. Wing. CMU Technical Report

CMU-CS-07-146, August 2007.

[5] Pardo-Castellote, Gerardo. SOA World Magazine,

November 2007. [Accessed July 13, 2009.]

[6] Joshi, Rajive. Real-Time Innovations, Inc., August

2007.

[7] Simanta, Soumya, Ed Morris, Grace A. Lewis, Sriram

Balasubramaniam, and Dennis B. Smith. Software

Engineering Institute, June 2009. [Accessed July 13,

2009.]

[8] Kontogiannnis, Kostas, Grace A. Lewis, and Dennis B.

Smith. “A Proposed Taxonomy for SOA Research.”

In FSOA 2007). Software Engineering Institute, June

2008. [Accessed July 13, 2009.]

[9] Brun, Yuriy, Giovanna Di Marzo Serugendo, Cristina

Gacek, Holger Giese, Holger Kienle, Marin Litoiu, Hausi

Müller, Mauro Pezzè and Mary Shaw. Lecture Notes in

Computer Science Hot Topics, Volume 5525, 2009.

[10] Gamma, Erich, Richard Helm, Ralph Johnson, and

John Vlissides. Design Patterns: Elements of Reusable

Object-Oriented Software. Reading, MA: Addison-

Wesley, 1994.

[11] Erl, Thomas. SOA Design Patterns. Upper Saddle

River, NJ: Prentice Hall, 2009.

[12] Balasubramaniam, Sriram, Soumya Simanta, Ed

Morris, Grace A. Lewis, and Dennis B. Smith. “Identity

Management and its Impact on Federation in a System of

Systems Context.” Proceedings of the 2009 3rd Annual

IEEE Systems Conference, 2009.

[13] Lewis, Grace A., and Lutz Wrage. Software

Engineering Institute, June 2005. [Accessed July 13,

2009.]

[14] Clements, Paul, Rick Kazman, and Mark

Klein. Evaluating Software Architectures: Methods and

Case Studies. Boston, MA; London: Addison-Wesley,

2001.

Grace Lewis is a Senior Member of the Technical Staff at the Software Engineering Institute (SEI) in Pittsburgh, PA. Currently, she is the lead for the System of Systems Engineering team within the Systems of Systems Practice (SoSP) initiative in the Research, Technology, and Systems Solutions (RTSS) program. Her current


2 January

22

interests and projects are in service-oriented architecture (SOA), technologies for systems interoperability, characterization of software-development life-cycle activities in systems of systems environments, and establishing an SOA research agenda. Grace’s latest publications include multiple reports and articles on these subjects, as well as a book in the SEI Series in Software Engineering. She is also a member of the technical faculty for the Master in Software Engineering program at Carnegie Mellon University (CMU). Grace holds a B.Sc. in Systems Engineering; an Executive MBA from Icesi University in Cali, Colombia; and a Masters in Software Engineering from CMU.

This Article is copyrighted by Carnegie Mellon University and is subject to the Software Engineering Institute’s Terms of Use found at http://www.sei.cmu.edu/.


2 January

23

Key management in heterogeneous wireless sensor

networks using Voronoi diagrams

Abstract

Wireless sensor networks' nodes are divided to H-

sensors and L-sensors. H-sensor nodes are more

powerful than L-sensor nodes in term of processing

and memory. Because of that H-sensors are

considered as the cluster head and L-sensor as the

cluster member. H-sensor is responsible for the

security of this communication. Each node can

communicate with neighbor nodes. Problems of the

network are security and battery lifetime for each

node. Proposed algorithm presents a scheme to

keep the security, reduce energy consuming and the

length of message in wireless sensor network. In

this scheme each node select as a cluster head

based on minimum distance of neighbor nodes.

This algorithm, uses Voronoi algorithm, did the

most optimal clustering and divides the operational

environment to Voronoi spaces and allocate a key

to each Voronoi space for secure connection with

neighbor spaces. Each Voronoi spaces have special

key, so that energy consuming decreases and

security increases. This scheme is evaluated by

MATLAB, simulation software, and compared

with previous algorithms. Results of this simulation

show that this scheme operates better than similar

schemes because it decreases the length of message

and energy consuming.

Keywords: key management, wireless sensor network,

Voronoi diagram

1. Introduction

Wireless sensor network consist of some H-

sensors and L-sensors that H-sensor apply as the

cluster head because of their power in processing

and memory and L-sensors are node's cluster

members. Communication between nodes must be

secure so H-sensors are reasonable

for authentication and security. The number of H-

sensor are not too much But they are more

powerful that L-sensors so using H-sensors in key

management and reduce money and consume

memory. First H-sensors pre-distribute with keys

and H-sensors pre-load L-sensor with key similar

BS works in front of H-sensors. In this scheme key

pre-distributed scheme based on random key pre-

distributed for Heterogonous sensor network

Proposed with Voronoi algorithm. This scheme

based on [2] using key management.

Note is that the keys pre-loaded in nodes with

cluster head and is not need to preload with BS also

derived keys.

For comparison of the proposed scheme with

scheme presented in [1], some factors are

compared and studied like: communication

captured node and consumed energy.

Communication is assumed to be secured.

Communication between two L-sensors in one

cluster or two different clusters is possible.

Voronoi spaces will be explained in section C, in

node capturing section will study communication

networks that one of their keys is discovered. The

only defect is memory consuming and it leads to

increscent of security and this consuming is not too

much so it can be ignored. In the other hand

security and energy consuming in proposed scheme

had been optimized.

This article is organized as below: Section 2

explains related works, section 3 and 4 is about

network model and proposed scheme. Section 5

presents results and analyzes the efficiency of the


2 January

24

Ronak Tahmasbi1, H.Haj seyed javadi2, M.E.Shiri3, Ahmad Allahyari4

1 Software Eng. Department of computer, Kish International Branch, Islamic Azad University, Kish Island, Iran

2 Department of Mathematics and Computer Science, Shahed University, Tehran, Iran 3Industrial Eng. Faculty of Amirkabir University of technology

4 Industrial Eng. Faculty of Industrial Engineering, Alghadir University, Iran

proposed scheme and finally section 6 will state the

conclusion of this study.

2. Related works

Banihashemian and Ghaemi Bafghi [1]

proposed an efficient key management in wireless

sensor networks. Resiliency and connectivity are

two important factors in proposed scheme. This

scheme contains four stages. These stages are key

pre-distribution and localization, seeds assignment,

deriving new keys and shared discovered keys.

Du et al. [2], based on symmetric pre- distribution

key management and proposed scheme called AP.

Main idea in AP is asymmetric pre-distribution key

management, preload many keys in little number of

H-sensors, H-sensors are powerful and they are not

too much so, keys are stored in L-sensors: L-

sensors have little range of communication storage

and capacity.

Chan and Perring [3] improves PIKE protocol

based on key establishment by using peer sensor

nodes as trusted communication.

In recent studies on security improvement of key

pre-distribution, some schemes are proposed in [4,

5] and [6] have studied on threshold key pre-

distribution scheme.

3. Network model

Base station (BS) is assumed to be secures and

resources such as energy process power and

memory are not limited.

H-sensors are more powerful in terms of memory

and processing than L-sensors. H-sensors are

connected to BS directly.

A. Assumptions

Assume that H-sensors and L-sensors are

distributed randomly in operational

environment.

H-sensors are clusters head and L-sensors are as

the cluster members.

Suppose that networks are secured in distribution

phase and only capture node along

communication.

Location of L-sensors and H-sensors are static.

Range transfer of H-sensors and L-sensors are

static.

Range conduction of H-sensors are high,

therefore L-sensors can receive message

“Hello” from one or more H-sensors.

Number of sensor nodes in a cluster is assumed to

be not determined.

Each H-sensor have GPS and report locations.

B. Notations

Using the following notations to describe proposed

key management protocol and involved

cryptographic operations in this paper.

BS: base station

advi: advertisement message by ith cluster head

CHi: cluster head of ith cluster

KBS-i: pair wise key between BS and node with IDi

Seedi,j: seed related to ith cluster and ith Voronoi

space

S: total number of seeds used in entire network

Sb: minimum of seeds needed by protocol

Sd: additional seeds that need after cluster

formation

EK(M): encrypt message M by key K

DK(M): decrypt message M by key K

Hash(K, seed): hash key K with seed

Dist: distance between Voronoi space neighbors

BKi: ith base key

DKi-j: ith key hashed by seed j

KN: shared key used by all nodes in the network

KCm: cluster key used by all nodes in cluster m

KBS-Chi: pair wise key between Chi and BS

4. Proposed protocol

Proposed scheme is base on [2]. Using the concept

of Voronoi space that the main idea is using cluster

information based on distance between node and its

cluster head in key management. Node in each

Voronoi space is selected based on its distance.


2 January

25

Distance is computed base on RSSI [3]. A unique

seed is allocated to each Voronoi space that is used

to create derived keys. Derived keys are used for

secure communication with neighbor Voronoi

spaces. IN general Networks are divided to

different Voronoi spaces with different keys.

The amount of H-sensors is not too much and

number of seeds is enough, so seeds meet key

management requirements, therefore a little amount

of seeds will belonged to H-sensors (Sb). The

number of base keys is equal to division of key

pool size on Sb.

A. Pre-distribution phase

In the first stage, a key pool is generated. In this

phase base keys are applied, but derived keys are

not used. Each node stores one base key of k base

keys randomly. And each H-sensor stores one base

key (c), in which c>>k .

Pair wise key is used between BS and KBS-Chi. Each

L-sensor stores one base key and one key has been

stored between nodes and BS that is used for

authentication by BS.

Key cluster is generated by using KN and each node

stores one KN. The node could be L-sensor or H-

sensor

B. Computing number of seeds needed for each

cluster

Because there is not enough information about

nodes location, number of seeds can not be

estimated. Minimum number of seeds is equal to

number of clusters because, each cluster has one

key. Each H-sensor is the cluster head and each

cluster head sends its location in operational

environment of network grid of 400m*400m in

Voronoi spaces. Number of Voronoi spaces is

equal to cluster heads.

Each cell in grid has coordinate Xcell and Ycell, each

node based on minimum distance to cluster head

specifies that each cell belongs to which cluster.

Cluster head is selected randomly and Voronoi

space is formed based on minimum distance to

cluster head. Now each cluster head reports its

distance from BS and BS sends seed to each cluster

head. For example if 5 Voronoi spaces after

dividing to 5 BSs, each BS sends seed for all

Voronoi spaces.

Figure 1. Example of 5 Voronoi spaces and 5 BSs

C. Computing new keys by seed

Some seeds are sent to cluster's nodes by their

cluster head. Nodes generate new keys by using

distance. Then BS sends seed to cluster head. Each

cluster head transmits a Hello message, computes

distance by RSSI to makes a seed join to another

cluster head that have minimum distance to that

node. Cluster key is computed by KCm= hash (KN ||

IDCHm).

BS CHi : EBS ([seedi,1 , dist1] , [seedi,2 , dist2] ,

…, [seedi,z , distz] )

Cluster head receives seed from BS and computes

new key and sends it to node’s cluster and this

message encrypt by keys of that cluster.

CHi Node: KCi ([seedi,1 , dist1] , [seedi,2 , dist2] ,

…, [seedi,z , distz] )

Each Voronoi space generates new key for

communication with neighbors Voronoi space by

seeds:

Kj1(1) = hash (kj1 , seedi , z )

Kj1(2) = hash (kj1 , seedi,z+1 )

.

.

Kj1(n) = hash (kj1 , seedi,z+n )

For security preservation, after first communication

seeds will be deleted.

D. Shared key discovery

Each node transmits a message that encrypt by key

cluster, this message contains its keys and its

Voronoi space. In result, neighbor's nodes find

shared key.

If multiple shared keys exist, one of them is

selected randomly, but if the shared key does not


2 January

26

exist, each node sends request message that

contains its ID, its Voronoi space, its list of keys

and other node's ID for cluster head. Cluster head

have more chance to have a shared key because the

number of key cluster heads is more. Cluster head

selects one of its keys and sends it to nodes, but if

cluster head did not have a shared key, nodes send

message to BS and BS sends a shared key to them.

5. Performance evaluation

In this section, performance of proposed key

management scheme is evaluated. Comparison

between two scheme had been done proposed

scheme and presented scheme in [1]. This

comparison was done based on 4 elements,

probability of secure connectivity (p), resilience of

proposed key management scheme (res), energy

consuming (k eng) and message length (ml).

A. Secure connectivity

Probability of secure connectivity between two L-

sensors is calculated for l0 sensors and in three

different states.

State 1; number of sensor nodes is 1000, radius is

50, number of captured nodes is 50 and all of them

are static and similar for two schemes. Number of

cluster is variable. Table 1 shows results for state 1.

Table 1. Comparison of secure connectivity in proposed scheme

and scheme in [1] (State 1)

Original

run Input p res k eng ml

1 10 0.04004 0.04009 0.01943 9.22658

2 12 0.03659 0.03656 0.01650 10.29395

3 14 0.03180 0.03194 0.01522 11.61720

4 16 0.02899 0.02911 0.01211 12.34847

5 18 0.02660 0.02680 0.01066 13.09144

6 20 0.02336 0.02310 0.00987 14.61928

7 22 0.02149 0.02115 0.00919 15.70155

8 24 0.02005 0.01969 0.00831 16.62267

9 26 0.01910 0.01849 0.00741 17.64261

10 28 0.01759 0.01644 0.00750 18.98006 [

Proposed


1 10 0.04341 0.04345 0.00294 2.89800

2 12 0.04345 0.04350 0.00235 3.36500

3 14 0.04325 0.04330 0.00112 3.32900

4 16 0.04357 0.04362 0.00163 3.29100

5 18 0.04383 0.04387 0.00163 3.29100

6 20 0.04491 0.04495 0.00052 3.59700

7 22 0.04295 0.04300 0.00071 3.82700

8 24 0.04358 0.04363 0.00034 3.80600

9 26 0.04407 0.04412 0.00032 3.82600

Figure 1 shows charts about results from Table 1 in

different number of clusters.

Figure 2. Charts about results from Table 1

State 2; number of sensor nodes is 1000, number of

clusters is 10, number of captured nodes is 50 and

all of them are static, results of tests variant radius

is presented in Table 2.



Original


1 50 0.03974 0.03980 0.01994 9.35810

2 60 0.04989 0.05004 0.01876 8.75780

3 70 0.06024 0.06065 0.01903 8.29519

4 100 0.08948 0.09127 0.01886 7.57775

5 200 0.18399 0.19316 0.02006 6.82113

6 300 0.27147 0.29106 0.01947 6.44641

7 400 0.36193 0.38901 0.01986 6.35146

8 500 0.36476 0.39110 0.01941 6.22636

9 600 0.35128 0.37824 0.01868 6.13834

10 700 0.36404 0.39152 0.02000 6.19354

Proposed


1 50 0.04400 0.04404 0.00254 3.04900

2 60 0.06294 0.06300 0.00256 3.13800

3 70 0.08237 0.08246 0.00228 3.01300

4 100 0.15327 0.15343 0.00259 2.94100

5 200 0.49987 0.50037 0.00341 2.77500

6 300 0.78441 0.78520 0.00240 2.92600

7 400 0.97181 0.97278 0.00305 2.93200

8 500 0.99829 0.99929 0.00458 2.89300

9 600 0.99900 1.00000 0.00314 2.78800

Figure 3 shows charts about results from Table 2 in

different radiuses.


2 January

27


State 3 is built for two schemes with flowing

factors; number of clusters is 10, number of

captured nodes is 50 and radius is 50, the variant

factor is number of sensor nodes and results is

showed in Table 3. Figure 4 shows charts about

results from Table 3 in different number of sensor

nodes.



Original


1 1100 0.04027 0.04033 0.02123 9.25462

2 1200 0.03972 0.03977 0.02270 9.17231

3 1300 0.04008 0.03956 0.02565 9.31462

4 1400 0.04062 0.04067 0.02666 9.11005

5 1500 0.03998 0.04002 0.03033 9.26051

6 1600 0.03950 0.03954 0.03229 9.39509

7 1700 0.03976 0.03980 0.03388 9.28175

8 1800 0.03989 0.03993 0.03437 9.19492

9 1900 0.03981 0.03985 0.03628 9.24743

10 2000 0.03985 0.03929 0.03841 9.20701

Proposed


1 1100 0.04346 0.04350 0.00363 3.23636

2 1200 0.04402 0.04406 0.00502 3.09833

3 1300 0.04422 0.04426 0.00426 3.08154

4 1400 0.04411 0.04414 0.00354 2.92071

5 1500 0.04336 0.04339 0.01064 2.74733

6 1600 0.04374 0.04376 0.00591 2.97875

7 1700 0.04335 0.04338 0.00720 2.83235

8 1800 0.04448 0.04450 0.00490 3.03611

9 1900 0.04373 0.04375 0.00800 3.13316

10 2000 0.04387 0.04389 0.00830 3.03400


B. Security analysis

In this section, resilience of proposed key

management scheme against compromise attack

mode will be checked. L-sensor t attacks to the

network, each L-sensor maintains k preloaded keys

and nk derived keys. Similar to study [1],

probability of captured nodes by L-sensor t is

calculated by:

1 21

t

revealkP

b s

Proposed scheme was evaluated by simulation and

was compared with [1]. Results that are showed in

Table 4 are about security analysis when number of

sensors is 1000, number of cluster is 10 and radius

is 50. Charts about results in Table 4 are presented

in Figure 5.



2 January

28

Table 4. Comparison of security analysis in proposed scheme


Original


1 20 0.17867 0.18782 0.00124 6.80858

2 35 0.18301 0.19240 0.00129 6.85880

3 75 0.17378 0.18215 0.00134 6.96039

4 125 0.18576 0.19498 0.00127 6.78461

5 250 0.17758 0.18646 0.00129 6.93642

6 330 0.18391 0.19336 0.00120 6.78118

7 450 0.17893 0.18785 0.00127 6.78461

8 540 0.18425 0.19453 0.00113 6.60541

9 600 0.17745 0.18657 0.00123 6.80744

10 750 0.18152 0.19108 0.00115 6.77319

Proposed


1 20 0.04469 0.04474 0.00256 3.09300

2 35 0.04318 0.04323 0.00437 3.12000

3 75 0.04391 0.04395 0.00400 3.20400

4 125 0.04450 0.04454 0.00384 3.30800

5 250 0.04365 0.04369 0.00294 3.02300

6 330 0.04419 0.04423 0.00253 3.28400

7 450 0.04362 0.04366 0.00295 2.94800

8 540 0.04347 0.04351 0.00429 3.18000

9 600 0.04412 0.04416 0.00235 3.39300

10 750 0.04350 0.04354 0.00234 2.90800

Results with variety of clusters, sensor nodes and

radiuses show, that probability p in three studies is

improved, energy consuming is decreased to 1/3

and message length decrease to 1/4 of initial

amounts. Probability of nodes capturing is

increased, but this increasing is little in comparison

with probability p and decreasing energy

consuming and message length.

6. Conclusions

In the proposed scheme is a new key management

based on pre-distribution randomly keys using

Voronoi diagram.

A lot of L-sensors and a few H-sensors used,

similar to [1], these H-sensors are cluster heads. In

the proposed scheme L-sensors and H-sensors base

on keys are pre-distributed and for each L-sensor a

seed is assigned based on distance of its cluster

heads and the cluster. This study compares the

proposed scheme with presented scheme in [1] that

probability of shared key (p), energy consuming

and message length are improved and results show

that proposed scheme is more effective and defects

are very little.

References

[1] Banihashemian, Saber and Ghaemi Bafghi, Abbas. A

new key management scheme in heterogeneous

wireless sensor networks. Mashhad: Ferdowsi

University of Mashhad (FUM), 2011.

[2] An effective key management scheme for

heterogeous sensor networks, Ad Hoc Networks.

Du, X., et al. 2007, Vols. 24-34.

[3] peer intermediaries for key establishment in sensor

networks. H, H. Chan and Perring, Pike, A. s.l. :

24th annual joint conference of the IEEE computer

and computer and communications societies, 2005.

INFOCOM 2005.

[4] Location-based pairwise key establishments for static

sensor networks. Liu D, D. and Ning, P. New

York : proceedings of the lst ACM workshop on

security of adhoc and sensor networks, 2003, Vols.

72-82.

[5] Securing sensor networks with location based keys.

Zhang, Y., et al. s.l. : Wireless Communications

and Networking Conference, 2005.

[6] Non-public key distribution. Blom R, R. s.l. :

Advances in cryptologyCRYPTO82, 1982, Vols.

231-236.

[7] Z, Liu, et al. A distributed energy-efficient clustering

algorithm with improved coverage in wireless

sensor networks. J. Future Generation Computer

Systems, s.l. : 2011.

[8] An initialization method for the K-means algorithm

using neighborhood model. C, Fuyuan, J, Liang

and G, Jiang. s.l. : J Computers and Mathematics

with Applications, 2009, Vols. 474-483.

[9] Hierarchical initialization approach for K means

clustering. JF, Lu, et al. s.l. : J Pattern Recognition

Letters, 2008, Vols. 787-795.


2 January

29

On Distributed Embedded Systems

Arvindra Sehmi

Bio-medical engineering, Leicester University, United Kingdom

Abstract

Thinking of distributed embedded systems (DES)—let

alone the more general area of embedded computing—as a

unified topic is difficult. Nevertheless, it is a vastly

important topic and potentially represents a revolution in

information technology (IT). DES is driven by the

increasing capabilities and ever-declining costs of

computing and communications devices, resulting in

networked systems of embedded computers whose

functional components are nearly invisible to end users.

Systems have the potential to alter radically the way in

which people interact with their environment by linking a

range of devices and sensors that will allow information to

be collected, shared, and processed in unprecedented

ways.

Keywords: distributed embedded systems

1. Introduction

DES conjures up images of pervasive collaboration among

connected devices, such as tiny, stand-alone, embedded

microcontrollers, networking devices, embedded PCs,

robotics systems, computer peripherals, wireless data

systems, sensors, and signal processors. Combining

information from in-place sensors with information from

other sources on the network will enable new, rich

scenarios to be realized in automotive and avionics control

systems, local environmental monitoring for precision

agriculture, medical systems, personal health-care

monitoring, and manufacturing and process automation,

for example.

Widespread use of DES throughout society could dwarf

previous revolutions in IT for two reasons. Firstly,

Moore’s law is primarily driving device miniaturization

and reduced power consumption (instead of increased

speed). Secondly, the industry is fast becoming better

equipped with development tool chains (software

included) and pervasive standards-based communications

protocols. As a consequence, embedded computing and

communications technology can quite literally be

everywhere and extend into all aspects of life—an

invisible component of almost everything in everyone’s

surroundings.

2. Contrasting DES with Traditional

Distributed Systems

DES differs from traditional distributed systems in

important ways. Embedded systems will eventually

interconnect millions, maybe billions, of nodes. This will

require changes in the way nodes interact with one

another. Broadcast, not peer-to-peer, communications will

be the norm. The sheer size of connected clusters of

applications will necessitate the use of statistically correct

(instead of deterministic) algorithms for resource

accounting, fault detection and correction, and system

management. These clusters will merge and dissolve

rapidly to host functionality that is of interest to groups

formed specifically for that purpose. Doing this

successfully requires new approaches to naming, routing,

security, privacy, resource management, and

synchronization. Heterogeneity will factor greatly in the

design, implementation, and operation of DES, as will

cross-cutting concerns such as dependability, energy-

aware computing, critical systems engineering, security,

real-time programming, and resource-bounded computing.

Some of these factors are familiar to traditional application

developers, but many are simply viewed as esoteric

boundary issues.

30


2 January

DES tends to be tightly coupled to the physical world and

will often be invisible when things are working properly.

In contrast to desktop computers, which are part of the

office or home furniture, DES instead will be integrated

into the furniture and other objects in the environment.

You will interact with these objects and devices, but will

be unlikely to think of them, as you do when interacting

with a computer.

DES components are highly resource constrained. They

are typically small, wirelessly connected, bandwidth

limited, and operating under physical constraints such as

limited energy and the need for adequate heat dissipation.

Since they would be integrated in buildings, bridges,

vehicles, and so on, they would be expected to last as long

as the objects in which they are embedded. The

expectation of longevity needs to be taken into account

when designing, deploying, and managing these systems.

Heterogeneity will be the norm because of the large

number of interacting elements that make up DES, so

interoperability is a key concern. Managing these

constraints and creating a system that functions properly

while remaining understandable and manageable by

human operators, users, and casual passersby, is a great

challenge for DES designers—arguably much more of a

challenge than that posed by traditional distributed-

systems design. The DES scenarios described later in this

paper should clarify these points.

3. Market Opportunity

DES is a fast-growth area of the computing industry and is

indicative of the long-term trend of moving away from

centralized, high cost, low volume products toward

distributed, low-cost, high-volume products.

The next step in this process is the emergence of massively

distributed systems—that is, distributed embedded systems

that are connected to enterprise systems and the Internet

(or the so-called cloud). These systems will penetrate even

more deeply into the fabric of society and become the

information power grids of the 21st century. As noted,

they will be ubiquitous, most will operate outside the

normal cognizance of the people they serve, and most will

be based on embedded systems that present nontraditional

computing interfaces to their users. Their full potential will

see them engineered to operate as distributed utilities,

much like the energy, water, transportation, and media

broadcast businesses do today [1]. The major industry

sectors where DES is likely to be used are automotive,

avionics/aerospace, industrial automation (and robotics);

telecommunications; consumer electronics and intelligent

homes; health and medical systems. The market

opportunity of these sectors is significant and the reader is

referred to the FAST report [2] for more details. In

summary, though, and as Table 1 shows, the overall value

of the embedded sector worldwide is about 1600 billion €

per year; the three largest markets for embedded systems

are telecommunications, automotive, and

avionics/aerospace with combined value worldwide of

1,240 billion € per year; and these three largest markets are

characterized by growth rates in excess of 10 percent.

Table 1. Estimated total value, through 2006, and growth, through 2010, of major

industry sectors using embedded systems (based on the FAST report2 and others)

ES = embedded systems; EC = electronic components

Industry sector

Annual

global value

ES

value

(%)

ES

value

EC

growth

(%)

ES

growth

(%)

Automotive 800 b€ 40% 320 b€ 10% 10%

Avionics/Aerospace 750 b€ 50% 370 b€ 5% 14%

Industrial automation 200 b€ 55% 110 b€ 5% 7%

Telecommunications 1000 b€ 55% 550 b€ 9% 15%

Consumer electronics and

intelligent homes 300 b€ 60% 180 b€ 8% 15%

Health and medical

systems 130 b€ 40% 50 b€ ? 18%

Total 3180 b€

1580 b€

The nature and characteristics of distributed embedded

systems are explored below through some example

scenarios drawn from the industry sectors mentioned

above. This will help draw similarities to traditional

distributed-systems development while also recognizing

that there are unique systems-design implications,

implementation issues, and approaches to solution

development.

4. Scenarios

4.1 Automotive Telematics Scenario

In the automotive and avionics industry, embedded

systems provide the capability of reaching new levels of

safety and sustainability that otherwise would not be

feasible, while adding functionality, improving comfort,

31


2 January

and increasing efficiency. Examples of this include

improved manufacturing techniques, driver-assistance

systems in cars that help prevent accidents, and advanced

power-train management concepts that reduce fuel

consumption and emissions.

In Western Europe, the “100 percent safe” car is

envisioned. It will have sensors, actuators, and smart

embedded software, ensuring that neither the driver nor the

vehicle is the cause of any accident. This concept extends

to all aspects of the driving experience: in-car

entertainment, information services, and car-to-car and

car-to-infrastructure communication.

For example, the car would know who is allowed to drive

it and who is driving it; where it is; where it is going and

the best route to its destination; and it would be able to

exchange information with vehicles around it and with the

highway. It would monitor its own state (fuel levels, tires,

oil pressure, passenger compartment temperature and

humidity, component malfunction, need for maintenance)

and the state of the driver (fatigue, intoxication, anger).

The car would first advise and then override the driver in

safety-critical situations, use intelligent systems to

minimize fuel consumption and emissions, and contain an

advanced on-board entertainment system.

Radio-frequency identification (RFID) smart tags within

the major car components would communicate with other

components during manufacture to optimize the process,

communicate with in-car systems during the car’s working

life to optimize maintenance cycles, and enable

environmentally friendly disposal of the car and its

components at the end of its life.

4.1.1 Challenges and Issues

To enable this scenario, components would need to be

embedded in long-lived physical structures (such as

bridges, traffic lights, individual cars, and perhaps even the

paint on the roads). Some components will be permanently

connected to a network, but many would be resource

constrained (for example, in terms of power) while

computing data and thus communicating it wirelessly only

when necessary. The many pieces of such a system will of

necessity be heterogeneous, not only in form but also in

function. There may be subsystems that communicate to

consumers in private vehicles, others that relay

information from emergency vehicles to synchronize

traffic lights, still others that provide traffic data and

analysis to highway engineers, and perhaps some that

communicate to law enforcement.

How information will be communicated to those

interacting with the system is of great importance in such

an environment. Safety is a critical concern, and issues of

privacy and security arise as well, along with concerns

about reliability.

4.2 Precision Agriculture Scenario

Incorporating DES technology into agriculture is a logical

development of the advances in crop management over the

last few decades. Despite deep understanding and

knowledge on the part of farmers about how to adjust

fertilizers, water supplies, and pesticides, and so on, to best

manage crops and increase yields, a multitude of variations

still exist in soil, land elevation, light exposure, and

microclimates that make general solutions less than

optimal, especially for highly sensitive crops like wine

grapes and citrus fruit.

The latest developments in precision agriculture deploy

fine-grained sensing and automated actuation to keep

water, fertilizer, and pesticides to a minimum for a

particular local area, resulting in better yields, lower costs,

and less pollution-causing runoff and emissions.

Furthermore, the data collected can be analyzed and

incorporated as feedback control to adjust irrigation flow

rate and duration tuned to local soil conditions and

temperature. Sensors that can monitor the crop itself (for

example, sugar levels in grapes) to provide location-

specific data could prove very effective.

In the future, DES might be used to deploy sensors for the

early detection of bacterial development in crops or viral

contamination in livestock, or monitor flows of

contaminants from neighboring areas and send alerts when

necessary. In livestock management, feed and vitamins for

individual animals will be adjusted by analyzing data from

networks of ingestible sensors that monitor amounts of

food eaten, activity and exercise, and health information

about individual animals and the state of the herd as a

whole.


In this scenario, embedded components must be adaptive,

multimodal, and able to learn over time. They will need to

work under a wide range of unpredictable environmental

conditions, as well as to interact with fixed and mobile

infrastructure and new elements of the system as they are

added and removed at varying rates of change.

32


2 January

4.3 Aviation and Avionics Scenario

The European Commission has set goals for the aviation

industry of reducing fuel consumption by 30 percent by

2021 through the use of embedded systems. This may be a

high goal to be achieved solely through the use of

technology. But in this industry, the goals appear to very

ambitious across the board.

The unmanned aerial vehicle (UAV) for use in

surveillance and in hazardous situations such as

firefighting promises to be cheaper, safer, and more energy

efficient to operate than conventional aircraft. There are

apparently many different kinds of UAVs under

development: some with long-duration operational cycles

and extensive sensor suites; some with military defense

and attack capability; others that are small enough to be

carried and deployed by individuals; and, in the future,

tiny, insect-like, UAVs providing a flying sensor network.

The aircraft of the future will have advanced networks for

on-board communication, mission control, and distributed

coordination between aircraft. These networks will support

advanced diagnosis, predictive maintenance, and in-flight

communications for passengers. For external

communication, future aircraft will communicate with

each other in spontaneous, specific-for the-purpose ways

similar to peer-to-peer networks.


The aviation and avionics industry has specific needs in

terms of security, dependability, fault tolerance and

timeliness, stretching the limits of distributed embedded-

systems design and implementation. The whole system, if

not each of its embedded components, needs to be high

precision, predictable, and robust for 100 percent

operational availability and reliability. It must enable high

bandwidth, secure, seamless connectivity of the aircraft

with its in-flight and on-ground environment. It should

support advanced diagnosis and predictive maintenance to

ensure a 20- to 30-year operational life span.

DES design environments and tools will need to provide

significant improvements in product development cycles,

ongoing customizations, and upgrades beyond those

achievable with current distributed-systems development

tools. Design advances in fast prototyping, constructive

system composition, and verification and validation

strategies will be required to manage this complexity.

4.4 Manufacturing and Process-Automation

Scenario

Embedded systems are important to manufacturing in

terms of safety, efficiency, and productivity. They will

precisely control process parameters, thus reducing the

total cost of manufacture. Potential benefits from

integrating embedded control and monitoring systems into

the production line include: better product quality and less

waste through close process control and real-time quality

assurance; more flexible, quickly configured production

lines as a result of programmable subsystems; system

health monitoring, which leads to more-effective,

preventive and lower-cost maintenance; safer working

environments due to better monitoring and control; and

better component assembly techniques, such as through

the use of smart RFID tags.


There are many implications of this industry scenario for

DES. One is a need for better man-machine interactions in

what is fundamentally a real-time, man-plus-machine

control loop. Providing better interactions will improve

quality and productivity by ensuring that there are no

operator errors, as well as by reducing accidents.

Availability, reliability, and continuous quality of service

are essential requirements for industrial systems achieved

through advanced control, redundancy, intelligent

alarming, self-diagnosis, and repair. Other important issues

are the need for robustness and testing, coherent system-

design methodology, finding a balance between openness

and security, integrating old and new hardware with

heterogeneous systems, and managing obsolescence.

4.5 Medical and Health-Care Scenario

Society is facing the challenge of delivering good-quality,

cost-effective health care to all citizens. Medical care for

an aging population, the cost of managing chronic

diseases, and the increasing demand for best-quality health

care are major factors in explaining why health-care

expenditures in Europe are already significant (8.5 percent

of GDP) and rising faster than overall economic growth.

Medical diagnosis and treatment systems already rely

heavily on advances in embedded systems. New solutions

that mix embedded intelligence and body-sensing

techniques are currently being developed [3], and current

33


2 January

advances in this area address patient-care issues such as

biomedical imaging, remote monitoring, automatic drug

dispensing, and automated support for diagnosis and

surgical intervention.


The medical domain represents a complex and diverse

arena for extraordinary developments that deploy a wide

range of embedded systems. Implanted devices such as

pacemakers and drug dispensers are commonplace, but

need to become more sophisticated, miniaturized, and

connected to networks of information systems. Wearable

devices for monitoring and managing cholesterol, blood

sugar, blood pressure, and heart rate must be remotely

connected to the laboratory and to the operating room in a

secure and reliable manner from beginning to end. Robotic

devices are being used today to guide and perform

invasive surgery requiring high-integrity engineering

practices not even imagined in a typical “mission-critical”

enterprise application.

4.6 Mobility Scenario

Combining mobile communications with mobile

computing is allowing people to talk to others and access

information and entertainment anywhere at any time. This

requires ubiquitous, secure, instant, wireless connectivity,

convergence of functions, global and short-range sensor

networks and light, convenient, high-functionality

terminals with sophisticated energy management

techniques. Such environments will enable new forms of

working with increased productivity by making

information instantly available, when needed in the home,

cars, trains, airplanes and wider-area networks. Imagine a

hand-held or wearable device giving easy access to a range

of services able to connect via a range of technologies

including GSM, GPS, wireless, Bluetooth and via direct

connection to a range of fixed infrastructure terminals.

Potential applications and services include: Entertainment,

education, internet, local information, payments,

telephony, news alerts, VPNs, interfaces to medical

sensors and medical services, travel passes and many

more.


Devices would need to reconfigure themselves

autonomously depending on patterns of use and the

available supporting capabilities in environment or

infrastructure and be able to download new services as

they became available. To develop such infrastructure, the

gap between large, enterprise systems and embedded

components would need to be bridged. Significant

developments are required in technology for low-power

and high performance computing, networked operating

systems, development and programming environments,

energy management, networking and security.

Issues that need to be resolved in the infrastructure to

support these kinds of scenarios include the provision of

end-to-end ubiquitous, interoperable, secure, instant,

wireless connectivity to services. Simultaneously the

infrastructure must allow unhindered convergence of

functions and of sensor networks. Addressing the

constraints imposed by power management (energy

storage, utilization and generation) at the level of the

infrastructure and mobile device poses a major challenge.

4.7 Home-Automation and Smart Personal

Spaces Scenario

By deploying DES in the home, an autonomous,

integrated, home environment that is highly customizable

to the requirements of individuals can be foreseen. Typical

applications and services available today include intruder

detection, security, and environmental control. But in the

future, applications and services to support the young,

elderly, and infirm will be developed, and these may have

the ability to recognize individuals and adapt to their

evolving requirements, thereby enhancing their safety,

security, and comfort. By tying in with applications and

services described in the medical/health-care and mobility

scenarios, smart personal spaces could be developed.


Multidisciplinary, multi-objective design techniques that

offer appropriate price and performance, power

consumption, and control will have to be used if we are to

realize the potential of embedded systems for home

entertainment, monitoring, energy efficiency, security, and

control. Such systems will require significant

computational, communication, and data-storage

34


2 January

capabilities. The mix of physical monitoring and data-

based decision support by some form of distributed

intelligence will rely on the existence of seamlessly

connected embedded systems and the integration of

sensors and actuators into intelligent environments. These

systems will be characterized by ubiquitous sensors and

actuators and a high-bandwidth connection to the rest of

the world. Technologies will need to be developed that

support sensing, tracking, ergonomics, ease-of-use,

security, comfort, and multimodal interaction.

Key to achieving this result will be developing wireless

and wired communications and techniques for managing

sensor information, including data fusion and sensor

overloading. The challenges are to make such systems

intelligent, trustworthy, self-installing, self-maintaining,

self-repairing, and affordable, and to manage the

complexity of system behavior in the context of a large

number of interoperable, connected, heterogeneous

devices. These systems will need to operate for years

without service, be able to recover from failure, and be

able to supervise themselves.

Managing these embedded systems will require support of

all aspects of the life cycle of the application and service

infrastructures, including ownership, long-term storage,

logging of system data, maintenance, alarms, and actions

by the provider (emergency, medical, or security) services,

authorization of access and usage, and charging and billing

under a range of different conditions of use.

5. Technical Imperatives

Some of the most challenging problems facing the

embedded-systems community are those associated with

producing software for real-time and embedded systems.

Such systems have historically been targeted to relatively

small-scale and stand-alone systems, but the trend is

toward significantly increased functionality, complexity,

and scalability, as real-time embedded systems are

increasingly being connected via wireless and wired

networks to create large-scale, distributed, real-time, and

embedded systems. These combined factors [4] require

major technical imperatives to be addressed by both

industry and research establishments: (a) self-

configuration and adaptive coordination; (b)

trustworthiness; (c) computational models; and (d)

enabling technologies. Let’s now look at each technical

imperative in more detail.

6. Self-Configuration and Adaptive

Coordination

Self-configuration is the process of interconnecting

available elements into an ensemble that will perform the

required functions at the desired performance level. Self-

configuration in existing systems is realized through the

concepts of service discovery, interfaces, and

interoperability. But embedded systems, which appear in

hybrid environments of mobile and static networks with

nodes of varying capability, energy availability, and

quality of connectivity, are plagued by diverse and energy-

limited wireless connectivity—making low power

discovery a challenge. Also scalable discovery protocols,

security, and the development of adequate failure models

for automatically configured networks will require that

solutions be developed.

Adaptive coordination involves changes in the behavior of

a system as it responds to changes in the environment or

system resources. Coordination will not necessarily be

mediated by humans because DES could be so large and

the time scale over which adaptation needs to take place

too short for humans to intervene effectively. Achieving

adaptive coordination in DES will draw on the lessons

learned from adaptive coordination in existing distributed

systems, but it will also require meeting the radical new

challenges posed by the physically embedded nature of

collaborative control tasks and large numbers of nodes,

and further complicated by the relatively constrained

capabilities of individual elements. Thus, to achieve

adaptability in DES, solutions are needed in decentralized

control and collaborative processing, and techniques must

be developed to exploit massive redundancy to achieve

system robustness and longevity.

7. Trustworthiness

If we can expect DES to be deployed in large numbers and

become an essential part of the fabric of everyday life, five

technical imperatives much be taken into account in their

design from the outset: reliability, safety, security, privacy,

and usability.

On reliability, current monitoring and performance-

checking facilities, and verification techniques are not

easily applicable to DES because of their large number of

elements, highly distributed nature, and environmental

dynamics.

35


2 January

In terms of safety or the ability to operate without causing

accidents or loss, bounded rational behaviors are essential,

especially in the face of real-time systems and massive

DES likely to exhibit emergent or unintended behaviors.

It may be virtually impossible to distinguish physical from

system boundaries in a large-scale DES, making security a

big challenge. And, considering that networking of

embedded devices will greatly increase the number of

possible failure points, security analysis may prove even

more difficult.

Privacy and confidentiality policies will be exacerbated by

the pervasiveness and interconnectedness of DES. Users

will be monitored, and vast amounts of personal

information will be collected. Thus, implementing privacy

policies, such as acquiring consent in a meaningful fashion

in large scale networks, will be very difficult.

Related to all of the above, embedded systems must be

usable by individuals who have little or no formal training.

Unfortunately, usability and safety often conflict, so trade-

offs will need to be made. Understanding the mental

models people use of the systems with which they interact

is a good way for designers to start addressing issues of

usability and manageability of embedded systems.

8. Computational Models

New models of computation are needed to describe,

understand, construct, and reason about DES effectively.

Understanding how large aggregates of nodes can be

programmed to carry out their tasks in a distributed and

adaptive manner is a critical research area. Current

distributed-computing models, such as distributed objects

and distributed shared memory, do not fully address all of

the new requirements of DES. Furthermore, DES’s tight

coupling to the physical world, the heterogeneity of their

systems, the multitude of elements, plus timing and

resource constraints, among other things, demonstrate the

need for a much richer computing model. Such a model

will need to incorporate resource constraints, failures

(individual components may fail by shutting down to

conserve energy, for example), new data models, trust,

concurrency, and location.

For example, in a sensor network, subsystems from

different vendors should interoperate easily and be

integrated seamlessly into the rest of the IT infrastructure,

providing intuitive interfaces for remote and novice users.

Multiple, concurrent clients will be exercising different

functionalities of the system for different purposes, and

although resources may not be the most stringent

constraint for the system, it has to be self-monitoring and

aware of its resources. It must have a certain level of

autonomy to decide on the best use of available resources

to fulfill multiple users’ concurrent and uncoordinated

requests. The complexity of the computational model may

be further exacerbated by the multiple ways to obtain a

piece of information. So, the model would have to capture

information equivalency relations over the rich variety of

sensor data, which in turn would require semantic

information and services to process and reason about the

sensor data in ways that move beyond protocol agreement

and data-format conversion. To quantify the semantic

information contained in sensor data and to capture the

relations between various semantic entities such as objects

and events in the physical world, the model would need to

define an ontology for a variety of commonly encountered

sensor data and provide a set of semantic transformation

services to incrementally extract new semantic information

from lower level data. (This topic is of particular interest

to the author and the reader is referred to [5], [6], [7], and

[8].)

9. Enabling Technologies

The evolution of more and more sophisticated DES and

complex embedded-systems solutions is fueled by the

revolutionary advances in information technology during

the past several decades. Silicon scaling is the main

driving force, with exponentially increasing processor

performance enabling a world in which sophisticated chips

can be manufactured and embedded easily and cheaply.

Continued improvements in the price and performance of

chip technology are expected for at least the next decade.

Still, new developments are needed in specific aspects of

communications, geo-location, software, and operating

systems.

As wireless (and wired) technologies continue to become

less expensive and more sophisticated, the vision of

pervasive, connecting, embedded processors becomes

increasingly feasible. However, most of the progress to

date in wireless technology has focused on medium- to

long-range communications (as in cellular phones and

pagers) and is not sufficient for the widespread

deployment of DES. Work is needed to understand how to

create network architectures and designs for low-power,

short-range wireless systems. Related to wireless are the

issues surrounding geo-location technology. Unlike

36


2 January

conventional computer networks, which are more

dependent on the relative positioning of elements in a

network topology, DES are often inextricably tied to the

physical world (a primary purpose often being to measure

and control physical-world attributes or objects), so

location in physical space is more important. DES will

therefore require ready access to absolute or relative

geographic information, especially for sensor networks

responsible for physical sensing and actuation.

Attention must also be given to the responsible and

effective integration of sensor devices into DES, which

will have impacts on the design of network-aware

embedded operating systems, application development,

and software tooling that has the characteristics required to

tailor solutions to the physical constraints, afford in-place

deployment, be upgradable, have high availability, and the

ability to migrate to new hardware. Since DES will be

embedded in long-lived structures, they will have to

evolve, depending on changing external conditions and

advances in technology as time passes. Thus, operating

systems and applications that can cope with this type of

evolution will be critical. Furthermore, real-time operation

and performance-critical constraints on multiple embedded

applications running concurrently on the same device will

create a demand for entirely new methods of software

development and systems architectures.

Figure 1 is a chart of the technical imperatives for DES

development and research discussed in the previous

paragraphs. Additional issues present in this field are given

in summary form and serve to highlight the significant

differences from traditional distributed-systems

development.

Figure 1. Technical imperatives for distributed embedded-systems

development and research

9.1 Further Issues and Needs

1. Predictability and manageability—Covers

methodologies and mechanisms for designing

predictable, safe, reliable, manageable distributed

embedded systems.

2. Monitoring and system health—Refers to a

complete conceptual framework to help achieve

robust operation through self-monitoring,

continuous self-testing, and reporting of system

health in the face of extreme constraints on nodes

and elements of the system.

3. Network topology and geometry—Represent

modeling techniques to support and incorporate

network geometry (as opposed to just network

topology) into DES.

4. Component systems and communications

interoperability—Is about the techniques and

design methods for constructing long-lived,

heterogeneous systems that evolve over time and

space while remaining interoperable.

5. Integration of technical, social, ethical, and

public-policy issues—Is predominantly about the

fundamental research required to address

nontechnical issues of embedded systems,

especially those having to do with the ethical and

public-policy issues surrounding privacy,

security, reliability, usability, and safety.

10. Development

To understand the nature of embedded-systems

development complexity, you should also understand the

typical embedded-device value chain. This consists of

links between various industry players that comprise

silicon vendors (SVs), embedded OS vendors, independent

hardware vendors (IHVs), device makers (original

equipment developer (OED) and original equipment or

design manufacturer (OEM/ODM)), distributors, and end

customers (businesses or consumers).

In Figure 2, you see that the embedded-device value chain

consists of three to seven links between SVs, OEDs,

OEMs, and end customers. Depending on the device

maker’s supply chain and market, it may also consist of

third-party software providers, IHVs, ODMs, and various

distribution intermediaries.

37


2 January

Figure 2. Embedded-device value chain

When developing traditional business applications and

systems, “devices” are standardized and readily available

off-the-shelf computers, making a significant part of their

value chain quite irrelevant to the development process.

However, in embedded-systems design and development,

a similar level of maturity or commoditization, if you like,

of “devices” has not yet been achieved in the industry. As

a result, development tool chains, processes, and

methodologies are often proprietary and established for a

specific goal. The vast majority of the industry in

embedded development is using open-source software and

custom development tools provided by the hardware

vendors (SV, IHV) and open source communities. Time

scales for the development of hardware and software at all

levels in the device value chain can therefore be long as it

requires proprietary or scarce skills and knowledge to put

solutions together. In some cases, where DES and real-

time scenarios are involved, especially in safety-critical

situations, these time scales can easily span a decade.

There are interesting offerings from the large operating

systems and software tools vendors such as Microsoft that

hold the promise of providing a more productive and

“traditional” development experience for embedded-

systems professionals (including academics and hobbyists)

in many key solution scenarios. The hope is that

eventually tool chains along the entire device value chain

will become mostly standardized and interoperable

enabling the embedded-systems industry to scale

development as seen in traditional software development.

Figure 3 shows some aspects of the embedded-systems

development life cycle—which is strongly tied to the

device value chain—and the Microsoft platform

technologies that may be applied through the life cycle.

Figure 3. Embedded-systems development life cycle and Microsoft

technologies

Because embedded devices contain both hardware and

software components understanding the interactions

between them are essential. Key skills in this area span

electrical engineering and computer science; they also

address the interrelationships among processor

architectures, performance optimization, operating

systems, virtual memory, concurrency, task scheduling,

and synchronization. Developers should have a breadth of

exposure to appreciate the utility of other fields in

embedded systems, such as digital signal processing and

feedback control. Finally, as embedded systems are not

general operating systems, developers should understand

the tight coupling between embedded applications and the

hardware platforms that host them.

11. Conclusion

This paper introduces you to the rich field of distributed

embedded systems. It is geared towards architects and

developers of traditional distributed systems and therefore

takes a broad perspective on the task of describing DES.

Several references at the end may assist readers in

exploring this subject in greater depth. Distributed systems

design approaches and their characteristics will influence

DES design and implementation, but there are significant

differences that have been described in this paper. The

way we conceive and program these systems is bound to

become easier. It has to, because smart, connected,

service-oriented embedded systems will permeate our

factories, hospitals, transportation systems, entertainment,

and personal spaces, and thus become essential to our

38


2 January

daily lives. In many ways, DES is the computing model

for the future, and the mainstream of the IT industry will

need to learn how to design, build, and operate these

systems well.

References

[1] Dan Nessett. Massively Distributed Systems: Design Issues

and Challenges. USENIX Workshop on Embedded System,

1999.

[2] FAST Report. Study of Worldwide Trends and R&D

Programmes in Embedded Systems. 2005.

[3] Siegemund F., Haroon M., Ansari J., Mahonen P., Senslets.

Applets for the Sensor Internet. Wireless Communications and

Networking Conference, 2008.

[4] National Research Council, Committee on Networked

Systems of Embedded Computers. Embedded, Everywhere: A

Research Agenda for Networked Systems of Embedded

Computers. National Academy Press, Washington, D.C., 2001.

[5] Jie Liu and Feng Zhao. “Towards Semantic Services for

Sensor-Rich Information Systems.” 2nd International Conference

on Broadband Networks, 2005.

[6] Jie Liu, Eker, J., Janneck, J.W., Xiaojun Liu, Lee, E.A.

“Actor-Oriented Control System Design: A Responsible

Framework Perspective.” IEEE Transactions on Control Systems

Technology, 12(2), March 2004.

[7] Schmidt D. C., Gokhale A., Schantz R. E., and Loyall, J. P.

Middleware R&D Challenges for Distributed Real-Time and

Embedded Systems. ACM SIGBED Review, 1 (1), 2004.

[8] Gul A. Agha, Ian A. Mason, Scott F. Smith, and Carolyn l.

Talcott. A Foundation for Actor Computation. J. Functional

Programming, 7 (1), 1997.

Arvindra Sehmi holds a Ph.D. in bio-medical engineering from the

University of Leicester, an MBA from the Open Business School,

and a Bachelor of Science degree from the University of Sussex.

39


2 January

Evaluating Application Architecture, Quantitatively

V. Gnanasekaran

Collabera, Bangalore, India

Abstract

This article describes how quantitative treatment can be applied

to an application’s architecture-evaluation process and shows

how a quantitative output with intuitive reports will provide

more clarity than a qualitative output on the quality of an

application architecture.

“You cannot control what you cannot measure.”—BILL

HEWITT

Keywords: quantitative treatment, architecture-evaluation, application architecture

1. Introduction

Evaluation of an application architecture is an important

step in any architecture-definition process. Its level of

significance varies from organization to organization,

based on a variety of factors (such as application size and

business criticality). In some IT organizations, it is a part

of a formal process; in others, it is performed only upon

special requests that stakeholders might raise. Enterprises

sometimes have a dedicated “Architectural Review

Board” (or ARB) that is made up of a team of experienced

architects who are earmarked for performing periodic

architectural evaluations.

Scenarios that drive the architecture-evaluation process

include:

When a business must validate an application

architecture to see whether it can support new

business models.

An expansion to new geographies and regions—

resulting in the need to check whether an

existing application architecture can scale to new

levels.

Impaired application performance and user

concerns that lead to an assessment, to see

whether it can be reengineered with minimal

effort to ensure optimum performance.

Stakeholders having to ensure that a proposed

application architecture will meet all technical

and business goals—ensuring that key

architectural decisions were made with key use

cases/ architectural scenarios in mind and will

meet the nonfunctional requirements of the

application.

In the context of the new application development, the

key objectives of carrying out an architecture-evaluation

process are:

Avoiding costly redevelopment later in the

software-development life-cycle (SDLC) process

by detecting and correcting architectural flaws

earlier.

Eliminating surprises and last-minute rework

that is due to the suboptimal usage of technology

options that are provided by platform vendors

such as Microsoft.

Architectural reviews are also performed based on only a

particular quality-of-service attribute—such as

“Performance” or “Security”—for example, how secure

the architecture is, whether an architecture has the

potential to support a certain number of transactions per

second, or whether an architecture will support such a

specified time.

The application architectural-evaluation process involves

a preliminary review, based on a checklist that is provided

by the platform vendor and subsequent presentations,

debates, brainstorming sessions, and whiteboard


2 January

40

discussions among the architects. Key aspects of

brainstorming sessions also include the outputs of the

scenario-based evaluation exercises that are performed by

using industry-standard methods such as the Architecture

Trade-Off Analysis Method (ATAM), Software

Architecture Analysis Method (SAAM), and Architecture

Reviews for Intermediate Designs (ARID). There are also

different methods that are available in the industry to

assess the architectures, based exclusively on factors such

as cost, modifiability, and interoperability.

The checklist that is provided by a platform vendor

ensures the adoption of the right architectural patterns

and appropriate design patterns. With its patterns &

practices initiative, Microsoft provides a set of

checklists/questionnaires across various crosscutting

concerns for the evaluation of application architectures

that are built on Microsoft’s platform and products. An

architecture-evaluation process usually results in an

evaluation report that contains qualitative statements such

as, “The application has too many layers” or “The

application cannot be scaled out, because the layers are

tightly coupled.”

Instead of having qualitative statements, if the evaluation

process ends up providing some metrics—such as a

kidney-diagnosis process that ends with a “kidney

number” or a lipid-profile analysis that ends with

numerical figures for HDL and LDL—it will be easier for

stakeholders to get a clear picture of the quality of the

architecture.

This article outlines a framework for applying

quantitative treatment to the architecture-evaluation

process that results in more intuitive and quantitative

output. This output will throw more light on areas of the

application architecture that need refactoring or

reengineering and will be more useful for further

discussions and strategic decision making.

2. Background

Evaluation of an application architecture is equal to

evaluation of the different architectural decisions that are

taken as part of the definition of that application

architecture. The objectives of architectural decisions can

be viewed from multiple perspectives.

An architectural decision is taken for any of the objectives

that are explained in the following list:

To adopt a best practice that suits a specific

context—Take, for example, a banking

application that has been architected for Internet

customers. In that context, to protect the

application from hackers and malicious users, it

is a best practice to keep the presentation layer in

a separate tier in a DMZ, the business-logic layer

in a separate tier, and the DB layer in another

separate tier. An architectural decision to

distribute multiple layers across different tiers is

the adoption of this best practice.

To achieve a particular business goal—Say

that a publishing company has a business goal of

increasing its sales volume by having an online

order-acceptance facility, to allow customers

worldwide to place an order. In this case, to

achieve the business goal, the system should be

built to make it highly available through an

architectural decision of having a distributed

architecture.

To achieve a desired level of a particular

quality-of-service attribute—In some scenarios,

stakeholders might directly demand “Reliability”

for a mission-critical application. In such cases,

an architectural decision might be taken to have

message queues and asynchronous

communications as part of the architecture, so as

to achieve a desired level in the “Reliability”

quality-of-service attribute.

When an architecture decision is taken either to achieve a

business goal or to adopt a best practice, it is implicit that

it might have an impact on one or more quality-of-service

attributes. In typical scenarios, the key quality-of-service

attributes that will be in focus are “Scalability,”

“Security,” “High availability,” “Reliability,” and

“Performance”—also known as SHARP qualities.


2 January

41

Microsoft’s patterns & practices resources that are

specific to application architecture provide

checklists/questions across these quality-of-service

attributes and span multiple subcategories. These

questions make the evaluation process simpler. Because

these questions are the result of the collective experience

of various experts from Microsoft, the performance of an

architectural review that is based on these questions will

definitely ensure that our application architecture is based

on proven best practices, as well as architectural and

design principles and standards.

While these review checklists/questions make our life

easier, architects have to put effort into using them when

they perform an application-architecture evaluation.

Architects have to take printouts of these

checklists/questions and conduct interview sessions with

respective application architects, based on these

checklists. Then, they have to perform some manual

analysis/due-diligence process and arrive at an output.

Like medical reports that have clearly defined metrics that

all doctors understand, if we want to have a clear

quantitative output for an architecture-evaluation process,

this will not be possible unless we have a framework that

will help architects apply a quantitative treatment that is

based on the checklists and generate outputs that will help

architects and stakeholders immediately get a sense of the

state of an application architecture.

Given this background, this article will outline a simple

framework that can be used to carry out an architecture-

evaluation process, based on the perspectives of adopting

best practices and achieving a desired level in quality-of-

service attributes.

3. Approach

There are two types of quality-of-service attributes: those

that result in the runtime behavior of the system (such as

“Performance,” “Security,” and “Scalability”—also

known as runtime qualities), and those that can be

evaluated only over the life cycle of an application (such

as “Maintainability” and “Flexibility”—also known as

design qualities). Usually, architectural evaluations focus

more on runtime- quality attributes. The significance of

the quality-of-service attributes that are considered for the

architectural evaluation will vary, based on the context.

For example, in line-of-business (LOB) applications,

performance and scalability will gain more importance,

while interoperability will become more important in

heterogeneous environments.

The questions that are available from the Microsoft

patterns & practices resources are the key input for this

framework. They are elaborate and exhaustive, and they

include questions that pertain to crosscutting concerns

and platform-specific issues. These questions can be

tweaked, so that the resulting repository can be used only

for architectural evaluation. In the scenarios in which

there is a need to evaluate application architectures in a

heterogeneous environment, some platform-specific

questions can be selectively dropped or replaced.

In fact, the questions and checklists that are available

from the patterns & practices resources also include

things that are applicable in technology-agnostic

scenarios.

More categories and subcategories of questions can be

added to the existing set, based on your experience; the

greater the number of quality-of-service attributes that are

covered by the repository, the wider the variety of

applications on which evaluations can be performed. In

the age of rich Internet applications (RIAs) and mashups,

“Usability” is also gaining high importance on par with

other key quality-of-service attributes. Figure 1 illustrates

the quantification framework.


2 January

42

Figure 1. Quantification framework for architecture-evaluation process

The resulting repository will be a set of checklists that are

based on the required quality-of-service attributes. These

checklists can be used by reviewing architects to question

the respective application architects. Also, answers for

these checklists/questions can be extracted from

documents such as a system-architecture definition and a

solution-architecture definition. For every positive

answer, a value of 1 can be assigned to each question, and

a value of 0 can be assigned to a negative response.

After the completion of this probing process, and based on

the number of positive responses, scores will be computed

for all the quality-of-service attributes that are considered

for evaluation. These scores are the summation of the

scores that are available for each subcategory. The scores

at the subcategory level are the summation of the ones

that are allotted to each item/question in the checklist, as

a positive response. Say, for example, that under the

“Performance” attribute, we might have subcategories

such as caching, data access, state management, resource

management, and concurrency. Then, the result will be as

shown in Table 1.

Table 1. Score for “Performance” quality-of-service attribute

Based on the actual number of questions that are available

in the repository in each subcategory under the

“Performance” attribute, we can arrive at a percentage

that is scored against the “Performance” attribute for the

application that is under review.

The same method can also be applied to arrive at

percentage scores for other required quality-of-service

attributes.

Now, you might think that the average of the scores

across the different quality-of-service attributes will give

an overall score that indicates the quality of an

application architecture. However, that might not be the

actual case.

Let us see why.

4. Architectural Trade-Offs

An application cannot score 100 percent across all

quality-of-service attributes. Architectural definition is the

result of the trade-off decisions that are taken across

various quality-of-service attributes. These trade-offs are

arrived at, based on the architecturally significant

scenarios and nature of the business domain for which the

application is developed. Also, one quality-of-service

attribute can have either a positive or negative impact on

other quality-of-service attributes.


2 January

43

Table 2. Mutual impact of quality-of-service attributes

Table 2 provides an idea on the mutual impact that exists

across different quality-of-service attributes. Because of an

architectural decision to achieve a desired level in a

particular quality-of-service attribute, another quality-of-

service attribute could be adversely affected.

For example, in a banking application, security is

considered to be more important than performance. The

“Security” quality-of-service attribute will have a negative

impact on the “Performance” quality-of-service attribute.

So, any architectural decision to achieve a high degree of

security will affect the performance of said application.

This is a known trade-off decision that is intentionally

taken; hence, the application that is under evaluation will

score less under the “Performance” quality-of-service

attribute.

To accommodate the trade-off decisions without affecting

the final score and resulting in a misguided outcome, we

have the concept of the prioritization of quality-of service

attributes. No application can have two mutually exclusive

quality-of-service attributes at the same level of priority.

For example, an application cannot have both

“Performance” and “Security” as equal priorities. If

“Performance” is the top priority for an application,

“Security” automatically assumes a position in the next-

available priority levels. If the evaluation of an

application architecture is based on the SHARP quality-

of-service attributes, and if the application is architected

for a domain in which “Performance” is most critical and

other attributes are of lower priority, the reviewing

architect might assign priority numbers, as shown in

Table 3.

Table 3. Prioritization of quality-of-service attributes

Prioritization should be based on the business goals and

input from stakeholders. It can also be achieved through

the ATAM method. Use of ATAM ensures that business

goals and stakeholder interests are taken into

consideration. As a rule of thumb, the highest priority

number should not exceed the number of quality-of-

service attributes that is considered for the architectural

evaluation. Also, no two quality-of-service attributes

should have the same priority number.

Table 4. Threshold numbers for quality-of-service attributes

As shown in Table 4, an architect can also assign

threshold numbers against each quality-of-service

attribute to indicate whether an application architecture

scores below that number; before proceeding to the next

stage, it is important to revisit the decisions under that

quality-of-service attribute. These threshold numbers are

subjective and should be based on a consensus that is

agreed upon by a team of architects in the enterprise-

architecture group.


2 January

44

If an application scores below the threshold values, it is a

clear indication of the level at which the application

architecture is below the mark.

This will also be especially helpful in mergers and

acquisitions (M&As). Say that when Company A acquires

Company B and carries out an assessment process,

Company A might retire the applications that score well

below the threshold values.

5. Architecture Index

After consideration of the scores for all quality-of-service

attributes and prioritization of those attributes, the final

quality of the application architecture can be arrived at by

using the weighted-average formula, as shown in Table 5.

Table 5. Architecture index through weighted-average formula

This weighted-average formula will result in a single

number, which can be called the “Architecture index.”

Table 6 shows an architecture-index value that is based on

the application of the weighted-average formula to the

sample scores of different quality-of-service attributes,

and their respective priority numbers.

Table 6. Scores of quality-of-service attributes & corresponding architecture

index

The architecture index will be between 0 and 100. This

number gives an immediate sense of where that

application architecture stands. Because the resulting

number is based on the best practices and guidelines that

are provided by platform vendors, it will reflect how best

the application can be architected. For instance, an

evaluation that is performed based on the

checklists/questions that are provided by the Microsoft

patterns & practices and results in a lower architecture

index will indicate that the application architecture does

not adhere to the proven best practices.

Because a positive or negative response to a question

directly contributes to a score of a particular quality-of-

service attribute, we can easily identify the impact of a

particular architectural decision on a particular quality-of-

service attribute and, hence, the overall quality of the

application architecture.

6. Intuitive Reports

Although a single architecture index gives a clear view of

the strength or quality of an application architecture, it

must have some intuitive reports that highlight the weak

areas of an application architecture, so that they can be

used to carry out an effective reengineering or refactoring

process.

It makes sense to have a tool or to build small software to

automate the entire process and generate reports.

Microsoft Office Excel can perform wonders, with few

scripts and limited effort. For an application architect to

know immediately what went wrong (based on the

architecture index) and react immediately, these intuitive

reports play a significant role.

Figure 2, and Figures 3 and 4, show screen shots of some

of the reports that are generated by the tool and that

resulted in our past successful architectural-consulting

engagements.


2 January

45

Figure 2. Overall-architecture quality of application

Figure 3. Quality of application architecture from perspective of

“Performance”

Figure 4. Quality of application architecture from perspective of “Security”

Say, for example, after an evaluation process, that an

application architecture scores 49 percent. The

application architect can immediately identify under

which quality-of-service attribute it is scoring low. If it

scored low in “Performance,” the architect could go to the

performance-analysis report, which will show the scores

across different subcategories (such as caching and state

management). If it scored less under a particular

subcategory —for example, caching— the architect could

trace back from that point to see why the architecture

scored so many zeros under that subcategory. The

architect could also get a handle on how a particular

decision might affect a particular quality-of-service

attribute and, hence, the overall architecture.

In scenarios in which the existing application

architectures are evaluated, application architects can use

these reports in meetings with stakeholders to convey why

application architecture is considered inferior, as well as

to highlight areas that need refocus. This will drive

corrective actions that must be taken to revamp respective

applications.

7. Conclusions

A quantitative architecture-evaluation process provides a

crystal-clear picture of the quality of an application

architecture. The output of this process helps in taking

concrete, corrective decisions.

While the quantitative evaluation of application

architecture is more promising and results in a clearer

picture of the state of the architecture of existing

applications or the proposed architecture of new

applications that are to be built, it cannot replace an

application-architecture process that is based on a

scenario-based method such as ATAM. ATAM involves a

more elaborate exercise that is based on architecturally

significant scenarios and could be supplemented by a

quantitative evaluation. While the output of a method

such as ATAM is qualitative and based on scenario-based

analysis, this framework- based evaluation output is

quantitative and based on best practices and guidelines.

Let us go back to our inspiration: the “kidney number” or

lipid-profile analysis. That is the key driver behind the

conceptualization of this idea in applying a quantification

treatment to the architectural-evaluation process. They

have industry-standard benchmarks and ranges that are

used as the basis to classify a particular patient.

Similarly, if platform vendors, service organizations, and

enterprise IT teams work together to publish benchmark

architectural indexes for applications, based on various


2 January

46

factors—such as business domain, architectural style and

pattern, SLA requirements, and various combinations of

quality-of-service attributes—they can be leading lights

for building well-architected applications.

Acknowledgements

Special thanks to Bala Variyam, CTO, Chander

Damodaran, Senior Architect, and Sohail from Collabera

for their reviews.

Resources

[1] Morgan, Gabriel. “ Implementing System-Quality

Attributes.” Microsoft Developer Network (MSDN)

Architecture Center, March 2007.

[2] Turner, Michael S. V. Microsoft Solutions

Framework Essentials: Building Successful Technology

Solutions. Redmond, WA: Microsoft Press, 2006.

[3] Gorton, Ian. Essential Software Architecture. Berlin;

New York: Springer, 2006.

[4] Bass, Len, Paul Clements, and Rick Kazman.

Software Architecture in Practice. Second ed. Boston,

MA: Addison-Wesley, 2003.

[5] Malcolm, Graeme, and Lin Joyner. Application

Architecture for .NET: Designing Applications and

Services. Microsoft patterns & practices Series.

Redmond, WA: Microsoft Corp., 2002.

[6] Meier, J.D., et al. Improving .NET Application

Performance and Scalability. Microsoft patterns &

practices Series. Redmond, WA: Microsoft Corp., 2004.

[7] Microsoft patterns & practices Team. Microsoft

Application Architecture Guide. Second ed. Microsoft

patterns & practices Series. Redmond, WA: Microsoft

Press, 2009.

[8] Esposito, Dino, and Andrea Saltarello. Microsoft

.NET: Architecting Applications for the Enterprise.

Redmond, WA: Microsoft Press, 2009.

V. Gnanasekaran is a Senior Architect at Collabera in Bangalore,

India. His areas of specialization include SOA/BPM, Integration, and

Enterprise Architecture. He spends most of his time on Solution

Architecture consulting, R&Ds on the latest technologies, and

technology evangelism. Currently, he is focusing more on Cloud

Computing and Enterprise Mobility.


2 January

47

http://www.collabera.com/

Software Architecture in the Agile Life Cycle

Diego Fontdevila1, Martín Salías2

1M.Sc. Software Engineering Management, Carnegie Mellon University, United States

2Senior Architect at Southworks, United States

Abstract This article proposes a set of techniques and practices to leverage the agile approach to software architecture—increasing overall quality, streamlining development practices, and providing business value as a constant flow. The article describes issues that are related to component API design and behavior-driven design, continuous measurement of complexity, automated quality-attribute evaluation, and design rationale recording. The reader should take away from the article several techniques to research and try, a basic development life cycle, and some leads for further investigation Keywords:

1. Introduction

Even while agile methodologies are getting widely accepted in the development world, there is still a lot of debate about how to apply them to the architectural space. One of the most conflictive issues stems around “big design upfront,” which is strongly discouraged by agile practitioners, and the traditional approach to architectural design. This article proposes a set of team dynamics, conceptual practices, and specific technologies to embed software architecture within the agile approach—keeping up the shared goals of technical excellence, streamlined development practices, and a constant and ever-increasing flow of business. It is the hope of the authors that readers can later compare our experiences with their own and provide further discussion, so as to keep improving our professional corpus.

2. Architectural Dynamics in Agile Teams

One of the 12 principles of the Agile Manifesto states that “the best architectures, requirements, and designs emerge from self-organizing teams.” [1] We take this to heart—especially, the reference to our shared specialization.

While architecture is an activity that is historically performed with an emphasis on the early stages of a project, the main focus of agile development is on emergent design and iterative production— creating a series of interesting challenges down the road. First of all, agile makes a big push toward shared responsibility and, thus, dilutes the traditional role of the architect as the one who “defines” the higher-level design of a solution. In this new approach, architecture (as most other development activities) is something that is performed by the whole team—preserving its multidisciplinary nature. This does not imply that the architect profile goes away, as with all the other roles; it means that while someone contributes with a broader and probably more experienced perspective (usually leading in this aspect), the whole team participates and understands the implications of the design decisions that it makes, and continuously evaluates them. In our experience, key considerations—such as the modularity strategy, how communication is handled within and outside the application, and how data and services are accessed and abstracted—are successfully defined and implemented when the whole development team establishes a consensus about these issues. In this way, team members fully understand the consequences of the selected alternatives, remain aware of their initial assumptions thorough the solution life cycle, and quickly raise concerns when their validity is affected. Most of these challenges are usually tackled by folding architectural discussion and revision into the regular meetings that take place over the course of an iteration—such as planning and review meetings, and frequent sync-ups and design meetings with plenty of white boarding and open talk. It is also worthwhile to have the most important guidelines permanently exposed in an informative space, including diagrams, checklists or reference charts around the walls and semi permanent flip charts that are used as posters.

48


2 January

Agile approach to software architecture

This article does not cover in detail specific techniques that apply to coordinating several sub teams; mainly, it mirrors the standard guidelines about the “Scrum of Scrums”[2]. The addition to such activities is a stronger focus on the preservation of conceptual integrity—thus, planning frequent high-level design meetings between teams. Again, these meetings should avoid becoming architect meetings; while the contribution of team members who have a stronger architectural background is obviously important, it is very important for other members to participate. Even the less experienced team members can provide a somewhat naïve perspective to some discussion—promptly flagging complexity excesses that are a professional malady among us architects. To close on the team dynamics, as the agile perspective goes over the standard view of the development team and extends to customers, operations personnel, and other stakeholders, expectation management is a big deal also for the solution architecture. As the next section shows, there is a strong emphasis on mapping the needs and goals of these actors to the architectural constraints and converting the most important into strong metrics to be evaluated.

3. Agile Architecture Patterns and Practices

There are several common approaches to support the previously described dynamics and keep the agile principles of high customer involvement and feedback, continuous delivery of working software, and attention to technical quality, among others.

3.1 Sashimi

There are several common approaches to support the previously described dynamics and keep the agile principles of high customer involvement and feedback, continuous delivery of working software, and attention to technical quality, among others. One of the most common patterns that we use to avoid the perils of big design up front is the “sashimi” approach to the architectural definition. In this approach, instead of spending a lot of time designing and implementing the different moving parts around layers and tiers, crosscutting concerns, and so on, we build the minimal amount of code that is needed to connect all of the pieces and start building the actual functionality on top—providing an early end-to-end experience of the results. Indeed, the focus is more on the API level of the infrastructure, and not the actual implementation, which is usually mocked up for the first little iteration. The main purpose is to avoid building architecture components that are hard to use or tying the business logic and other high-level abstractions to the underlying

implementation. As iterations progress, the actual implementation is incrementally completed, following the needs of the functional part of the application. At some point, such things as load or stress testing that is performed over the functional side of the solution will even require fine-tuning of these components for robustness, increased performance, resource consumption, and so on. To be able to support this emergent implementation over architectural pieces, definition of a highly decoupled API is the most critical factor. Whenever implementation details permeate outside the API—hence, coupling with its consumers—refactoring the architectural components becomes a nightmare. That is why API design becomes a key activity in the earlier stages, and why starting with no implementation at all is a better approach. This practice applies even when using third-party components, which is both common and generally advisable, for the most part. In such cases, existing default implementations for those third-party components provide early support modules; and, many times, configuration is needed instead of coding in the early stages.

Iteration 1 2 3 5 10

15

UI layer Home, with login

Custom areas

User contacts

… … …

Business layer

None, really

Layout validation

Social graph

… … …

Data layer

User name Profile Social data

… … …

Crosscutting concerns

Authentication (mocked)

Authentication (basic)

Logging (mocked)

Table1. Example of how actual functionality and architecture grow iteratively on common three-tiered Web application. Note how the load time for the home page (a very important metric, in this case) is measured since the first iteration.

Table 1 shows an example of how this works in practice, as iterations go by. Note that at the end of the first iteration, the application goes throughout all of the proposed layers, and how the most important nonfunctional requirement (home-page response time) starts to be under control from then on, across the whole project. Of course, this first test can be done with a single concurrent user, and it measures mainly static content; but the thresholds will be in place as back-end generation goes, and testing will involve many concurrent

49


2 January

connections in future iterations. However, no one can change functionality or infrastructure and affect response time without being noticed immediately, then reducing the fixing effort.

3.2 Architectural Patterns

Another common practice in the agile development of software architecture is the concentric approach, in which the starting point is a high-level technical vision of the solution, which the team can shape collaboratively, as previously described. This technical vision will provide the conceptual baseline that will serve as both a reference point to focus future work and a sanity check for refactoring (more on this later, when conceptual integrity is discussed). The second level is the module decomposition, which consists of a set of modules with services that provide actual value to users or other modules and allow for a coherent separation of responsibility. These modules work as placeholders to which specific functionality can be added incrementally through the design and construction process. This decomposition provides a high-level grouping of components that make the design more manageable for both architects and other stakeholders, and the modules work sometimes as namespaces to help identify stakeholder concerns. The third level is a decomposition that is usually described in terms of architectural styles or patterns—layers and tiers, in particular— for enterprise or business-information applications. At this level, the usually most significant definitions are thelayers, which are varying levels of abstraction, in terms of user-level value (in this case, the lower level of abstraction is what the end user knows the least)—in particular their API, as previously described—and tiers, which describe a structure for separating responsibilities according to their volatility and allowing for distribution. This level is the first that has well-defined interfaces and is usually considered good for work allocation among teams. That kind of allocation must be handled carefully to avoid architectural mismatch between the parts, as well as to keep from losing the advantages of collaboration to the hard separation of work pieces [3]. The fourth level is that of components, which are packaged pieces of software whose very specific responsibilities are defined by their interfaces and, possibly, with multiple implementations that can be selected dynamically. These are usually the highest-level pieces that software-development platforms recognize conceptually (in other words, those that are seen by the platform, which, in terms of syntax, means that the platform has the terms that correspond to that component or component type). At this point, our agile teams start to gain the capacity to use directly the language that they share with their users in the software that they produce.

The fifth level is the class level—finally, the object-oriented level of decomposition. At this level, programming languages are at their best, and developers can fully use the language that they share with the stakeholders in the software that they write (programming-language code and software configuration). Figure 1 illustrates a quick review of the concentric approach.

Figure 1. Concentric approach, which starts with overall vision and keeps growing as we get closer to final implementation. (All levels are refactored over time but kept in sync, although the inner levels usually stabilize faster.) (Click on the picture for a larger image)

Note also that we can use to our advantage domain-specific languages [4] providing a higher-level abstraction to how components orchestrate between them at the fourth level, or getting the domain closer to the object modeling at the fifth level. This latter approach can be leveraged by using an external DSL or an internal one, which often can be built by following domain-driven design [5]. All of these levels (which, in architecture literature, are also called structures [6]) can also be considered independently, according to the specific needs and scope of each project.

3.3 Quality Attributes and Architecture

One of the most common discussions about architecture is about what aspects of a system’s design are architectural in nature. In particular, quality-attribute-related requirements are most often determined by the architecture. From an agile perspective, it is very important to keep in mind that quality-attribute requirements must be managed as part of the product backlog and implemented incrementally. Specifically, that means managing the prioritization of a heterogeneous mix of requirements, both features and quality-attribute requirements. Another aspect of interest is the fact that multiple quality attributes tend to require trade-off analysis and decisions, where standard prioritization might not be enough.

50


2 January

http://msdn.microsoft.com/en-us/architecture/ff476940.a3f1(l=en-us).png

To manage quality-attribute requirements effectively, the authors recommend considering the quality attribute as a user goal, with specific requirements built into user stories that support that goal. The stories must have measurable acceptance criteria defined clearly, so that tests can be written for the components that are implemented. Examples of these requirements (with metrics in parentheses) areflexibility(complexity, dependencies, coupling, layering), performance (response time, resource usage), and scalability (load and response time). These metrics should be integrated with the continuous build process, as the next section will show.

3.4 Architecture Validation

To finish this section, the authors present the key practices for testing and validation that are related to architecture. From our perspective, these are test-driven development, automated integration testing, automated quality-attribute requirements testing, automated deployment, environment-configuration management, and application-configuration management. As described in the first part of this section, the authors believe in the early definition of interfaces. These definitions, wherever possible, must be created in terms of executable unit tests (or supported in some other way by the language or testing harness, such as language-syntax pre- and post-condition specifications [7] .Not only will these specifications be the safeguards in place for local and multi component refactoring, but they will also provide the entry point for finding defects when an incident is reported. The idea is that any incident that is reported will require finding the applicable test, so that if it is not there, it can be created; otherwise, it must be modified to catch the defect, and then the implementation can be corrected. It must be kept in mind that many architecturally significant changes will escape notice by unit tests. To manage changes that exceed the unit-test contracts, automated tests are required for integration and quality attributes. The latter tend to be harder to create, but they pay off when quality-attribute requirements that are hard to implement are affected. These tests usually need to be scheduled with lower frequency than unit tests, depending on their resource usage. Examples of these are: Scalability. Acceptable response times when system load is increased to a certain level. Implementation of such tests requires not only tool support, but also careful capacity planning for the testing environment—both client side and server side, when applicable—and automated deployment to the testing environment. Flexibility. Instantiation of the layers pattern. Implementation of supporting tests includes dependency metrics matching the structure of the pattern

implementation. As described in the following section on model base evaluation, it requires the configuration of tests to accept upper-layer to adjacent lower-layer dependency, and not the reverse. For all of this to be possible, it is necessary to manage configuration in two levels: environment-dependent and environment-independent. Managing environment-dependent configuration will enable automated deployment, and will focus on physical and logical resource configuration. For the rest of the configuration, the issue will be defining variability of available functionality (usually, dependent on the customer). The next section discusses the use of available technologies for the implementation of these practices.

4. Specific Techniques and Technologies

To implement reasonably the techniques that the previous section described, it is necessary to use appropriate tools and technologies, not only because of the expense that is incurred, but also to provide the necessary discipline through automation. As the agile mindset stated in its manifesto, individuals and interactions are more important than processes and tools; from there, however, the agile world has derived a helpful set of tools that take tedious manual tasks away from people and make them easy to execute fast and frequently—providing a lot of feedback upon which individuals can act. For our architectural quest, the authors follow the same principles and basic ideas and extend them to cover the concepts that have been discussed. The first level of technologies that are used can comprise regular testing tools and frameworks, such as unit-testing tools—from the traditional xUnit (such as jUnit, NUnit, cppUnit, and MS Test) to the ones that come from behavior-driven development [8] (such as RSpec, xUnit.net, JBehave, and Cucumber, among others). Included also are user-acceptance or functional testing tools (such as Fit/Fitnesse, Selenium, and Watir, among others) and a host of technologies that are needed for performance and stress testing. All of these, of course, run at an individual level, as well as on the build server, and with different frequencies (unit tests in every check-in, functional a few times a day, load and stress usually over the night, and so on). In short, we build up from the basics of the appropriate development practices—adding some specific test at the unit, acceptance, or stress level to validate some architectural concerns. To this standard tooling, a second level is added—with more specific checks over quality attributes, such as lines of code per class/module, code-coverage statistics, static analysis, style analysis, cyclomatic complexity, afferent and efferent coupling, dependencies, and more. Some of the tools that are used in this space are (for .NET) FXCop, StyleCop, NDepend, and

51


2 January

built-in tools in Microsoft Visual Studio Team System; and (for Java) FindBugs, JDepend, Checkstyle, Lattix, and built-in features on IntelliJ IDEA. Within the realm of dynamic languages such as Ruby, JavaScript, and Python, this is a less developed area, because of the inherent difficulty of performing static analysis on them. However, there is strong evidence that shows that as the runtime engines are going increasingly the way of just-in-time compilers, this gap will be filled soon. Then, there is a third level of metrics about flexibility and maintainability that has to do with the project life cycle itself— metrics such as code-churn, volatility, correlations, and adherence to the architectural models. In this space, Visual Studio Team System is making great strides, while there are many people who implement part of this by using build-tool plug-ins or custom scripts that crunch data and produce reports or alarms, based on data that comes from the source repository, build server, issue tracker, testing environments, and modeling tools. Indeed, to be able to perform validation against an architectural model, such a model has to be in place. To do so, we can pick among myriad tools—from Enterprise Architect (or some of the Rational suite of tools) to Visual Studio Team System. What is important here is to take the time to automate the process to extract the relevant metadata that is needed to validate the code, references between packages or services, or module composition. Additionally, it is very important to distinguish the code or module view of the system from the runtime view of the system during evaluation. Runtime characteristics are usually harder to perceive, but their high implementation costs make early analysis and testing worthwhile. Finally, it is very useful to learn also how to perform some level of reverse-engineering—allowing to grab some information from the actual implementation into the model, and automating part of the documentation chores. The final step of this methodology involves the deployment and configuration of the different staging environments, in which virtualization becomes an incredible enabler—allowing for quick turn-on and turn-off of all the needed environments (with baseline configuration), where we can use remote scripting to perform the deployment of the latest build and configuration to any of these environments, and then perform all sorts of testing. The current power of virtualization platforms such as VMWare, Hyper-V, and others makes it really easy to manage multiple basic images—taking and reverting to snapshots, even across distributed physical machines. Of course, all of this is not something that the authors encourage anyone to try setting up from day one. Instead, you should increasingly add over each iteration, but have all of the appropriate (and project-relevant) techniques folded into the main plan, to ensure that these controls are getting into place as the project goes on.

5. Conclusions

The authors of this article believe that architectural considerations are fundamental for delivering value in most software projects—also, that agile teams have much to offer in terms of mechanics, techniques, and tools for the software-architecture community. These contributions are best considered in terms of the development of a language that is shared by all stakeholders and spans the spectrum from the user’s view of the system to the actual code. This language consists of the set of both user requirements and design decisions that are made during the life of the product. Its final purpose is to allow users and teams to create excellent results that will provide value, according to the expectations of stakeholders, throughout the lifetime of the product.

References [1] Fowler, Martin, et al. Manifesto for Agile Software

Development Web site, 2001. [2] Cohn, Mike. “ Advice on Conducting the Scrum of

Scrums Meetings.” Mountain Goat Software Web site, May 2007. (Originally published in Scrum Alliance Web site.)

[3] Austin, Robert D., and Lee Devin. Artful Making: What ManagersNeed to Know About How Artists Work. New York: Prentice Hall, 2003. (Page 144.)

[4] Martin Fowler is currently writing a whole book on DSL, but the work in progress is available athttp://martinfowler.com/dslwip/.

[5] Evans, Eric. Domain-Driven Design: Tackling Complexity in theHeart of Software. Boston: MA, Addison-Wesley, 2004.

[6] Bass, Len, Paul Clements, and Rick Kazman. Software Architecturein Practice. Second ed. Boston, MA: Addison-Wesley, 2003.

[7] Mandrioli, Dino, and Bertrand Meyer. Advances in Object-OrientedSoftware Engineering. New York: Prentice Hall, 1991. (Chapter 1, “Design by Contract.”)

[8] North, Dan. “Introducing BDD. ” http://dannorth.net/introducing -bdd. DanNorth.net Web site, September 20, 2006. (Originally published in Better Software Magazine Web site.)

Diego Fontdevila, Professional Services Director at Grupo

Esfera, specializes in software architecture and agile

methodologies. He has 13 years of experience as both software

developer and university teacher. Currently, Diego is a Master of

Software Engineering Management student at Carnegie Mellon

University.

Martín Salías, Senior Architect at Southworks, has more than 25

years in the software industry, working on different industries for

customers around the world, and covering many platforms and

languages. He is a member of the Agile Alliance and has been

awarded as a Microsoft MVP since 2002.

52


2 January

Advances in Computer Science: an International Journal - CiteSeerX

Documents

Transcript of Advances in Computer Science: an International Journal - CiteSeerX