SOA PRACTICES AND PATTERNS APPLIED IN GLOBAL

SOFTWARE DEVELOPMENT

Marcelo Zilio Pereira, Jorge Luis Nicolas Audy, Rafael Prikladnicki

Faculdade de Informática, Pontifícia Universidade Católica do Rio Grande do Sul, Av. Ipiranga, Porto Alegre, Brazil

Mayara Figueiredo

Instituto de Ciências Exatas e Naturais, Universidade Federal do Pará, Belém, Brazil

Cleidson de Souza

IBM Research – Brazil, São Paulo, SP, Brazil

Keywords: Service oriented architecture, Design patterns, Practices, Framework, Distributed software development,

Global software development.

Abstract: Prior research has established a relationship between coordination of software development activities and

software architecture both in collocated and distributed projects. Despite the recognized importance of the

software architecture in the coordination of development activities, it is still unclear how software architects

design the architecture of software systems in distributed projects. To better understand this scenario, this

paper reports from a qualitative empirical study where we interviewed software architects to collect

information about the software architecture of distributed projects. Information collected has exposed the

wide adoption of Service Oriented Architectures (SOA), indicating a trend towards the usage of this low

coupling architectural style by companies developing projects with distributed teams. More detailed data

collected by follow-up interviews suggested a set of best practices for designing SOA architectures to

facilitate the work of the project members.

1 INTRODUCTION

Software Architecture (SA) is an important area

within Software Engineering as a transition between

the functional specification and coding. It represents

a mapping from the abstract concepts defined in the

specification to concrete concepts enabling the

software coding (Pressman, 200) (Sommerville,

2006).

Motivated by the growth of software development

companies with subsidiaries and offices worldwide,

researchers in the areas of Global (or distributed)

Software Development (GSD), and Computer

Supported Cooperative Work (CSCW) have

revisited the work of (Conway, 1968) that suggests

that software architecture is an important aspect

used in the coordination of collocated and

distributed software development activities.

Examples of research along these lines include

(Cataldo, 2009), (De Souza, 2004) and (Garlan,

2000).

(Herbsleb, 2007) argues that the need to manage a

variety of dependencies between distributed sites is

the essential problem of GSD. Additionally, to

achieve substantial progress in GSD is necessary to

deep the current understanding about the types of

coordination required in distributed projects and the

coordination principles adopted, aiming to reduce

the amount of communication. In other words, a

process should take distribution into account, or

even eliminate the incompatibilities in the process

through well-defined software architecture.

To design a SA, architects consider existing

architectural styles and their adherence to a

particular problem. These architectural styles are

286

Zilio Pereira M., Luis Nicolas Audy J., Prikladnicki R., Figueiredo M. and de Souza C..

SOA PRACTICES AND PATTERNS APPLIED IN GLOBAL SOFTWARE DEVELOPMENT.

DOI: 10.5220/0003507502860292

In Proceedings of the 13th International Conference on Enterprise Information Systems (ICEIS-2011), pages 286-292

ISBN: 978-989-8425-55-3

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

abstractions of how software should be structured to

solve a certain problem.

Interviews conducted with expert software architects

in software development companies involved in

distributed projects indicated that most of these

companies are designing their projects based on

Service Oriented Architectures (SOA) (Papazoglou,

2007). This led us to conduct additional interviews

to identify best practices and patterns adopted in that

SOA projects in order to propose a framework of

practices in SOA focused on development phase of

DSD projects.

This paper presents information gathered from those

interviews and proposes the development of SOA

practices and patterns aiming to facilitate the

coordination of activities and the reduction of

communication gaps in DSD projects. The next

Section presents related work, while Section 3

presents the methodology used to collect data.

Information about the research settings is presented

in Section 4. Finally, Section 5 presents our results,

and section 6 concludes the paper.

2 RELATED WORK

Empirical studies have focused on identifying how

the software architecture and coordination of tasks

related each other in a DSD environment. (Grinter,

1999) studied the system architects work and how

they have coordinated design across boundaries,

tools and processes used to support the work.

(Herbsleb and Grinter, 1999) have proposed to

observe problems of coordination in geographically

distributed projects with the aim of identifying the

types of unforeseen events that may cause

coordination problems.

(Ovaska, 2004) found examples of coordination

problems in software projects and tried to identify

categories of cases that explain the coordination

problems encountered. After that, they used these

categories to compare centralized and decentralized

development to finally have a list of requirements

for a development methodology that uses the

architecture to support coordination.

Recently, (Cataldo, Nambiar and Herbsleb,

2009) presented the initial results of a qualitative

