Maintenance Best Practices for Service Oriented

CPSC 543 Software Maintenance

Maintenance Best Practices for Service
Oriented Architecture (SOA)
May 15, 2009

Submitted By
Ali Raza

Submitted to
Prof. Allen Holliday
California State University, Fullerton

i

Table of Contents

1 Introduction.................................................................................................................................1
2 What is Service-Oriented Architecture (SOA).............................................................................1
3 SOA Building Blocks..................................................................................................................2
4 SOA Design Principles for Development and Maintenance.........................................................3
4.1 Guiding principles ...............................................................................................................3
4.2 Specific principles ...............................................................................................................3
4.2.1 Loose coupling .............................................................................................................3
4.2.2 Encapsulation ...............................................................................................................3
4.2.3 Abstraction ...................................................................................................................4
4.2.4 Contract .......................................................................................................................4
4.2.5 Reusability ...................................................................................................................5
4.2.6 Composability...............................................................................................................5
4.2.7 Autonomy .....................................................................................................................6
4.2.8 Optimization..................................................................................................................6
4.2.9 Discoverability ............................................................................................................6
4.2.10 Relevance ...................................................................................................................7
5 Maintenance of SOA Infrastructure [2]........................................................................................7
6 Maintenance Role for SOA [2]....................................................................................................7
6.1 Front End Support Group ....................................................................................................8
6.2 Back End Maintenance Group .............................................................................................8
6.3 Database Support for End Point Group ...............................................................................8
6.4 Management group for maintenance ...................................................................................8
6.5 Business Process Design .....................................................................................................8
6.6 Quality Assurance ...............................................................................................................8
7 SOA Governance ........................................................................................................................8
8 SLA (Service Level Agreement) and SOA..................................................................................9
9 Reusability for SOA System........................................................................................................9
10 Quality of Services (QoS) .......................................................................................................10
11 Reverse Engineering and SOA.................................................................................................10
12 Conclusion...............................................................................................................................11
13 References................................................................................................................................12
14 Appendix A..............................................................................................................................13
14.1 WSDL..............................................................................................................................13
14.2 SOAP...............................................................................................................................13
14.3 BPEL................................................................................................................................13
14.4 UDDI................................................................................................................................13
14.5 OASIS..............................................................................................................................13

i

1 Introduction
Software Maintenance plays a key role in an enterprise environment. This is because software
maintenance embodies more efforts than any other software engineering activity.
Major progress has been observed on the Web during last two decades. The web became more
distributed and dynamic. Most of the companies have moved their core applications to the web.
As a result, the web has been evolving and we have seen a significant growth of software
systems that are developed in the form of services which are available through infrastructure.
Not only do these services help to increase the productivity but also these are changing the
mindset of the entire enterprise. These services are delivered by utilizing either open or
proprietary network protocols. Additionally, these services are available either on corporate
intranets or on the Internet. This approach to systems development is usually referred to as
service-oriented architecture (SOA), SOA-based systems, or service-oriented systems [1].
The SOA trend has a set of implications for system development and maintenance processes.
The standard process for maintaining SOA systems are derived from the standard maintenance
process which offer a starting point, however, a number of tasks in SOA environments are
different from those traditional maintenance tasks and therefore require a different set of
approaches [2].
This research paper attempts to provide information about the maintenance best practices for
SOA-systems. It outlines the current research work for the SOA products and how we can
maintain the SOA-system. Additionally, for acronyms, please refer to Appendix A.
2 What is Service-Oriented Architecture (SOA)
The intention of SOA architecture is to improve efficiency and overall output of the enterprises.
In the SOA system, we develop and support services in which solution logic is represented.
These services are associated with enterprise strategic goals through the service-oriented
computing.
The service-oriented computing platform spins around the service-orientation design paradigm
and relationship with service-oriented architecture. SOA is simply a group of web services that
communicates with each other. This process of communicating involves between service
provider and a client, consumer [13].
The SOA implementation can consist of technologies, products, APIs, supporting infrastructure
and various other components such as BPEL. However, each enterprise would have a unique
service-oriented architecture. Building technology architecture around the service-oriented
architectural model determines an environment suitable for the system solution [4].
In SOA, service orientation is a design model which consists of a specific set of design
principles. On the other hand, service itself is just an independent program which would have its
own functionality and capabilities.

