Chapter-1

Introduction
Service Oriented Computing (SOC) is an emerging distributed
computing technology that is set to replace the existing ways of building
software [1]. It is an architectural practice followed by organizations to
reduce

total

cost

of

ownership,

ease

of

maintenance

in

software

development. Many organizations today are looking up to SOA as an

architectural solution to provide a robust computing platform to connect
to legacy systems.
The main causes of acceptance of this latest design paradigm are its
distinct advantages of reusability ease of maintenance, interoperability,
reduced development cost, defined standards and many more. SOA based
solutions promise a better landscape in terms of all benefits mentioned
and has proven to be a boon for large scale organizations.
Being service oriented basically means employing an architecture
that consists of a variety of services, the basic building block of SOA
application. Service is a unit of solution logic specially designed to attain
the inter operability, federation, agility, loose coupling and other strategic
goals of Service Oriented Computing. It is a self contained stateless
business function that accepts multiple requests and returns multiple
responses through well defined standard interface. They are hosted by the
service provider and are initially discovered and further invoked and
interacted by the service consumer through UDDI (Universal Description,
Discovery and Integration) public service registry following the service
contract as shown in Figure1.

Fi gure1: S ervi ce Ori ent ed Archi t ect ure.

Service

orientation,

services,

service

compositions,

service

inventory and SOA are essential elements for realizing Service Oriented
Computing.
SOA might be defined as an application architecture in which all
functions are implemented as independent services with well-defined
invokable interfaces, which can be called in sequences to form business
processes. Recent IT developments have pushed SOA forward. For
instance with personalized, portal-style user interfaces over multiple
wired and wireless channels an increasing number of solutions require the
reuse of application components. Different users such as customers,
employees, managers using many devices in different situations all may
request access to the same set of business applications. Flexibility in
design of new software, reuse of business components, interoperability,
integration capability, and ease of assembling new business processes are
few of the advantages of SOA.
SOA is not always a remedy for existing shortcomings in todays
mix and match IT-architectures. This approach of distributed computing is

not suitable for homogenous IT environment, true real time systems, old
legacy systems and systems where tight coupling is required. SOA is also
not recommended for standalone short lived applications. Moreover it is
also not useful for applications that need GUI based functionality. Besides
certain areas where SOA has not proved to be beneficial there are certain
critical aspects that are to be considered. Service versioning, service
security, availability, service discovery, unfurnished standards, request
change etc. are few of them.
It has been almost a decade since the advent of SOA. Expectations
for SOA were high, but early adopters faced obstacles that inhibited the
realization of SOAs benefits. Many of the failed IT projects blamed SOA,
but the actual cause did not lie in the technology, but was in the way it
was implemented. Although lot of work has been done to develop design
patterns for SOA development, the dissatisfactory performance of SOA
projects has stimulated the developers to analyze the SOA worst practices
or antipatterns. Our research aimed at identifying these wrong practices in
implementation of SOA. A careful and intensive study of existing
antipatterns of SOA is done. These antipatterns are categorized are
categorized as SOA development process, SOA framework and SOA design
antipatterns. They are presented in a proposed SOA antipattern template
specifying there name, root cause, primal forces and description.
Various case studies, implementations, intensive study and research
we identified four antipatterns in SOA design related to the use of SOAP,
WSDL, UDDI and basic service definition, which initially seemed to be
correct but later resulted into reduced performance benefits.

1.1

Aim

The aim of our research work was to identify and formalize new
antipatterns in SOA design.

1.2

Objectives

1)

To analyze various design patterns and antipatterns.

2)

To identify various problems and failures in SOA design.

3)

To identify various Antipatterns.

4)

To formalize new Antipatterns.

Chapter-2
Literature Review
Readily accessible internet and World Wide Web (WWW) in past
few years has increased the use of distributed systems by enterprises
exponentially. Initially, distributed systems interacted using proprietary
protocols. Certain application specific methods were used to manage these
systems.
SOC is a latest computing paradigm that utilizes services as the
basic constructs to support the development of rapid, low-cost and easy
composition

of

distributed

applications,

even

in

heterogeneous

environments [1]. SOC has not occurred with an impact but it has been
gradual evolution overtime from the basic object oriented paradigm. The
presented work started with the depth study of the origin of SOC. Roots of
service orientation lie in one of the oldest design paradigm object
orientation [3, 4]. It laid the foundation of important principles like
abstraction, encapsulation and reusability etc. that were further reinforced
by component based development, with its advantages of extensibility and
maintainability [2].
Component based development could not cater complex issues such
as

distributed

deployment,

application

integration,

heterogeneous

platforms, web based access and diverse protocols. These drawbacks led
to the evolution of client server computing [3-5]. Its tightly coupled
nature paved the way to distributed computing. It supported highly
dispersed heterogeneous systems with reduced coupling between the
components [7, 8, 12, 13].
SOA is a logical way of designing a software system to provide
services either to end-user applications or other services distributed in a
network via published and discoverable interfaces. Many papers and
articles have matriculated the use of SOA [10, 11, 24, 29, 39, 42].

Various implementations of SOA approach derived the best practices

and design patterns of SOA documented in [15, 22, 26, 32, 40]. In first
phase of our work systematic review of various antipatterns in SOA has
been done. Antipatterns have been addressed by practitioners after year s
long experience in the field. A survey on different antipatterns was done
exploring various worst practices and the causes of the failure of SOA
projects [23, 28, 32]. The dissatisfactory performance of SOA projects has
stimulated

the

developer

to

analyze

the

SOA worst

practices

or

antipatterns. This module of SOA development has been weakly analyzed.

Antipatterns for SOA have already been documented [16-20, 25, 28, 37,
44], but the major concern was on the development process and SOA
framework [48]. Moreover, they have been described at different levels of
abstraction, which makes them appear independent and isolated.
SOA antipatterns have been categorized as development process,
framework and design antipatterns. There details include name, root
cause, primal forces, description and the name of the antipattern to which
the current antipattern is similar to, following the standard antipatterns
template [21, 37]. SOA design antipatterns were further emphasized and
classified and re-factored solutions were provided to them After studying
various SOA implementations, case studies [9, 12, 33-35], News agency
Service project of Signett IT enabled services, Travel Portal project of
HCL systems and few others [38, 40-42] , it has been observed that there
are some flaws in implementation of SOA. The problem exists more in
companies transiting from traditional approach to SOA. The reason can be
any beginning from lack of experience to haste or others. Companies
implementing SOA for the first time, start creating services as nothing
else, but methods that bind inside SOAP envelop and can be described
through WSDL. Some of the domain areas which should be considered
while implementing SOA in projects are highlighted in the presented
work. [44] Specifies various other research challenges and issues in SOC.

Chapter-3
Scope and Research Methodology Used
SOA is the latest design paradigm for distributed systems. It has a
wide scope for research. Major concern for SOA is to readily develop
applications with the integration of services and composite applications
within the enterprise by supporting the features such as reliability, proper
routing and coordination of services, and managing other technical details
including protocol and integrating party agreements [44].

3.1

Scope
SOA has been implemented in major projects of many companies

but since it is in its nascent stage developers are learning more from there
ill experiences with it. Our work aims to highlight certain steps which if
taken wrongly may prohibit the desired results of the project. After an
intensive study and implementation we identified few antipatterns in SOA
design. These are just a small fraction of the major SOA areas where more
antipatterns could be identified.
The proposed antipatterns will definitely help programmers to be
aware of various wrong practices in SOA implementation, specifically in
designing of such applications. This work specifies four antipatterns in
service design and will assist the SOA designers for developing better
frameworks and tools to develop integrated SOA applications.
Quality of Service (QoS) requirements, security, management and
monitoring of services are also other requirements that need to be
clarified when designing service based application architectures. SOA has
a broad influence in each stage of application development including
analysis and design of individual services, service deployment, creation of
new applications from services and implementation of services through
service oriented strategies and approaches. There are various other aspects
like SOA versioning, change request, service security, data sources, load

balancing etc which need the attention of the developers and have vast
scope of research.

3.2

Research Methodology
The main aim of our research was to identify antipatterns in SOA

design. We started with the in depth study of the subject. This latest
design paradigm has its roots in the decades old object oriented paradigm.
In order to understand the subject it was necessary to compare SOA with
other common approaches. Software development and computing trends
were discussed in context to evolution of SOA, showing changes in their
implementation with time and their role [2-8].
Various design patterns and antipatterns of SOA were reviewed and
a template for SOA antipatterns was proposed and used to represent
studied antipatterns. They were further categorized as SOA development
process, SOA framework and SOA design antipatterns [21]. The work was
supported

in

parallel

by

news

agency

registration

service

for

implementing SOA. After intensive case studies of SOA failures various

weak areas of SOA implementation were identified. Some of them were
service designing, versioning, service discovery, request change, load
balancing etc. Based on the research work certain antipatterns were
proposed and which were further implemented and formalized in an
antipattern template. For the support of the proposal, registration service
was implemented both as SOAP based and REST based.

Chapter-4
Service Orientation
Service orientation is a design paradigm comprised of a specific set
of design principles. The application of these principles to the design of
solution logic results in service-oriented solution logic [11]. The most
fundamental unit of service-oriented solution logic is the service. The
service-oriented

