2009 IEEE International Conference on e-Business Engineering

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
Abstract

promote code reusability. However, SOA method is often very

complex and hard to adopt within the actual environment.
Comparing to the traditional software development life cycle,
the process is simpler and easy to implement, but lack of
emphasis on code reusability.
Many companies that adopt the SOA method have modified
and invented their own SOA methods to suit their corporate
environment and needs. Hence, it is difficult to judge the
effectiveness and efficiency of any method. We need to
carefully study and evaluate the pros and cons of every method
before applying into the actual system. Among the various
SOA methods, IBMs SOMA method stands out as they
constantly reviewing and updating the architecture. Another
reason of choosing SOMA method is: it has various phases that
emphases on ways of categorize the business functionalities
into service components. Based on our observations, they serve
as important steps and can be closely coupled into the
requirement and design phases in the SDLC.

Service-oriented architecture (SOA) is for flexibility and

reuse, and enables organizations to easily integrate systems,
data, applications and processes through the linking of
services. SOA also addresses the critical security and privacy
issues. This paper focuses on the investigation and studies on
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

2. Experiment and analysis

Service-oriented architecture (SOA) is specially designed to

provide flexibility and reuse, enables organizations to easily
integrate systems, data, applications and processes through the
linking of services as well as addresses the critical security and
privacy issues of healthcare environment [6]. Major companies
like IBM, Microsoft, Oracle, BEA, Sun, SAP, and HP have
conducted many years of research and development in SOA
methods, and use 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], [5]. Microsoft developed its
own Abstract SOA Reference Model, describing the usage of
web services and services integration [9], [10], [11]. Oracle
also developed a SOA Suite that helps organizations build,
deploy,
and
manage
deployments
ranging
from
department-level to enterprise-wide systems.
The amount of money spent on software in the US grows
approximately 12 percent each year, and the demand for added
software functions grows even faster [6]. Lack of reusability
and reproduction of software components often adversely
affects the schedules and effectiveness of healthcare system.
Companies start adopting the SOA method in their software
development with objective to cut down reproduction cost and
978-0-7695-3842-6/09 $26.00 2009 IEEE
DOI 10.1109/ICEBE.2009.64

In this paper, we illustrate the latest release version of

service-oriented modeling and architecture (SOMA) method
(v.3.1) using one of the components in u-Healthcare service
environment, mobile healthcare system. We analyze the SOMA
key techniques by creating a u-Healthcare prototype and focus
mainly on SOMA three major phases: Identification,
Specification and Realization. We define the activities and
tasks needed to successfully build a reusable u-Healthcare
system.

2.1. The Prototype: uCareCenter

Context: The uCareCenter prototype system is designed based
on online researches and real-world scenarios about the
demand and needs of the healthcare services. Physicians and
patients often suffer from lack of communication due to busy
schedules and inconveniency. The lack of interaction has often
caused the delay of diagnosis and thus increases the possibility
of sickness. UCareCenter is designed to accommodate the busy
schedule of both parties, and maximizing the communication
channels between patients and physicians (refer Figure 1).
Features: The prototype mobile healthcare system, namely
uCareCenter should consist of 2 major portals: Doctor and
Patient Portal. The system should include features as following:
409

1. Appointment center
- Doctor shall be able to view and validate appointments.
- Patient shall be able to view available appointment time and
make appointment for consultation.

6. Locate healthcare center

- Patient shall be able to locate nearest healthcare location
available.

2. Online consultation
- Doctor and patient shall be able to login and chat online.
- Consultation time shall be logged for billing purposes.

The traditional software engineering process which can be

described using the Software Development Life Cycle (SDLC)
consists of 5 main steps: requirements gathering, design,
implementation, verification and maintenance. The overall
processes are very similar with the service-oriented architecture
(SOA) process [3], which will be described in the following
sections.
As a software development life-cycle method for developing
SOA-based solutions, SOMA defines key techniques and
describes the roles on a SOA project and a work breakdown
structure (WBS). The WBS includes tasks, the input and output
work products for tasks, and the prescriptive guidance needed
for detailed analysis, design, implementation, and deployment
of services, components, and flows needed to build a robust and
reusable SOA environment.
The SOMA method includes the seven major phases shown
in Figure 2. The fractal phases contain capabilities that can be
leveraged as needed in different sequences. SOMA has a fractal
software development life cycle because SOMA applies
method components (capability patterns) in a self-similar
manner recursively in small release or iteration cycles, focusing
on addressing technical risk and delivering software valued by
the business. Realization, for example is leveraged in all
phases. No rigid sequencing is implied. In a fractal model,
phases will consist of capabilities that may be used by other