1

3 SOA Building Blocks
SOA building blocks consist of three building components – web services, the application that
discovers those services and finally, the SOA infrastructure. Figure number 1 illustrates the
SOA Components [2].
Each service presents a business process and provides interface, so that clients can invoke the
service. On the other hand, SOA infrastructure provides the mechanism to communicate between
two applications.
Additionally, these web services are independent software components which are used in various
service oriented applications. Web services are described before being published and they can be
discovered and invoked via Web infrastructure by using a stack of known standards protocols
and contracts such as SOAP, WSDL and UDDI [7].
Figure number 1 illustrates SOA Components

Application A Application B Application C

SOA Infrastructure

Security Component Deployment Tool Discovery

rd
3 Party Services
via Internet
Service B Service C Service D

SQL Server/
MYSQL/DB2
database

Legacy or Mainframe System

2

4 SOA Design Principles for Development and Maintenance
For building and maintaining SOA products, we actually need to follow some principles. There
are two kinds of principles – Guiding Principles and Specific Principles.
4.1 Guiding principles
Following are the ground rules for development, maintenance and how to use SOA [5] [6].
• Reuse, granularity, modularity, component based and interoperability.
• Also, we need to follow the standards to build SOA systems such as SOAP and WSDL.
• Services identification and categorization.
• Service needs to deliver or provide required data
• Service monitoring and tracking [6].

4.2 Specific principles
These principles are related to the architecture and design. Additionally, these principles would
help maintainers during the maintenance process.
4.2.1 Loose coupling
The loose coupling strategy provides adaptability, flexibility and increased efficiency. It is an
important factor for delivering information as a service to make sure that data is available and
can be reusable.
Typically, coupling refers to a connection or relationship between two programs or component.
As per this principle each service in SOA system should have its own individual design. For this
purpose, each component service is an intentionally discrete component and can be bound
dynamically in real time easily and quickly with other services. As a result, each service will
behave like a single tightly coupled application.
During the maintenance mode, maintainers need to make sure that services maintain a
relationship that minimizes dependencies, so that it would have a minimum impact on the system
[6]. In SOA context, web services offer an alternative approach to enterprise integration on the
fly instead of the tightly coupled integration between applications through customized code or 3rd
party systems. SOA systems allow loose coupling of existing systems from two perspectives,
architecture and the network organization.
Maintainers can easily modify the services which have been used in SOA systems, if services are
loosely coupled. However, at the same time they have to verify each and every service which
communicates with the loosely coupled service. In SOA, the loose coupling standardizes the
relationship to a limited set of transactions so that services can be tested, optimized and made
available to applications across all technical boundaries. Thus, SOA provides the loose coupling
that is required in modular process architectures, and support process-level efficiency benefits
[8].
SOA is the collection of the services where we can modify each service individually and
independently. Therefore, developers or maintainers don’t need to worry about the other
services, if the services would have designed according to this principle.
4.2.2 Encapsulation
Service Encapsulation is the practice where all the solution logic, resources and information is
contained within a single service and its boundaries.

3

