in baibaothi

7/29/2019 In BaiBaoThi

1/6

Science Academy

Publisher

International Journal of Research and Reviews in Ad Hoc Networks

Vol. 1, No. 1, March 2011

Copyright Science Academy Publisher, United Kingdom

Comparative Analysis of SOA and Non-SOA for Building

Complex Systems

VSRK Sarma1, M. Sitarama Kumar

2, K. Mrithyumjaya Rao

3and Y.K.Sundara Krishna

4

1Faculty of Computer Science, S.V.H.College of Engineering, Machilipatnam, Andhra Pradesh, India.2HCL Technologies, Banglore, Karnataka, India.3Department of Computer Science & Engineering, Vaagdevi College of Engineering, Warangal, Andhra Pradesh, India.4Department of Computer Science, Krishna University, Machilipatnam, Andhra Pradesh, India.

Correspondence should be addressed to VSRK Sarma,[email protected]

Abstract In this current generation of complex systems, the longevity of a system is governed by the cost of ownership,

while the usability is governed by the ease of integration. In a series of architectural evolutions, the latest wave that

encompasses these two merits is the Service Oriented Architecture. In this paper, we present detailed analysis on the merits of

Service Oriented Architecture over traditional architectural styles considering a practical implementation of a thesaurus

system.

1. IntroductionService Oriented Architecture (SOA) refers to a collection

of services that communicate with each other enablingfunctionality provisions to distributed clients [1]. This

process involves re-engineering that promotes the

construction of applications based on entities commonly

referred to as services.

2. Literature Review2.1. Agility

Continual change of software systems is a major source of

expense. In SOA, each service is discrete and has

independent functionality that interacts with other services

through API. Integrating a new service to the application is

simple and agile [2].

2.2. Language IndependenceService is a collection of various protocols and standards

that enable to exchange data between Applications and

systems [3]. It is written in Web Service Definition Language

(WSDL) and accessed through HTTP and Simple Object

Access Protocol (SOAP). SOAP is XML-based

communication protocol that enables various applications to

exchange information over HTTP. It is both platform and

programming language independent.

2.3. Loose CouplingThe Loose Coupling can be defined as The state in which

the impact of change (change in service consumers, service

providers, or cross-cutting policies) is minimized across

dependencies. It also refers to a connection or relationship

with level of dependency with other service boundaries likeservice contract, implementation and consumers etc.

2.4. Cost of OwnershipTypically assumed and computed based on the factors of

service complexity, interoperability etc.

2.5. MaintainabilityThe changes to the business logic that underlies a

particular service should have no effect on the overall SOA

application.

2.6. Ease of RegressionThe method of regressing the bugs, error and

incorporating any additional change in requirements are

easier.

3. Operational EfficiencyThe following factors are day to day performance of the

system as far as efficiency is concerned.

Scalability

Response Time

Resource Use

Recovery From Anomalies

Availability

In this comparative study of SOA vs. Non-SOA, we

consider building and maintaining thesaurus system as the
http://www.sciacademypublisher.com/mailto:[email protected]:[email protected]:[email protected]:[email protected]://www.sciacademypublisher.com/


2/6

International Journal of Research and Reviews in Ad Hoc Networks 14

case study. The dictionary definition of thesaurus is A book

containing a classified list of Synonyms. This paper furthers

that definition by considering that a thesaurus is a system that

comprehends words, and the way a word is derived from root

word, its synonyms, antonyms and how it is connected to

various other words. One of the primary complexities of the

said system is the possibility of users collaborating across

geographic locations to build a centralized word repository[4].

4. Case StudyIn the sections that follow, we describe how such system

can be visualized and the way it can be built and maintained

using Non-SOA and SOA approaches. The thesaurus system

considers the following roles and their collaboration using

various API and/or service calls. The roles considered for

this study are:

4.1. Roles for the study4.1.1. Contributor

Contributor is a special user who can submit a word and

