2008 IEEE International Symposium on Service-Oriented System Engineering
A Study of Design and Implementation on SOA Governance： A Service
Oriented Monitoring and Alarming Perspective
Kuang-Yu Peng
Shao-Chen Lui
Ming-Tsung Chen
Chunghwa Telecom,Taipei, R.O.C.
{ rolandpeng, boboki, kanebo}@cht.com.tw
Abstract
Integrating enterprise IT infrastructure and
providing services to the public, SOA (Service
Oriented Architecture) has been become the main
stream in the field of IT domain. For example, Web
Services as well as JMS (Java Message Service) are
techniques commonly applied in SOA. In order to make
sure that all services on the SOA platform are stably
served, SOA Governance has become more important
in terms of applying SOA to enterprise. But for various
particular governance requirements, it is not an easy
task to perform the role of governance well.
This document will describe the basic concept of
SOA, maturity model, and explore the enterprise
solution of integrating applications and management
of SOA. Then introduce how the evolution of CHT
(Chunghwa Telecom) toward SOA Governance and the
major functions of a practical governance system
named SOBUS (Service Oriented Bus) which is
developed by SOA Governance Evolution Project in
CHT.
1. Introduction
NGOSS (New Generation Operations Systems and
Software) Project initiated recently by Chunghwa
Telecom has been claimed to fulfill standardized
guidelines by TeleManagement Forum. When applying
techniques in NGOSS TNA (Technology Neutral
Architecture), the architecture of NGOSS project
should be neutral and flexible. SOA is perfectly
satisfying such requirements. SaaS (Software as a
Service) is currently quite an appealing way to provide
application service. Customers are charged by the time
of usage under the SaaS-based application. With the
growing of SOA, the extremely flexible and agile
architecture makes such a sales way more feasible and
more attractive to customers. However, another
978-0-7695-3499-2/08 $25.00 © 2008 IEEE 215
DOI 10.1109/SOSE.2008.26
important issue was led up while the enterprise owning
the convenience of the services. Who should take
charge of the stability of services? SOA Governance is
the key to solve this issue. When SOA was led in the
enterprise, SOA Governance must be in progress as
well.
Until now, SOA Governance is not a well-defined
term of tasks. In general, “Governance” means how to
coordinate and how to cooperate heterogeneous
services under the specified rules. According to the
definition of IBM [6], Governance is the establishment
of ：1) Chains of responsibility to empower people. 2)
Measurement to gauge effectiveness. 3) Policies to
guide the organization to meet its goals. 4) Control
mechanisms to ensure compliance. 5) Communication
to keep all required parties informed. On the other
hand, the key activities of SOA Governance mentioned
at WIKIPEDIA [1] are those ： 1) Managing the
portfolio of services. 2) Managing the service lifecycle.
3) Using policies to restrict behavior. 4) Monitoring
performance of services.
The major subjects of SOA Governance are to
retain the high reliability of services status, record how
many services are available to serve on the platform
and make sure all of the services operating within an
acceptable service level. Based on those requirements
mentioned above, the SOA Governance Evolution
Project in CHT was established to tackle all the issues
and then SOBUS (Service Oriented Bus) was
developed to assist the governance tasks.
This article introduces the experience of how we
promote CHT toward SOA Governance and briefly
describes the major functions of SOBUS developed by
Telecommunication Laboratories, including the
monitoring of web services and message services and
data analysis of services performance.
2. The SOA maturity model
 There are many SOA maturity models advocated by