Let’s say we have some legacy environment. This legacy system calculates the insurance
premium. For this purpose, we need to come up with the service in which any customer can
consume premium service and upon consuming this service will send the response (premium)
back to the consumer. In this situation, all our logic would be encapsulate in one service on the
service provider side by using new calculation and legacy APIs. Additionally, the service
provider side we will use the legacy API, calculates the premium and send response back to the
consumer. Thus it is very necessary that during SOA design we need to come up with discrete
and complete service solution rather than invoking many services.
There are two aspects of maintenance in service encapsulation. Firstly, if we are the consumer of
a particular web service then clearly we don’t need to understand the solution logic, all we need
to do is just send the request and get the response. Secondly, if we are maintaining a service then
we need to consider the encapsulation principle mentioned in an object oriented world. This is
because in an object oriented world, we bundle the data and its related functionality together as a
unit class. As a result, maintenance would be much easier on the class level. Similarly, in SOA
our business logic and other information or data related to any particular functionality will be a
separate service. So in the future, if we have to make any changes then it would affect only one
service.
4.2.3 Abstraction
Abstraction is a technique in which we hide information about the encapsulated service. So in
other words, during development or maintenance of SOA systems, we determine how much of
encapsulated logic, business logic, we are exposing to the public. This way, consumers programs
would be less affected. This is because all the underlying information about the service will be
hidden to the outside world and all consumers will do is just invoke the service by using
interfaces and get the result back.
To achieve this principle on SOA systems, we need to design services that are consistently
abstract which should have specific information about technology, logic and functions [4].
Therefore, during system development, we need to make sure that we are hiding business logic
from outside world. So in other words, we need to separate business logic from the underlying
technology and provide only interface in order for any service to be consumed.
This principle would be very helpful during maintenance. This is because, let say if we are the
consumers of the service then all we need is to make sure that we can invoke the service and
getting the response back from the server. We don’t need to understand entire service
functionality; therefore our approach would be a black box invoking approach. Thus, the effect
of this principle is less coding and maintainers can reuse the service faster. All maintainers have
to do is just become familiar with the interface of the service so that they can invoke a particular
abstracted service quickly and easily.
Hence, we can say that this SOA principle allow us to establish services as a black box.
4.2.4 Contract
For SOA system we need to get a hold of the communication and performance agreement. For
communication we use WSDL and for performance we use SLA.
This principle would provide us some important information about the service such as service
information (version, name, processes and owner), additionally, how to invoke the services and
what kind of action or operations have been provided by a particular service. Moreover, this is a
key principle with respect to maintenance. This is because service contracts provide the technical
constraints and requirements to the consumers.

4

For instance, through WSDL, we would know how many operations are public and what to
expect from the service. Additionally, which kind of binding service provider is being used and
how to invoke a service? For maintainers, this service contract is very important. This is because
let’s say there is no documentation available and this maintainer just joined this maintenance
project then by simply looking at WSDL, they would know all the information about the service
right away. Thus, maintainability will be increased.
4.2.5 Reusability
In the SOA world we can design a service in such a way that it can be reusable repeatedly. For
this purpose the service has reuse potentiality if it provides capabilities that are not specific to
any one business process [4].
Furthermore, with respect to maintenance, this is one of the key principles for SOA as well;
therefore, maintainers should be very careful during maintenance mode. According to this
principle, design service logic in such a way that it can be reusable. This principle would help
maintainers a lot. This is because they can reuse the same service over and over again.
Additionally, once the program has been implemented and is in use, we need to ensure how we
are going to reuse this program and how it will be evolved. Certainly, we cannot just arbitrary
make changes to any reuse service. Therefore, we need to perform impact analysis first and then
make changes.
Additionally, if we are fixing a defect or adding new functionality and during this process the
interfaces of a particular reuse service will change, then we need to inform consumers about his
change.
On the other hand, if a particular reuse service is going to be changed then QA needs to verify
that it won’t impact existing functionality; therefore, they need to perform regression testing.
Similarly, if interfaces of any reusable services will be changed then we need to test all the
components which are using this service. This is because if interfaces change then consumers
need to make changes as well. Therefore, we need to test service provider and all the components
which are using this service.
4.2.6 Composability
Composition is one of the important principles of SOA. Composition is a vital part of software
design in that we can benefit from the decomposition of solution logic in that it can be
recomposed into new configurations to solve various kinds of similar problems. There is a
relationship between service reusability because composition can be seen as a form of reuse.
Therefore, the service composition starts off with simple design and ultimately it becomes very
complex. For this purpose the service contract needs to be flexible so that it can aid different
types of data exchange requirements for similar functions.
During maintenance, we need to make sure that services would remain coordinated and they
need to tie together, so that maintainers and developers should come up with composite solution
rather than reinventing the wheel. This is because the more SOA system will continue to grow,
more it gets complex. Therefore, in maintenance mode, we need to maintain a single composite
service solution which then calls other related services. For instance, if we need to add one new
feature for a new requirement and it can be achieved by invoking multiple services during
maintenance, rather than we create or develop a new service, we should collectively reuse
existing services. This way we will not only reduce the cost but our productivity will be increase.
However, we need to be extra cautions during this activity because during the composition we