computing

platform

revolves

around

the

service-

orientation design paradigm and its relationship with service-oriented

architecture. This chapter introduces Service Oriented Computing and
Service Oriented Architecture.

4.1 Service Oriented Computing and its evolution

A new generation distributed computing platform having its own
design paradigm, principles and patterns. In the following section, SOC is
briefly described.
4.1.1 Introduction
The term was formalized in 1996; prior to it many companies were able to
implement service layers using a variety of distributed technologies,
including Common Object Request Broker Architecture (CORBA) and the
Distributed

Common

Object

Model

(DCOM).

On

the

other

hand

development of enterprise application with a traditional approach was

facing lots of problems. Since the solutions were created with a common
approach of identifying the business task to be automated, defining there
business requirements and then building the corresponding solution, the
new solution logic results in many problems like significant amount of
redundant functionality, targeted scope of the project and many others.

Having
generations

to

host

numerous

of technologies

applications

and

perhaps

even

built

from

different

different
technology

platforms often requires that each will impose unique architectural

requirements. Applications built only with the automation of specific
business processes in mind are generally not designed to accommodate
other

interoperability

requirements.

After

repeated

generations

of

traditional distributed solutions, the severity of such problems has been

amplified and hence conceived the concept of Service Orientation.
4.1.2 Evolution
Modern software development methodologies and implementations
have their roots in the decades old object oriented paradigm. Object
orientation laid the foundation of important principles like abstraction,
encapsulation

and

reusability

etc.

that

were

further

reinforced

by

component based development, with its advantages of extensibility and

maintainability. Components were not successful for web based access,
hence evolved client server computing. But its tightly coupled nature
paved the way to distributed computing. It supported highly dispersed
heterogeneous systems with reduced coupling between the components. An
efficient design paradigm for implementing distributed system is SOC
[13].
Development Trends
Traditionally, software ran in stand-alone systems where users
interface, application logic, persistent data all reside on a single machine
with attached peripherals. While todays software development is based on
distributed systems, where presentation, application logic, data resources
all reside on remote, heterogeneous, loosely coupled systems. Several
trends are emerging to cope up with the current computational scenario.
Various development and computing trends have been implemented
overtime.

10

The use of distributed systems

by enterprises has increased

exponentially in past few years due to certain factors such as readily

accessible internet and World Wide Web (WWW) [1]. Initially, distributed
systems communicated using proprietary protocols. Grid computing is
such an implementation of distributed computing. Certain standards have
been developed over the years to simplify the management, maintenance
and deployment issues. Web services, SOA, Cloud computing are the
current implementations of these standards.
Today, the key technology to implement distributed systems is SOC.
Service orientation / SOA are an extensive buzzed around words today,
without knowing its actual context and meaning. It is a style of building
reliable distributed systems with inherent features like loose coupling,
interoperability etc. Web services are a popular implementation of SOA.

Fi gur e2: Evol uti on of S OC .

Object Oriented Development

11

Object orientation is established as a dominant paradigm for

virtually all modern software development, from small software to a fullfledged enterprise application. Object orientation is based on its four
fundamental principles viz. Abstraction, Encapsulation, Inheritance and
Polymorphism. Class is the basic construct that binds the data attributes
and their associated behaviors. Object is a run time instance of class. The
main emphasis is to structure a system with classes, ensuring modularity
and reusability. A module or a class offering functionality exposes a set of
public interfaces or contracts and hides out implementation details. The
user accesses the functionality through the objects without being bothered
about its implementation. This has close resemblance with SOC, which
evolved as a successor of component based and object oriented computing.
Object oriented design comprises of fundamental design principles
which structure and organize object logic within and across classes.
Object oriented principles include increased extensibility, flexibility,
reusability, predictability and robustness. Many of these principles have
been carried in service orientation while some like inheritance (is-a
relation),

abstract

discouraged.

class,

Different

polymorphism,

component

of

aggregation

object-oriented

have
approach

been
like

classes, methods and interfaces relate to different components of service

oriented approach as shown in Figure 3.

12

Fi gure 3: El em ent s of obj ect ori ent at i on and servi ce ori ent at i on.

Object

orientation

evolved

out

of

approaches

that

included

procedural programming while service orientation builds upon object

oriented

principles

development

with

(CBD),

additional

aspect

influence

oriented

of

component

programming

(AOP),

based

business

process management (BPM) etc.

Component Based Development
Component
construction

of

Based

Development

computer

based

emphasizes

systems

using

the

design

reusable

and

software

components. Component is the most important, independent replaceable

part of a system that fulfills a clear functionality. A set of pre built
standardized software components are made to fit a specific architectural
style.

In

component-based

development,

initially,

an

appropriate

architecture style to meet the objectives of the system to be built is

selected. The components to be reused are then identified. The selected
components

are

then

qualified

so

architecture.

13

that

they

fit

into

the

desired

The next step is

to adapt

the component

according to the

requirement, if modifications are required. Finally all the components are

integrated to form the subsystem. Separate components are created to
fulfill the requirements, which could not be implemented using the
existing components.
Component Middleware allows a group of component objects to
interact with each other through multiple interfaces provided, and also
defines run time mechanism to execute these component objects in generic
application servers in a distributed environment. Technologies such as
Enterprise Java Beans (EJB), Common Object Request Broker Architecture
(CORBA)

and

Component

Object

Model

(COM)

are

implementing

component middleware.
SOA comprises of a set of components that can be invoked and
whose interface descriptions are published and discovered. Component
model is used for developing and executing components. The usage of the
terms invoked and execute is noteworthy. Component based architectures
and service based architectures both work towards the foundation for
loosely joined and highly interoperable software architectures. Services
have to be publicly accessible; moreover they have to be independent of
implementation

specific

maintainability

issues

development,

but

attributes.
got

complex

Extensibility,

addressed
issues

such

through
as

reusability

and

component-based

distributed

deployment,

application integration, heterogeneous platforms, and web based access

and diverse protocols could not be catered.
To address such issues client server computing emerged. Initially it
was tightly coupled. Soon the need was felt for distributed systems to
support wide area network and for communication between highly
dispersed heterogeneous systems. Multi tier architecture evolved, with the
front tier to deal with the client, middle tier to cater the incoming request

14

(also called broker) and database tier to handle the backend issues. The
middle tier may be comprised of multiple layers. Coupling between
components

was

reduced,

statelessness

was

desired

and

enhanced

components were further represented as services, rather web services [4].

Distributed Computing
A distributed system consists of multiple autonomous computers
that communicate through a computer network . The computers interact
with each other in order to achieve a common goal. There are several
autonomous computational entities, each of which has its own local
memory . The entities communicate with each other by passing message.
Initial service based systems used different technologies like Dynamic
Component Object Model (DCOM), CORBA to provide standard based
interoperability in a distributed environment. CORBA has been designed
to be free of the operating system. It runs on many OS platforms. Cross
language, cross vendor interoperability is achieved through IIOP (Internet
Inter ORB Protocol), a protocol for distributed applications written in
RMI (Remote Method Invocation) or IDL (Interface Definition Language).
CORBA had its own complexities like passing of object references,
passing

actual

(not

abstract)

argument

values

etc.

These

growing

complexities are reduced by the service oriented computing, it is a style of

organizing and utilizing the distributed capabilities that may be controlled
by different organizations.
Grid Computing
Grid Computing aims at utilizing the unutilized resources from
different administrative domains. It involves computation in a distributed
fashion, which may also involve the aggregation of large-scale cluster
computing

based

systems.

It

can

run

the

users

application

on

heterogeneous computing resources which are dispersed geographically. It

15

has high security mechanism involved. It has almost been two decades
since the advent of grid computing even then it is not much popular in the
research community. Only a small number of the researchers actually use
grid software [5]. The reason behind is the complexity involved with the
grid, like, its complex architecture, the grid certification process, cryptic
command line options, non-assurance of the availability of resources etc.
Grids are application oriented. They are not fully web based; they also
have command line option to enter into a grid. Resources in a grid may be
administered by different set of people. It follows dedicated resource
policy i.e. a resource is reserved to a particular application for the
particular time, until its use, It cannot be used by any other application.
Cloud Computing
Cloud Computing is an extension of grid computing, parallel
computing and distributed computing. It aims to provide high performance
computing resources to the client over the internet. It can deploy, allocate,
reallocate computing resources dynamically and monitor the usage of
these resources at all times. Cloud provisions multiple users to share a
single resource concurrently. Simultaneously, it assures that one users
data or application is not shared by the other. It uses the technique of
virtualization, so dynamic scaling of resources is possible. It provides
virtual data centers, but does not depend on any particular data center.
Many of the internet applications are cloud based. Uploading photo,
text files, online shopping, gaming, music resources etc are all cloud
based. Google apps, EC2 (Elastic computing cloud) are the examples of
popular clouds. Some clouds offer testing and production environment
free of cost. Developers can develop and deploy their application on the
cloud free of cost. Cloud data centers are owned by private vendors and
are fully commercialized. They are not designed for a particular domain or
problem. All activities in a cloud can be achieved through web browsers

16