2.2. Overview of SOMA method

3. Health information
- Doctor shall be able to enter patients health information and
attach reports.
- Doctor shall be able to restrict the access of sensitive
information from patients view.
- Patient shall be able to view his own health information
assigned by the doctor.
4. Health alert
- System shall be able to send email to Doctor upon
appointment request made by patient, and vise versa.
- System shall be able to send email to remind patients of
prescription reordering.
5. Refill prescriptions
- Doctor shall be able to enter the reordering period of
medicine.
- Patient shall be able to track their medicine dosage and order
the medicine online.
- Patient shall be able to choose home delivery or pick up the
medicine from selected pharmacy.

Mobile Healthcare System

Enter Daily
Schedule

View Appointment

Make appointment

Online Consultation

Modify and Cancel

Appointment
Enter Health
Information

Access to Own
Health Information

Restrict Access to
Health Information

Patient
Receive Alert

Reorder Medicine
Send Alert
Enter Medicine
Reordering Period

Locate Healthcare
Location

Figure 1. Use Case Diagram for uCareCenter

410

Physician

2.3. Identification phase

phases. Governance serves as the context and background for

the service-oriented life cycle. SOMA provides support for and
linkages to the two main aspects of governance: design-time
and runtime governance.
The life cycle of a SOMA project uses a fractal approach.
The main principle of fractal software development is the
application of method tasks to self-similar scope, meaning tasks
are done in a similar way in larger or smaller boundary scopes.
The notion of similarity indicates that the application of
principles is similar but not identical, meaning that as we
approach larger scopes, even though the same tasks apply, the
additional work needed has to evolve in order to take into
account factors that arise from the larger scope. In SOMA
method, we identify the main activities in a broader scope
during the initial stage, and further elaborate and refine the
scopes in the later stage.
The SOMA method also applies the second principle of
fractal software development, which is prioritization of the
service model based on a service-dependency diagram and
takes into account the risk factors involved in the IT aspects of
the architecture.

Service identification follows three main complementary

techniques: goal-service model (GSM), domain decomposition,
and existing asset analysis. GSM uses an approach that is
predicated on business challenges and opportunities, corporate
strategy, and business goals. Domain decomposition uses a
top-down analysis technique that is focused on business
process modeling, rules, information, and variation-oriented
analysis. Existing asset analysis uses bottom-up approach that
is looking at the existing application portfolio and other assets
and standards to identify good candidates for service exposure.
2.3.1. Goal-Service Modeling (GSM)
In GSM, a generalized statement of business goals relevant
to the scope of the project is decomposed into sub-goals that
must be met in order for the higher-level goals to be met [4].
This hierarchical decomposition then leads to a set of
actionable goals which lead to identifying the services that will
help in fulfilling the sub-goals. Key Performance Indicators
(KPIs) are also important as they help to evaluate the objectives
of the sub-goals.

Figure 2. Software Engineering Process and SOA Process

411

In uCareCenter, the highest-level goal is to increase the

efficiency of healthcare services by offering various healthcare
services that are enabled through multiple channels such as
on-line, self-service portals, and mobile devices. The set of
services that meets business goals greatly refines the scope of
the service orientation. These services are listed in the Services
column in Table 1.

1.1.1.4 Enable
alert service via
self-service portal

Increase the
efficiency of
alert service

1.1.1.5 Enable
refill
prescriptions
service via
self-service portal

Increase the
number of
patients using
prescriptions
service

1.1.1.6 Enable
healthcare center
locator service via
self-service portal

Provide
convenience of
locating
healthcare
center

Number of alerts
sent within
certain period of
time.
Number of
re-order service
through online
channel.

Table 1. Goal-Service Model for the proposed uCareCenter

Goals and sub
goals
1. Ease the
healthcare
services
1.1 Enable
healthcare
services through
channels such as
online and
self-service
portals
1.1.1 Enable
healthcare
services such as
appointments,
consultation,
health reports,
prescriptions
ordering online
1.1.1.1 Enable
patient healthcare
services such as
check health
report status,
check health
history, and check
doctors analysis
via self-service
portal

