Post on 21-Feb-2023
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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).
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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).
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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/.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
run Input p res k eng ml
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.
Table 2. Comparison of secure connectivity in proposed scheme
and scheme in [1] (State 2)
Original
run Input p res k eng ml
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
run Input p res k eng ml
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
2 January
27
Figure 3. Charts about results from Table 2
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.
Table 3. Comparison of secure connectivity in proposed scheme
and scheme in [1] (State 3)
Original
run Input p res k eng ml
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
run Input p res k eng ml
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
Figure 4. Charts about results from Table 3
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.
Figure 5. Charts about results from Table 4
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
2 January
28
Table 4. Comparison of security analysis in proposed scheme
and scheme in [1] (State 3)
Original
run Input p res k eng ml
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
run Input p res k eng ml
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
4.2.1 Challenges and Issues
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
4.3.1 Challenges and Issues
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.
4.4.1 Challenges and Issues
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
4.5.1 Challenges and Issues
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.
4.6.1 Challenges and Issues
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.
4.7.1 Challenges and Issues
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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.
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
2 January
47
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
2 January
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
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
ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 1, No. , 2013 www.ACSIJ.org
2 January