and no manual interactions are required. Like grid, cloud data centers may
be located in geographically different locations but they will be under the
same administrative domain in contrast to a grid, which may have
different owners.
Besides

normal

implementation,

cloud

computing

is

also

implemented in following different styles:

i) SaaS - Software as a Service. In this form of cloud, software services
are hosted over the web. It is a new delivery model for software. Instead
of hosting software on premise in their own data center companies and
individuals use software that is hosted and managed by the SaaS provider.
SaaS mainly uses REST (Representational State Transfer) and SOAP
(Simple Object Access Protocol). In the users views, this approach can
save some cost on servers and software. In the providers views, they only
need to maintain one program, this can also save cost. SOA is a design
model whereas SaaS is consumption model.
ii) PaaS - Platform as a Service. It implies the concept of using web as a
platform. The providers offer application APIs and services so that the
user consuming these, may write their own applications and run these
applications using these APIs in the providers server, independent of
other

applications.

Platform

Oriented

Architecture

(POA)

is

the

architecture on which PaaS is designed. PaaS and SaaS are virtually same
for service consumption, but PaaS offers development and service hosting
opportunity.
iii) Utility Computing In utility computing virtual data centers are
created to provide storage and virtual services through collecting memory,
input-output equipments, storage and computing power to a virtual
resource pool.

17

iv) IaaS - Infrastructure as a Service delivers computer infrastructure ,

typically a platform virtualization environment, as a service . Rather than
purchasing servers, software, data center space or network equipments,
clients buy these resources as fully outsourced services. The service is
typically billed on the basis of amount of resources consumed and
therefore the cost will typically reflect the level of activity. It is an
evolution of virtual private server .
Cloud computing expands SOA on the internet by adding scalability
and grid computing. Many SOA based applications are deployed and
hosted on a cloud network like EC2, windows Azure, etc. Although it is
not necessary to host web services on a cloud but it is preferred because
cloud provides no limit to the size of data, no limit to the processing
power, no limit to the number of service instances. SOA applications take
advantage of the elasticity of the cloud.
Service Oriented Computing (SOC)
The service-oriented computing paradigm uses services to support
the

development

of

rapid,

low-cost,

interoperable,

evolvable,

and

massively distributed applications . It evolved as the latest design paradigm

for developing distributed enterprise applications.
4.1.3 Elements of SOC
Following elements are essential to realize service oriented computing:
a)

Service Orientation: It is a design paradigm comprised of a specific

set of design principles. The application of these principles to the design

of solution logic results in service oriented solution logic.
b)

Services: The most fundamental unit of service-oriented solution

logic is the service. Each service is assigned its own distinct functional

18

context and is comprised of a set of capabilities related to this context.

Those capabilities suitable for invocation by external consumer programs.
c)

Service

services.

The

Compositions:
consistent

These

are

application

a
of

coordinated

aggregate

service-orientation

of

design

principles leads to the creation of services with functional contexts that

are agnostic to any one business process. These agnostic services are
therefore capable of participating in multiple service compositions.
d)

Service Inventory: It is an independently standardized and governed

collection of complementary services within a boundary that represents an

enterprise or a meaningful segment of an enterprise. An enterprise
environment can contain multiple service inventories, each of which can
be individually standardized, governed, and supported by its own serviceoriented technology architecture. Service inventories are typically created
through top-down delivery processes that result in the definition of
service inventory blueprints.
e)

Service Oriented Architecture: SOA is an architectural model that

aims to enhance the efficiency, agility, and productivity of an enterprise

by positioning services as the primary means. They represent the solution
logic in support of the realization of strategic goals associated with SOC.
SOA implementation can consist of a combination of technologies,
products, APIs, supporting infrastructure extensions, and various other
parts.
4.1.4 Service Models
Services can be categorized depending on the type of logic they
encapsulate, the extent of reuse potential this logic has and how this logic
relates to existing domains within the enterprise.

19

Hence services can be classified in three broad categories:a) Entity Services

It is the business model document that defines the organizations
relevant business entities. Examples of business entities include customer,
employee, invoice, and claim. The entity service model represents a
business centric service that bases its functional boundary and context on
one or more related business entities. It is considered a highly reusable
service because it is agnostic to most parent business processes. It is also
sometimes called entity centric business services or business entity
services.
b) Task Services
A business service with a functional boundary directly associated
with a specific parent business task or process. This type of service tends
to have less reuse potential and is generally positioned as the controller of
a composition responsible for composing other, more process-agnostic
services. Task services are also known as task-centric business services or
business process services.
c) Utility Services
It

is

dedicated

to

providing

reusable,

cross-cutting

utility

functionality, such as event logging, notification, and exception handling.

It can consist of a series of capabilities that draw from multiple enterprise
systems and resources, while making this functionality available within a
very specific processing context. Utility services are also known as
application services, infrastructure services, or technology services. The
use of these service models results in the creation of logical service
abstraction layers.

20

4.2

Service Oriented Architecture

Software architecture is a description of a software system in terms

of its major components, their relationships, and the information that

passes among them. A fundamental purpose of software architecture is to
help manage the complexity of software systems and the modifications
that systems inevitably undergo in response to external changes in the
business,

organizational,

and

technical

environments.

SOA

is

an

architectural style for building enterprise solutions based on services.

More specifically, SOA is concerned with the independent construction of
business-aligned services that can be combined into meaningful, higherlevel business processes and solutions within the context of the enterprise.
An architectural model that enhances the cost effectiveness, efficiency,
agility and productivity of an enterprise by positioning

services as the

primary means to represent logic and by reducing IT burden on the overall

organization
4.2.1 Strategic Goals of SOA
The vision behind SOC is extremely ambitious and therefore also
very attractive to any organization interested in truly improving the
effectiveness of its IT enterprise. A set of common goals and benefits has
emerged to form this vision [15].
Increased Intrinsic Interoperability
Interoperability refers to the sharing of data. Software programs
that are not interoperable need to be integrated. Therefore, integration can
be seen as a process that enables interoperability. A goal of serviceorientation is to establish native interoperability within services in order
to reduce the need for integration

21

Increased federation
A federated IT environment is one where resources and applications
are

united

governance.

while

maintaining

SOA aims

to

their

increase

individual
a

autonomy

federated

and

perspective

selfof

an

enterprise.
Increased Vendor Diversification Options
Vendor diversification refers to the ability an organization has to
pick and choose amongst multiple vendor products and technology
innovations and use them together within one enterprise. It is not
necessarily beneficial for an organization to have a vendor diverse
environment; however, it is beneficial to have the option to diversify
when required.
Increased return of investment
SOC advocates the creation of agnostic solution logic i.e. logic that
is agnostic to any one purpose and therefore useful for multiple purposes.
Agnostic services have increased reuse potential that can be realized by
allowing them to be repeatedly assembled into different compositions.
Any one agnostic service can therefore find itself being repurposed
numerous times to automate different business processes as part of
different service-oriented solutions.
Increased Business and Technology Domain Alignment
Although initial applications have traditionally been designed to
address

immediate

and

tactical

requirements,

it

has

always

been

challenging to keep applications in alignment with business needs when

the nature and direction of the business changes. The fact that services are
designed to be intrinsically interoperable directly facilitates business
change. As business processes are augmented in response to various

22

factors (business climate changes, new competitors, new policies, new

priorities, etc.) services can be reconfigured into new compositions that
reflect the changed business logic.
Increased Organizational Agility
Agility, on an organizational level, refers to the efficiency with
which an organization can respond to change. Increasing organizational
agility is very attractive to corporations, especially those in the private
sector. Being able to more quickly adapt to industry changes and
outmaneuver competitors has tremendous strategic significance. Services
have been positioned as reusable IT assets; they can be repeatedly
composed into different configurations. As a result, the time and effort
required

to

automate

new

or

changed

business

processes

is

correspondingly reduced because development projects can now be

completed with significantly less custom development effort
Reduced IT Burden
Consistently applying service-orientation results in an IT enterprise
with reduced waste and redundancy, reduced size and operational cost, and
reduced overhead associated with its governance and evolution. Such an
enterprise can benefit an organization through dramatic increases in
efficiency and cost-effectiveness.
4.2.2 SOA Design principles
A

principle

is

generalized,

accepted

industry

practice.

It

represents a highly recommended guideline for shaping solution logic in a

certain way and with certain goals in mind. These goals are usually
associated with establishing one or more specific design characteristics
[15].

23

Standardized Service Contract

Services express their purpose and capabilities via a service
contract. It is the most fundamental part of service orientation in that it
essentially requires that specific considerations be taken into account
when designing a services public technical interface and assessing the
nature and quantity of content that will be published as part of a services
official contract.
Service Loose Coupling
Coupling refers to a connection or relationship between two things.
A measure of coupling is comparable to a level of dependency. This
principle advocates the creation of a specific type of relationship within
and outside of service boundaries, with a constant emphasis on reducing
dependencies between the service contract, its implementation, and its
service consumers.
Service Abstraction
This principle emphasizes the need to hide as much of the
underlying details of a service as possible. Doing so directly enables and
preserves the previously described loosely coupled relationship. Service
Abstraction also plays a significant role in the positioning and design of
service compositions.
Service Reusability
The principle of Service Reusability emphasizes the positioning of
services