study about the decisions that architects had to take

on the design on DSD projects. This study revealed

some design patterns that were used to solve the

problem both from a technical viewpoint as well as

an organizational viewpoint, suggesting there is a

relationship between the organizational structure and

SA designed.

3 METHODOLOGY

While the design of software architectures is a

practical problem to every company doing

distributed software development, we took the

opportunity to plan this work following a rigorous

research process The research question that has

guided this work is the following: “Which practices

in SOA could facilitate development in DSD

projects?” This research is an empirical study,

conducted through qualitative data collection and

analysis to identify the strategies adopted by

software architects to design software architectures.

These architects are from software development

companies, an aspect considered of relative

importance in the field of DSD (Herbsleb, 2001).

This empirical study is intended to enable,

through a qualitative data analysis based on

Grounded Theory methods, a deep understanding of

good practices in SA and how these practices could

facilitate software development activities in

distributed projects. Grounded Theory approach

allows the process of data collection, data analysis

and collection of new data analyzed to continue

indefinitely, causing researchers to discover a way

forward, not knowing where to go or come to an end

when, based on samples to test and refine new

theories, ideas or categories as those that are

emerging from data collected and analyzed. This

process ends only when you can no longer get

through the data collected new categories or theories

(Oates, 2006). Yet, the current stage of the research

allowed us to make use of part of Grounded Theory

(there were no refinements of the theories that have

emerged or exhaustion of possibilities for research).

Because this was a qualitative study should be clear

the limitations of this type of research, mainly in

relation to organizational environments studied,

limiting the generalization of the results.

4 RESEARCH SETTING

The review of researches like (Cataldo, Nambiar and

Herbsleb, 2009), (Grinter, 1999), (Herbsleb and

Grinter, 1999) and (Ovaska, 2004), that focus on the

relationship between SA and DSD, the need for

further research in this field was raised. Those

SOA PRACTICES AND PATTERNS APPLIED IN GLOBAL SOFTWARE DEVELOPMENT

287

works tried to identify: software architect roles, SA

designs to improve the coordination of activities,

coordination problems in DSD environments and

events that may cause these problems, and even the

relationship between SA and organizational

structures. Aiming to better understand the

relationship between DSD and SA and to identify

how software architects are working on designing

the systems to a distributed environment, in practice,

we held a research divided in three phases of

interviews with specialists (Software Architects),

with expertise in DSD projects.

Data was collected using semi-structured interviews

conducted in five companies involved with

distributed software development projects, located

in Porto Alegre, RS, Brazil. Last round of

interviews, an in-depth interview, revealed solutions

adopted to solve architectural problems in SOA and

in business rules. Below are presented the problems

that were identified and the solutions adopted to

solve or minimize them. These solutions stand as a

set of practices in SOA in DSD projects.

4.1 Practices Adopted by Companies

Situation 1: Service Composition

- Problem: A particular requirement allows a user to

have one or more types of Internet product accounts,

and for each account type there is a service

(program) responsible for its creation, however there

is one type of account that must always be created.

- Solution: To avoid inconsistencies in the creation

of user accounts, they have created a service that

comprises the sum of transactions of two or more

services. With this kind of implementation two or

more services can become in one without the need

for changes in the implementations of those

services.

Situation 2: Service Security Facade

- Problem: The Company has a great concern for the

safety of their operations. Therefore, it is necessary

that all services implements a minimum set of

security requirements.

- Solution: To avoid failure in the development of

services security layer, they’ve designed a bus that is

responsible for receiving all requests, interpret the

entries and validate the safety rules and then invoke

the target service, which performs only the business

rule and also does not need to translate

communication protocols.

Situation 3: Sandbox

- Problem: The large number of service requests and

data traffic would cause an overload on the

company's ESB.

- Solution: To prevent service disruption could

hardly implement in the ESB, service requests are

passed to an intermediate service, isolating the bus

from external problems, preserving the continuity of

other services.

Situation 4: Contract Versioning

- Problem: During the development of a service,

changes can happen in the format of the output

responses of this service or on how to interpret the

incoming messages.

- Solution: To prevent other development teams,

who need to access this particular service are

constantly affected by these changes, has been

implemented what is known as versions of the

contract, where a service can serve multiple clients

simultaneously with different versions.

Situation 5: Multi-system Transaction

- Problem: A particular service starts a transaction

that triggers actions in several other subsystems and

modules that make up the architecture of a system of

sales.

- Solution: It was developed a mechanism for multi-

system rollback and commit to meet the business

needs.

Situation 6: Messages Marshaling / Un-marshaling

