Migrating a Web-Based Application to a

Service-Based System – An Experience Report

Pushparani Bhallamudi1 Scott Tilley2 Arunesh Sinha3

1
Department of Computer Sciences, Florida Institute of Technology
pbhallamudi2008@fit.edu
2
College of Business, Florida Institute of Technology
stilley@fit.edu
3
Department of Electrical & Computer Engineering, Carnegie Mellon University
aruneshs@cmu.edu

Abstract One such organization that chose to successfully migrate

Service-Oriented Architecture (SOA) is a way of
designing, developing, deploying, and managing
enterprise systems where business needs and technical
solutions are closely aligned. Increased return on
investment (ROI) is a prime motivating factor for many
organizations to migrate their existing systems to ones
based on services. This paper details the experience of
migrating a traditional Web-based application to a SOA-
based system. The paper focuses on the business and
technical issues that motivated the migration, but it also
describes the advantages of the new service-oriented
system in terms of ROI.
Keywords: Service-Oriented Architecture (SOA), Web
application, migration, evolution, case study
1. Introduction
In a competitive business world, information technology
not only aids the business in working efficiently but it
also drives the business. To achieve this purpose,
information technology must align with business needs to
deliver the functionality necessary to satisfy these
business needs in an efficient and effective manner.
Service-Oriented Architecture (SOA) is a way of
designing, developing, deploying, and managing
enterprise systems where business needs and technical
solutions are closely aligned [3]. As such, adopting SOA
for new systems, or migrating existing systems to a SOA-
based environment, is an attractive option to meet some of
these needs [1]. However, it is not without considerable
challenges as well [4].
its legacy systems to SOA is XYZ Corp.1 Section 2
provides insight into the business requirements behind the
need for migration and also provides an overview of the
new service-oriented system. Section 3 presents a brief
introduction about the XYZ project, its business
functionality, and some technical aspects of the old non-
service based system. Section 4 discusses some of the
return on investment (ROI) issues associated with the
migration. Finally, Section 5 summarizes the paper.
2. The Web-Based Application
XYZ has a retail Web-based application that allows
consumers to choose, customize, and locate new and pre-
owned vehicles using a fast, secure, and easy-to-use Web
interface. The purpose of this Web site is to increase sales
by providing customers with the functionality to choose,
customize, compare vehicles, locate a dealer, and request
a quote. The Web site provides pricing information about
the base models and the various options and accessories
that customers can choose based on their budget. The
Web site also provides real-time incentives data, and
shows configured vehicle prices with the incentives
applied. Using the Web site, customers can search for
dealers in their local area and also view the inventory data
of each of these dealers.
One very important feature that the Web site provides is
to help the customer submit quote to the dealers. Using
1
The name of the company has been changed for confidentiality
reasons. Throughout the paper, the actual organization will be
referred to simply as “XYZ”.

978-1-4244- 5126-5/09/$26.00 ©2009 IEEE 71