analysts and SOA vendors, as IBM, HP, and Sonic etc.
This chapter will go through the points announced by
Sonic [2] and Kunal Mittal [3] first and compare the
model to our enterprise later.
The SOA maturity model is used to evaluate the
current state of SOA adoption of an enterprise. The
model is designed to enable the enterprise to identify
itself on a scale of 1 to 5 (with 5 being the most
advanced, or mature, level) in terms of architecture
maturity. Figure 1 shows the basic SOA maturity
model.
Figure 1: The SOA maturity model
At lower levels of maturity, individual project teams
define their own architecture using nonstandard
techniques. These techniques lead to less-predictable
and less-repeatable solutions that are difficult to
manage and do not adapt to change. As the enterprise
matures to Level 3 and 4, a strong enterprise
architecture group presence emerges that acts like a
governing body for architectural principles. Elements
of a reusable architecture appear, and are flexible to the
needs of each LOB (Line of Business) that it serves.
This solution tends to be effective, provides some level
of interoperability, and paves the path toward service
orientation. The Level-5 enterprise is one that has
implemented and been successful in its SOA initiatives.
This type of enterprise has bought into the concepts
and has evolved to the point of truly building and
sharing services among the LOBs and maybe even
with the customers, partners, suppliers, and possibly
even competitors.
An enterprise must determine what the first steps
are in its SOA initiatives. To be successful in
implementing SOA in the enterprise, we first need to
understand the IT landscape and overall architecture of
our organization. The SOA maturity model is just that
a means of helping us assign a level of maturity to the
216
IT architecture of the enterprise. When this assessment
is complete, we’ll have the information we need to
determine the best path to SOA for the enterprise.
This paper referred to is exactly our best practice
from Level 3 to Level 4 and toward Level 5 further,
truly achieving the SOA. It is important to ensure
services work well on SOA. The SOA Governance will
be applied to improve the performance and enhance the
reliability of services cooperation.
3. Overview of the practical governance
system
Before diving into the details, we shall have an
overview of the governance system. This chapter will
introduce the definition of SOA Governance and why
we choose to develop a governance system and then
give a brief picture of the system architecture.
3.1. Definition
According to the explanation of the previous
chapter, we have the definitely target of SOA
Governance. In the beginning of the task to SOA
Governance, we faced some special requirements：1)
Services will be deployed on ESB (Enterprise Service
Bus) of different brands. 2) Services are consisted of
two types, web services and message services. 3)
Requirements of services performance analysis may be
changed frequently. 4) The budget of resource is
limited at the initial stage. 5) The use of UDDI is
planned to be involved in SOA Governance.
There is not any suitable system on the market
could meet such special requirements, so we decide to
develop the system. The first priority of the SOA
platform operation is the quality assurance of the
platform which works day and night without any
exception. Based on these targets, the main functions
of SOBUS are listed below ： 1) Managing the
applications and registrations of the services on ESB. 2)
Managing and monitoring the web services and
message services. 3) Analysis of services performance.
3.2. Architecture
SOBUS is a system which assists CHT in
implementing SOA Governance to a higher maturity
level. It can be divided into two main subsystems, one
is for SOA platform monitoring and another is for
services management. The platform monitoring
subsystem includes web services monitoring module
and message services monitoring module. It is
responsible for sending the test message to the
monitored services and checking the healthy of service
platform, then recording the whole process and
operation information. The system managing
subsystem includes reporting module and alerts
notification module. It is in charge of providing
performance reports and exception alarming to the
system administrator and request users. Figure 2
demonstrates SOBUS system architecture.
Figure2 SOBUS system architecture
SOA platform includes ESB and EMS (Enterprise
Message Service). It takes charge of providing web
services and message services. For web services, ESB
acts as the service bridge between request users and
real backend services and provides proxy services as
the interface for users call. Each backend service maps
to at least one proxy service. Users may invoke
through proxy services without discovering the exit of
backend services. So all web services operations can be
controlled and monitored through ESB. For message
services, EMS is a message oriented middleware
providing two types of message services, queue and
topic. There is a set of specified management rules to
authenticate and authorize the message services which
will be mentioned later.
Based on two mentioned subsystems and a stable
SOA platform, the prototype of SOA Governance
system could be constructed.
4. System prototype
Service registration is a key element of SOA. SOA
with the registration allows OSS/BSS (Operations and
Business Support Systems) to use the services
provided by others in the organization. It is also the
first step in monitoring service. In order to monitor all
services, including web services and message services
in our SOA platform, it is necessary that all services
must be registered in SOBUS first.
217
4.1. Service models overview
The EMS is based on the JMS (Java Message
Service). The JMS is a messaging standard that allows
application components based on J2EE (Java 2
Platform, Enterprise Edition) to create, send, receive,
and read messages [5]. It enables distributed
communication that is loosely coupled, reliable, and
asynchronous. The term 'communication' can be
understood as an exchange of messages between
software components. Message-oriented technologies
attempt to relax tightly coupled communication such as
TCP network sockets, CORBA or RMI. It allows
software components to communicate indirectly with
each other. One of benefits is message senders no need
to know any precise knowledge of their receivers since
communication is performed using the messaging
service model.
The JMS supports two types of communication
models, queue and topic. In the queue model, a
producer sends messages to a particular queue and a
consumer receives messages from the queue. The
producer knows the message destination and sends the
message directly to the consumer's queue. It is
characterized by the following ： 1) Only one
consumer will get the message. 2) The producer needs
not to be active when the consumer consumes the
message, nor does the consumer need to be active at
the time the message is sent. 3) Every message
successfully processed is acknowledged by the
consumer.
The topic model supports publishers publishing
messages to a specific message destination and
subscribers subscribing messages from that. In this
model, neither the publisher nor the subscriber knows
about each other. The following are characteristics of
this model：1) Consumers can get the message and
there is a timing dependency between publishers and
subscribers. 2) The publisher has to create a
subscription for subscribers to subscribe. 3) The
subscriber has to remain active continuously to receive
messages unless it has established a durable
subscription. In that case, messages published while
the subscriber is not connected will be redistributed
whenever it reconnects. Figure 3 shows the JMS
programming model.