its relevant information, such as synonyms, antonyms,

relation to other words etc., to the thesaurus system. On the

submission of each word, a notification event will be raised

for the approval.

No submitted word is committed into the system without

approval from the approver.

4.1.2. ApproverApprover is a user who performs four-eye check on each

word submitted by contributors.Upon receiving a notification about the new arrival of a

word, approver judges the validity of the word and its related

content. If the entry is considered as valid, he approves it for

committing into the system, which raises a notification to

relevant subscribers.

In case the approver considers the entry as invalid, he

marks the entry as invalid with appropriate remarks. In such

cases, a notification will be sent to the contributor indicating

the invalidity.

4.1.3. SubscriberA subscriber is a client for Thesaurus system that can

access various services of thesaurus, such as word

information and its related details in various aspects, based on

the service level agreement (SLA).

Subscribers have the facility to listen to various

notifications raised by the Thesaurus system, such as

approvals on new / modified entries and upgrades on entries.

4.1.4. API UserHe or she is a user or client who extends the API given by

the service provider to leverage and build his own system.

API is basically collection of utilities to play the role of

contributor, approver and subscriber.

4.2. Thesaurus System with Non-SOAA Non SOA system that integrates these roles and

concepts looks as presented below.

API

Figure 2. Pictorial Representation of Thesaurus System with NON-SOA

This requires a low level description on how each role

communicates to each other in various contexts.

The Low Level Description

1. Contributor submits an entry into the thesaurus system

2. Contributor sends an entry notification to the

Approver on submission of an entry.

3. On receiving a notification the approver mark an entry

as valid or invalid one.

4. On successful validation the notification will be sent to

relevant subscribers

5. On failure a notification will be sent to the

Contributor.

6. A subscriber leverages the system using the various

API calls provided.

7. API user has programmatic access to all the above

functionality

In this kind of the system, the whole thesaurus system is

directly accessible to the user. Any change of functionality

directly impacts all the other modules since the modules are

tightly coupled. Also it should be noted that even though a

user has interested in only partial set of functionality, he

nevertheless has to buy and own the entire system which

increases the cost of ownership.

Additionally for the developers of the thesaurus system

using Non-SOA to make it available for the users, they have

to build SDKs which are targeted for different frameworks

and languages. This is because of tight coupling.

4.3. Thesaurus System with SOAThe thesaurus system looks like below using SOA

approach.

Contributor

ThesaurusSystem

Approver

Single API Library

Subscriptions

1

2

2

3

6

45


3/6


SOA

API

Figure 2. Pictorial Representation of Thesaurus System with SOA

1. Word Entry

2. Word update entry

3. Notification against word entry / word updating

4. Word approval

5. Notification against approval

6. API user access

The connections indicated are loosely coupled message

contracts that exchange data through asynchronous means. It

should be noted that now there are three distinct layers

segregating the system into loosely coupled modules based onoperational boundaries.

4.3.1. Thesaurus LayerThis layer consists of only thesaurus system exposing its

functionality through service end points.

4.3.2. User LayerThis layer primarily hosts the user services. The typical

service descriptions are.

Contributor submits an entry into the thesaurus system

Thesaurus system sends an entry notification to the

Approver on submission of an entry. On receiving a notification the approver mark an entry

as valid or invalid one.

On successful validation the notification will be sent to

relevant subscribers by thesaurus system

On failure, a notification will be sent to the

Contributor by thesaurus system.

A subscriber leverages the system using the various

service calls provided.

User has service level agreements for various services

like contributor, approver and subscription services.

4.3.3. API LayerThis is the layer that hosts all the programmatic access

services. A user can directly use the services of any layer

without going through other layers [5].

Any change of functionality in one layer does not impact

other layers since they are separated across operational

boundaries. Also it should be noted that if a user interested in

only partial set of functionality he does not have to buy and

own the entire system which decreases the cost of ownership.

Additionally, for the developers of the thesaurus system to