- Problem: The use of parsers to read and write an

XML object can become very expensive depending

on the amount of information.

- Solution: It was used SOAP message components

that translate into specific objects of the system,

eliminating the need to use an XML parser

manually.

Situation 7: Publish / Subscribe Service

- Problem: There are main services that centralize

information on the system. Those services have a

great demand, causing possible overload on it.

- Solution: It was implemented a mechanism that

includes the use of queues for asynchronous

processing of information. Information is published

in a queue where a component responsible for the

consumption of items from the queue, do a

broadcast to client services.

Situation 8: Centralized Error Log Service

- Problem: Error logs must be stored in a central

repository in order to be verified by a specific team.

- Solution: Every service deployed solution must

write the error log, invoking a specific service so

that another team, responsible for maintenance,

could have access to this information.

As we could get from data collected from these

interviews, there are practices that had adopted

solutions in the development phase of projects and

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

288

could be related to some known design patterns. An

example is the situation (4) adopted by the company

B to solve problems caused by changes in the

specification of a service that fits the SOA patterns

classification proposed by (Erl, 2009) as a Service

Contract Design Pattern known as Concurrent

Contracts, which let us to direct this research

towards the development of a conceptual framework

of SOA practices.

Therefore, it is believed that the specification of a

framework is the most suitable at the moment, as a

better scientific contribution, and may serve as a

reference for the initial development of Service

Oriented Architectures in DSD environments,

enabling that in the future, further research could

develop the studies of modeling practices in SOA.

Thus, next section presents the set of practices in

SOA and the proposed framework.

5 SET OF PRACTICES IN SOA

The set of practices in SOA that is proposed in this

work is based on concepts extracted from a literature

review in Software Engineering and on practices

adopted by software architects working for the

companies involved in distributed software

development projects.

There were problems and solutions on SOA

programming, and some of these solutions are

reported in the literature related to SOA Design

Patterns, as defined by (Erl, 2009). According to

(Erl, 2008), the focus of a design pattern is to offer a

solution to a common problem, but that does not

mean that this will be the best solution for all

situations. Table 1 below connects the situations

described by architects in section 4.1 with SOA

design patterns, defined by (Erl, 2009), giving rise

to a set of practices proposed in this research.

Table 1: Mapping from situations to practices to SOA

Design Patterns.

Situations Practices SOA Design Patters

Situation 1 Practice 1 Capability Composition

Situation 2 Practice 2

Service Perimeter Guard

Protocol Bridging

Situation 3 Practice 3 Asynchronous Queuing

Situation 4 Practice 4 Concurrent Contracts

Situation 5 Practice 5

Situation 6 Practice 6

Situation 7 Practice 7 Event Driven Messaging

Situation 8 Practice 8

The table above shows the mapping from the

situations described by the software architects to

some SOA design patterns found in the literature.

Also, based on table 1 (section 4.1), we can see that

practices extracted from those situations can be

associated with none, one or more design patterns.

To highlight those practices, we describe below

some definitions of each, according to (Erl, 2009):

• Practice 1 (Capability Composition Design

Pattern): Defined as a service composition,

where a functionality encapsulated by a service

includes logic able to access functionality from

other services. Thus, a service is able to create a

composition between the features of one or

more services. This practice is related to

situation 1, described by company A.

• Practice 2 (Service Protocol Bridging and

Service Perimeter Guard Design Patterns): This

practice covers two types of patterns and is

related to the situation #2, described by

company A. Perimeter Guard Service, which

provides an intermediate service at the

perimeter of a private network, which plays the

role of a safe contact point with external

services that need to interact with internal

private network services, and the Protocol

Bridging, which allows two services to connect

to a broker instead of connecting directly. In

other words, a service responsible for

translating the communication protocols

between the service provider and consumer.

• Practice 3 (Situation 3 Queuing Asynchronous

design pattern): As the situation described by

the architect of Company A, this practice

implements a mechanism for asynchronous

requests and responses to ensure that service

consumers could not inhibit performance and

compromise system reliability.

• Practice 4 (Concurrent Contracts Design

Patterns): This includes the establishment of

multiple service contracts for a single service,

and each such contract is directed toward a

specific type of consumption, thereby

facilitating multi-consumer coupling

requirements and abstraction concerns at the

same time.

• Practice 5: This practice is related to the

situation 5 described by the architect from

company B, which we couldn’t relate it to a

similar position available in the literature so far.

SOA PRACTICES AND PATTERNS APPLIED IN GLOBAL SOFTWARE DEVELOPMENT

289

It is believed that this may be linked to the fact