Figure 3 JMS programming model
Web service is a kind of application program based
on XML and supports the communication between
different operating systems over a network with
different programming languages. For example, Java
can talk to .NET, Windows applications can talk with
Unix-like applications. The XML, WSDL, SOAP and
UDDI open standards are used to describe a
standardized way of integrating web based applications
over the internet protocol backbone. XML is used to
package the data, SOAP is used to transfer the data,
describing the services available is used WSDL and
listing what services are available is used UDDI. Web
services allow organizations to communicate data
without intimate knowledge of each other's IT systems
behind the firewall when communicating with each
other or with clients. Figure 4 describes web services
basic model. [4]
Figure 4 Web services basic model
4.2. Service monitoring
Service registration is stricter in the monitoring
message services. In addition to services required to
submit applications for registration, the users who
would like to use this service also make an application
for using the service. Service was named by service
218
provider according to particular naming rules. On the
purpose for the user easier to understand the usage of
message service, the names of the destinations must be
simple, clear and consistent. Fill out a detailed
description of services, purposes, the monitoring
conditions and its threshold, and the way of warning
type. Service providers have to submit applications of
registration and monitoring to SOBUS. Once the
application is approved, the other users can find the
services they would like to use. If a user wants to use a
service, an application must be submitted. Similarly,
the service users can define their monitoring conditions.
In order to use message services, we must have a
MOM (Message Oriented Middleware) that can
manage the sessions and resources. Management of
MOM is also one of the critical points in message
services. The MOM management includes
authorization control, destination permission control,
resources control, messages reliable delivery and
message filtering, etc., to maintain the normal
operation of MOM.
In web services, the service registration includes
service packing and backend application configurations.
The main purpose of service packing is creating a
process with web services provided by services
provider which follows SOBUS monitoring criteria
and adding monitoring components in process. When
users using the service, all related details between
components will be logged, such as input parameters,
whole process execution time, call backend application
response time, etc. With the monitoring data, it helps
SOBUS to do some important performance analysis
and then improves designed process. With backend
application configurations, only URL of WSDL and
connection type of service from service provider are
necessary.
Further more of web services monitoring, two jobs
including ping test and WSDL content length
comparing are invoked on schedule to monitor web
services. The ping test ensures the healthy of network
connection. It is a basic monitoring function since all
services are in heterogeneous and distributed
environment. When backend application is registered,
the URL is used to give a WSDL accessing test, parse
content and store its length when the monitored job
running. According to the result of comparison, it will
be the foundation of warning notification.
Except these two jobs, the real client invocation is
simulated to perform a test. This simulation program is
generated automatically through the registered WSDL
stored in the repository. Then follows the test plan
which is corresponding to each web service to get the
results and check the accuracy.
4.3. Service notification can be calculated using particular statistics methods.
Even if the failure of service calling occurred, SOBUS
All services can be monitored after services also keeps the service failure rate for the service
registrations are completed. If any exception occurs, provider as operation reference. In message services,
the alarm notification is automatically invoked. In KPI includes：1) The amount of queue/topic usage. 2)
message services monitoring, the most important is The real-time pending messages counts of
whether MOM works well or not. Users can use queue/topic/durable.
SOBUS to monitor how many clients are connecting to Over 100 services, including web services and
MOM, lists of all destinations and concurrent message services on the SOA platform, are stably
connections for each destination, and messages served for more than 60 OSS/BSS at present. Through
statistics, etc. Messages statistics in each destination checking services performance analysis, services
include how many messages produced, how many providers and the platform administrator can evaluate
messages consumed, how many pending messages in whether the service with rarely usage to be disabled or
each destination, etc. In message services warning not and improve the efficiency of poor services. Users
notification, SOBUS can monitor them and detect can easily retrieve the relative statistics information
warning according to monitoring conditions and its from graphical charts as shown in figure 5.
threshold set by users in the registration. For the
monitoring condition of threshold values, it’s also a
kind of SLA (Service Level Agreement) defined to
assure the quality of message services. There are many
monitoring conditions in SOBUS such as MOM work
abnormally, too many concurrent connections in MOM
or in each destination, too many pending messages in
each destination, detecting and deleting unusual
customer connections automatically, destination not
used in certain period and client library version
detecting, etc. If any warning condition mentioned
above occurs, SOBUS will notify customers or service
providers by E-mail or SMS (Short Message Service)
immediately so that the exception can be solved as
Figure 5 KPI of service performance
soon as possible..
In web services warning notification, we have
Only a few operating information can be retrieved
mentioned about two jobs of testing in the previous
on the SOA platform in the beginning before
section. If the testing result is unexpected, SOBUS will
implementing SOA Governance. After executing SOA
send warning notification by using E-mail or SMS.
Governance for a period of time, we have some
achievements in the improvement of services usage.
5. Services performance and data analysis According to the investigation of statistics on SOA
platform, as Figure 6 demonstrated, the average
Quality assurance is an important issue over SOA amounts of message sessions are up to 90 millions, and
Governance. SOBUS provided some KPI (Key the report shows that the top usage level of web
Performance Indicator) to indicate services services is up to 2 million counts during a month. That
performance. As mentioned above, there are two types means the usage of services within enterprise has the
of services on the platform, web services and message increasing trend after system integration via SOA.
services. Therefore, SOBUS provides two types of data
analysis separately to evaluate services performance.
KPI in web services includes：1) The amount of
service usage. 2) Latest/mean/longest services access
time. Users invoke the proxy services at first and then
the relative backend services are called by specified
workflow. So the key information, such as begin time
of service invocation and end time of service return,
etc., are stored in database after each call of web
services. The amount of service usage and the service
execution time by proxy service and backend services

