A SOA Based Software Engineering Design Approach in
Service Engineering
Narasimha Pavan Kumar Lankadasu(nl18@mail.zips.uakron.edu)
ABSTRACT
Service oriented architecture(SOA)
is for flexibility,reuse and enables
organizations to easily integrate
systems,data,applications and processes
through the linking of services.This
paper focuses on the investigation and
studies on the SOA based software
engineering methods in the service
engineering environment.Among the
various SOA related software design and
development methods available,
service oriented modeling
and architecture (SOMA) service
architectural environment is chosen as
the target platform in the study. A web
based service oriented ubiquitous
Healthcare (u-Healthcare) software
system was designed and implemented
using the set of the software engineering
methods developed in the study to gain
empirical knowledge and experience on
applying the approach to construct SOA
service software.
1. INTRODUCTION
Major companies like IBM, Microsoft,
Oracle, Sun and HP have conducted
many years of research and development
in SOA methods and used them to
conduct projects of varying scope in
multiple industries worldwide.
IBM has invented and developed a SOA
method called service-oriented modeling
and architecture (SOMA). This is a
software development life-cycle method
for designing and building SOA-based
solutions [4].The SOA method is
being adopted with the objective to cut
down reproduction cost and promote
code reusability. However, SOA is hard
to adopt and very complex. In
comparison with the traditional software
development life cycle it is easy to
implement. The effectiveness and
efficiency of the SOA methods cannot
be judged correctly as every company
has it’s own way of SOA
implementation based on their needs.
Among the various SOA methods,
IBM’s SOMA method stands out as they
are constantly reviewing and updating
the architecture. The SOMA method has
various phases that emphases on ways to
categorize the business functionalities
into service components.
2.uCareCenter:
The uCareCenter system has been
designed based on several studies and
real world scenarios about the demand
and need for health care services. The
uCareCenter brings both the physicians
and the patients on to a common
platform overcoming the lack of
communication between them. In this
scenario we concentrate on the mobile
health care system. The mobile health
care should consist of two major portals
namely doctor portal and the patient
portal. The system should include
features as following:
1. Appointment center
- Doctor shall be able to view and
validate appointments.
 - System shall be able to send email to
Doctor upon
- Patient shall be able to view available appointment request made by patient,
appointment time and and vise versa.
make appointment for consultation. - System shall be able to send email to
remind patients of
2. Online consultation prescription reordering.
- Doctor and patient shall be able to
login and chat online. 5. Refill prescriptions
- Consultation time shall be logged for - Doctor shall be able to enter the
billing purposes. reordering period of
medicine.
3. Health information - Patient shall be able to track their
- Doctor shall be able to enter patient’s medicine dosage and order
health information and the medicine online.
attach reports. - Patient shall be able to choose home
- Doctor shall be able to restrict the delivery or pick up the
access of sensitive medicine from selected pharmacy.
information from patient’s view.
- Patient shall be able to view his own 6. Locate healthcare center
health information - Patient shall be able to locate nearest
assigned by the doctor. healthcare location
available.
4. Health alert

Figure 1: Use Case diagram for uCareCenter[1]

2.1 SDLC process in 5 main steps and they are:

The Software Developmental Life requirements gathering, design
Cycle(SDLC) can be used to describe ,implementation, verification and
the traditional software engineering
maintenance. The SOA processes are
also very similar with these processes.
SOMA defines key techniques and
describes the roles on an SOA project
and workbreakdown structures (WBS)
[1].The WBS includes tasks, the input
and output for work product for tasks
and the perspective guidance needed for
the detailed analysis design,
implementation and deployment of
services ,components and flows needed
to build a robust and a reusable SOA
environment.The SOMA method
includes several phases( shown in figure
2).The fractal phases have the capability
Figure 2:Software engineering process and SOA process [1]
to be utilized as needed in different
sequences.
Similarily, SOMA can be implemented
in a self-similar way in terms of small
iteration cycles. In a fractal model the
capabilities of one phase could be
utilized by the other. The support for the
design time and runtime governance is
provided by SOMA. The SOMA utilizes
a fractal approach ie. the application of
method tasks to self- similar scope. The
notion of similarity indicates that the
application is similar but not identical.
The same tasks might be applied for the
large scopes as well as the small scopes.
But, the overheads for the large scope
should be handled .This is done by the
evolution of the application. In SOMA
the main activities are identified in a
broader scope initially and then
elaborated later.