as

enterprise

resources

with

agnostic

functional

contexts.

Numerous design considerations are raised to ensure that individual

service capabilities are appropriately defined in relation to an agnostic
service context, and to guarantee that they can facilitate the necessary
reuse requirements.

24

Service Autonomy
For services to carry out their capabilities consistently and reliably,
their underlying solution logic needs to have a significant degree of
control over its environment and resources. The principle of Service
Autonomy supports the extent to which other design principles can be
effectively realized in real world production environments
Service Statelessness
The management of excessive state information can compromise the
availability of a service and adversely affect its scalability potential.
Services are therefore ideally designed to remain stateful only when
required.
Service Discoverability
Services are supplemented with communicative meta data by which
they can be effectively discovered and interpreted
Service Composability
The ability to effectively compose services is a critical requirement
for achieving some of the most fundamental goals of SOC.

4.2.3 Types of SOA

The intentional design of technology architecture is very important
to successfully implement SOC. The following types of technology
architecture exist underneath SOA [15].
1)

Service Architecture:
It refers to the architecture of a single service.

Services exist as

independent and highly self sufficient and self contained software

program requires that each be individually designed.

25

Abstraction (Information Hiding): In support of service

abstraction design principle their contents are often protected and hidden
from other project team members.

Design Standards: Various design standards are created and

followed at Endpoint, Application and Data level while designing

services.

Service Contracts: The technical contract expresses the scope

and nature of underlying capability. It is in form of XML schema

documents

(XSD) and WSDL (Web

Service

Description

Language)

documents and Service Level Agreements (SLA).

Service Agents: Event Driven Intermediary programs, capable

of transparently intercepting and processing messages sent to or from a

service.

Service Capabilities: Functionality offered by a service

resides within one or more capabilities.

2)

Service Composition Architecture:

The architecture of a set of services assembled into service

composition. Compositions are fully functional solutions capable of

automating larger, more complex business tasks. Security, Transaction
management, reliable messaging, and other infrastructure extensions may
all find way into typical composition architecture. When composition
architecture refers to another, it is called Nested Compositions.
3)

Service Inventory Architecture: The architecture that supports a

collection of related services that are independently standardized and

governed. The service inventory is first conceptually modeled leading to
the creation of service inventory blueprint.

26
12

4)

Service Oriented Enterprise Architecture: It represents all service,

service composition and service inventory architectures that reside within

a specific IT enterprise.
The following Figure4 represents the relative positions of the above
architectures in SOA.

Service Architecture
Service Composition Architecture
Service Inventory Architecture
Service Oriented Enterprise Architecture

Fi gur e4: La ye re d archi t ect ures.

4.2.4 Limitations of SOA

Where SOA is not to be used.
Following we highlight certain areas where SOA is not of much use [23].
1. Homogenous

IT

environment:

If

an

organization

uses

the

technologies of a single vendor then it is possible that the

additional overhead of an SOA would not be cost effective. This is
generally the case for small IT infrastructures like running a
website. Homogeneity can be at hardware, software infrastructure,
applications and data level.
2. True real time systems: SOA relies on asynchronous communication
to provide loose coupling between service consumers and producers.

27

It is not well suited to situations that require strictly enforced

response times.
3. Old legacy systems: If the existing legacy system not requires and
not expects any change in business logic, presentation, data flow,
process or any other aspect of the application then there is no need
to convert the application to SOA based.
4. Tight Coupling is required: Loose coupling is required for enabling
communication in distributed computing environment, however if
the communication need to know the details of the other end or if
developer controls all the components at once then the components
need to have an intimate understanding. So if you require tight
coupling for high performance communications among components
then SOA may not be appropriate.
Barriers of SOA
Hindrances on the way of implementing SOA can be at organizational,
technical or at security level [15]. Some of these are discussed below:
1.

Immutable Interface: Any change in a web service due to any

reason may require a change in the interface, which may further
break the service contract. Hence the updates are very hard to
accommodate.

2. Standards are not furnished: Although organizations like OASIS

(Organization

for the Advancement

of Structured

Information

Standards) are driving to develop standards for SOA, but the

standards on security and interoperability are not yet complete.
3.

Skill set:

SOC is new paradigm, hence finding the right

expertise is a challenging task.

4.

HTTP Protocol: Web Services is the fundamental approach

implementing SOA. It uses HTTP to send and receive messages
between users and service providers. It is a stateless unreliable
protocol. Newer protocols such as JMS, ESB supported by web

28

services allow automatic handling of failure mechanisms which

cannot be handled by HTTP.
5.

XML Parsing: Parsing of XML (Xtensible Markup Language)

is a time consuming process and directly proportional to the
complexity of the XML data transferred between user and the
service. Although newer technologies like XPP (XML pull parsing)
are introduced, but there application is limited.

6.

Reliability: Reliability on a third party unknown service is a

major issue in SOC. For e.g. Web services are based on unreliable
open internet connection, can be invoked by unknown parties and
involve runtime discovery and dynamic binding.

4.3 Design Patterns

Concept introduced by Alexander Christopher. They are the proven
solution to a common problem individually documented in a consistent
format and usually as a part of a larger collection. They are generally
repeatable by most IT professionals involved with design and can be used
to ensure consistency in how systems are designed and built. Design
pattern should have a consistent profile format and structure based on
certain templates. These are used in most of the popular design patterns.
4.3.1 Design Pattern Template
Each

pattern

description

must

follow

consistent

rhetorical

structure called the pattern template. There are many pattern templates
viz. Alexanderian form consisting of name, problem and solution in form
of diagram and description, Micro-pattern template containing name,
problem and solution in precise manner, Inductive Mini pattern consisting
of Name , context, forces and solution and many other [37]. A system of

29

pattern templates comprises of the following elements, explained as the

element followed by their context:
Name: What is this pattern called?
Also Known As: What are other names for this pattern?
Example: What is an example of the need for this pattern?
Context: When does this pattern apply?
Problem: What is the problem solved by this pattern?
Solution: What is the underlying principal underlying this pattern?
Structure: What objects are involved and related?
Implementation: What are some guidelines for implementing this pattern?
Variants: What are important variations of this pattern?
Known Uses: What are real world systems using this pattern?
Consequences: What are the benefits and liabilities of using this pattern?
See Also: What are related patterns and how do they differ?
Many best practices in the form of design patterns have been
defined for SOA. Since services, service inventory, service composition
are basic elements of service orientation, SOA design patterns have been
classified as service inventory design patterns, service design patterns,
service composition design patterns and common compound design
patterns.

4.4 Antipatterns
Antipatterns describe a commonly occurring solution to a problem
that generates negative results i.e. seemingly well but in fact, wrong
solutions. Design patterns and antipatterns are closely related. Former
defines commonly applied solutions to well known problems, while later
are the specific repeated practices that initially appear to be beneficial but
ultimately result in undesirable consequences. An essence of antipattern is

30

two solutions. First is the commonly occurring problematic solution that

generates wrong results, another is the re-factored solution i.e. the
resolved, reengineered and beneficial form of antipatterns. Those that
describe only the negative solution are called pseudo antipatterns [37].
4.4.1 Antipattern viewpoints:
There are three major viewpoints in which the antipatterns can be
discussed: the software developer, the software architect and the software
manager. Hence the antipatterns

can be discussed as development

antipatterns, architectural antipatterns and management antipatterns.

Development or Design Antipatterns : They describe situations encountered
by the programmer when solving programming problems. The antipatterns
encountered in programming and code management, i.e. at the lowest
level, are the design antipatterns. Popular design antipatterns include the
Blob, Lava flow, Poltergeists, Dead end, C-P programming, Mushroom
management etc.
Architectural Antipatterns : Architecture provides a view of the whole
system through different viewpoints. Architecture antipatterns focus on
system

level

and

enterprise

level

structure

of

applications

and

components. Antipatterns that occur in defining and maintaining large

structures

of

the

system

are

architecture

antipatterns.

Software

architecture is distinguished from development in many ways. The

architect takes into account the cost of their decisions. He is responsible
for managing complexity. Architecture focuses on three aspects of design
viz.

Partitioning,

Interfaces

and

Connections.

These

decisions

are

implemented by a much larger group of developers. There are significant

challenges for architects for example communicating the design to
developers, managing the implementation and extension of the design.

31

Popular antipatterns in this category include Stovepipe systems, Re-invent

the wheel, Swiss army knife etc.
Management Antipatterns: Traditionally management chains conveyed
information

across

organizational

boundaries

whereas

in

electronic

organization communication can occur seamlessly across space, time, and

boundaries. However managers still play important roles in the areas of
software

process

management,

resource

management,

and

external

relationship management. Antipatterns related to management i.e. in

adoption, management of system and people, fall in the category of
management

antipatterns.

Common

management

antipatterns

include

Blowhard jamboree, Analysis paralysis, Intellectual violence etc.

4.4.2 Antipattern Templates:
Patterns have a problem and a solution while antipatterns have two
solutions (instead of a problem and a solution). The first solution
generates negative consequences (forces that must be resolved).The
second solution is a migration (or refactoring) from the first solution that
provides dramatically improved benefits and much reduced consequences.
Like design patterns, antipatterns should also follow a general profile
format for their representation [9]. Following are the some of the
antipattern templates used to describe antipatterns:
PseudoAntipattern Template:

Name: What is the Antipattern called?

Problem: What are its characteristics?

Mini Antipattern:

Name:

What

shall

practitioners?

32

this

Antipattern

be

called

by

Antipattern Problem: What is the recurrent solution that

causes negative consequences?

Refactored Solution: How do we avoid, minimize, or

re-factor the Antipattern problem?

Full Antipattern Template:

It comprises of a number of required and optional sections. The core
sections are the general form of the antipattern and the re-factored
solution.
Antipattern Name: The Antipattern name is a unique

noun phrase. The name is used for future reference to the principles
contained

in

the

antipattern.

They

form

the

basis

for

an

organizations terminology when members discuss and document

software and architectures.
Also Known As: This identifies additional popular or

descriptive names and phrases for this Antipattern.

Most

Frequent

Scale:

This

identifies

where

Antipattern fits into the software design level model.

this
Each

antipattern is logically placed in the scale where it is most

applicable. The scale can be any of the following levels:
- Object level: It is concerned with the development of reusable
objects and

classes.

- Micro architecture: It involves patterns that combine multiple

objects or object classes.
- Framework: This level includes patterns at the macro component
level, involving one or more micro architectures.

33

- Application: Applications typically involve numerous object

classes, multiple micro architectures, and one or more frameworks.
- System: A system comprises several integrated applications, which
provide the functionality. It also adds interoperation between the
applications

- Enterprise: The enterprise level is the largest architectural scale

within an organization. Enterprise level software comprises multiple
systems, where each system comprises several applications
- Global/industry: The global level is the largest scale of the
architectural levels, comprising multiple enterprises.

Re-factored Solution Type: It identifies the type of action that

results

from

the

Antipattern

solution.

It

can

be

software,

technology, process, or role. Software indicates that new software is

created by the solution. Technology indicates that the solution
entails acquisition of a technology or product. Process indicates that
the solution entails pursuing a process. Role indicates that the
solution entails assigning responsibility to an individual or group.

Root Causes: These are the general causes for the antipattern. They
can be one or more of the following values
- Haste: It is popularly said Haste makes waste. Hasty decisions
lead to compromises in software quality. As successive project
deadlines are missed, anything that appears to work is considered
acceptable, regardless of quality.
- Apathy: It refers to not caring about solving known problems. It is
a basic unwillingness to attempt a solution.

34

- Narrow-mindedness: It is the refusal to practice solutions that are

otherwise widely known to be effective.
-

Sloth:

Distributed

object

technology

enables

application

developers to define system level interfaces quickly using the ISO

Interface Definition Language (ISO IDL). Automatically generated
interface stubs and skeletons make the task of constructing a
distributed system relatively easy. The ease of creating and
changing interfaces leads to the deadly sin of slothlack of
configuration control.
- Avarice: Architectural avarice means the modeling of excessive
details, which results in excessive complexity due to insufficient
abstraction.
- Ignorance: It is the result of failing to seek understanding. The
problem of ignorance (implementation dependency) often occurs in
the migration of applications to distributed architectures.
- Pride or responsibility: Often, developers unnecessarily invent
new designs when knowledge from preexisting systems, products,
and standards are readily applied through architecture mining.
Reinvention involves many unnecessary risks and costs.

Primal Forces: Forces are concerns or issues that exist within a

decision-making context. In a design solution, forces that are
successfully addressed (or resolved) lead to benefits, and forces that
are unresolved lead to consequences. The choices include any of the
following:
-Management of functionality i.e. meeting the requirements.
-Management of performance refers to meeting the required speed
of operation.

35

-Management of complexity means defining abstractions.

-Management of change controlling the evolution of software.
-Management

of

implementation of

IT

resources

refers

to

controlling

use

and

people ad IT artifacts.

-Management of technology transfer refers to controlling the change

in technology.

Background: This is an optional section. The background can

contain further examples of where problems occur or general
background information that is useful or interesting.

Symptoms and Consequences: This is a list of symptoms and

consequences that result from this Antipattern.

Re-factored Solutions. This section explains a re-factored solution

that is structured in terms of solution steps.

36

Chapter-5
SOA Antipatterns
There are various problems in adaptation of SOA, which result into
the dissatisfactory performance of SOA projects. These problems are to be
seriously catered; hence practitioners have started addressing different
bad or worst practices of SOA implementation in form of antipatterns.
Antipatterns proposed by different organizations have been fragmented
and have been focusing on the complete SOA life cycle i.e. from the
origin of concept to realization. The pioneer work on the subject focused
primarily on object oriented antipatterns. It should be known that object
oriented patterns and service oriented patterns have a subtle difference
between them. Some of the object oriented design patterns form the major
antipatterns for SOA such as No legacy Antipattern and vice versa.
The full antipattern template as described in the previous chapter
comprises of number of required and optional sections. The core sections
are the general form of the antipattern, and they specify the name, root
cause, primal forces, description, the name of the antipattern to which the
current antipattern is similar to, background, consequences, variations,
known exceptions, example, related solution etc.
The SOA antipatterns discussed below utilize this template to
document the common dysfunctional practices in the adaptation of SOA. It
specifies the name, root cause, primal forces, description and the name of
the antipattern to which the current antipattern is similar to.
5.1 SOA Antipattern Categories

37

Antipatterns in SOA can also be classified primarily on the basis of

classification of traditional antipatterns, as SOA management antipatterns,
SOA architecture antipatterns and SOA development/ design antipatterns .
5.1.1 SOA Development Process antipatterns
Development process comprises of all activities that have to be
performed

in

development
management,

order
of

to

arrive

SOA based

resource

at

an

implemented

applications

management,

includes
and

system.
software

external

Initial
process

relationship

management. Antipatterns related to such aspects of the development

process i.e. in adoption, management of system and people, fall in the
category of SOA development process antipatterns as shown in Table 1.
Tabl e 1: S OA Devel opm ent Process Ant i pat t erns

5.1.2 SOA Framew ork antipatterns

Framework provides a view of the whole system through different
viewpoints. It focuses on system level and enterprise level structure of
applications and components. SOA antipatterns that occur in defining and
maintaining

large

structures

of

the

38

system

are

SOA

framework

antipatterns. The following antipatterns focus on some common problems

and mistakes in the creation, implementation, and management of SOA
framework. These are listed in Table 2.
Tabl e 2: S OA Fram ework Ant i pat t erns

5.1.3 SOA Design antipatterns

The

antipatterns

encountered

in

programming

and

code

management, i.e. at the lowest level are the SOA design antipatterns as
shown in Table 3. Patterns in IT that revolve around the design of
automated systems are called design patterns. Many of the SOA design
patterns have their origin and influences to established design concepts
and pattern catalogue of object orientation, enterprise application and
software architecture in general.
Design patterns concentrate on design, development and realization
of SOA. Design antipatterns focus on the worst practices encountered in
programming and code design. Their knowledge is useful for the

39

practitioners while, they work on designing services. Designing of

service oriented systems involves the design of service inventory, service
compositions and lastly services. On the basis of these, we further
categorize SOA design antipatterns as follows:
-

Service inventory design antipatterns

Service composition design antipatterns

Service design antipatterns

General compound design antipatterns.

Tabl e 3: S OA Desi gn Ant i pat t erns

These antipatterns are described individually with the following

template: name, also known as, root cause, primal forces, description and
re-factored solution. The term re- factored solution is the description of
the positive consequences, after the re-factoring i.e. when the antipattern
solution has been applied.

40

5.2 Conclusion
SOA antipatterns have been classified as SOA development process,
SOA framework and SOA design antipatterns. It has been observed
that amongst the large number of addressed SOA antipatterns, failures
are mainly due to limited number of interrelated antipatterns focusing
mainly

on

the

SOA

design.

Interrelationships

categorized antipatterns could also be established.

41

between

these

Chapter-6
Proposed SOA Antipatterns
In order to fulfill the main objective of identifying new antipatterns,
certain domain areas were identified as most error prone areas of SOA
implementation, hence probable areas of finding new antipatterns. This
was on the basis of the implemented module, case studies and study of the
subject.
Viewing at different architectures underneath SOA as described in
chapter 4, designing of a Service oriented application can be further
broken up as service design, service composition design and service
inventory design. Hence the SOA design is further categorized as
1) Service Design (SD)
2) Service Composition Design (SCD)
3) Service Inventory Design (SID)
4) Service Oriented Enterprise Design (SOED)
The identified domain areas prove to be the weaker links of SOA and
need to be implemented correctly and carefully. Following are the
considered domain areas, the category in which they may be include is
mentioned in brackets:
i)

Concept of Service (SD)

ii)

Service Scalability/Load Balancing (CD)

iii)

Service discovery (CD)

iv)

Service Composition (SCD)

v)

Data Sources

(CD)

42

vi)

Security (SID)

vii)

Change request (SID)

The study of the above domain areas could be a major research area.

Following are the observed common ways of implementing SOA but which
later proved to be wrong way, hence can be identified as Antipatterns.

6.1

SOA=SOAP
Newbies implementing SOA often consider that, the three standards