5

should not change any design and coding otherwise it will affect other services, and it may have
ripple effects to other services.
Thus, the concept of composition is kind of similar to reusability. This is because service
composition often turns out to be a form of reuse [4].
4.2.7 Autonomy
In the SOA, autonomy represents the capability of implementing any service and its design logic
independently. As a result service would have the control to govern itself at runtime and it will
be more reliable and predictable. On the other hand, a dependable service would have influences
from the outside world, service, and at the same time it would not be reliable and loose coupled.
The goal of this principle is to reliability, performance and predictability and to increase the
amount of control during service runtime environment. This is because, as per this principle we
need to increase post implementation control over the service and the service control over its
own executions environment [4].
Furthermore, a single service could be the composition of multiple services and it should have a
high level of control over underlying runtime services. High level means independent, so that it
can be reused and reliable. Also, during maintenance, if we find any issue on a particular service
which was designed on this principle then it would be much easier for us to maintain because of
the characteristics of this principle.
Therefore, maintainers need to consider this principle during reusability, so that they can fix
defects or add new features quickly and assemble any service.
4.2.8 Optimization
This principle is related to reusability. As discussed, above, during maintenance or development
there are a number of times we consider reusing the existing service. Therefore, before we will
plan to reuse any service, maintainers need to consider high-quality services as compared to low-
quality ones. But at the same time, there is a tradeoff, if we are reusing a service over and over
again which considered being a high-quality then it may affect the performance. Therefore, all
things need to be examined before we try to use existing service. Thus by using this principle,
we eventually optimize our SOA systems.
4.2.9 Discoverability
Services are designed to be externally descriptive so that they can be found and we can access
any service via available discovery mechanisms [11].
In SOA, service contract are set with suitable meta data that will be properly referenced when
discovery queries are issued. For this purpose, the meta information is used to make service
contracts discoverable and interpretable and provide guidelines for how and when service
contracts should be further added with comments. So in other words our goal will be to improve
the communications quality of service meta data. Furthermore, we record meta data information
outside of the contract. This information is either composed in a supplemental document in
preparation for a service registry or it is placed in the registry itself [4].
This is a very important principle for maintenance perspective. This is because during
maintenance, if the service cannot be discovered, located or searchable, then maintainers will
introduce a new similar service, and ultimately our SOA system would have functionalities that
overlap with the existing services and will introduce redundancy. As a result, it will affect other
principle such as reusability and optimization, and over all enterprise architecture becomes
complex.

6

Therefore, it is very important that the SOA systems should follow this principle. For this
purpose, the team should be aware of SOA discovery process and how services can be
searchable.
4.2.10 Relevance
The functionality of the service which is available through the service provider needs to be
documented, accepted and recognized by the consumer as a meaningful service. This is because
for instance, if we are maintaining an application and consuming a service where we don’t have
any system documentation, but a service end point has meaningful operation names and
maintains the industry practice. Then in this situation, we can understand that service quickly and
easily. At the same time if we are maintaining a SOA system where we are using many service
and there is no documentation available then by looking into naming conventions and relevant
operation names, we would understand the system. On the other hand if naming conventions are
not following industry practice and standard business process name then it would be very
difficult to understand the system. As a result it will time to fix the code or add new features.
5 Maintenance of SOA Infrastructure [2]
Maintainers of SOA infrastructure always try to provide a stable infrastructure. This
infrastructure is based on standards, infrastructure services and maintenance tools. Moreover,
infrastructure supports the SOA protocol and data format of the service. We can classify SOA
infrastructure into three categories.
• Infrastructure developers/maintainers - These resources are focus on providing a stable
infrastructure that includes standards, infrastructure service.
• Developer/Maintainers who focus on the client side, for discovery, composition and
invocation of service.
• Developers/Maintainers who focus on the granularity of service so that application can
easily locate and can be used by the consumers.