2.2 Identification phase: The KPI’s will provide a measure of

Software services for a business are success of meeting its goals and sub-
identified. The goals for the business to goals[2].
meet its objectives are identified. Sub-
goals are then identified recursively until
services can be identified for fulfilling
each of the sub-goals. Performance
indicators are identified for each of the
sub-goals. Each indicator has a metric
identifying the type of measurements
that need to be collected to assess the
state of the corresponding indicator.
Services and indicators are entered in a
services portfolio database. A services
solution for the business is then
implemented using a services oriented
architecture using the services in the
portfolio.[2]

2.2.1 Goal Service Modeling:

The goal service modeling takes place in
several phases (shown in figure3)
Initially, goals important to the business
are identified. These goals are broken
down into set of sub-goals in a recursive
fashion. Typically three to four levels of
sub-goals will suffice[5].However, the
Figure 3:Goal Service Modeling [2]
braking down stops once the identified
sub-goals reach a point at which services
need to fulfill the sub-goals can be
identified. In the uCareCenter the major goal would
Goals give an indication of what really be to increase the efficiency of health
matters to a business at a specific point care services. This can be done through
in time and what will be the priority in online-services, self-service portals and
the future[2].For each of the sub-goals, mobile services. The set of services that
KPI’s are identified that will be used to meets the business goals greatly refines
determine metrics that can be measured the scope of the service orientation.
for the attainment of the sub-goals These services are listed in table 1
through the identified services. below.
Table 1:Goal-service model for the proposed
uCareCenter[1]

2.2.2 Domain decomposition:

The top-down process is referred to
as domain decomposition, which
consists of the decomposition of the
business domain into its functional areas
and subsystems, including its flow or
process decomposition into processes,
sub-processes, and high-level business
use cases[4].The results of the domain
decomposition are shown below in the
table2. The uCareCenter system focuses
on few business domains:
user management, report services,
appointment services, Consultation
services, alert services, prescription
services and Location services.
Table 2:Functional areas and subsystems[1]
In SOMA, typically ,processes are
developed for a business domain to
initiate the process modeling and
decomposition.In uCareCenter, a process
hierarchy was first developed for the Get
user business process. Then, the sub
process of search user, Retrieve user
information and Retrieve user type were
identified (table3)
Table 3:Process decomposition
For the uCareCenter a common glossary
is essential in-order to understand the
terminology and also express them[1].
The key business entities identified are
user, healthcare center, appointment and
prescription. In the uCareCenter in-order
to improve the efficiency health report,
online consultation and appointments are
considered to be the main elements.
During the service refactoring activity
the services are grouped based on their
logical grouping .Services that can be
exposed as web services are identified.
Most functions are converted to web
services as they have higher reusability.
The services in uCareCenter are
categorized by functional areas
Namely user-profile, health reporting,
appointment activities, online
consultation, alert management,
prescription management and location
management.
2.3 Specification phase
In the SOMA specification phase, the
SOA is designed. High-level design as
well as significant parts of the detailed
design of service components is
completed in this phase. During the
specification phase, the services in
uCareCenter and flows are further
elaborated.
We leverage the existing assets and
further elaborate the services, flows, and
components from the identification
phase in an iterative and incremental
fashion to help reach the realization
decision [3].
In doing specification, we also focus on
the design of service messages which
include input, output, and error
messages.
Service specification is the core of the
service modeling activity and focuses on
elaborating the detailed design of the
services. There are 4 main service
hierarchies in the uCareCenter namely
patient record ,user ,medicine and
appointment. These service operations
are grouped within the service
hierarchies based on their functionality.
2.3.1 Subsystem analysis
Subsystems signify logical IT
boundaries for business functionality.
Subsystems are identified by functional
decomposition of functional areas.
Functional areas and the subsystems that
exist in those functional areas are refined
into coarse-grained service components
that are each responsible for a functional
aspect of the subsystem[3]. User
Management subsystem (refer Figure 4)
contains one major functional
component, namely User Profile. It
relates to other functional components
(User Type, Patient Record and Health
Center) and is controlled using Rule
Engine. The services identified include
User Management, Password
Management and Physician Patient
Assignment. The Password Management
contains Login Engine that defines the
validation and login rules.
Figure 4:Composition of User Management
2.3.2Component specification subsystem[1]

