CPSC 543 Software Maintenance

Maintenance Best Practices for Service Oriented Architecture (SOA)

May 15, 2009

Submitted ByAli Raza

Submitted toProf. Allen Holliday

California State University, Fullerton

i

Table of Contents

1 Introduction.................................................................................................................................12 What is Service-Oriented Architecture (SOA).............................................................................13 SOA Building Blocks..................................................................................................................24 SOA Design Principles for Development and Maintenance.........................................................3

4.1 Guiding principles ...............................................................................................................34.2 Specific principles ...............................................................................................................3

4.2.1 Loose coupling .............................................................................................................34.2.2 Encapsulation ...............................................................................................................34.2.3 Abstraction ...................................................................................................................44.2.4 Contract .......................................................................................................................44.2.5 Reusability ...................................................................................................................54.2.6 Composability...............................................................................................................54.2.7 Autonomy .....................................................................................................................64.2.8 Optimization..................................................................................................................64.2.9 Discoverability ............................................................................................................64.2.10 Relevance ...................................................................................................................7

5 Maintenance of SOA Infrastructure [2]........................................................................................76 Maintenance Role for SOA [2]....................................................................................................7

6.1 Front End Support Group ....................................................................................................86.2 Back End Maintenance Group .............................................................................................86.3 Database Support for End Point Group ...............................................................................86.4 Management group for maintenance ...................................................................................86.5 Business Process Design .....................................................................................................86.6 Quality Assurance ...............................................................................................................8

7 SOA Governance ........................................................................................................................88 SLA (Service Level Agreement) and SOA..................................................................................99 Reusability for SOA System........................................................................................................910 Quality of Services (QoS) .......................................................................................................1011 Reverse Engineering and SOA.................................................................................................1012 Conclusion...............................................................................................................................1113 References................................................................................................................................1214 Appendix A..............................................................................................................................13

14.1 WSDL..............................................................................................................................1314.2 SOAP...............................................................................................................................1314.3 BPEL................................................................................................................................1314.4 UDDI................................................................................................................................1314.5 OASIS..............................................................................................................................13

i

1 IntroductionSoftware 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 BlocksSOA 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

SOA Infrastructure

Security Component Deployment Tool Discovery

3rd Party Services via Internet

Service B Service C Service D

Application A Application B Application C

Legacy or Mainframe System

SQL Server/MYSQL/DB2

database

2

4 SOA Design Principles for Development and MaintenanceFor 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 SOAA 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 SystemAlthough 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 SOAIn 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 ConclusionThis 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 WSDLWSDL stands for Web Services Definition language. It is an XML format layout for describing the Web service.

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

14.3 BPELBPEL 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 UDDIUDDI stands for Universal Description, Discovery and Integration. It is a platform independent XML-based service registry provided by OASIS

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

13