The tasks for the developers/maintainers with respect to infrastructure, client and server provider
side are as follows.
• Reuse standards and products to implement as part of infrastructure.
• Maintain a set of infrastructure services such as discovery of the services, communication
between client and services and security.
• Document and support infrastructure.
• Understand existing SOA infrastructure.
• Invoke identify service in application and test those service, so that they can implement
error handling, availability and any data conventions issues.
• Test services during new service addition and create the test harness approach to verify
the results.
• Maintain/Develop code that receives the service request, execute the process and then
send the response back.
6 Maintenance Role for SOA [2]
As we have seen, there are many components which were described by SOA systems; therefore,
we should assign roles for the maintenance of SOA system. We can divide these roles into
different groups, such as

7

6.1 Front End Support Group
This group is responsible for supporting the SOA-based application that is in direct contact with
business customers. This group contains two kinds of roles
• Personnel support – Help customers in the day to day operation of business process,
accepts reports on problem or changes in business process.
• Secondly, business process support personnel – Conforms reported problem in business
process and identifies workarounds.
6.2 Back End Maintenance Group
This group is accountable for creating, maintaining reusable services and business processes.
Therefore, individual who belong to this group must be proficient in business processes as well
as services.
6.3 Database Support for End Point Group
Traditionally, this group is a database group which will maintain the legacy databases and their
interfaces, so that any service can retrieve the data from the database by using the interface.
6.4 Management group for maintenance
This is the important group in the SOA system. This is because this group is responsible for the
governance of SOA-systems and ensuring that business needs are met on a strategic, planned and
operational level. The individual in the group needs to have both in depth business knowledge
and technical knowledge so that they can support enterprise environment.
6.5 Business Process Design
This group is responsible for modeling and building architecture of business processes.
6.6 Quality Assurance
This group is responsible for the quality of the SOA system by using business processes and
assuring their interoperability.
7 SOA Governance
SOA governance plays very important role in the SOA system. They do not only guide
development/maintenance of reusable service but also provide information on how these services
should be implemented. Moreover, SOA governance would demonstrate how those services will
change over the time. Additionally, it established the process of change for SOA systems. That
includes agreements between the provider of services and consumer of the services. This would
help consumers to know what to expect from the services and at the same time providers to
inform what to provide. SOA governance team doesn't design service rather it guide other
development and maintainer teams how to modify or build the services and how to follow SOA
principle. As a result, the SOA governance team determines many key issues such as how many
service will be needed? If change required, for example, to add new feature in the existing SOA
system then do we need to build a new service or do we need to change the existing service?
SOA governance also builds the bridge between business and technology. This is because
technology and business are focus on requirements; however SOA governance team would
ensure that both parties are working together and their efforts are not contradicting with each
other [14]. Furthermore, SOA governance setup policies for identification, development and
maintenance of service, establishment of service level agreement (SLAs), management of service

8