During component specification we

explore the use of patterns that can help
us to structure service components into a
set of functional components (supporting
business capabilities) and we look for
the technical components responsible for
providing auxiliary support from the
perspective of technology and
infrastructure [3].
2.4 Realization phase
We validate realization decisions by
performing technical feasibility
exploration that seeks to exercise the
architectural decisions and highest
project risk factors through extensible
prototypes designed and developed early
on[3].Selection and instantiation of
patterns is fundamental to successful and
repeatable SOA deployment. The results
of the realization phase is shown in the
SOA reference architecture.
Figure 5:SOA reference architecture for uCareCenter [1]

3. Performance & Results

The results from every phase of SOMA
can be accessed. I have created a matrix
to capture the comparison between the
list of components created after the
realization phase of SOMA and the
service components after
implementation. The results are shown
in the table 4 below. Ratings are given in
terms of poor, average and excellent.

if the component is matching with the

actual service created in all the
requirements, it is rated excellent, if it is
barely matching with any or has minimal
functionality, it is rated poor. Each
rating is given a point number 1 for
poor,2 for average,3 for excellent.
Table 4:Correctness Assessment for health
reporting[1]
Figure 6:Assesment formula[1]
The assessment result for Health
Reporting is calculated as follows:
[(2 * 1) + (4 * 2) + (7 * 3)/ 13] = 2.4
The benchmark of this formula is 2. All
the results after applying this assessment
method should be at least 2 and above
to show the correctness of the services
identified. As a result, the components
defined in Health Reporting are
considered as acceptable.
4.Summary:
A system based on SOA can be designed
and implemented in many way. There
has been a wrong notion about the
definition of SOA. Many think SOA is
equivalent to web services this is not
completely true.SOA based system is
generally developed with a set of
services or components and web services
are not mandatory. The benefits of using
SOA can be seen, especially when the
application needs to interact between
various different applications or different
types of clients like web, desktops and
mobile.
In this paper, we used SOMA few key
methods to assist in identifying a list of
services for the healthcare environment.
The main idea is to introduce more code
re-use and scalability by developing
various services that can be shared
among different parties and are platform
independent. The services should
be able to be created using any language
and hosted on any platform [4], [5].
We are able to interact with various
types of services which
comprised of web services and local
services. Some services are created by
external parties while others are self-
developed. Since services can be
designed in many ways, we have created
a set of services that fetch data from the
database and also some services that
perform business logic. SOMA helps
define the work breakdown structure of
activities and tasks while designing our
prototype.
5.Conclusion:
REFERENCES:
SOA offers a huge set of benefits by
providing loose coupling, platform
neutrality, standards based
implementation, rigid contracts for
version independence etc. Nowadays,
many companies already adopt SOA in
their applications. The decision of
whether to develop application with or
without SOA really relies on the usage
and requirements of the system. It is
always advisable to adopt SOA
framework if they need to interact with
various types of services.
We have demonstrated the way of
building a SOA based healthcare
application using IBM SOMA method.
SOMA has been designed and developed
from hundreds of projects around
the world in multiple industries. The life
cycle of a SOMA project uses a fractal
approach.As a conclusion, SOMA
benefits in providing guidance to
development of SOA-based solutions.

[1] A SOA Based Software Engineering Design Approach in

Service Engineering
Weider D. Yu Chia H. Ong
Computer Engineering Department, San Jose State University,
San Jose (Silicon Valley), California, USA 95192-0180

[2] UNITED STATES PATENT APPLICATION PUBLICATION

Goal Service Modeling
Pub No.:US 2008/0027784
Inventors:Jenny Slaw Hoon Ang,Ali P.Arsanjani,Lyubov Cherbakov,George M.
Galambos,Kerrie Lamont Holley,David Hugh Janson.
[3] http://www.istockanalyst.com/article/viewnewspaged/articleid/2626954/pageid/1
(Source: IBM Systems Journal) By Arsanjani, A Ghosh, S; Allam, A; Abdollah, T;
Ganapathy, S; Holley, K)

[4] Service Identification Approach to SOA Development- Nafise Fareghzadeh

[5] http://www.ibm.com/developerworks/library/ws-soa-design1
Service Oriented Modeling and Architecture- Ali Arsanjani