219
 [3]SOA Maturity Model
http://www.sonicsoftware.com/solutions/service_oriented_ar
chitecture/soa_maturity_model/index.ssp

[4] Web Service Architecture

http://www.w3.org/TR/ws-arch/#webarch

[5] Sun Java™ System Message Queue 3

http://docs.sun.com/source/819-2224/index.html

[6] Introduction to SOA Governance

http://www.ibm.com/developerworks/architecture/library/ar-
servgov/?S_CMP=cn-a-wes&S_TACT=105AGX52
Figure 6 statistics of services’ usage

6. Conclusions and future work

SOA Governance is one of the most important
fundamentals to realize SOA technology. It is our best
practice in maturity model from Level 3 to Level 4,
even toward Level 5. It also helps the enterprise to
ensure and realize the important benefits of SOA such
as adding business services agilely and protecting IT
investments. SOA Governance also reduces the time
schedule to adopt SOA and helps to avoid the risk
while delivering the services. The effective strategy of
SOA Governance must not only ensure the consistency
of behavior of project develop teams and corporate
goals, but also must emphasize and focus on the
security that compliance with standard specification.
In this paper, different methods are used to monitor
the services base on the type of services. In order to
achieve the goals of SOA Governance, consolidating
the integrity of services, increasing the transparency of
services, establishing interoperability, consistency and
formal service agreements between users and providers
and the management of services lifecycle are what we
trying to do.
We plan to extend our current job for the security
issues between services and try to create a SOA
repository to store all related information or resources
about SOA Governance. The information stored in
SOA repository ensures users and system
administrators quickly and easily finding relationship
and ownership between services. It helps to figure out
and fix the troubles as soon as possible and also
reduces the maintenance effort to make it more
efficiency.

7. References.
[1]WIKIPEDIA- SOA Governance
http://en.wikipedia.org/wiki/SOA_Governance

[2]Service Oriented Architecture Maturity Model

http://www.kunalmittal.com/html/soamm.shtml

220