registries, and other effects. Once these policies are setup, technology can used to manage those
polices. For instance, technology doesn’t define SLA, instead it can be used to enforce and
measure compliance.
8 SLA (Service Level Agreement) and SOA
A service level agreement (SLA) is a contracted delivery time of the services. From which we
can measure the performance. In other words, it is an agreement or contract between two
services, between client and service provider. From an enterprise perspective SLA plays a key
role in the context of SOA. This is because SLA is developed for reasons such as business meets
their goals by the interaction of services which usually contain a business process. By the help of
SLA, we can establish assurance to quality levels which can be essential to service users and
providers together [10].
Thus, performing maintenance on SLA is very important so that we can ensure SLA live and
breathe. For this purpose we can conduct below activities.
• We can conduct monthly review performance meeting with customers, management and
maintenance team, so that we would know the monthly performance and if there are
some spikes or issue during some certain timeframe then we can go back to our desk and
find the root cause. Also, it may give us an opportunity to isolate any changes in the
service agreement.
• Furthermore, we can also find out the most impacted area from customers which can be
determined from performance meeting. So that we can collaborate with customers and if
they need any training on a certain function, it will be provided to them.
• Moreover, based on our monthly finding, we can negotiate our SLA agreement after
every year such as we can adjust time of response, business process etc. For instance, if
we invoke one service and before it is working fine but from last 12 months it response
time went a few sec up due to data optimization then we can adjust the SLA agreement
with the customers and management [10].
9 Reusability for SOA System
Although reusability is the goal of the software system ever since the application had been
developed but in SOA, it is very important concept and a core idea. SOA is a distributed
architecture in which applications are built by organizing reusable service using business process
or work-flow. The complexity of maintaining these processes is address by SOA development
life cycle, Modeling, Development/Maintenance, executing and Monitoring [9]. SOA is the
solution which is based on services. These services provide standard interface which promote
reusability. The goal of SOA is to reuse service and integration of various systems.
As a maintenance point of view, SOA provide black box approach. This is because any
consumer can invoke services and get the data back. Therefore, they don’t need to know about
the implementation details as long as service is available and they can invoke. Maintainers can
reuse service without any modification. Furthermore, reusability allows maintainers to develop
any new future quickly and easily.
In SOA world the more emphasis is on business drivers, and aligned IT process with these
business drivers such as SLA, therefore, SOA approaches both business and IT from the
perspective of reuse. As a result, SOA reusability idea would not only help maintainers to reuse
any service but also the business user. This is because SOA enables business analysts to define,
change and optimize the business process with minimum help from IT department.

9

10 Quality of Services (QoS)
Web services are key component in SOA system. In web services the concept of quality of
service (QoS) has been used extensively in the middle tier and networking. In quality of web
service (QoWS) may include functional and quality attribute requirements which measure web
service performance. In SOA world we can measure following quality attribute as per non
functional perspective [3].
• Response time – It is the response delay time between two services such as a time
between two services were invoked and response the data back to the client from the
server.
• Reliability – The ability of a service operation to be executed within maximum expected
timeframe.
• Availability – a high available service operation is one that will most likely be working at
a given instant time.
• Accessibility - service operation is capable of serving a Web service request, for instance,
there could be situations when a Web service is available but not accessible.
• Scalability refers to the ability to consistently serve the requests despite variations in the
volume of requests. This parameter can be quantitatively measured.
• Integrity - A transaction refers to a sequence of activities to be treated as a single unit of
work. All the activities have to be completed to make the transaction successful. When a
transaction does not complete, all the changes made are rolled back.

Thus, maintainers need to make sure that QoS management is properly handled into SOA
environment, so that SOA systems would sustain its core idea and at the same time the system
would remain dynamic and flexible. For this reason, QoWS management must be integrated in
the SOA.
11 Reverse Engineering and SOA
In the context of software engineering, the term reverse engineering was defined in 1990 by
Chikofsky and Cross in their seminal paper as the process of analyzing a subject system to (i)
identify the system’s components and their inter-relationships and (ii) create representations of
the system in another form or at a higher level of abstraction [12].
As per Chikofsky, in reverse engineering we discover many components of the systems and also
we try to find the relationship among those components. As a result we would get the
composition of the system or may also get the high level view about the system. Thus, we can
say that reverse engineering has been view with two aspects, information extraction and
abstraction.
In SOA world, reverse engineering would be little bit challenging. There are two kinds of the
components in web services, service provider, which serves the service and the client,
consumers. Since the implementation details and technology is hidden on service provider side
therefore we cannot perform reverse engineering rather our approach will be black box. For this
approach service providers typically provide some kind of documentation and WSDL, from
which we would understand the interfaces, operations and as a result we can invoke the service.
However, from the consumer side we can apply reverse engineering techniques.
Moreover, upcoming work in reverse engineering can support service providers to automatically
produce service/component annotations capable of supporting automatic discovery and

10