that enable implementation of Web services are the Simple Object Access
Protocol (SOAP), Web Services Description Language (WSDL), and
Universal Description, Discovery, and Integration (UDDI). Here, SOAP is
an XML-based protocol to support communication between a Web service,
its clients, and UDDI registry. WSDL is an XML-based standardized
interface definition language used to describe what a Web service can do,
where it resides, and how it can be invoked. A WSDL file associated with
a Web service contains important details about the Web-service interface
for client-service interaction.
UDDI standard is used to publish, discover, and manage Web
services in an UDDI registry. Although it is a good and most preferred
way to implement web services, the other ways to create light weight
services should also be preferred. A REST-Web service is basically a
simplified

model

where

everything

is

wrapped

around

the

HTTP

send/receive protocol.
Using services based on SOAP envelop always, may be an overhead,
whereas that same work could be done using lightweight approach like
REST (Representational State Transfer) using traditional methods. The
main responsibility of accessing the service in the SOAP-WSDL process

43

lies on the consumer. He will have to programmatically extract the Web

service SOAP message in order to do something useful with it in the
application.
Although core services holding logic should be bind in an SOAP
envelop but simple data handling services , CRUD operations should be
implementing using traditional Http methods viz. GET, PUT, POST,
DELETE i.e. through RESTful way. REST emphasizes resources with a
uniform interface for addressing them, while SOAP based RPC emphasizes
processes with a uniform interface for invoking them. With a RPC-based
architecture, there is no limit to the number of processes. In REST we can
everything get by only four basic methods GET, POST, PUT and DELETE
of the Http standard, and make the resource addressing handle the
variability.
For services representing basic CRUD (Create, Read, Update,
Delete) operations REST way of implementing services is simpler and
lightweight.
6.1.1

Refactored Solution
In the development of Web service based SOA applications, the

designing of services should not be adamant to a traditional style but

other approaches should equally be used when and where required.
Following, we compare both the approaches and depending on the
requirement, appropriate method for implementing services could be
selected. Both these approaches are not the counterparts and can be used
together in the same application.

44

a) Approach
REST and SOAP are parallel ways of implementing web services.
Let us first discuss the two different approaches of implementing web
services.
RESTful Web Services
REST is an architectural style that prescribes the use of standards
such as Http, URL, Resource representations (XML, HTML, Gif etc.),
MIME Types etc. [11].
The RESTful web service makes available URL to a resource and it
may allow the client to specify the format of the returned resource i.e.
HTML or an XML document. The service itself may be described using
WSDL (Web Service Description Language) or WRDL (Web Resource
Description Language) and can be accessed either as a resource or using
JSON (Java Script Object Notation). RESTful services are stateless; each
request from client to server must contain all necessary information. All
resources are accessed with generic interface (Http GET, POST, PUT,
DELETE). These resources are named using URI (Uniform Resource
Identifier). The client may progress from one state to another using
interconnected URL representation.
SOAP Based Web Services
In this method provider creates and implements a web service
interface onto an existing application. He has to create a XSD (XML
Schema Document) and WSDL contract in order to distribute the Web
service details to potential consumers. Consumer obtains WSDL contract
for consumption through UDDI registry. Then the consumer implements
the WSDL in a specific platform - Java, C#, PHP, Perl - and creates a
caller application.

45

Client

sends multiple

requests using the same

URL for all

transactions. It is the responsibility of the SOAP server to a parse the

SOAP message and determines which method to invoke. The returned data
would not contain any URL, since a URL that points to a SOAP service is
just to the SOAP server. In REST all decisions are made based upon the
URL and the Http method selected while in SOAP, server receives all
messages, peeks into the SOAP envelop and then distributes each message
to the appropriate application for processing.
b) Proxy servers
Proxy servers play a major role as web intermediaries for a web
application. Below we briefly discuss their functionality for a web
service.
REST
In it the URL identifies the resource that is desired. The Http
method identifies the desired operation. The Proxy server decides based
upon the identified resource and the Http method whether or not to allow
the operation. Using XLink (the XML hyperlink technology) in addition to
providing a URL to the target resource, data about the resource could also
be provided using Xlink:role. The application can dynamically make
decision about what resource to access next.
SOAP
In SOAP based approach, proxy server cannot directly allow or
disallow the message since it is unaware of the desired contents or
resources. Either the proxy server should understand the semantics of each
SOAP application that a client will access, but for that the proxy server
will need to be updated for each new SOAP application.

46

c) Caching
It refers to the ability to maintain a copy of the desired resources in
order to improve the performance.
REST
The result of a resource contains an indication in the Http header of
whether the results are cacheable or not. If it is, cache servers make a
local copy, which can be returned for the same request if repeated .
SOAP
A SOAP message is always with a POST method, which makes the
cache server unaware of the actual intension of the request type (GET or
POST). Moreover the SOAP URI is always to the SOAP server which
prohibits the cache server again from knowing the actual resource
requested. Hence no caching is possible with SOAP.
d) Generic Interface
Generic

interfaces

imply

generalized

functionality

and

hence

support scalability whereas application specific or custom interface

interfaces may need some additional functionality to be called in a generic
context.
REST
In REST every resource has a generic interface namely Http GET,
PUT POST, and DELETE which enable caching and proxy servers to do
their work.

47

SOAP
There is no defined set of methods. Any type of methods could be
defined which makes customization on application basis and reduces
scalability.
e) Interoperability
Interoperability

means

sharing

the

data

amongst

multiple

applications. The more interoperable software programs are, the easier it

is for them to exchange information.
REST
Interoperability

is

based

on

standardization.

REST relies

on

standards of addressing and naming resources (URI), resource interfaces

(GET, POST, PUT etc.), representations (HTML, XML etc.), and media
types (MIME types).
SOAP
In this approach, each SOAP message provides its own unique
method of naming a resource moreover each SOAP application defines its
own interface hence interoperability is possible only for closed systems
where all participants are known prior.
REST and SOAP do not replace each other, each of them have their
uses but when making high performance and client rich websites REST
can provide a significant improvement.
Traditional way of implementing SOA only through SOAP also leads
to other antipatterns. REST style needs no registry and makes resources
directly available hence it also helps in overcoming the following two

48

antipatterns viz. Discovery of web service through UDDI and Using plain
WSDL to define service interface.
6.1.2

Standard Representation
Following

the

Standard

Antipattern

Template

[14]

and

SOA

Antipattern Template [37], the above proposed antipatterns can be

described as follows:
Antipattern Name: SOA==SOAP
Also known as/ similar to : Not Applicable
Root Cause: The common and fundamental reasons for the problem can be
coined as haste, apathy, ignorance.
Primal Forces: These are certain architecture and development related
concerns or issues present in most decision making context. They greatly
affect the design and development process and in this case it can be
management of functionality and management of technology transfer.
Misuse of these above mentioned forces leads to the development of this
antipattern.
Description :

SOAP-WSDL

is

considered

to

be

the

only

way

of

implementing SOA by companies implementing SOA for the first time.

Solution :

Although

SOAP-WSDL

is

the

established

way

of

SOA

implementation through web services but other alternative ways like REST
should be equally considered. For CRUD applications RESTful services
should be preferred and for application specific services holding core
logic SOAP based services should be preferred.

49

Implementation
The above antipatterns were derived after final implementation of
both the ways of implementing web services i.e. SOAP and REST.
Following are few screenshots of their implementation i.e. SOAP-WSDL
based web service in .Net through Visual Studio 2008 and REST Based
web service in java through Netbeans7.0.1.
Figure5 represents a structure of SOAP based service. It shows various
methods which are application specific and need not have a generic
structure.

Fi gur e5: S t ruct ure of S OAP based servi ce

50

Figure6 shows the structure of REST based service. It reflects certain

methods like getJSON() to retrieve java script object notation form of
data, getXML() to retrieve its XML format.

Fi gur e6: S t ruct ure of R ES T based servi ce.

51

The figure 7 and figure8 below show the interface of the two services developed.

Figure7: SOAP based web service.

Note the presence of

Links which refer to URI
and return individual
details through get
method.

Figure8: REST based web service.

52

The Figures 9 and 10 below show the WSDL for SOAP based service and WADL for
REST based service.

Figure9: WSDL file for the SOAP based web service.

Figure10: WADL file for the REST based web service.

53

The next set of figures11 and 12 represent the checking of availabilty of the user ids. In
REST Http get method is used while in SOAP appropriate application specific methods
are used.

54

Figure11: Verification in SOAP based service

The id is
checked
through get
method for the
availability

Figure12: Verification in REST based service

6.2

Using Plain WSDL to define all service interfaces.

WSDL (Web Service Description Language) is used to define

service interfaces. It describes two different aspects of a service: its

signature (name and parameters) and its binding and deployment details
(protocol and location).
WSDL describes services in three layers:
Layer 1: It describes the interface of a service. Layer 2, describing the
binding of a web service i.e. protocol and format for which web
operations are provided. Layer 3 defines the physical location i.e. address
URL where service is available.

55