make it available for the users they now have to publish just a

service description in a standard format such as WSDL that is

understood by all standard frameworks. This further

decreases the cost of development and maintenance.

4.4. ComparisonThe quantification of above claims is presented below.

The process of quantification is organized from the

perspective of goals (i.e., Agility, Language Independence,

Loose coupling, Cost of Ownership, Maintainability, Ease of

regression), potential metrics that might influence these goals,

and some possible measures [6].

0 Not Useful This is totally irrelevant to the next

higher-level factor.

1 Marginally useful This could increase (or decrease)

thenext higher-level factor by not

more than 10%.

2 Moderately useful This could increase (or decrease)

the next higher-level factor by 10-

25%.

3 Extremely useful This could increase (or decrease)

the next higher-level factor by 25-

75%.

4 Blockbuster This could increase (or decrease)

the next higher-level factor by

more than 75%.

Considering all goals we identify the factors to measure.

Further, each factor as a metric we do comparison for SOA

and Non SOA based systems to finally rate factors andgoals on a five point scale.

Contributor

ThesaurusSystem

Approver

User

Subscriptions

1

2 5

2

3

6

4


4/6


Various aspects we mentioned in introduction and the relevant factors identified to measure are as follows.

No

.

Factor Description Rating

(0-5)

1 Change in Requirements Non SOA:

From Non SOA diagram (Fig:1), if the system is undergoing any change, the

below derived data can be used to calculate the impact analysis.

Number of modules=4

Number of tight coupled modules = 4

Number of modules to be rebuild due to a change =4Number of modules to be tested after a change


5/6


the language independence feature we mentioned.

7 Knowledge required to use

service as compared with

that possessed by the

intended customer(s)

(estimated % more or less)

This adds more cost on a non SOA based system as the customer need to gain the

knowledge related to various technologies and languages on which the system is

built. But in a SOA based system it is very less as the service contracts are written

in universal languages like WSDL. This highlights the language independence

feature we mentioned.

In conclusion the Time (seconds) and amount of knowledge (hours of specialized

training) required to sign on is less in an SOA system.

5

8 Reliability of the customer

to access the service.

Due to lose coupling it is always easy to track the reliability of a customer in an

SOA based system. But in a non SOA based system it requires a robust

Authentication Control Mechanism to control the access to the end user at

presentation layer. This adds extra development and maintenance cost.

4

9 Percent of intended

customers that the system

is designed to

accommodate with tailored

processes, interaction

mechanisms, and output

formats.

A nonSOA system always draws a line in this aspect based on the factors like

performance, scalability, technology on which it was built.

In case of an SOA system a service provider can upgrade or replicate the system

thus he can make the system highly available to the as many user as possible.

This proves SOA is more agile.

5

10 Ability to use data and

services from other

organizations

This is possible in SOA based system more cheaper way as it can connect to the

other system with other systems in a loosely coupled manner.

A non SOA system requires dedicated connections to get data from externalsystems which add huge amount of cost on customer like new development,

testing and maintenance efforts and related costs. It might add regression also in

the system which is tough to handle in case of non SOA system.

This highlights the features like Ease of regression and Loose coupling.

5

11 Effort required to check on

policy consistency /

applicability when system

changes are made

Any change creates lot of regression in a non SOA based system.

Whereas due to lose coupling the regression is minimal in SOA based system.

This highlights the ease of regression feature of SOA.

5

12 Percent of typical changes

that can be made using s

template or simple

scripting language

The reason can be because of the calculation formulas and new business rules etc.

A Non SOA system needs to be upgraded in this aspect unless all the aspects are

comprehended before the delivery.

An SOA system always easy to upgrade.

This highlights the features like Loose coupling and Language independence.

5

13 Adaptability to variations

in processes, services and

ontologies across the

Enterprise

A Non SOA system is always frozen for any adaptable systems. So this aspect

adds development, maintenance and various other costs across all modules.

