ABSTRACT: A Beneficial SOA To Register Advantageous Cloud
Technology
Chinmoy Tarafdar, Ramendu Bikash Guin, Sayan Chakrabarti, Sourav Banerjee, Sourav Mandal
Dept. Of Computer Science & Engineering
Kalyani Government Engineering College
Kalyani, Nadia-741235, West Bengal(India)
E-mail: {chinmoykgec, ramenduguin, sayanchakrabarti7, contact200683, souravmandalhlr}@gmail.com
Abstract- Cloud Technology is a style of computing in
which dynamically scalable & virtualized resources
are provided as a service to the clients. Users need not
have to be aware of the technology or infrastructure
“in the cloud” that supports them. Service Oriented
Architecture (SOA) is the basis of it. SOA is the base
of cloud. SOA has several advantages &
disadvantages. Here in this paper we propose a
beneficial SOA in order to build a cost effective cloud.
A cost effective Orchestration Block is developed to
reduce the cost of SOA. This block will set aside the
unnecessary processes and pass only the required
services to build the business process. This reduces
the service complexity as well as the overall cost of
implementing SOA. Mr. David S Linthicum’s
formula for the cost of SOA has been used.
Service complexity has been calculated as per
the assumption of us.
Keywords – Cloud Technology, Service Oriented
Architecture, Loosely-Coupled, Third Party services,
Orchestration.
I. INTRODUCTION
Service Oriented Architecture (SOA), as the
name suggests refers to an architectural model that
shares various services available in the network
among the intended users. Services refer to the
business functions which are decomposed into
small, distinct units that are combined together to
form a business application [1].
One important feature of SOA is ---- it is loosely
coupled, that means services are abstracted from
the clients. The clients communicate with the
services via a well-defined interface. He does not
care much about the service implementation, such
as in which language it is written, which platform it
runs on, how it processes the request etc.[2]
II. WHY SOA WAS APPROACHED?
Of late, SOA is one of the hot topics of the IT
industry. But the picture was not painted in a day.
Software industries always dreamt of combining
existing systems to build a better business system
that includes connected applications and shared
data. One architecture was needed to implement
this. SOA came as a handful tool for it.
III. WHAT CHANGES THE ADVENT OF SOA
MADE?
Previously, several applications existed, but there
was no connection between them. SOA solved the
problem. It uses the concepts of distributed
computing & modular programming to use large
applications as an ad-hoc collection of smaller
units. Applications are built from same pool of
services, thus providing greater flexibility. We
need not have to provide same information again
and again to connect with different applications.
For example, one can interact with a Job searching
site, while connected with a social networking site.
SOA uses the concept of Orchestration to create
link between a sequences of services. Orchestration
refers to the automated arrangement, co ordination,
and management of complex computer systems,
middleware and services. [3]
In contrast with the earlier cases, where the chunks
of functionalities were connected together in
hierarchial arrangement like classes(which includes
a group of functions), SOA creates links between
several services where using Orchestration the
large chunks of services are connected in a non-
hierarchial fashion.
SOA interlinks many large chunks of functionality
to build a large software using already existing
systems. The larger the chunk of function is, the
smaller is the interface to communicate between
them. But the large chunks are not useful enough to
be reused. But the great benefit of SOA is that the
marginal cost of creating nth application is zero. As
all the services required to create the application is
already available, only orchestration is needed to
string them together to create the application.
The concept of SOA created applications that use
the available services in the web or that can be
made available as services in the web to be used by
other applications. This initiated the idea of third-
party services or even that are created at home.
This promises to spread the cost overhead among
several users inside or outside the industry. The
financial industries are forwarding in this direction.
IV. BENEFITS OF SOA [2]
 Reusability: Reusability of the existing
codes is one of the benefits of SOA. It
removed the overhead of the IT industry
to integrate different parts of a system that
were developed in different departments
of the same enterprise or any other partner
enterprise. As these are developed in
different platforms, or using different
languages, it is very difficult to string
them together to create the final system.
SOA cleaned the problem as only the
characteristics of the services are required
to know to build the interface.
 Reduction of cost: The use of modular
architecture and sharing reduces the cost
of developing systems and also spreads
the total cost among several clients.
 Flexibility: As SOA is loosely coupled,
it offers greater flexibility than the tightly
coupled systems. It can adopt to functional
changes better than the tightly coupled
one.
 Increased Efficiency: As SOA uses
modularity & reusability of business
systems, It promises to efficient &
consistent.
 Easy Up gradation: As SOA systems are
loosely coupled, it can be upgraded easily
with the changes in the business
environment that was difficult in previous
systems.
V. CHALLENGES OF SOA [4]
 Security Problem: As it is a totally web
based service, so security problem comes
automatically. Therefore, a well
automated authentication & authorization
technique is required to secure the data
shared via web.
 Business service governance : Business
services includes several services that are
implemented on different platforms using
different languages, so they should be
 governed properly to maintain the
dynamic links between the services.
VI. A PROPOSED ARCHITECTURE SOLVING
SOME OF THE PROBLEMS
We divide the whole architecture into three
major layers, keeping in mind the process of
generation of cloud. The first layer is the Vapor
Layer (VL), consisting of the service developers
who use data and logics to build separate services,
then concerning about the security of it. They give
the inputs to build the cloud. Then comes the
Cloud Layer (CL) that includes the Orchestration
block which links between services built in
different platforms & languages and the Service
Repository, containing the services. Finally, the
Pool Layer (PL), consisting of the users who use
the services provided by the providers. As both the
vapor & pool contain water, similarly users and
service developers are technologists helping to
build the cloud.
Each of the three layers is abstracted from the
upper & lower layers (if has), by a proper interface.
Because the cloud technology is mostly abstract as
far as our paper is concerned.
A. Vapor Layer
We can divide this layer into three different blocks,
Information Block (containing data and logic of a
service), Service Block (containing different
services built in different companies or by different
providers), & Security Block ( concerning of the
security of the transmittable data)
. Fig1. A Proposed Service Oriented Architecture
 1) Information Block:
Information block includes data and logic
that are available to the service developers
prior to the creation of any service; only
the service developers are concerned with
it.
2) Service Block:
Service developers can use any
technology or programming technique to
construct the service using the available
data & logic according to their wish.
Mostly the data and logic are abstracted
from the users due to the copyright
purpose.
3) Security Block:
As cloud technology is mainly web-based,
the question of security comes itself. The
service developers should be concerned of
the security before transmitting the service
to the next layer.
We leave all the responsibility of this layer upon
the Service Developers, assuming that they will
arrange their services as they wish.
B. Cloud Layer
This layer can be subdivided into 2 blocks named
Orchestration Block (we will concentrate on it
mainly) & the Service Repository.
1) Orchestration:
Orchestration is the process of stringing
together a number of services to build a new
business process. Orchestration is also responsible
for managing, coordinating, arranging these
services properly.[3]
Orchestration must provide dynamic, flexible, and
adaptable mechanisms to meet the changing needs
of the domain. This is accomplished through the
separation of process logic and the back-end
services employed [5]. Some orchestration
providers are EMC closed-loop network
orchestration, WS-BPEL etc.
Orchestration is a base of SOA. If one doesn’t have
good orchestration he/she can’t have a useful SOA.
The main goal of SOA is to integrate a number of
services to build the desired business process.
Orchestration provides the standards to define how
web services work together, including business
logic, sequencing, exception handling, process
decomposition, including service and process
reuse. So, we can conclude that SOA is defined by
Orchestration. Orchestrations may span a few
internal systems, systems between organizations, or
both. [6]
Orchestration should be approached just
like a new technology. First, the value & purpose
of it should be stated, then problem domain should
be defined including the available data & services
& lastly an instance should be prototyped to
experience functionality. [5]
a) Defining The Value Of Orchestration
Orchestration is the most valuable part of SOA as
far as the process integration is concerned. It is
responsible for linking services that span in one
organization or between several organizations. One
important note is that the orchestrations are itself
services. Orchestration may be public, private or
shared. Orchestrations are always decomposable
down to the source or target process.
Now it the time adopt our own strategy to
orchestrate number of services.
Here, we give a proposed orchestration block. That
consists of 4 parts.
 Service pool: It consists of small services
developed by the service developers.
 Decomposition block: It decomposes
services to find the data & logic.
 Compare Block: A sector for comparing
the logic with the desired business logic. It
compares the logic of the small processes
with the desired business processes to find
only the required process needed to be
combined. After it is done with it, it will
forward the services to the integration
block.
 Integration block: It is used to combine
desired small processes to get the desired
final business process.
2) Service Repository:
Service repository contains the required services to
build the desired service. We recommend a queue
for it, as it gives first in first out service and LRU
technology to replace the unnecessary services by
the latest desired services.
 Fig2: Orchestration Block
VII. COST ANALYSIS
Cost is the main concern of SOA. Before
implementing SOA, any organization must
interpret the cost of it.
Typically it's expressed as:
Cost of SOA = (Cost of Data Complexity + Cost of
Service Complexity + Cost of Process Complexity
+ Enabling Technology Solution). [7]
Now, the comparison block removes the
unnecessary processes, thus reducing overall
service complexity, finally cutting lower the cost of
SOA.
As Service Complexity = ((No of Services)*(Cost
of Service Storage)*Labor Units).
As the comparison block reduces the no. of
services, thus reduces the Service complexity and
above all the cost of SOA.
The cost of service storage is on the service
repository, which contains the final necessary
services to be integrated to develop the final
business process. As the no of services is less, the
cost is also small.
VIII. CONCLUSION & FUTURE WORK
Our developed SOA is desired to cause
reduction in the field of Cost of Implementing
SOA. In this paper we have calculated the service
complexity. Based on it one can calculate the other
complexities. As SOA is the main base of Cloud
Technology, its cost reduction, we hope will
benefit cloud developers. Now, our future work
will be developing a web based application
depending on it. As well as other cost reduction
should also be concentrated on.
IX. REFERENCE
[1] Gurpreet Singh Modi (048/GTBIT/CSE/2004).
“Seminar Report On Service Oriented
Architecture & Web 2.0.”
[2] ED Ort, “Service-Oriented Architecture and
Web Services: Concepts, Technologies, and
Tools.” April 2005.
[3] Orchestration (Computing) - Wikipedia {
http://en.wikipedia.org/wiki/Orchestration_%28co
mputing%29}
[4] Manoj Mansukhani, “Service Oriented
Architecture White Paper”, June 28, 2005.
[5] A CEO’s guide to EAI, SOA, and business
integration. Unknown CEO, Bridgewerx, Topic:
“SOA = Orchestration”, Sep 8, 2005 {
http://it.toolbox.com/blogs/davidlinthicum/soaorch
estration-5670}
[6] A CEO’s guide to EAI, SOA, and business
integration. Unknown CEO, Bridgewerx, Topic:
“Why Orchestration defines your SOA?” , Mar 31,
2005.
[7] David S Linthicum, Linthicum Group |
Techworld, “How to cost an SOA project”.
Published: 12:00 GMT, 08 June 07