WSDL does not contain full interface of a service, it does not have
any semantic information. A WSDL file does not specify how to access
next desired service, how long a service usually runs, who is allowed to
call it, how much a service call cost and many other non functional
attributes. All these aspects must usually be known in order to manage a
service in a large SOA landscape. With future WSDL versions this might
change.
6.2.1 Refactored Solution
Service Description should be provided in a separate format and
WSDL should be generated from it when required. WSDL files can be
extended internally with additional XML elements and attributes or
externally

with

supplementary

files

[43].

WSDL

allows

elements

representing a specific technology under various elements defined by

WSDL. These elements are known as extensibility elements.
Extensibility elements allow vendors to expose their Web Services
as EJBs, Remote Java Objects and .NET objects without having to write
SOAP bindings for them.
Currently, the WSDL specification introduces specific binding
extensions for the following protocols and message formats:
- SOAP
- HTTP GET/POST
- MIME
Using the extensibility mechanism a service developer can describe
commonly used services such as EJB, .NET and Java Objects. The
consumer of the service can use the WSDL and generate the necessary
client side stubs to invoke the endpoints in the native protocol. This
approach has a several advantages. The service developer does not have to
spend time in exposing his service with SOAP bindings. Also, invocation
of the service will be faster since the call will occur over the native

56

protocol, and less time will be spent for SOAP marshalling and unmarshalling. A service can have multiple bindings associated with it and
the consumer of the service will have the choice of selecting one binding
or the other.
Implementation
The figure13 below show the standard WSDL file for a simple web
service in java.

Fi gur e13: S t andard WS D L repres ent i ng a servi ce.

In the code segment below the information for locating the EJB is
stored in <ejb:port> section of the WSDL definition and the information
for invoking the EJB is stored in the <wsdl:binding> section.

57

Fi gure14: Code represent i n g WS DL ex t ensi ons usi ng WS D L4J .

6.2.2 Standard Representation

According to SOA Antipattern Template [37], the above proposed
antipatterns can be described as follows:
Antipattern Name: Using Plain WSDL to define all service interfaces.
Also known as/ similar to: Not Applicable
Root Cause: It can be the result of haste, sloth and ignorance.
Primal Forces: Management of change, management of complexity and
management of technology transfer.
Description : Simple WSDL describes only two different aspects of a
service:

its

signature (name

and parameters)

and its

binding and

deployment details (protocol and location). This does not describe various
non functional attributes like how to access next desired service, cost of
service etc.
Solution: WSDL files can be extended internally with additional XML
elements and attributes or externally with supplementary files. Certain

58

extensibility mechanisms have been defined for specific purposes like,

those supported by WSDL4J for ejbs. Techniques for defining WSDL
extensions have been proposed [12] and are one of the major research
areas in WSDL.

6.3

Discovery of web service only through UDDI

In a real SOA enterprise infrastructure with hundreds of services, it

is safe to assume that service endpoints are going to constantly be

subjected to changes in areas such as location (URL), policy (security,
etc) or contract (WSDL, operations).
A common practice to accomplish that is to have client application
to resolve service metadata such as endpoints or policies against a service
repository.

In

order

to

address

these

challenges,

the

big

SOA

vendors (Microsoft, Oracle, IBM etc) created a standard that with the
purpose of modeling service metadata information that could be used to
enable service discovery capabilities. The standard was known as
Universal Data Discovery and Integration (UDDI) and, unfortunately, it
became the cornerstone of SOA governance products. UDDI has proven to
be an incredibly ineffective mechanism to enable service publishing and
discovery. The SOA models created with UDDI are incredibly complex to
implement and use and, quite often, end up becoming another bottleneck
of SOA.
6.3.1 Refactored Solution
While building SOA application, the complexities of UDDI should
be avoided and instead use a simpler mechanism to facilitate the discovery
and query of services. This can be achieved by implementing a 100%
RESTful API that allows querying the entire service registry using plain
HTTP GETs. No requirement of centralized registry. More advantages of
REST are discussed in previous section. User defined or application

59

specific registries can also be defined like Oracles OSR (Oracle service
registry), But these application specific registries are very complex and
far from the reach of a simple programmer.
6.3.2 Standard Representation
According to SOA Antipattern Template [37], the above proposed
antipatterns can be described as follows:
Antipattern Name: Discovery of web service through UDDI
Also known as/ similar to : Not Applicable
Root Cause: It can be haste, sloth and ignorance.
Primal Force s: Management of performance, management of IT resources
and management of technology transfer.
Description : Since SOA literatures and previous implementation of the
technology, effectively present the usage of UDDI as the central registry
for SOA services, the new small projects consider it to be an undetachable component of SOA. The truth lies behind the fact that UDDI is
incredibly complex and difficult to implement. Even and Microsoft have
refrain from their UDDI registries. In such case adhering to UDDI seems
to be right but in fact not the perfect way of service discovery.
Solution : Customized registries according to the application should be
created. Various other registries using JNDI (Java Naming and Directory
Interface), OSR (Oracle Service Registry) can also be used in an SOA
application. REST based services should be prefered for data access
services. They are directly accessed through URIs hence require no
central registry.
Implementation

60

This antipattern can also be easily observed in the implemented

module. The REST services are available as URIs hence require no
service registry.

Resources
are available
as URI

Fi gure14: RES T based servi ce di scovered t hrough UR Is.

6.4

Service for an application

In the development phase of the module it has been observed that

the first step in implementation of SOA, if taken mistakenly can prove to

be a useless investment. Services are supposed to be designed for
achieving main goals of SOA viz. reusability, interoperability, increasing
organizational agility etc. Many IT developers with object oriented
experience implement SOA in the way they started Object oriented
software.
Services are designed application specific. No enterprise level
service classification is involved. Service just become another way of
creating an application, hence, provides no business benefits. Large
numbers of services are designed, leading to another antipattern: Service
Silos. These services have little or no reuse across applications.

61

6.4.1 Refactored Solution

Proper training and education of basic SOA goals and principles
should be given to the involved members before the actual work begins on
the project.
The service design should also follow basic SOA design principles
as mentioned in Figure7 [45]:
1) Standardized Service Contract: Services in the same inventory should
follow same design contract.
2) Service Loose Coupling: Services should be loosely coupled with
customer requirements and their own surrounding environments.
3) Service Abstraction: Service contract should contain only the essential
generic information.
4) Service Reusability: Services should have reusable enterprise logic.
5) Service Autonomy: Services should be autonomous i.e. their runtime
environment should be under their control.
6) Service Statelessness: State information should not be maintained with
service itself.
7) Service Discoverability: Services should be effectively discovered and
interpreted through suitable mechanisms.
The Figure7 below represents various service design principles.

62

Service

Fi gur e 7: Desi gn pri nci pl es pl ayi n g t hei r rol e in creat i on of a servi ce [ 45] .

6.4.2 Standard Representation

According to SOA Antipattern Template
antipatterns can be described as follows:

[37], the above proposed

Antipattern Name: Service for an Application.

Also known as/ similar to : Not Applicable
Root Cause: It can be haste, apathy, sloth and ignorance.
Primal Forces: Management of functionality, management of change,
management of complexity and management of technology transfer
Description : Services are built for use within an application forgetting the
basic service design principles.
Solution : The services should be classified as intra application and inter
application.

Inter

application

services

should

be

designed

for

interoperability. Application specific services if required should be at the

63

lowest level and callable only by the generic services providing interface
to the service consumer. Services at lowest level should further be
properly identified as entity services, task services and utility services
[15]. Services should essentially follow basic design principles for a
successful SOA implementation.

64

Chapter-7
Results and Conclusions
7.1 Results
Service Oriented Architecture is the latest design paradigm for
distributed applications. It has not been able to gain acceptance by
mediocre and small companies as expected, even though software giants
are shifting towards service oriented applications. The reason behind
appears to be the complexity of SOA implementation and initial failed
projects.

After

careful

study

of

various

SOA

projects

and

its

implementation certain root causes of the SOA revulsion were identified

and presented in the given work as antipatterns. The main focus in the
submitted work was identification of new SOA antipatterns.
It has been observed that amongst the large number of addressed
SOA

antipatterns,

failures

are

mainly

due

to

limited

number

of

interrelated antipatterns focusing mainly on the SOA design. Four

antipatterns SOA=SOAP,

Discovery of web service through UDDI, Using

Plain WSDL to define all service interfaces, Service for an application

were identified and represented. The above conclusions and derivations
were based on the case studies and SOA implementation, using both,
SOAP based and REST based services. The codes were developed in .Net
and Java using VS2008 and NetBeans7.0.1 respectively.

7.2 Conclusions
Categorization

of

SOA

antipatterns

as

development

process,

framework and design will definitely help the developers to concentrate

on specific areas of SOA design. Identification of weak domain areas in
SOA implementation will open wide aspects for SOA research. It is

65

sincerely hoped that the identified four antipatterns will make SOA
programmers more aware of the commonly made mistakes in SOA design
and implementation.
In our study we importantly laid stress on SOA design antipatterns.
Some of the domain areas such as Request change, data handling have
been left unexplored and few more antipatterns can be identified. A
framework for building SOA applications could also be developed which
would

integrate

various

features

necessary

features

for

SOA

implementations. WSDL extensions could also be defined for other

approaches other than java and .Net. The concept of service registry
should be simplified and a simpler tool than the existing ones should be
developed.