reconfiguration mechanisms [10]. After this support, we can able to execute trace, extract source
code, and monitor data or build understanding among modules.
12 Conclusion
This paper provides maintenance best practices for SOA system. For this purpose, this paper
discussed fundamental principles of SOA which have to be considered during maintenance and
development of SOA system, supporting groups for SOA system and other maintenance and
development aspects of SOA system.
As we all know the growth of SOA is getting increased day by day and now most of the
enterprise went through with the learning curve of SOA system. As a result more systems will
fall under maintenance mode; therefore this paper will be useful for those maintainers who want
to use industry best practices for SOA systems.
Furthermore, this paper is also very useful for SOA governance group. This is because this group
is the one, who not only responsible for successfully adoption of SOA and new development but
also the maintenance process for technical services as well as business process and entire SOA
system.
Additionally, if we don’t use or follow best practices then not only we will be building incorrect
solutions but also the productivity will be affected and company’s bottom line will be impacted.

11

13 References
[1] Kontogiannis Kostas, Lewis A. Grace, Smith B. Dennis. “The Landscape of Service-Oriented
Systems: A Research Perspective for Maintenance and Reengineering”.
http://www.cs.vu.nl/csmr2007/workshops/1-%20PositionPaper-SOAM-v2-4.pdf

[2] Kajko-Mattsson, Mira, Lewis, A. Grace, Smith B. Dennis. “Roles for Maintenance and
Evolution of SOA-Based Systems”.
http://www.cs.vu.nl/csmr2007/workshops/3-%20Kajko-Mattsson-soa-role.pdf

[3] Yu Qi, Liu Xumin, Bouguettaya Athman, Medjahed Brahim. “Deploying and managing Web
services: issues, solutions, and directions”. The VLDB Journal; Springer-Verlag, 2006.
http://people.cs.vt.edu/~xuminl/WS-Survey-VLDBJ.pdf

[4] Erl Thomas. “SOA Principles of Service Design”. Prentice Hall, 2008.

[5] Balzer Yvonne. “Improve your SOA project plans”. 16 July 2004.
http://www.ibm.com/developerworks/webservices/library/ws-improvesoa/

[6] “Service-oriented architecture”. http://en.wikipedia.org/wiki/Service-oriented_architecture

[7] CHUKMOL Uddam. “A Framework for Web Service Discovery: service’s reuse, quality,
evolution and user’s data handling”. ACM, 2008

[8] Mooney G. John and Ganley Dale. “Improving business agility with loose coupling and a
Web services oriented architecture”. 15 Nov 2007.
http://searchdatamanagement.techtarget.com/generic/0,295582,sid91_gci1282202,00.html#

[9] Muthusamy Vinod, Jacobsen Hans-Arno. “SLA-Driven Distributed Application
Development”. ACM, 2008

[10] Bianco Philip, Lewis A. Grace, Merson Paulo. “Service Level Agreements in Service-
Oriented Architecture Environments”. SEI, 2008.
http://www.sei.cmu.edu/pub/documents/08.reports/08tn021.pdf

[11] LaBounty Char. “How to Establish and Maintain Service Level Agreements”. Help Desk
Institute, 2002.
http://www.thinkhdi.com/library/deliverfile.aspx?filecontentid=55

[12] Canfora Gerardo and Penta Di Massimiliano. “New Frontiers of Reverse Engineering.”
IEEE, 2007

[13] “Service-oriented architecture”.
http://en.wikipedia.org/wiki/Service-oriented_architecture#Introduction

[14] Woolf Bobby. “Introduction to SOA governance”. Jul 2007 (Published 13 Jun 2006).

12

http://www.ibm.com/developerworks/library/ar-servgov/
14 Appendix A

14.1 WSDL
WSDL stands for Web Services Definition language. It is an XML format layout for describing the Web
service.

14.2 SOAP
SOAP stands for Simple Object Access Protocol. This protocol is based on XML which used to exchange
messages between web services.

14.3 BPEL
BPEL stands for Business Process Execution Language. It is a computer language based on WSDL,
XML, XSD and XSLT and designed for programming business services.

14.4 UDDI
UDDI stands for Universal Description, Discovery and Integration. It is a platform independent XML-
based service registry provided by OASIS

14.5 OASIS
OASIS stands for Organization for Advancement of Structured Information Standards. It is a group which
promotes web service standards.

13

Maintenance Best Practices for Service Oriented

More Related Content

What's hot

Viewers also liked

Similar to Maintenance Best Practices for Service Oriented

More from aliraza786

Maintenance Best Practices for Service Oriented