this feature, customers provide their details to the dealers
and get a quote from the chosen dealer for the selected
vehicle. The user information (called leads) is collected
by this Web site and sent to the dealer.
2.1 Legacy Application Components
The non-service based system was a Web-based Java
application with many custom components. The
application consisted of the following important
components:
Config Engine: This engine allows configuring any
system where the parts for configuration, rules for
compatible parts (and incompatible ones), and rules of
default selections can be provided in a custom XML
format. This engine loads all this information about each
model at startup. The code for vehicle comparison is
written as a wrapper around the core config engine.
Dealer Search Engine: This is a simple engine that
accesses external Web sites to get dealers in a region.
Inventory Search: This data is also obtained from an
external Web site by querying the Web service using the
dealer identification code. This data provides detailed
information about each vehicle in the inventory.
Get-A-Quote Engine: This engine takes the user supplied
information and converts it into a lead. A lead is user
information in an XML format called ADF. This lead is
securely posted to the dealer.
Incentives and Pricing Engine: The incentive data is
obtained by accessing a Web service that hosts details
about the incentives. A small configurator decides which
incentives are compatible and groups them as required.
The pricing is obtained as a part of the model data.
When a user starts his session on the Web site, all these
engines are cloned and put in this session object. The
configured vehicle is stored in each session in a custom
patented format, which uses little memory. If the session
makes a dealer/inventory/incentives query then the
appropriate engine is called to perform the task and stores
relevant information in the context of this user. When the
user submits his private information, it is taken up by the
Get-A-Quote engine and sent to the dealer.
2.2 Motivation for the Migration Project
Migrating a legacy system to new service-based
architecture can be complex, expensive, and time
consuming, so there needs to be strong motivation and
compelling reasons for carrying out this process. A SOA-
based system may offer many benefits over the old Web
application, but before considering the migration it’s
important to understand the issues that lead to migration.
Based on the issues, one can decide if SOA is the most
72
suitable solution for the problems. As with most
organizations, business issues are drivers for change;
similarly for XYZ there were many business issues that
lead to migration.
In this project there were major concerns regarding data
inconsistency and high maintenance costs, and all these
problems were associated with duplicate data. XYZ also
has other Web sites that also rely on the same data (like
incentives) that this retail Web site uses. They needed a
way to consolidate of all vehicle data at one place that
would reduce the problems associated with data
inconsistency and also reduce the maintenance costs.
They also had concerns related to the time-consuming
change process. In the past there were many business
decisions related to vehicles that were actually minor
changes in the Web site but required minimum of 2-3
days of work, which was bad for business and was a
major concern for the vehicle manufacturer. They
required a system where making such simple changes was
easier and faster.
The modeling data received by the Web application was
habitually incorrect: the data was provided by non-
technical people, which often led to inconsistency in the
rules. This required modeling data to be reviewed
multiple times to get the correct modeling data. With the
old system this meant integrating the model and getting
the whole Web site up on test platform; this inefficient
process took about 4 weeks.
Apart from these business issues, there were some
technical issues associated with the old system. There
were memory problem with the Web site: the old system
was developed using old version of Java, which couldn’t
use memory efficiently, and this led to the server going
down at peak load. With years of development and Java
packages being the only way to separate functionalities
(and engines), the code became too complex to
understand and hence became nearly unmanageable.
Due to improper code separation, writing a new feature
required lots of time. Changes in one part of the code
potentially could have unintended effect on other features,
which forced costly testing cycles even for small changes.
Moreover, the user interface was not configurable and a
simple change required a considerable amount of user
interface code and a full new build.
These business concerns and technical issues were strong
motivation for migrating to a better solution. To mitigate
these problems, XYZ, in consultation with a software
consulting company, came up with Service Based
Platform (SBP). The next section of the paper describes
the service-based system in detail and also focuses on the
benefits of the migration.
3. The Service-Based System
The XYZ Service-Based Platform (SBP) is based on
SOA. Using a service-based architecture one can imagine
a system as a collection of different services that
represents certain business tasks. Similarly, SBP is a
collection of services that provide vehicle information
along with a library to load vehicle data, and tools that
help to create, manipulate, and test vehicle data. SBP
offers a common simplified data source to all the Web
sites to pull data from.
Services are integral part of SBP. One of the major tasks
in implementing SOA-based systems is to identify correct
services to implement. Most of the engines that
represented business functionality now represent services;
these services are RESTful and stateless. Input to the
services is passed through the URL parameters, or in the
POST body. Output from the services is either XML or
JSON (JavaScript object). Below is the list of a few
important services that are part of the new system.
Config Service: This is the most important service. The
legacy application code was stateful, so it stored the
previous configuration and then updated it based on part
selection. This service is now stateless (since it is
implemented using Web services); the user interface now
stores the information related to previous configuration
and sends it to this service on each request. Config service
provides information related to vehicle configuration.
There are sub-services of this service, such as Part
Service, that return part names, the Product and Compare
services, which provide configuration related information.
All these sub-services use the same product data library
and use the same server and code of the core config
engine, but are exposed as different services.
Part Service: This service provides information related to
different parts of the vehicle available for Vehicle/Model.
Product Service: This service provides information
related to different models available for given vehicle. For
example, for each vehicle make the service would show
different models available.
Compare Service: This service provides information
related to comparison between two models.
Incentives and Pricing Service: This service uses an
external Web service to get the incentive details.
Incentives and pricing service provides information
related price of the vehicle and the price of each part. It
searches for appropriate incentives and schemes to apply
to the pricing information for the selected vehicle. Since
this service needs the configuration of the vehicle to find
prices and incentives, it is a client of the config service.
73
Dealer and Inventory Service: This data is also obtained
from an external Web site by querying the Web service.
This data provides detailed information about each
vehicle in the inventory. This service is dependent on the
config service; hence this service is also a client of the
config service.
Lead Service: This service takes the user-supplied
information from the user interface and turns it into a
lead. This lead is securely posted to an intermediate lead
processing system, after which it is sent to the dealers.
User Interface Client: The user interface for the XYZ
retail Web site is hosted on different servers and they are
clients to all the services listed above. It uses an open
source JavaScript utility to implement a central JavaScript
controller that interacts with various user interface
components like flash. The central controller also feeds
data to all the components, after it gets the data by
querying the web services in the backend. Overall the UI
client itself is built with a SOA style framework.
A campaign management tool running on the server
allows flexibility to configure the user interface by
modifying the user interface on the fly. The new system
uses open source technology such as Spring and
Hibernate for the backend, and open source JavaScript
utilities for the front end.
4. The ROI of Migrating to SOA
Business and technical issues motivated the migration to
the new service-based platform. The rationale behind
considering SOA as an option for migration was
influenced by the numerous benefits that SOA offers [3].
Three main ROI benefits were experienced by the
migration: aligning business needs with IT functionality,
keeping data consistent, and reducing cost.
4.1 Aligning Business with IT
The most important factor that makes migration to SOA a
most suitable solution is that SOA aligns IT with
business, and most of the issues faced in this project were
due to lack of alignment between business and IT.
XYS’z data management problem was a major business
issue and since the software was not aligned with the view
of data in the business world, there existed a lot of
mismatch in business specification and technical
specification. This can only be reduced using SOA. The
service-oriented approach not only helped in getting
better specification but also reduced the time required for
creating final specification, as disagreement between
business and technical people is now less than what was
earlier. Now the business people know what each service
does, without really knowing the internals of the service.
With the new service-based model, implementing changes
or adding new features turned out to be easier. This
enabled making changes to the Web site more rapidly
than before. It also made it easier to meet the demands of
an ever changing business environment, like bringing up
an incentive plan on the website within minutes. This
approach reduces the time to production; and hence
generates business value for XYZ by being able to market
incentive schemes around important dates (like 4th July).
4.2 Consistent Data
After migration, all XYZ Web sites pull data from a
single source (a Web Service in SBP) and hence are
always consistent. This shows the benefit of exposing
reusable services for this project.
4.3 Reduced Cost of Maintenance
Migrating to new service-based model also helped XYZ
reduce the overall development cost. The modular design
and current technology has made outsourcing and division
of work easier. Little specialized expertise is now
required to maintain the Web site. The testing cost is also
lower in maintenance phase, as isolated changes to the
service require testing only that service and part of the
user interface application that uses this service. Making
the services stateless makes finding and fixing bugs
easier, as the bugs do not depend on some state that is
reached by a complicated control flow.
The time required for development has also reduced
because the code is now well documented and aligned
with the business model, making it easier to understand.
The SBP and user interface part was developed in
parallel, by first fixing the service contract and then using
hardcoded responses for the services in user interface.
This enabled overall development to finish faster.
The new service-based model made it possible to build a
number of tools for business users to be able to control
the Web site. For example, there is a new campaign
admin tool that can reconfigure the XYZ user interface in
minutes, and a new modeling tool for the modelers to
enable them to verify model correctness. Now integrating
new models takes only one week, and has further reduced
the cost of maintenance.
The services approach also scales much better than the
old approach. In the legacy Web application, when more
models added all the servers in Web site were also more
loaded. Now only the config service gets loaded more and
if it leads to performance degradation changing/getting
only one extra server can fix it easily.
74
5. Summary
The XYZ Service-Based Platform is success story about
migration to SOA. It illustrates that SOA is not all hype,
but can deliver what it promises. Migrating to the service-
based system helped XYZ to align its IT with business,
and also helped in achieving business agility. The new
service-based system is more adaptable to change; the
time to production for isolated small changes has reduced
considerably. Overall the cost of migration was less than
the estimated cost of re-factoring, and yet SOA provides
more benefits than the traditional framework that existed.
For contract-based development projects, SOA can help
in reducing the risk of development failure. It allows work
to be distributed among different contracts as services.
Different development teams can develop consumer
application independently.
As was found in other case studies (e.g., [2]), this
migration was successful because SOA was suitable for
this type of project. For example, in this project all the
services are owned by single organization. Due to this
reason, SOA governance was not a major concern in this
project. Identification of services was rather easy in this
project as most of the engines in the old system
represented some kind of business task. There were also
strong business and technical reasons for migration. If
these conditions did not exist, migrating to SOA might
not have been the best choice. But in this case, it was.
References
[1] Hau, T.; Ebert, N.; Hochstein, A.; and Brenner, W.
“Where to Start with SOA: Criteria for Selecting SOA
Projects.” Proceedings of the 41st Annual Hawaii
International Conference on System Sciences (HICSS
2008: Honolulu, HI; Jan. 2008).
[2] Kajko-Mattsson, M.; Lewis, G.; and Smith, D.
“Evolution and Maintenance of SOA-Based Systems at
SAS.” Proceedings of the 41st Annual Hawaii
International Conference on System Sciences (HICSS
2008: Honolulu, HI; Jan. 2008).
[3] Lewis, G. “Service-Oriented Architecture and its
Implications for Software Life Cycle Activities”. SEI
Webinar Series. Online at
http://www.sei.cmu.edu/collaborating/spins/081408webin
ars.html. Last Accessed 04/25/09.
[4] Tilley, S.; Gerdes, J.; Hamilton, T.; Huang, S.; Müller,
H.; Smith, D.; and Wong, K. “On the Business Value and
Technical Challenges of Adopting Web Services.”
Journal of Software Maintenance and Evolution:
Research and Practice, 16:31-50. John Wiley & Sons,
2004.