1.1.1.2 Enable
appointment
schedule via
self-service portal

1.1.1.3 Enable
consultation
service via
self-service portal

Key
Performance
Indicators
Increase
efficiency of
healthcare
services.
Increase number
of patients using
healthcare
services

Metrics

Services

Increase number
of patients using
healthcare
services

Number of
accounts opened
in the portal to
make use of the
healthcare
services.

- Open account
- Close account
- Get user
profile
- Update user
profile

Increase number
of patients using
healthcare
services

Number of
healthcare
services through
various channels.

Increase the
efficiency of
appointment
center

Number of
appointments
made online
within certain
period of time.

- Update report
status
- Get report
status
- Upload report
analysis
- View health
report
- View
diagnosis
analysis
- Send question
- Order health
report
- Get health
history
- Create
appointment
- View
appointment
- Update
appointment
- Check doctor
schedule
- Cancel
appointment
- Create
consultation
session
- Join
consultation
session
- Save
consultation
content
- Exit
consultation
session

Number of
locator services
through online
channel.

- Alert reminder
services
- Send alert
- Create
automatic
re-ordering
- Update
re-ordering
occurrence
- Select
payment type
- Select delivery
method
- View re-order
information
- Enter search
location
- Search
location with
available
doctors
- Select search
radius

2.3.2. Domain decomposition

Increase the
efficiency of
consultation
service

Number of
consultations
made through
online channel.

Domain decomposition uses a top-down analysis technique

that is focused on business domains, business process
modeling, rules, information, and variation-oriented analysis.
The process of information analysis begins with the
identification of business domains. The business domains are
further partitioned into functional areas that explain the
underlying structure. Further partitioning is performed to arrive
at set of loosely coupled subsystems as logical IT boundaries
for carrying business functionalities. The domains and their
functional areas are initial connections to governance under
SOA; they will be the owners of the services. The results of
domain decomposition are shown in Table 2.
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
Domains
User management
Report services
Appointment services
Consultation services
Alert services
Prescription services
Location services

Functional Areas
User profile
Contact and event
history
Health reporting
Report activities
Appointment activities
Online consultation
Consultation content
history
Alert management
Alert tracking history
Prescription
management
Order event history
Location management

Subsystems
User management
Report management
Appointment
management
Content management
Alert setup
Medicine Reordering

In SOMA, typically, processes are developed for a business

domain to initiate the process modeling and decomposition. In

412

We have identified 4 main service hierarchies in

uCareCenter system, namely User, Patient Record, Medicine
and Appointment. The service operations are grouped within
the service hierarchies based on their functionality. All the
service operations are exposed and their parent of the exposed
service is a functional area in the service hierarchy (refer Figure
3). The input and output messages of the service operations are
carefully identified.

uCareCenter, a process hierarchy was first developed for the

Get User business process. Then, the sub-processes of Search
User, Retrieve User Information and Retrieve User Type were
identified (refer Table 3).
Table 3.

Process decomposition

1. Get User
2. Maintain User

1. Get User
1.1. Search User
1.2. Retrieve User Info
1.3. Retrieve User Type
2. Maintain User
2.1 Create User
2.2 Update User
2.3 Delete User
2.4 Change Address
2.5 Change Contact Info
2.6 Assign Doctor

2.4.2. Subsystem analysis and component specification

Subsystems in SOMA represent logical IT boundaries for
business functionality. They each represent a functional aspect
of the system. During subsystem analysis, subsystems are
identified by functional decomposition of functional areas. We
also identify the relationship among the subsystem and present
them in the figures below.
User Management subsystem (refer Figure 3) 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.

A common business glossary is essential so that everyone in

the enterprise can learn to speak the same terminology and
define a consistent way to express the business in terms of
information. In uCareCenter, the key business entities that were
identified are: user, healthcare center, appointment and
prescription.
The life-cycle methods for these significant business
entities are added as candidate services to the service portfolio.
In uCareCenter, managing health report and appointments and
online consultation are also main elements in improving the
efficiency of healthcare services. After applying the techniques
in service identification, the services that are needed in
uCareCenter are chosen and configured.

<<Subsystem>>
User Management