that the situation mentioned is attached to a very

specific business rule.

• Practice 6: This practice is related to the

situation 6 described by company B, which we

couldn’t relate it to a similar position available

in the literature so far. It is believed that this

may be linked to the fact that the situation

referred to is on the use of proprietary software

components.

• Practice 7 (Event Driven Messaging Design

Pattern): Implements a pattern where a service

consumer requests to service provider to be

automatically notified about important events.

Thus, whenever the service provider receives

information updates it will notify all services

that had subscribed.

• Practice 8: This practice is related to the

situation 8 described by Company C, which we

couldn’t relate it to a similar position available

in the literature so far. It is believed that this

may be tied to a specific organizational

structure.

From this initial set of practices, we propose a

framework that will implement these practices to be

applied in designing DSD-based on SOA. In

addition, the purpose of this framework is not to be

the solution for SOA implementations in DSD

projects, but to serve as an initial reference to

support development task on scenarios of that kind.

Moreover, not all practices listed in Table 1 are part

of the framework, since some of them were specific

business solutions, or even, lack data that

characterize as a differential for DSD. To illustrate,

Figure 1 below, presents an overview of the

conceptual framework, divided in types of services

that in turn are related to groups of Design Patterns,

established by (Erl, 2009).

The layers of the framework are based on groups of

services patterns defined by (Erl, 2009), which

means it is possible to associate almost each type of

service to a practice. The following describes each

of those layers and practices that make them up.

• Service Security & Transformation Layer:

This part of the framework contains services

that reach vertically all other services in the

architecture and aims to implement a security

layer to services and further treatment and

conversion of messages. Implementation of

Figure 1: Framework conceptual view.

this layer was based on the second practice,

which falls in the Transformation and Service

Security Patterns groups, suggested by (Erl,

2009). Moreover, it is believed that the

implementation of this layer would be

beneficial to distributed teams of developers,

since the implementation of a comprehensive

security mechanism to the project may relieve

developers, letting them focus on the

implementations of the functional requirements

of the system.

• Service Contract Layer: Again, according to

(Erl, 2009), although there are efforts in the

phases of analysis and modeling services, those

services will still be subject to new situations

and new requirements that could force a change

to its original design. Therefore, patterns have

emerged to help upgrade a service without

compromising their original responsibilities.

One of these patterns is described by practice #4

and cataloged as Concurrent Contracts. This

kind of pattern can prevent distributed teams of

being constantly affected by changes in services

that are under development and holds essential

information requested by other services.

• Messaging Service Layer: According to (Erl,

2009), several factors may be involved in

service design to estimate the possible scenarios

that may occur at run time. Messaging Service

Layer, represented by the group called

Messaging Service Patterns, provides

processing and coordination techniques to the

exchange of data between services, as observed

in the case mentioned by the third practice,

where it is necessary to maintain isolation

between service bus and target services. This

situation is covered by the Asynchronous

Queuing Pattern, which includes the exchange

of messages between services via intermediate

buffer, preventing overloading of service

provider and stuck service consumer, which

may cause performance problems. Practice #7

fits this group of patterns, in which a service

has access control to basic information and

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

290

needs to broadcast changes on that information.

This pattern was defined as event-driven

messaging, characterized as services that

automatically send notifications to consumers

about some change in the information it holds.

• Service Support Layer: This framework’ layer

aims to group the services exemplified by

practice #8, where all sorts of service logging is

centralized in a dedicated logging service,

enabling specific QoS teams to take actions in

time. Despite not having been found in the

literature so far a pattern to this type of service,

we chose to include it within the framework by

understanding that distributed teams of

developers who work in the maintenance of the

software can be positively affected by this

approach.

As highlighted earlier, not all the practices described

in table 1 were part of the framework. In this

situation are: practice #1, practice #5 and #6. These

practices are not part of the framework because we

understood that they represent specific solutions and

may not have a relationship with DSD. In this sense

another possible design for the proposed framework

is depicted in Figure 2.

Figure 2: Practices over framework's layers.

In the above figure, Security Service &

Transformation layer is represented by practice #2,

Messaging Service layer is represented by practices

#3 and #7, Service Contract layer is represented by

practice #4 and the Service Support layer is

represented by practice #8.

6 FUTURE WORK

The contribution of this paper is a set of practices in

SOA for distributed software development projects,

as well as an initial version of a framework that will

implement these practices. The following items are

aspects that we are evaluating as next steps in this

research.

• Confirmation: allow to confirm with

interviewed architects whether this set practices

could improve developers task in a distributed

environment;