A SOA in contradiction it is minimal as the light weighted modules are owned by

each participant of a contract.

This highlights the feature of Agility.

5

14 Does the system have easy-

to-use / automatic dynamic

configuration

management?

In a Non SOA system it is a million dollar question to be answered. Because this

decides the co-ordination between various modules in the system.

This has very less impact in SOA as the number of modules owned by each

individual participant is very less.

4

15 Day to day performance of

the system with respect to

factors like

scalability,

response time,

resource use,

recovery from anomalies,

availability

The list of factors has more impact on a Non SOA base system as the system is

totally owned by the customer.

Whereas an SOA based system it is always flexible as the change in these aspects

at one place in a layer doesnt impact the other layers and the change at one

service endpoint doesnt impact the other end point.

5

5. ConclusionIn an ever-increasing world of complexities decoupling

and reuse are the key factors for successful production both

in terms of development and ownership. This studypresented a detailed comparative analysis of SOA and

Non- SOA approaches for building complex systems as

large as a thesaurus.

Acknowledgment

Authors are very much thankful to Mr. Gopala Krishna

Palem, Software Architect, Symphony Services,

Bangalore, for his valuable guidance in preparing this

paper.


6/6


References

[1] Y. W. Sim, C. Wang, C. Wang, L. Gilbert, G. B. Wills AnOverview of Service-Oriented Architecture , ECSTR-IAM05-004

Version 1a1 July 2005.

[2] Haluk Demirkan, Robert J. Kauffman, Jamshid A. Vayghan, Hans-Georg Fill, Dimitris Karagiannis, Paul P. Maglio, Service-oriented

technology and management: Perspectives on research and practice

for the coming decade, Electronic Commerce Research and

Applications 7 (2008) 356376.

[3] Marcos Lopez-Sanz, Cesar J. Acuna,Carlos E. Cuesta, EsperanzaMarcos, Modelling of Service-Oriented Architectures with UML

Electronic Notes in Theoretical Computer Science 194 (2008) 23

37.

[4] Rikard Land, Ivica Crnkovic, Software systems in-houseintegration: Architecture, process practices, and strategy selection,

Information and Software Technology, 49 (2007) 419444.

[5] Amjad Umar, Adalberto Zordan, Reengineering for serviceoriented architectures: A strategic decision model for integration

versus migration, The Journal of Systems and Software 82 (2009)

448462.

[6] F.B. Vernadat, Interoperable enterprise systems: Principles,concepts, and methods, Annual Reviews in Control 31 (2007)

137145.

VSRK Sarma, qualified in Master of

Philosophy in Computer Science and Post-

graduate in Computer Applications from

Madurai Kamaraj University, Madurai.

Now, he is working as a faculty member in

the department of Computer Applications,

S.V.H.College of Engineering,

Machilipatnam. His research interests are

SOA, EAI and other Integration Technologies.

M.Sitarama Kumar qualified in Master of

Technology from Cochin University,

Cochin. Now, he is working as Technical

Lead in HCL Technologies, Bangalore. His

research interests are SOA, EAI and Object

Oriented Technologies.

Dr.K. Mrithyumjaya Rao, qualified in

Ph.D in Computer Science & Engineering

in the year 1979. Now, he is working as

Professor in the department of Computer

Science & Engineering, Vaagdevi College

of Enginerring, Warangal. His research

interests are Datamining Techniques

applied to real world applications.

Y.K. Sundara Krishna qualified in Ph.D in

Computer Science & Engineering from

Osmania University, Hyderabad. Now, he is

working as Professor in the Department of

Computer Science, Krishna University,

Machilipatnam. His research interests are

Mobile Computing, SOA and GIS

Applications and having practical work

experience in the areas of Computing

Systems including Developing of Simulators for Distributed

Dynamic Cellular Computing Systems, Applications of

Embedded & Win32 clients, Maintenance of Multi-user System

Software.

in baibaothi

Documents