Service component
User Management

Service component
Password Management

2.3.3. Service refactoring and rationalization

During this activity, the services are grouped and
re-factored based on their logical grouping. Services that can be
exposed as Web services are identified. Not all services can be
implemented in WSDL. Most CRUD functions are converted
to Web services since 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.

Functional component
User Profile

Functional component
User Type

Service component
Physician Patient Assignment

Functional component
Patient Record

2.4. Specification phase

Functional component
Health Center

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 this phase, the services in uCareCenter and flows are
further elaborated. We focus on refactoring the existing code,
and analyze the interfaces and the input and output parameters
of the methods. Duplicate, unstructured and unused code is also
identified.

Technical component
Login Engine

Technical component
Rule Engine

Figure 3. Composition of User Management subsystem

2.5. Realization phase

There are a few activities involved during realization phase.
Decision on architectures and technologies are defined during
this phase. We can relate this phase with the steps during
defining tools and technical components in SDLC. The
difference is within SOA application, it is focused more on the
technical feasibility design of the components which also
include risk analysis, impact on the design to the operational
requirements. Prototyping is highly recommended during this
phase.

2.4.1. Service Specification

This is the core of the service modeling activity. During

service specification activity, we have identified a list of
service operations and service hierarchy that are to be exposed
as Web services. As defined in SOMA, service operations are
described in business use cases where requirements are
gathered.
413

3. Performance and benchmark

We have decided to prototype our service components using

Windows Communication Foundation (WCF) Framework. Our
decision is supported by the continuous development and
support of the framework. WCF is a programming framework
used to build applications that inter-communicate [9]. WCF is
designed in accordance with SOA architecture principles.
Client applications can communicate with WCF services using
any of the RPC-based mechanisms. Microsoft has released their
first release in November 2005 as part of .NET 2.0, uses mainly
SOAP messages in communication. In .NET Framework 3.5,
WCF added support for REST-style communications where
JSON and plain-old-XML data serialization is supported7.
The results of this phase explained in the SOA reference
architecture in Figure 4.

The results from every phases of SOMA can be accessed.

To access the completeness and correctness of the result from
SOMA, 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.
Table 4 shows the correctness assessment for the
components defined for Health Reporting. Each component is
given a rating from poor, average and excellent. If the
component is matching with the actual service created in all the
requirements, it is rated excellent, if it barely matching with any
or minimal functionality, it is rated poor.

Figure 4. SOA reference architecture for uCareCenter

414

SOA based application. It has a rich Work Breakdown

Structure that comprises activities, tasks and corresponding
input and output. SOMA can also be used to support

Each rating is given a point number, 1 for poor, 2 for

average and 3 for excellent. The ratings will be accumulated at
the end of the matrix.
1
1.1

Services Defined
Manage Report
Verify Patient Info

1.2

Retrieve Report

1.3
2
2.1
2.2
2.3

Update Report Status

Maintain Report
Create Report
Verify Doctor Info
Get Patient Info

2.4
2.5
3
3.1

Upload Attachment
Save Report
Update Report
Verify Doctor Info

3.2
3.3
4
4.1

Get Report
Save Report
Delete Report
Verify Doctor Info

5
5.1

Get Report
Get Report Summary

Actual Services Created

Poor

Average

Excellent
U

GetUCareUserByUserName_Password
GetUCareUserRecordbyUserID
GetPatientRecordByPatientID
GetPrescriptionListByPatientRecordID

U
U
U
U

AddPatientRecord
GetPhysicianByPhysicianID
GetPatientListByPhysicianID
GetUCareUserRecordbyUserID
GetPatientRecordByPatientID
(Local service)
UpdatePatientRecord

U
U
U

GetUCareUserByUserName_Password
GetPhysicianByPhysicianID
GetPatientRecordByPatientID
UpdatePatientRecord

U
U

GetUCareUserByUserName_Password
GetPhysicianByPhysicianID

GetPatientRecordByPatientID
GetPrescriptionListByPatientRecordID

U
Total Count

Table 4. Correctness assessment for health reporting

comp

= (Count p * P) + (Count a * A) + (Count e * E)

identification and prioritization of high-priority services.