• Experimentation: allow to perform

experiments to evaluate the benefits, which in

practice may result from the use of the

framework implementing SOA practices in

DSD projects. It is intended in this experiment

to compare different parameters when an SOA

project in DSD is developed using the

framework and when it is developed as adhoc;

• Framework consolidation: After experiments,

refinement and evaluation of results is expected

to propose a final version of the SOA practices

framework to DSD projects.

With this paper we expect to bring important

benefits to both the theory and practice of software

development:

i) Design software architectures based on SOA to a

better management of development of distributed

software projects;

ii) Adopt design practices used in the DSD projects

to facilitate the coordination of software

development activities; and

ACKNOWLEDGEMENTS

The first three authors were supported by the PDTI

program, financed by Dell Computers of Brazil Ltd.

(Law 8.248/91). The third author was also supported

by CNPq (483125/2010-5, and 560037/2010-4). The

fourth and fifth authors were supported by the

Brazilian Government under grant CNPq

473220/2008-3 and by the Fundação de Amparo à

Pesquisa do Estado do Pará through “Edital

Universal N° 003/2008”. The fifth author conducted

this work while at Federal University of Pará.

REFERENCES

Cataldo, M. and Nambiar, S. 2009. On the relationship

between process maturity and geographic distribution:

an empirical analysis of their impact on software

quality. In Proceedings of the European Software

Engineering Conference and the ACM SIGSOFT

Symposium on the Foundations of Software

Engineering (Amsterdam, The Netherlands, August

24 - 28, 2009). ACM, New York, NY, 101-110

Cataldo, M., Nambiar, S., and Herbsleb, J. D. 2009 Socio-

Technical Design Patterns: A Closer Look at the

relationship between Product and Organizational

Structures. In 2nd International Workshop on Socio-

Technical Congruence (Vancouver, Canada, May 16-

24, 2009). ICSE Companion ’09. IEEE Computer

Society, Washington, DC, 476-477.

practice 2

practice 3 / practice 7

practice 4

practice 8

SOA PRACTICES AND PATTERNS APPLIED IN GLOBAL SOFTWARE DEVELOPMENT

291

Conway, M. E. (1968). How Do Committees invent?

Datamation, 14(4), 28-31.

Erl, Thomas. Introducing SOA Design Patterns. SOA

World Magazine. 8,6 (June 2008). 2-7.

Erl, T. 2009 SOA Design Patterns. 1st. Prentice Hall PTR.

Garlan, D. 2000. Software architecture: a roadmap. In

Proceedings of the Conference on the Future of

Software Engineering (Limerick, Ireland, June 04 -

11, 2000). ICSE '00. ACM, New York, NY, 91-101.

Grinter, R. E. 1999. Systems architecture: product

designing and social engineering. SIGSOFT Softw.

Eng. Notes 24, 2 (Mar. 1999), 11-18.

Herbsleb, J. D. and Grinter, R. E. 1999. Architectures,

Coordination, and Distance: Conway's Law and

Beyond. IEEE Softw. 16, 5 (Sep. 1999), 63-70.

Herbsleb, J. D. and Moitra, D. 2001. Global software

development. IEEE Softw. 16,5 (Mar/Apr 2001), 16-

20.

Herbsleb, J. D. 2007. Global Software Engineering: The

Future of Socio-technical Coordination. In 2007

Future of Software Engineering (May 23 - 25, 2007).

International Conference on Software Engineering.

IEEE Computer Society, Washington, DC, 188-198.

Oates, B. J. 2006 Researching Information Systems and

Computing. Sage Publications Ltd.

Ovaska, P., Rossi, M., Marttin, P. (2004). Architecture as

a Coordination Tool in Multi-site Software

Development. Software Processes: Improvement and

Practices. 8,4 (Set 2004). 233-247.

Papazoglou, M. P. and Heuvel, W. 2007. Service oriented

architectures: approaches, technologies and research

issues. The VLDB Journal 16, 3 (Jul.2007), 389-415.

Pressman, R. S. 2000 Software Engineering: a

Practitioner's Approach. 5th. McGraw-Hill Higher

Education.

Sommerville, I. 2006 Software Engineering: (Update) (8th

Edition) (International Computer Science). Addison-

Wesley Longman Publishing Co., Inc.

De Souza, C. R., Redmiles, et al. 2004. Sometimes you

need to see through walls: a field study of application

programming interfaces. In Proceedings of the 2004

ACM Conference on Computer Supported

Cooperative Work (Chicago, Illinois, USA, November

06 - 10, 2004). ACM, New York, NY, 63-71.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

292