66

Our Contribution
[1] D. Tripathi, Development Trends and Evolution of SOA ,
Proceedings of National Conference on Emerging Trends in
Mechanical, Electronics and Computer Engineering, held at IIST
Indore on 17 t h & 18 t h April 2010, pp 139-143.
[2] D. Tripathi, U. Suman, M. Ingle. A Systematic Review of
Antipatterns

in

SOA ,

Proceedings

of The

International

Conference on Computing Business Application and Legal

Issues, Ghaziabad, 3-4 march2011, pp 1-7.

67

REFERENCES
[ 1] L. S ri ni vasan, An overvi ew of S ervi ce Ori ent ed Archi t ect ure, Web S ervi ces and
Gri d Com put i ng, HP (Hewl et t P ackard) Whit e P aper, Novem ber 2006.
[ 2] D. J ana, Obj ect Ori ent ed Technol ogi es, C SI Journal , Febru ar y 2008, pp 4-5.
[ 3] htt p: / / en.wi ki pedi a.org/ wi ki / C om ponent - based soft ware engi ne eri n g.
[ 4] S . Chat t erj ee, An Int rodu ct or y Overvi ew of Web S ervi ces, C SI Journal , March
2007, pp 6- 12.
[ 5] K. Kal ai sel van, P. Venat a Kri shna, Gri d t o C l oud (G2C ) - A i nfrast ruct ure based
t ransi t i on, C SI Journal , Febru ar y 2010, pp 22-25.
[ 6] htt p: / / en.wi ki pedi a.org/ wi ki / C l oud_com put i ng.
[ 7] S . Zhang, X. Huo, X. Chen, C l oud Com put i ng R esearch and Devel opm ent Trend,
Second Int ernat i onal Conf erence on Fut ure N et w orks , 2010.
[ 8] L. Hanchen g, Desi gn of S aaS -based Soft ware Archi t ect ur e,
C onf erence on N ew Trends in Inf ormat i on and Servi ce Sci ence , 2009.

Int ernat i onal

[ 9] D. C happel l , Int roduci n g Windows Az ure, sponsored by Mi crosoft Whit e P aper,

March 2009.
[ 10] D. J ana, S ervi ce Ori ent ed Archi t ect ur e- A new P aradi gm , CSI Journal , March
2006, pp 12- 15.
[ 11] T. Erl , S OA: P ri nci pl es, C oncept s and Techni qu es, 1st Edi ti on P rent i ce Hal l ,
2009.
[ 12] A. Kont ogogos, P. Ageri ou, An overvi ew of Soft ware Engi neeri n g approach es t o
S ervi ce Ori ent ed Archi t ect u res i n vari ous fi el ds, 18t h IEEE Int ernat i onal Work shop
on Enabl i ng Technol ogi es, 2009.
[ 13] D. Tri pat hi , Dev el opm ent Trends and Evol uti on of S OA, P roceedi ngs of
Nat i onal Conferen ce on Emergi ng Trends i n Mechani cal , El ect roni cs and C omput er
Engi neeri ng , hel d at IIS T Indo re on 17t h & 18t h Apri l 2010, pp 139-143.
[ 14] J . Evdem on, P ri nci pl es of S ervi ce Desi gn: S ervi ce P att erns and Ant i pat t erns,
Mi crosoft Corporat i on, Archi t ect ur e S t rat egy, August 2005.
[ 15] T. Erl , S OA: Desi gn P at t erns, 1st Edit i on P rent i ce Hal l , 2009.
[ 16] G. Farrow, S OA Ant i pat t erns, IB M Whi t e paper, June 2009.
[ 17] J. Kral , M. Zem l i cka, The Most Im po rt ant S ervi ce Ori ent ed Ant i pat t erns,
IC SEA 2007.
[ 18] S OA Ant i pat t erns: How not t o do servi ce Ori ent ed Archi t ect ure , Oracl e Whi t e
P aper i n Ent erpri se Archi t ect ur e, J anuar y 2010.

68

[ 19] H. Haci gum us, Ant i pat t erns: Int e gr at i ng Dist ri but ed and Het erogenous Dat a
S ources i n S OA, IEEE Congr ess on servi ces, www.IE EEXpl ore 2008.
[ 20] J . Kral , M. Zem l i cka, P opul ar S OA Ant i pat t erns, Com put at i on Worl d: Fut ure
C om put i ng, S ervi ce C om put at i on, C ogni t i ve Cont ent , P at t erns, 2008.
[ 21] D. Tri pat hi , U. S um an, M. In gl e, A S yst em at i c R evi ew of Ant i pat t erns i n S OA ,
P roceedi n gs of The Int ernat i onal C onf erence on Comput i ng Busi ness Appl i cat i on and
L egal Issues , Ghaz i abad, 3- 4 March 2011, pp 2-7.
[ 22] M. Endrei , J . Ang, A. Arsanj ani , S . C hua, P. C om t e, P. Krogd ahl , M. Luo, T.
Newl i ng, P at t erns: S ervi ce Ori ent ed Archi t ect ure and Web S ervi ces, IBM R edbook,
Apri l 2004.
[ 23]

C . S at i sh, Bar ri ers

of S OC , P roceedi ngs

of t he

Second

Wor kshop

on

Int roduci ng Servi ce- Ori ent ed Comput i ng WISOC , 2007.

[ 24] S . Moosavi , M. S e yya d i , A m et hod for S ervi ce Ori ent ed Desi gn, 6t h
Int ernat i onal C onf erenc e on IT, N ew Generat i ons , 2009.
[ 25] J. P. Ha yes , K. Ford, Ant i pat t erns i n the creat i on of Int el l i gent S yst em s , Hum an
C ent ered C om put i ng, P ubli shed by IE EE com put er S oci et y 2007.
[ 26] N. Mi l anovi c, S ervi ce Engi neeri n g Desi gn P at t erns,
Symposi um on Servi ce Ori ent ed Syst ems Engi neeri ng SOSE , 2006.

2nd

Int ernat i onal

[ 27] soa- rm -cs.pdf -Oasi s refe renc e m odel for S OA 1.0, Com mi t t ee speci fi cat i on 2006.
[ 28]

C.

Sm it h,

L.

G.

Wil l i am s,

S oft ware

P erform an ce

Ant i pat t erns,

2nd

Int ernat i onal Work shop on Sof tw are Engi neeri ng and Research , 2008.
[ 29] htt p: / / www.S oaP at t erns.org .
[ 30] S . Chat t erj ee, A int roduct or y overvi ew of Web S ervi ces, C SI j ournal vol -29
i ssue- 9, March 2007, pp 6-12.
[ 32] J. fronckowi ak, S OA Best pract i ces and desi gn pat t erns, Whi t e paper,
www.Oracl e.com / t echnol o gi es , March 2008
[ 33] htt p: / / j ava.sun.com / devel oper/ t ech Art i cl es/ WebS ervi ces/ soa3/ l oanp roc essi ng.ht m .
[ 34] T. P andey, B. S i ngh, Aut hent i cat i on and Bi l l i ng Fram ework for S ervi ce Ori ent ed
Archi t ect ur es i n vari ous fi el ds, 4t h Int ernat i onal C onf erence on Syst ems , 2009.
[ 35] S . Puni t a, C . Babu, P erform anc e P redi ct i on Model for S ervi ce Ori ent ed
Appl i cat i ons, 10t h Int ernat i onal C onf erenc e on HPC and C ommuni cat i ons , 2008.
[ 36] Y. Zhao, S ervi ce Ori ent ed In fr ast ruct ur e Fram ework , IE EE Congr ess on
S ervi ces 2008.

69

[ 37] W. J . Brown, R. Mal veau, Ant i pat t erns: R efact ori ng soft ware, Archi t e ct ures and
P roj ect s in cri si s, 2nd Edit i on J ohn Wil e y & Sons, Inc, 1998.
[ 38] N. M. J osutt i s, S OA i n P ract i ce, 1st Edi ti on OR ei l l y Medi a, August 2007.
[ 39] M. Mabrouk, S OA fundam ent al s i n a nut shel l , Techni c al Art i cl e www.IB M.com ,
S ept em ber 2008.
[ 40] Mai nfr am e

S OA Im pl em ent at i on Best

P ract i ces, Techni c al

art i cl e, S OA

S oft ware, Apri l 2011.

[ 41] S . Til l ey,S O A Mi gr at i on C ase St udi es and Le ssons Lea rned , IEEE 2011.
[ 42] F. Zaoupa, D. Cowan, A S ervi ce- ori ent ed P rocess t o Devel op Web Appl i cat i ons,
Journal of Uni versal Comput er Sci ence , vol . 14, no. 8, 2008.
[ 43] C . Dai , A fl ex i bl e ext ensi on of WS D L t o descri be nonfunct i onal at t ri but es,
IEEE 2010.
[ 44] M. P. P apaz ogl ou, P. Trave rso, S ervi ce - Ori ent ed Com put i ng: St at e of t he Art and
R esearch C hall enges, IE EE C om put er S oci et y, Novem ber 2007.
[ 45] T. Erl , S OA: P ri nci pl es of S ervi ce Desi gn , 1st Edit i on P rent i ce Hal l , 2009.

70