There is always a dilemma about the definition of SOA.
Many think SOA is equals to web services. This is not entirely
true. From our point of view, SOA based system is often
developed with a set of components or services, and web
services are not mandatory component of a SOA.
SOA is not just architecture of services seen from a
technology perspective, but the policies, practices, and
frameworks by which we ensure the right services are provided
and consumed [1], [10]. So we need a framework for
understanding what constitutes a good service.
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 order to share the same back-end engines, the
components that are created must be platform independent.
Scaling the application or migrating services to different
platform or vendor is always a problem in many companies. It
always causes re-write the entire application or develops a new
solution. In order to re-use the existing applications and
migrates services without disturbing the existing system, SOA
is the best choice.
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

Count all
where:
Count p = Count Entry of Poor, P = 1,
Count a = Count Entry of Average, A = 2,
Count e = Count Entry of Excellent, E = 3,
Count all = Total Count of Entry

Figure 5. Assessment formula

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.
Completeness of the components defined can also be
assessed using the same formula.

4. Summary
SOA based system can be designed and implemented in
many ways. SOMA provides a good guidance in designing a

415

service-oriented solutions. (2008, August 6). Retrieved September 26,

2008,
http://www.research.ibm.com/journal/sj/473/arsanjani.html
[5] Arsanjani, A., IBM developerWorks, November 9, 2004
http://www.ibm.com/developerworks/webservices/library/ws-soa-des
ign1/
[6] Estefan. J., & Laskey. K., & McCabe. F., & Thornton. D.
Reference Architecture for Service Oriented Architecture Version 1.0
(2008, April 23). Retrieved October 14, 2008,
http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf
[7] Priscilla Fowler, Stan Rifkin, (September 1990) Software
Engineering Process Group Guide. Computer Sciences Corporation.
http://www.sei.cmu.edu/pub/documents/90.reports/pdf/tr24.90.pdf
[8] Wikipedia. Windows Communication Foundation. Retrieved
March 30, 2009,
http://en.wikipedia.org/wiki/Windows_Communication_Foundation
[9] Microsoft. How to: Host a WCF Service in IIS. Retrieved April 08,
2009,
http://msdn.microsoft.com/en-us/library/ms733766.aspx
[10] MSDN Blog. With or without SOA? Retrieved April 20, 2009,
http://blogs.msdn.com/bsinghal/archive/2009/02/02/with-or-withoutsoa.aspx
[11] MSDN. Understanding Service Oriented Architecture. Retrieved
April 20, 2009.
http://msdn.microsoft.com/en-us/library/aa480021.aspx

different parties and platform independent. The services should

be able to be created using any language and hosted on any
platform [7], [11].
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 logics. There are also
some components in the presentation layer that utilize the third
party services like calendar and map. Before adopting SOMA
method, we often create applications using bottom-up
approach. SOMA helps define the work breakdown structure of
activities and tasks while designing our prototype.
We have gone through a few iterations during the process.
Main reason is caused by incremental changes of
functionalities and to refine the design. This shows one of the
main concept of SOMA where fractal life-cycle model is used.

5. Conclusions
SOA offers a huge set of benefits by providing loose
coupling, platform neutrality, standards based implementation,
rigid contracts for version independence etc [11]. 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, where the application of
method tasks to self-similar scope, meaning tasks are done in a
similar way in larger or smaller boundary scopes. In SOMA
method, we identify the main activities in a broader scope
during the initial stage, and further elaborate and refine the
scopes in the later stage. This also fits well with the actual
software development environment where requirements
change incrementally throughout the development cycle.
As a conclusion, SOMA benefits in providing guidance to
development of SOA-based solutions.

References
[1] Brown, A., & Adams, A. (2007). The ethical challenges of
ubiquitous healthcare. International Review of Information Ethics
(Vol. 8), Article,
http://www.i-r-i-e.net/inhalt/008/008_9.pdf
[2] Microsoft. Connected Health Framework Architecture and Design
Blueprint, A Stable Foundation for Knowledge Driven Health.
(October 2006). Retrieved October 13, 2008,
http://www.microsoft.com/industry/healthcare/businessvalue/
chframework.mspx
[3] Erl, T. (2007). SOA Principles of Service Design (1st ed.). Prentice
Hall.
[4] Arsanjani, A., & Ghosh. S., & Allam. A., & Abdollah. T., &
Ganapathy. S., & Holley. K. SOMA: A method for developing

416