Service Oriented Computing and Applications manuscript No.(will be inserted by the editor)

Management of service-oriented systems

Dong Liu, Ralph Deters

Department of Computer ScienceUniversity of Saskatchewan, Saskatchewan, Canada

Received: date / Revised version: date

Abstract The service-oriented architecture (SOA) is becoming increasingly popular asa paradigm for developing new distributed systems and integrating heterogeneous legacysystems. A service-oriented system (SO system for short) is a group of applications that in-teract with other(s) by providing and/or consuming services. As the deployments of service-oriented applications and systems increase, it becomes obvious that systems management isthe “Achilles’ heel” of these systems. This paper reviews the underlying concepts, principlesand technologies related to SO systems management.

Key words SOA – Systems management – Services – Manageability – SLM – Self-management

1 Introduction

Alan Kay, the recipient of 2003 Turing Award for his contributions to object-oriented pro-gramming languages and personal computing, pointed out that “the computer revolution”has not happened yet [1,2] : “The printing press was invented in the middle of the 15thcentury, yet it took 100 years before a book was considered dangerous enough to be banned.150 years before science was invented, almost 200 years before a new kind of political essaywas invented . . . The commercial computer is now about 50 years old and is still imitatingthe paper culture . . . we could claim that the computer revolution hasn’t even started.” Al-though it may not be a revolution from the current point of view, the computer is changingour life to what we cannot even imagine. Among all the computer-related technologies, theInternet has the greatest influence. The use of email and World Wide Web (WWW, orweb) boosts the popularity of the Internet, though they are not its original design goals.The web has changed many aspects of human life such as mass media, business, entertain-ment, science, and politics. It even introduces new elements to languages and cultures. Theweb is considered as the global space of information, where everyone can easily access andpublish hypermedia content. Besides information, the functionalities to process informationare essential parts of computing. However accessing such functionalities is technically more

2 Dong Liu et al.

1970 200019901980 2010

Distributed

Computing

Technology

Significant

Events

CSP (1978)

C (1978) C++ (1985)

SUN RPC (1984)

Java/JVM 1.0

(1995)

W3C (1994)

CORBA 2.0 (1991)

RMI (1997)XML RPC (1998) SOAP 1.2 (2003)

REST (2000)

WSDL 1.1 (2001)

JavaScript (1995) AJAX (2005)

MessagesProcedure

callsObjects

Message | RPC | object

Services?

XML 1.0 (1998)HTTP 1.0 (1996)

Web 2.0 (2004)

Fig. 1 The development of distributed computing technologies.

difficult than accessing information via the web. Based on the model and technologies ofthe web, can we develop a technology that enables easy access of the information-processingfunctionalities? Will the technology lead to the formation of a space of interconnected func-tionalities?

A service refers to a concrete autonomous technical functionality of retrieving and pro-cessing information. There are already numerous “services” running in enterprise and per-sonal computing environments, like “create an order”, “fulfill an order”, and “check email”.However, most services are not ready for easy access and integration due to their hetero-geneous platforms, languages, and ownership. It is a theme of distributed computing todevelop technologies that enable easy access and integration.

Distributed computing technologies can be roughly classified into two categories by com-munication methods: distributed shared memory, and message passing [3]. Systems usingmessage passing can be more open and scalable than those based on distributed sharedmemory since messages make the distributed nodes more loosely coupled with each otherthan shared memory [4]. In the category of message passing, a “Deja Vu” was observed [5],and it has continued: messages in 1970’s, remote procedure calls (RPC) in 1980’s, objects in1990’s, and XML-RPC, SOAP, and REST since late 1990’s. As shown in Fig. 1, distributedcomputing technologies have been largely shaped by programming languages and paradigms.Therefore, many distributed computing technologies are tightly coupled with languages andplatforms supporting those languages. The situation changed with the extensive adoptionof XML (Extensible Markup Language) and HTTP (Hypertext Transfer Protocol). XML isan application-independent way to serialize and encode structured data. HTTP provides acommunication infrastructure independent of languages, platforms, and vendors.

SOA (Service-Oriented Architecture) is a paradigm for designing, implementing and uti-lizing services in different ownership domains in a loosely-coupled and interoperable way [6].A service-oriented system (SO system for short) is a group of applications that interact withother(s) by providing and/or consuming services. Such a system is often formed by evolu-tion rather than by design. Openness is an essential advantage of SO systems. A softwaresystem is considered open if it implements open standards and technologies and it is easyfor an alien component to join and become part of the system. However, the openness canbring chaos to systems. The functions of services, the interdependencies between services,and the structure of a service-oriented system can change at runtime. The workloads onsome service endpoints can change dramatically with time. A SO system can show emergentbehaviors that may have never been considered during design. Enterprises have to considermanagement challenges when moving towards SO systems.

Management of service-oriented systems 3

Management of service-oriented systems is a large area of research. It entails fault man-agement, configuration management, performance management, and security management,or operation, administration, maintenance, and provision of SO systems. It also impliesdeveloping systems that can carry out those management tasks. The rest of the paper isstructured as follows. Section 2 reviews the concepts and technologies of SOA and webservices. Section 3 reviews the principles and techniques of general systems management.Section 4 discusses the challenges of service-oriented systems management, and reviews thestate of the art of SO systems management. Section 5 concludes the paper, and discussesfuture directions.

2 Service-oriented systems

The fundamental concepts and principles of SOA are reviewed in Section 2.1. Section 2.2and 2.3 are reviews of XML and web services. Section 2.4 introduces the concept of servicecomposition. The characteristics of service-oriented systems are summarized in Section 2.5.

2.1 Concepts of SOA

The OASIS SOA reference model technical committee defines SOA as “a paradigm for or-ganizing and utilizing distributed capabilities that may be under the control of differentownership domains” [6]. It is also referred as “a model in which automation logic is decom-posed into smaller, distinct units of logic” [7]. Note that SOA does not refer to any specificarchitecture.

Don Box summarized the essential common principles of SOA into four tenets [8]:

– Boundaries are explicit. Services need to communicate across boundaries of differentgeographical zones, ownership and trust domains, and operation environments. In orderto reduce the cost of cross-boundary communication, explicit message passing is appliedfor services rather than implicit method invocation. Explicit service boundaries alsoreduce the cost of communication between developers and development organizations.

– Services are autonomous. Services are independently deployed. A deployed service doesnot assume the existence of its consumers. The topology of a service-oriented system isdynamic, i.e. changing with time. New services may be introduced to the system withoutadvance acknowledgements. The applications consuming a service can leave the systemor fail without notification. A service need to handle the issues of authentication andtrust for the incoming service requests.

– Services share schema and contract, not class. Services interact by message passing. Mes-sage structures are specified by schemas, and message-exchange behaviors are specifiedby contracts.

– Service compatibility is determined based on policy. The semanticcompatibility of a service, i.e. its capabilities and requirements, is based on explicitpolicies.

2.2 Loose-coupling

A common goal of the four tenets is to developing loosely coupled distributed systems basedon the notion of services. Coupling refers to “the measure of the interdependency between

4 Dong Liu et al.

two modules” in the context of structured program design [9]. Two modules are coupled ifone module calls the other (normal coupling), they share the same common data (commoncoupling), or one module refers to the inside of the other (content coupling). Commoncoupling and content coupling are considered bad designs because one module depends onthe other so much that even a minor change of the depended module may result in thedependent module not working properly. It is difficult to quantify the coupling between twomodules in a multi-module program. The terms of “loose” and “tight” are used to qualifythe degree of coupling. Loose-coupling is a design requirement for multi-module programsthat can be easily maintained and evolved.

In object-oriented programming, the consumers of a class’s operations are loosely coupledwith its implementations by relying on the provided interface [10]. In distributed computing,two applications are considered loosely coupled when they communicate by message passingrather than memory sharing [3]. In web services, a service and its consumers are looselycoupled by using explicit message passing instead of implicit method invocation [11]. Thereare also examples of loose-coupling in everyday life. Lego blocks are loosely coupled, sinceany block can be easily connected to other blocks in the same set. Electrical devices areloosely coupled with the power supply, and they can be plugged into standard outlets toget power. An effective design principle to achieve loose-coupling is to emphasize and makeuse of the simplest and standardized interfaces. In SOA, contract sharing is an applicationof this principle.

Coupling was originally used to denote the interdependency between two modules at thesame abstraction level, e.g. two functions, two objects, and two services. It is also used todenote the interdependency between two entities of different levels of abstraction in somecontexts, e.g. the coupling between a system and its components, and the coupling betweena system and its environments [12].

There are always constraints of coupling for any technology in every design. When SOAprinciples are applied to reduce the coupling between distributed components and appli-cations, some other types of coupling will be introduced, e.g. the coupling between serviceimplementation and service contract, and that between service consumer and service con-tract [13].

2.3 XML

The EXtensible Markup Language (XML) is a subset of the Standard Generalized MarkupLanguage (SGML), an ISO standard1, originally designed for large-scale electronic pub-lishing. XML is popular for data exchanging on the web and among applications2. XMLprovides a method for encoding and serializing structured data that is independent of ap-plications and vendors. XML is a natural choice for distributed applications to accomplishloose-coupling. XML is one of the most fundamental technologies of web services. The ap-plications of XML are ubiquitous in service implementation: messages, service schemas andcontracts, and policies.

An XML document represents and stores information in elements that are assembled ina structure. An element is specified by tags and attributes. When the data represented byXML documents or streams are exchanged on the web or among applications, the documentsor streams should be validated to ensure that the information can be uniquely understood.

1 See www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=16387 .2 See www.w3.org/XML .

Management of service-oriented systems 5

CommunicationHTTP (W3C, IETF), FTP (IETF), SMTP (IETF), ...

Information representationXML (W3C)

MessagingSOAP (W3C), WS-Addressing (W3C), ...

Metadata

WSDL (W

3C), U

DDI (O

ASIS), ...

Process

BPEL (O

ASIS), W

S-

Choreography (W

3C)

Security

WS-Security

(OASIS)

ResourceWSRF (OASIS), ...

ManagementWSDM (OASIS), ...

Fig. 2 Web services standards.

The validation of an XML document can be carried out according to either a DocumentType Definition (DTD) or an XML schema specifying its structure and the types of eachelement. Although DTD appeared earlier than the XML schema, the schema is more widelyused, and offers more powers of data expression. Moreover, the XML Schema definitionlanguage (XSD) is itself represented in XML. The abilities of XML to represent both datainstances and metadata including structure, content, and semantics make it favoured in webservices technologies.

2.4 Web services

Although web services are closely related to SOA, they are different. SOA refers to a para-digm based on which a service-oriented system can be developed, and web services technol-ogy is just one of the technologies that can be used to develop those systems. According toW3C [14], a web service is “a software system designed to support interoperable machine-to-machine interaction over a network.” Web services are the implementations of a numberof standards proposed and maintained by W3C, IETF3, OASIS4, and other organizations.Fig. 2 shows the layered structure of some essential standards [15,16,17]. The fundamen-tal standards in the stack are those for communication and information representation likeHTTP and XML.

Fig. 3 shows several interaction scenarios between web services. When a service consumerwants to find web services of interest, it will ask the service registry for suggestions. Theservice registry has the metadata of services and supports enquiry and registration of serviceentries. UDDI (Universal Description, Discovery, and Integration) [18] is a group of service

3 See www.ietf.org .4 See www.oasis-open.org .

6 Dong Liu et al.

Service registry

(UDDI)

Service A

Service B

Service

consumer

agent

Service description

(WSDL)

Message

(SOAP)

Message

(SOAP)

Service description

(WSDL)

Service description

(WSDL)

Message

(SOAP)

Message

(SOAP)

Message

(SOAP)

Fig. 3 Interactions between web services.

registries specified by the standard of UDDI. Customers can get answers to “who, what,where, and how” questions about services from a UDDI. The answer for the question “who”is about the enterprise supplying services; the answer for “what” is about the servicesprovided; that for “where” is the services URL’s or email addresses; and that for “how” isabout interfaces to interact with the services. When a service consumer has the informationabout “where” and “how” about an interesting service, it can send a message to the service,e.g. Service B in Fig. 3. If the service request is successful, Service B will reply a messageto the service consumer. SOAP is a protocol for exchanging messages between web services.SOAP, originally known as Simple Object Access Protocol, was introduced by Microsoft in1998 as an object access protocol. Then it was submitted to W3C and became a standard.Now it no longer refers to an object access protocol, but to “a stateless, one-way messageexchange paradigm” [19]. WSDL (Web Services Description Language) is a language inXML to describe the shared schema and contract of a web service. The WSDL document ofa web service includes entries for service name, service interface, endpoint name, endpointaddress, and endpoint binding information.

SOAP is the successor of XML-RPC, a protocol designed for RPC (remote procedure call)using XML for encoding and HTTP for transportation. This tradition makes the developerstend to use SOAP for RPC of objects. There is nothing improper for this usage of SOAP,but it conflicts with the principle of “Services share schema and contract, not class” in SOAcontext. In fact, SOAP is also good for document-style messaging in which the entries of anXML message do not, by default, map to the corresponding methods. The usage of SOAPraises many debates since some developers consider SOAP as one of the essential technologiesto implement services while others disagree and use plain XML messages instead. Somedevelopers prefer the RESTful services that rely on plain XML or JSON (JavaScript ObjectNotation) 5 and HTTP.

5 See json.org .

Management of service-oriented systems 7

REST (Representational State Transfer) is a software architecture style for distributedlarge-scale systems [20,21]. Roy Fielding coined the term based on his experiences in the de-velopment of the HTTP protocol and Apache HTTP server project. The modern web is con-sidered an instance of REST. The RESTful services emphasize the URL (uniform resourcelocator) and standard operation interfaces of Post, Get, Put, and Delete. E.g. to access anorder based on its ID, a RESTful service would have a URL like example.com/order/{id}.Get can be used for retrieving the detail of an order, Put for submitting an order, and Delete

for canceling an order. Correspondingly, three operations will be required for SOAP design,i.e. Order getOrder(id:ID), ID createOrder(order:Order), and bool cancelOrder(id:ID).Many popular web services providers like google.com, ebay.com, and amazon.com, now sup-port RESTful service interfaces.

2.5 Service composition

SO principles emphasize service composability, by which a set of services can be composedto achieve desired functionalities. Service compositions are also called service assemblies [7].A service participating in a composition is called a composition member. It is importantto note that service orchestration and service choreography are two fundamentally differentapproaches for composition. Service orchestration depends on a central conductor or con-troller service that executes a plan/workflow that defines when and how the members areto act. Service choreography, on the other side, does not have a central service and is basedon the idea that the members are able to interact according to a previously agreed choreog-raphy description. Consequently, choreography assumes that the members are collaborativeenough to be able to achieve a common goal while the members of a service orchestration donot need to know any details about the orchestration and is therefore much easier to imple-ment. Not surprisingly, service orchestration is the dominant approach for achieving servicecompositions. The WS-BPEL (Web Services Business Process Execution Language) specifi-cation [22] defines a language to specify service orchestration. The WS-CDL (Web ServicesChoreography Description Language) [23] is a language to specify service choreography.

Service compositions offer diverse compound functionalities and flexible cost-benefitchoices based on available services. A service composition can be easily developed accord-ing to its functional and nonfunctional requirements based on the determined schemas andcontracts of member services no matter whether or not those member services are alreadyimplemented. This is valuable for the development of large distributed software systems,when the components for high-level functionalities and those for the low-level functionalitiesare required to be developed in parallel for timely delivery. Service composition introducesbusiness opportunities for small vendors to deliver their services quickly by composing theservices supplied by major service providers in IT industry. There are many such businessapplications that are based on the services supplied by Amazon, eBay, Google, and others.

2.6 Characteristics of SO systems

Service-oriented systems have the following characteristics:

– Distributed. Services can be distributed across geographical zones, organizations, andtrust domains. It is impossible to have a centralized system to control or manage allthe members in a system. Multiple firewalls and authentications can be involved ininteraction between services and their consumers.

8 Dong Liu et al.

– Homogeneous and yet Heterogeneous. Services and their consumers in a service-orientedsystem interact according to the shared message schemas and contracts. They speaka common language and communicate in the same manner. At the same time, theyrun on different platforms and virtual machines, and/or are implemented in differentprogramming languages.

– Open. There are few organizational, geographical, or domain obstacles for service providersand consumer to become part of a service-oriented system. Services communicate on thebasis of standards. Service contracts and policies are explicit.

– Dynamic. The structure of a service-oriented system can change with time. The changesof a service’s business logic should not interrupt its interactions with consumers whenthe shared contract remains unchanged.

– Hierarchical and Heterarchical. Service composition forms hierarchies, in which the ser-vices at higher positions consume those at lower positions. The hierarchy reflects thedependency between the higher level services and the lower level ones. At the same time,many services appear on the same “horizon” of providing functionalities to consumersin a macro view. Services enable the formation of hierarchies and also heterarchies.

– Scalable. A service-oriented system can be very small when it is composed of only pairsof services and their consumers. It can also be very large in scale due to its opennessand service composability.

3 Systems management

This section gives an overview of systems management — concepts, principles, and tech-niques. The simple network management protocol (SNMP) provided a good example tounderstand the basic concepts and principles of systems management. Those concepts andprinciples are still valid for SO systems management.

3.1 Concepts of systems management

In business, management often refers to the process composed of four classic activities [24]:planning, organizing, leading, and controlling for accomplishing a goal. For most organiza-tions, there are always three factors to consider when they carry out management operations:cost, quality, and revenue. Quality of provided services is important for an organization tokeep their competence on the market and eventually make more revenue. However, improv-ing service quality also implies increasing the cost for expertise, equipments, maintenance,and so on. These extra costs will eventually cut down the revenue. Management is the “art”of maintaining or improving service quality with minimal impact on the cost. While people-to-people relationships and interactions are the theme of business management, machine-to-machine interactions are more emphasized in systems management. In order to definesystems management, there are basically three aspects to be discussed: purposes, scopes,and building blocks of a management system. Fig. 4 shows a three-dimension view of sys-tems management, where the axes are management function purpose, management systembuilding block, and management scope respectively.

The TMN (Telecommunications Management Network) reference model defined fivefunction categories by their purposes for network management: Fault, Configuration, Ac-counting, Performance, and Security (FCAPS) [25,26]. Fault management is about moni-toring a system’s operating status, event logging, fault diagnosis, and recovery from failure.

Management of service-oriented systems 9

Business

Service

Infrastructure

(network/device)

Fault

Configuration

Accounting

Performance

Security

Communication

Representation

Logic

Fig. 4 Facets of systems management.

Configuration management is about initialization and revision of configurations of infrastruc-tures and services. Configuration management is often related to fault management, perfor-mance management, and security management, because improper configuration changes areoften the sources of fault, security and performance issues. Most systems provide services totheir customers for revenues, and accounting management is to ensure the customers gettingproper service according to their payments. Performance management is about monitoringsystem performance and tuning the system to achieve an expected performance goal. Notethat monitoring tasks in fault management and performance management target differentinformation, i.e. fault events and performance measures respectively.

Not all the management functions can be well classified using the FCAPS referencemodel. Some management tasks like monitoring can be classified into two or more categoriesof FCAPS. In some cases, only some of the five categories are addressed by a managementsystem, e.g. autonomic computing [27] focuses on fault management(self-healing), configura-tion management(self-configuration), performance management(self-optimization), and se-curity management(self-protection). The details of autonomic computing will be discussedlater in Section 4. Operation, Administration, Maintenance, and Provision (OAM&P, orOAMP) is another way to categorize management functions like FCAPS according to theirpurposes [25].

Systems management can be classified into categories of business, service, and infras-tructure from the perspective of scope [25,28]. The infrastructure refers to network, devices,and other fundamental systems. The service refers to any functions provided by a systemto customers, and it is different from the ‘service’ in service-oriented sense. Business-scopemanagement has to rely on service-scope and infrastructure-scope management at lowerlayers to achieve business goals, and the FCAPS functions details are carried out mainly atlower layers.

Management goals are achieved by operations of deployed management systems. A man-agement system is composed of three conceptual building blocks, i.e. management informa-tion communication, management information representation, and management logic. Sincea management system is by itself a distributed system in most cases, communication andrepresentation are the basis for different parties of a management system to talk to andunderstand each other. Management logic is responsible for analysis and decision making ofthe FCAPS or OAM&P functions based on collected information of managed systems. How

10 Dong Liu et al.

Managed element

AgentSensor Actuator

Manager

Fig. 5 The anatomy of a management system.

much human effort is required in the logic block depends on the complexity of a managementtask and the implementation of a management system.

An element to be managed and an element to perform management are two basic roles ina systems management context. A component or subsystem of the latter role is often called amanager. As shown in Fig. 5, an agent resides at the managed element, and it is responsiblefor providing management information to the manager and executes the management actionsdecided by the manager. Those two functions can be described as sensor and actuator.Correspondingly, the manager provides interfaces to the sensor and the actuator.

3.2 Manageability

Developing management systems for heterogeneous distributed systems will become lessdifficult if they are provided with manageability. A system’s or component’s manageabil-ity refers to its capability to be managed. A system’s manageability includes how muchan agent can report and change the system’s state, and the easiness of interacting withthe agent through sensors and actuators. The manageability of a system depends on themanageability of its subsystems and components. It is impossible to manage a large-scaleSO system if services offer no manageability. Developing services with built-in manageabil-ity is indispensable for composing manageable SO systems. The manageability of a servicedepends on the manageability features of its platform and its design.

Most modern operating systems, database systems, and application servers afford man-ageability features. Windows (2000 and later version) and SUSE Linux enterprise serverhave built-in management components implementing the Web-Based Enterprise Manage-ment (WBEM)6, a group of standards in the DMTF. The Windows WBEM implementationis the Windows Management Instrumentation (WMI)7. The current WMI is accessible bythe .NET technologies, and supports communication through DCOM and SOAP8.

Operating system virtual machines (OPVM’s) can provide to users virtualized homo-geneous operating systems regardless of the underlying physical hardware and/or host op-

6 See www.dmtf.org/standards/wbem .7 See msdn2.microsoft.com/en-us/library/aa394582.aspx .8 See msdn2.microsoft.com/en-us/library/ms257340(VS.80).aspx .

Management of service-oriented systems 11

erating systems by means of software [29,30]. A management solution developed for oneoperating system can be easily ported to other operating systems with OPVM’s installedon them. In this way, the manageability of operating systems is leveraged by software vir-tualization.

The introduction of application virtual machines (AVM’s) has made software develop-ment and integration across different platforms much easier. It is straightforward to takethe advantage of VM for management of heterogeneous infrastructures. E.g. the Java Man-agement Extensions (JMX) [31,32] technology supplies tools for management of resourceson the JVM (Java Virtual Machine). The managed resources need to implement the MBean(Managed Bean) interface to expose its manageability. Each MBean is registered on a JMXagent that performs the management of a resource. The manageability consumers can re-motely communicate with the JMX agent through connectors and protocol adaptors. MX4J9

implements the JMX specification [31], and provides an HTTP adaptor.

3.3 Management science and systems management

Management science is “the application of mathematical techniques and scientific principlesto management problems to help managers make better decisions” [33]. Although systemsmanagement is not an area that management science focuses on, the problem solving tech-niques of management science are applicable to systems management problems.

How to model and solve a management problem depends on the problem’s nature. Ta-ble 1 lists some commonly used management science techniques. Basically, the techniquescan be grouped into four categories: policy, linear/nonlinear/integer and dynamic program-ming, probability modeling, and simulation. The first two are more suitable for deterministicsituations, while the third is for uncertain situations. Simulation is a group of techniquesto address management problems when experiments with the real systems and/or analyticmodeling are either impossible or expensive. Simulation is able to model variability andprovide transparent dynamic view of a system [34]. Some management solutions may beclassified into two or more of these categories. These techniques are applied in SO systemsmanagement, which is reviewed in Section 4.

3.4 SNMP: a case study of systems management

The SNMP (Simple Network Management Protocol) [41,42,43] is the de facto networkmanagement standard that is specified by a number of RFC’s (Requests for Comments) ofIETF. So far, it has three versions, version 1 since 1988, version 2 since 1993, and version 3since 2002. The SNMP can be used for management of both network devices like routers andswitches and servers like DNS’s (Domain Name Servers). Most network device and operatingsystem venders implement SNMP in their products.

There are two kinds of entities in SNMP-capable systems: agents and managers. AnSNMP agent is deployed on a managed device or system. It can send management informa-tion to an SNMP manager either proactively or interactively. An SNMP manager is oftena server that communicates with a number of agents and performs management function-alities. A manager is also called network management station (NMS). The SNMP describesthe details about management information communication and modeling.

9 See mx4j.sourceforge.net .

12

Dong

Liu

etal.

Table 1 Commonly used management science techniques

Technique Details Target problem

Policy

Policy is the most straightforward approach to reasoning and making de-cisions for familiar situations. Basically, a policy contains two parts: thecondition(s) and the action(s). The evaluation of policies is triggered bycertain event(s). An inference engine is required when a policy base be-comes complicated.

Decision making

Linear/nonlinear/integerprogramming [35]& dynamic programming [36]

Some programming problems can be represented as a system of constraintequations/inequations and an objective function with a number of vari-ables. If all the constraint equations/inequations and the objective func-tion are linear, it is a linear programming problem, and otherwise a non-linear problem. Some network flows problems can be solved by linear pro-gramming. If the solution space is a set of integers, the problem is an inte-ger programming problem. Search algorithms are often applied to solvinglinear/nonlinear/integer programming problems.

Some other programming problems can be represented as a multi-stagedecision process whose optimal solution is a sequence of decisions. Dy-namic programming is a technique to solve such problems.

Optimization and programming

Probability modeling [37,38,39]

Probability is the methodology to deal with uncertainty that is quite com-mon in real-life management. The widely applied probability techniquesinclude parameter estimation, hypothesis testing, Bayesian inference, riskanalysis, Markov chain, and queueing theory among others.

Systems involving services and waiting lines can be modeled as queuesor networked queues. Queueing theory studies queue length, waiting andresidence time, service utility, throughput and other measures with givenarrival rate, service time, and topology of queues.

Estimation, prediction, inference, and de-cision support

Simulation [34,40]

A simulation aims to produce a system’s behaviour and final state in along time period and/or across a number of nondeterministic initial andtransient states by generating random variables and processes that wouldregulate the model’s state transitions. Simulation can be used to analyzesystems when no analytic approaches will work without rigorous assump-tions. Simulation is friendly to managers or administrators by intuitiveand animated presentations of a dynamic system.

Prediction and decision support

Management of service-oriented systems 13

Agent

Poll Trap

Notification

Message

(UDP)

Manager Agent

Request

Message

(UDP)

Response

Message

(UDP)

Manager

Fig. 6 The message exchange pattern of a poll and a trap.

The User Datagram Protocol (UDP) is chosen as the transportation protocol for infor-mation communication between SNMP agents and managers because of its connectionless.No connection is required when packets are sent from an agent to a manager or reversely.UDP does not guarantee the delivery of a message and the delivery order of a sequence ofmessages. UDP is therefore more lightweight than other protocols like TCP (TransmissionControl Protocol). This means that the communication between agents and managers willhardly degrade the performance of the managed network by introducing extra overhead.And it scales well when a manager receives small messages from a large number of agents.

By and large, there are two types of message exchanges between an agent and a manager:poll and trap. A poll refers to the process that a manager sends a request to an agent andthe agent responds according the request. A trap refers to the action that an agent notifiesthe manager about some events proactively. No acknowledgement of receiving is expectedfor a trap by an agent. Fig. 6 shows the message exchange patterns of poll and trap. Thethree versions of SNMP define different operations for polls and traps. Get, GetNext, Set,and GetBulk are poll operations. Get*’s are used to retrieve management information fromagents, and Set is for changing parameters of agents. Trap, Notification, and Inform aretrap operations. Note that Inform was introduced in SNMPv2 in order to enable acknowl-edgement for traps.

The next question for agent-manager interactions is how they can understand each other.The SNMP addresses this by introducing the Structure of Management Information (SMI)and the Management Information Base (MIB). The SMI defines common structure and vo-cabularies for network management. The MIB defines the management information objectsby using SMI syntax. The SMI can be considered as the schema or metadata of MIB’s. Theinformation structured by the SMI is formed as a tree. The vendors of devices and systemsdefine MIB’s for specific applications and purposes. In order to ensure the NMS’s and agentsdeveloped by different vendors to work together, a vendor needs to publish the MIB’s of itsproducts.

How the managers should act according the management information obtained by pollsand traps depends on the specific application logic. Most NMS’s implement policy-basedmanagement techniques.

The SNMP is a comprehensive framework for network management. Since there are fewerand fewer difference between network management and systems management in presentIT industry, the framework is a good reference for developing management protocols andsystems of service-oriented systems. Many common aspects can be found between SNMPand current approaches of SO systems management.

14 Dong Liu et al.

4 Approaches of SO systems management

SO systems management is considered a challenge towards the success of SOA in bothIT industry and research areas [44,45,46,47]. The characteristics of SO systems raise thefollowing problems for systems management.

– Distributed management. It is impossible to apply a non-distributed management ap-proach to SO systems. A manager needs to communicate with the managed nodesthrough multiple firewalls and authentications.

– Unification of services management and infrastructures management. From a pure servicepoint of view, the management of a SO system is composed of management of services inthe system. On the other side, the management of a system involves management of webservers, application servers, databases, and other infrastructures. Service managementand infrastructures management should be unified to achieve the goals of SO systemsmanagement.

– Management integration. Managers and agents may run on heterogeneous platforms andvirtual machines where the services are deployed on, and they need to be integratedtogether.

– Dynamic management. A management system needs to adapt to the changes and faultsof services, especially partial failures.

– Consistency of management of service compositions and member services. The manage-ment goals of service compositions need to be achieved by management of the memberservices.

– Management scalability. The management approach needs to be scalable for systems ofdiverse sizes.

Some of these problems have been addressed by the approaches reviewed in this section,and some are still open for further investigation.

4.1 Service level management of SO systems

The interests of the provider and consumers of a service are protected by service contracts.A service contract can cover many aspects of delivered services, such as prices, time, quality,and so on. A service level agreement (SLA) is part of a service contract, and specifies servicecontext, service quality goals, and obligations of service provider if the SLA is not complied[48]. Service Level Management (SLM) is the process of managing computing systems inorder to provide acceptable service quality to service consumers according to the agreementof price and time constraints [28]. Quality of Service (QoS) is a technology-centred measureof the performance of a service [49], e.g. response time and failure rate. SLM appeared earlierthan SOA and SO systems. It is quite natural to apply SLM to SO systems management.SLM is related to performance and accounting management of SO systems. SO systemsmanagement can be classified into infrastructure-scope, service-scope, and business-scopeapproaches from bottom to top similar to general systems management [28]. SLM is anexample of unification of business-scope, service-scope, and infrastructure-scope management

for SO systems.IBM developed an XML-based language, called the Web Service Level Agreement (WSLA)

language [50,51], to specify the service level agreements for web services. An SLA representedin WSLA is composed by three parts: the parties, the service definitions, and the obliga-tions. The part of parties describes the service participants’ names, contact information,

Management of service-oriented systems 15

and actions related to violations of the SLA. The participants include one service provider,one service consumer, and zero or a number of supporting parties. The part of service def-initions describes the service operations and operation groups specified in the SLA. Eachoperation or operation group is defined by their schedules, SLA parameters and the metricsof these parameters. The part of obligations describes service level objectives and the ac-tions to perform while the service level objectives are not satisfied. A service level objectivedefines the service quality, the validity period of the objective, and the methods to measurethe service quality. The management applications of web services are able to automaticallyevaluate and monitor the SLA’s represented by WSLA other than natural languages. Danet al. applied WSLA to automated web services management [52]. They proposed a frame-work to perform dynamic resource provision, and workload management based on WSLA.The framework monitors the performance of a managed service, and provisions the serviceresources according to the associated SLA’s based on performance prediction. The serviceexecution management component of the framework measures the resource usage, and triesto meet the SLA’s by means of throughput policing, queue management, request scheduling,and load balancing.

HP developed a less sophisticated web services SLA language [53], and applied it toautomated SLA monitoring for web services [54]. SLA-based approaches imply flexibility andnegotiability of the service levels between providers and consumers. However, it is sometimesinconvenient for both service providers and service consumers to institute and apply formalSLA’s. The Web Service Offering Language (WSOL) [55,56] was designed for such cases.The WSOL describes the services as service classes associated with different service levels.Instead of negotiations of SLA’s with the service providers, the service consumers can chooseand switch between the service offerings. The Web Service Offering Infrastructure (WSOI)[57] was developed as a general web services management framework supporting the WSOL.The WSOI monitors the compliance of service offerings, and adapts the way to composingthe services that are consumed by the subscribers of service offerings [58].

Pricing is important for service participants including providers and consumers in bothB2B and B2C contexts, where time and quality aspects of services are directly associatedwith the corresponding prices. In enterprise computing environments, service consumptionis sometimes not charged within the same organization, where the quality is the key of thewhole service level management. Wang et al. presented an approach to integrating message-oriented QoS management into enterprise SO applications [59,60].

4.2 Standards and specifications for management information modeling and communication

The Web Services Distributed Management (WSDM)10 is a two-part OASIS standard “tounify management infrastructures by providing a vendor, platform, network, and protocolneutral framework for enabling management technologies to access and receive notificationsof management-enabled resources.” The Management Using Web Services (MUWS) specifi-cation [61,62] is the first part of WSDM, and describes how to represent the manageability ofresources and how to access the manageability. The Management Of Web Services (MOWS)specification [63,64] is the second part of WSDM, and specifies how to represent the man-ageability of web service endpoints and how to access the manageability. The WSDM isdeveloped on the basis of the OASIS Web Services Resource Framework (WSRF), a groupof specification for modeling and accessing stateful resource using web services. Note that

10 See www.oasis-open.org/committees/wsdm .

16 Dong Liu et al.

OASIS DMTF

WSRF

CIM

WS-M

ITIL

SNMP

MUWS

MOWSSML

Modeling

Communication

MUWS

SNMPWSRF

WSML

Fig. 7 The standards and specifications of management information modeling and communication.

WS-BaseFaults, part of WSRF, specifies a base set of information that can be used toconstruct fault messages, and is potentially valuable for fault management. Martin et al.developed a self-managing web service environment based on WSDM [65].

The Web Services for Management (WS-Management) [66] is a specification about soft-ware and hardware management using web services maintained by the DMTF (DistributedManagement Task Force) 11. The WS-Management specification defines constraints of web-service-based approaches for management of hardware and software systems including webservices. The WS-Management focuses on management information communication, andit does not address management information modeling like WSDM. The contributors ofWS-Management are developing the Service Modeling Language (SML) [67], a languageto modeling complex IT services and systems. The SML covers many management aspectsincluding configuration, deployment, monitoring, policy, health, capacity planning, targetoperating range, service level agreements, and others. The SML was submitted to W3C forstandardization in 200712. Both WSDM and WS-Management lack popular implementa-tions currently, and the major drawback of these two approaches is that they depend on alarge web services standards stack. Light approaches like SNMP could be favoured in a longrun.

The Common Information Model (CIM) standards [68] define management informationfor systems, networks, applications, and services. The DMTF provides a specification forbinding the CIM to the WS-Management [69]. The ESSI WSMO working group13 developedthe Web Service Modeling Language (WSML) and submitted it the W3C14. The WSML isbased on logical formalism and can be used for modeling semantic web services. There areother standards that can be applied to SO systems management like the Simple NetworkManagement Protocol (SNMP) [41] and the IT Infrastructure Library (ITIL)15. All these

11 See www.dmtf.org .12 See www.w3.org/Submission/2007/01 .13 See www.wsmo.org .14 See www.w3.org/Submission/WSML .15 See www.itil.co.uk .

Management of service-oriented systems 17

standards and specifications help to tackle the problem of management integration anddistributed management.

4.3 Management science techniques used in SO systems management

There are many scenarios in SO systems management in which management science tech-niques can be applied. Table 2 listed the techniques reported in literature and the manage-ment problems addressed by them. Some interesting observations are

1. Many approaches use more than one technique listed in Table 1.2. Optimization problems are mainly addressed by programming algorithms.3. Probability modeling techniques are mainly applied for performance modeling.

Table 2 SO systems management problems addressed by management science techniques

Technique SO systems management problem

PolicyDynamic reconfiguration [70], self-healing web services [71],adaptive services [72], service level (QoS) management [73,74,59,60], service stability and reliability improvement [75]

Linear/nonlinear/integerprogramming& dynamic programming

Service composition with QoS requirements [76], resource(server) allocation and request scheduling [77], resource(thread) allocation [78,79], admission control and requestscheduling [80]

Probability modelingperformance prediction by queueing theory and Markov chain[78,77], capacity planning [79], QoS prediction of service com-positions [81]

Simulation Resource allocation [82], Process model validation [83]

4.4 Self-management of SO systems

The complexity of SO systems management brings new challenges for IT industry. IT vendorstry to decrease the costs of SO systems management while the efficiency and reliability ofthe management approaches still need to be satisfied. In 2001, IBM began to advocate andwork on a technology named autonomic computing that addresses the observed increasingsoftware complexity crisis [84,27]. The nature of autonomic computing is to develop self-managing systems that can self-configure, self-heal, self-optimize, and self-protect. A self-managing system is composed of self-managing components. The conceptual structure of aself-managing component is shown in Fig. 8. A self-managing component includes two parts:a managed element and a manager. The manager is able to access the state of managedelement through the sensors bounded on it. The manager monitors the state of managedelement, analyzes obtained information, plans the actions that the managed element shouldtake, and then execute them by the effectors on the managed element. The monitor-analyze-plan-execute control loop is based on the knowledge about managed element. It is natural toapply self-managing technologies to SO systems management, where the managed elementsare service endpoints. Some major IT vendors, like IBM, HP, and CA, are pushing towardsthis direction [47].

18 Dong Liu et al.

Fig. 8 The conceptual structure of a self-managing component [85].

The principle of self-management is widely applied in SO systems management, thoughthe term of “autonomic computing” may not be used. E.g. all the approaches mentionedin Section 4.1 [52,53,57,59] adopt automated control mechanism to ensure the service lev-els. A self-management process is very similar to a control loop: the control components ormanagers get run-time information from the managed services, and then change the ser-vices’ configurations according to some control mechanisms. How to implement the controlmechanisms differs from one approach to another. Policy-based reasoning was applied forcontrol mechanisms in some approaches [70,72,59]. The rules in [70] were constructed in theform of event-condition-action. Other approaches [79,77,74] modeled SO systems based onqueueing theory, and developed control mechanisms based on mathematical optimizationmethods. An and Jeng [82] applied system dynamics to modeling SO systems in order toanticipate system behaviors under different control configurations. Autonomic computingis a promising direction to developing management systems that are able to address thedynamics, consistency and scalability problems of SO systems management.

5 Conclusion and future directions

This paper presents an overview of the characteristics of service-oriented systems and majorchallenges of SO systems management. A number of management approaches have been pro-posed to tackle those challenges, and some problems are still open for further investigations.These problems, in our vision, include:

(1) Management of service compositions. The provider of a service composition will havelimited control of its member services that belong to different organizations. The man-agement information that can be obtained from member services is constrained by theircontracts and policies. How to conduct successful management of a service compositionwith such constraints is an open problem. For service orchestrations, central controllerservices are responsible for conducting management tasks. For service choreographies,member services have to be cooperative for management.

(2) Service Experience Management (SEM). Most current SLM approaches focus on technology-centred QoS. The user-centered service experience will attract more and more attention

Management of service-oriented systems 19

in SO systems management. Service experience is the measure of service quality dur-ing human-service interaction from the end-customer’s perspective. Service experienceis affected by QoS and usability of a service and the interest of the customer. How toevaluate service experience and how to improve it are open questions.

(3) Self-management of SO systems. A SO system evolves when new service consumers joinin and new service hierarchies and heterarchies are formed. To maintain a centralizedmanagement solution for an evolving system is difficult. A SO system deals with partiesacross organizational and ownership boundaries. There is no one-for-all management so-lution satisfying diverse interests of those parties. Practically, there is no one responsiblefor developing and maintain such a solution. Self-managing services is a promising so-lution to lower the complexity order of the management problem. The questions thatfollow are whether the aggregation of self-managing services results in a self-managingSO system, whether a self-managing service performs the same through the evolvingprocess of a system, and whether self-management solutions from different parties canwork together. Services and service compositions with built-in manageability is the basisof self-managing SO systems.

6 Acknowledgements

This work was supported by the Natural Sciences and Engineering Research Council underGrant Number ???. We would like to thank Nathaniel Osgood, Eric Neufeld, Rick Bunt,Chris Zhang, and anonymous reviewers for their valuable comments and discussions of ourwork and this paper.

References

1. Kay, A.C.: The computer revolution hasn’t happened yet (keynote session). In: MULTIMEDIA’00: Proceedings of the eighth ACM international conference on Multimedia, New York, NY,USA, ACM Press (2000) 1

2. Kay, A.: ”the computer revolution”, ”computer science”, and ”software engineering” haven’thappened yet. In: EMSOFT ’04: Proceedings of the 4th ACM international conference onEmbedded software, New York, NY, USA, ACM Press (2004) 6–6

3. Hariri, S., Parashar, M.: Tools and Environments for Parallel and Distributed Computing.Wiley-Interscience (2004)

4. Coulouris, G., Dollimore, J., Kindberg, T.: Distributed Systems: Concepts and Design. fourthedn. Addison Wesley (2005)

5. Waldo, J., Wyant, G., Wollrath, A., Kendall, S.: A note on distributed computing. Techni-cal report, Sun Microsystems Laboratories (1994) http://research.sun.com/techrep/1994/

smli_tr-94-29.pdf.6. OASIS: Reference model for service oriented architecture v 1.0. Web (2006) http://www.

oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf.7. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall PTR

(2005)8. Box, D.: Code name indigo: A guide to developing and running connected systems with in-

digo. MSDN Magazine (2004) http://msdn.microsoft.com/msdnmag/issues/04/01/indigo/

default.aspx.9. Page-Jones, M.: The Practical guide to structured systems design. second edn. Yourdon Press

(1988)

20 Dong Liu et al.

10. Booch, G., Maksimchuk, R.A., Engel, M.W., Young, B.J., Conallen, J., Houston, K.A.: Object-Oriented Analysis and Design with Applications (3rd Edition). Addison-Wesley Professional(2007)

11. Kaye, D.: Loosely Coupled: The Missing Pieces of Web Services. RDS Press (2003)12. Orton, J. Douglas, Weick, Karl E.: Loosely coupled systems: A reconceptualization. The

Academy of Management Review 15(2) (1990) 203–22313. Erl, T.: SOA Principles of Service Design. Prentice Hall PTR (2007)14. W3C: Web services glossary. Web (2004) http://www.w3.org/TR/2004/

NOTE-ws-gloss-20040211/.15. W3C: Web services architecture. Web (2004) http://www.w3.org/TR/2004/

NOTE-ws-arch-20040211/.16. Weerawarana, S., Curbera, F., Leymann, F., Storey, T., Ferguson, D.F.: Web Services Platform

Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging,and More. Prentice Hall PTR (2005)

17. Cabrera, L.F., Kurt, C.: Web Services Architecture and Its Specifications: Essentials for Un-derstanding WS-*. Microsoft Press (2005)

18. OASIS: Uddi version 3 specification. Web (2004) http://uddi.org/pubs/uddi_v3.htm.19. W3C: Soap version 1.2 part 0: Primer. Web (2003) http://www.w3.org/TR/2003/

REC-soap12-part0-20030624/.20. Fielding, R.T.: Architectural styles and the design of network-based software architectures.

PhD thesis, University of California, Irvine (2000)21. Fielding, R.T., Taylor, R.N.: Principled design of the modern web architecture. ACM Trans.

Inter. Tech. 2(2) (2002) 115–15022. OASIS: Web services business process execution language version 2.0. Web (2007) http://

docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.pdf.23. W3C: Web services choreography description language: Primer version 1.0. Web (2006) http://

www.w3.org/TR/2006/WD-ws-cdl-10-primer-20060619/.24. Nelson, B., Economy, P.: The Management Bible. Wiley (2005)25. Clemm, A.: Network Management Fundamentals. Cisco Systems (2007)26. Hobbs, C.: A Practical Approach to WBEM/CIM Management. Auerbach Publications (2004)27. Kephart, J.O., Chess, D.M.: The vision of autonomic computing. IEEE Computer 36(1) (2003)

41–5028. Casati, F., Shan, E., Dayal, U., Shan, M.C.: Business-oriented management of web services.

Commun. ACM 46(10) (2003) 55–6029. Hammersley, E.: Professional VMware Server. Wrox (2006)30. Wolf, C., Halter, E.M.: Virtualization: From the Desktop to the Enterprise. Apress (2005)31. SUN: Java management extensions instrumentation and agent specification, v1.2. Web (2002)

http://jcp.org/aboutJava/communityprocess/final/jsr003/index3.html.32. Kreger, H., adn Leigh Williamson, W.H.: Java and JMX: Building Manageable Systems. Ad-

dison Wesley Professional (2002)33. Taylor III, B.W.: Introduction to Management Science. ninth edn. Prentice Hall (2006)34. Robinson, S.: Simulation: The Practice of Model Development and Use. Wiley (2004)35. Hadley, G.: Linear Programming. Addison-Wesley (1962)36. Bellman, R.E.: Dynamic programming. Princeton University Press (1957)37. King, W.R.: Probalility for Management Decisions. Wiley (1968)38. Mendenhall, W., Reinmuth, J.E.: Statistics for Management and Economics. Wadsworth (1971)39. Ross, S.M.: Introduction to Probability Models. eighth edn. Academic Press (2002)40. Chung, C.A.: Simulation Modeling Handbook: A Practical Approach. CRC (2003)41. Mauro, D.R., Schmidt, K.J.: Essential SNMP. second edn. O’Reilly (2005)42. Morris, S.B.: Network Management, MIBs and MPLS: Principles, Design and Implementation.

Addison Wesley (2003)43. Miller, M.A.: Managing Internetworks With SNMP: The Definitive Guide to the Simple Net-

work Management Protocol (SNMP and SNMP Version 2). M & T Books (1997)

Management of service-oriented systems 21

44. Papazoglou, M., van den Heuvel, W.J.: Web services management: a survey. IEEE InternetComputing 9(6) (2005) 58–64

45. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., Kramer, B.J.: Service-orientedcomputing: A research roadmap. In Cubera, F., Kramer, B.J., Papazoglou, M.P., eds.: ServiceOriented Computing (SOC). Number 05462 in Dagstuhl Seminar Proceedings, InternationalesBegegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany (2006)

46. Papazoglou, M.P., Heuvel, W.J.: Service oriented architectures: approaches, technologies andresearch issues. The VLDB Journal 16(3) (2007) 389–415

47. HP, IBM, CA: Management using web services: A proposed architecture and roadmap. Tech-nical report (2005)

48. Muller, N.J.: Managing service level agreements. Int. J. Netw. Manag. 9(3) (1999) 155–166

49. McConnell, J., Siegel, E.: Practical Service Level Management: Delivering High-Quality Web-Based Services. Cisco Press (2004)

50. Ludwig, H., Keller, A., Dan, A., King, R.P., Franck, R.: Web service level agreement (wsla)language specification. Web (2003) http://www.research.ibm.com/wsla/.

51. Keller, A., Ludwig, H.: The wsla framework: Specifying and monitoring service level agreementsfor web services. Journal of Network and Systems Management V11(1) (2003) 57–81

52. Dan, A., Davis, D., Kearney, R., King, R., Keller, A., Kuebler, D., Ludwig, H., Polan, M.,Spreitzer, M., Youssef, A.: Web services on demand: Wsla-driven automated management.IBM Systems Journal, Special Issue on Utility Computing 43(1) (2004) 136–158

53. Sahai, A., Durante, A., Machiraju, V.: Towards automated sla management for web services.(2001)

54. Sahai, A., Machiraju, V., Sayal, M., van Moorsel, A.P.A., Casati, F.: Automated SLA monitor-ing for web services. In: DSOM ’02: Proceedings of the 13th IFIP/IEEE International Workshopon Distributed Systems: Operations and Management, London, UK, Springer-Verlag (2002) 28–41

55. Tosic, V., Patel, K., Pagurek, B.: Wsol - web service offerings language. In: Web Services,E-Business, and the Semantic Web: CAiSE 2002 International Workshop, WES 2002, Toronto,Canada, May 27-28, 2002. Revised Papers, Springer Berlin / Heidelberg (2002) 57–67

56. Tosic, V., Pagurek, B., Patel, K., Esfandiari, B., Ma, W.: Management applications of the webservice offerings language (wsol). Information Systems 30(7) (2005) 564–586

57. Tosic, V., Lutfiyya, H., Tang, Y.: Extending web service offerings infrastructure (wsoi) formanagement of mobile/embedded xml web services. In: The 8th IEEE International Confer-ence on and Enterprise Computing, E-Commerce, and E-Services, The 3rd IEEE InternationalConference on E-Commerce Technology. (2006) 87–87

58. Esfandiari, B., Tosic, V.: Towards a web service composition management framework. In:ICWS 2005: Proceedings of 2005 IEEE International Conference on Web Services. (2005) –426

59. Wang, G., Chen, A., Wang, C., Fung, C., Uczekaj, S.: Integrated quality of service (qos)management in service-oriented enterprise architectures. In: EDOC 2004: Proceedings of EighthIEEE InternationalEnterprise Distributed Object Computing Conference. (2004) 21–32

60. Wang, G., Wang, C., Chen, A., Wang, H., Fung, C., Uczekaj, S., Chen, Y.L., Guthmiller,W., Lee, J.: Service level management using qos monitoring, diagnostics, and adaptation fornetworked enterprise systems. In: 2005 Ninth IEEE International EDOC Enterprise ComputingConference. (2005) 239–248

61. OASIS: Web services distributed management: Muws primer. Web (2006) http://www.

oasis-open.org/committees/download.php/17000/wsdm-1.0-muws-primer-cd-01.doc.

62. OASIS: Web services distributed management: Management using web services (muws 1.1).Web (2006) http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/20576/

wsdm-muws1-1.1-spec-os-01.pdf and http://www.oasis-open.org/apps/org/workgroup/

wsdm/download.php/20575/wsdm-muws2-1.1-spec-os-01.pdf.

63. OASIS: Web services distributed management: Mows primer. Web (2006) http://www.

oasis-open.org/committees/download.php/17001/wsdm-1.0-mows-primer-cd-01.doc.

22 Dong Liu et al.

64. OASIS: Web services distributed management: Management of web services (wsdm-mows) 1.1.Web (2006) http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/20574/

wsdm-mows-1.1-spec-os-01.pdf.65. Martin, P., Powley, W., Wilson, K., Tian, W., Xu, T., Zebedee, J.: The wsdm of autonomic

computing: Experiences in implementing autonomic web services. In: SEAMS ’07: Proceedingsof the 2007 International Workshop on Software Engineering for Adaptive and Self-ManagingSystems, Washington, DC, USA, IEEE Computer Society (2007) 9

66. DMTF: Web services for management (ws-management). Web (2006) http://www.dmtf.org/

standards/published_documents/DSP0226.pdf.67. BEA, BMC, CA, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft, Sun: Service modeling language.

Web (2006) http://www.serviceml.org/SML-200610.pdf.68. DMTF: Common information model (cim) infrastructure specification. Web (2005) http://

www.dmtf.org/standards/published_documents/DSP0004V2.3_final.pdf.69. DMTF: Ws-management cim binding. Web (2006) http://www.dmtf.org/standards/

published_documents/DSP0227.pdf.70. Cao, J., Wang, J., Zhang, S., Li, M.: A dynamically reconfigurable system based on workflow

and service agents. Engineering Applications of Artificial Intelligence 17(7) (2004) 771–78271. Gurguis, S.A., Zeid, A.: Towards autonomic web services: achieving self-healing using web

services. In: DEAS ’05: Proceedings of the 2005 workshop on Design and evolution of autonomicapplication software, New York, NY, USA, ACM Press (2005) 1–5

72. Lewis, D., O’Donnell, T., Feeney, K., Brady, A., Wade, V.: Managing user-centric adaptiveservices for pervasive computing. In: ICAC 2004: 1st International Conference on AutonomicComputing, New York, NY, USA, IEEE Computer Society (2004) 248–255

73. Menasce, D.A., Ruan, H., Gomaa, H.: Qos management in service-oriented architectures. Per-form. Eval. 64(7-8) (2007) 646–663

74. Sharma, A., Adarkar, H., Sengupta, S.: Managing QoS through prioritization in web services.In: Proceedings. Fourth International Conference on Web Information Systems EngineeringWorkshops. (2003) 140–148

75. Tseng, J.C., Wu, C.H.: An expert system approach to improving stability and reliability ofweb service. Expert Systems with Applications 33(2) (2007) 379–388

76. Zeng, L., Benatallah, B., Ngu, A.H., Dumas, M., Kalagnanam, J., Chang, H.: Qos-awaremiddleware for web services composition. IEEE Trans. Softw. Eng. 30(5) (2004) 311–327

77. Pacifici, G., Spreitzer, M., Tantawi, A., Youssef, A.: Performance management for cluster-basedweb services. IEEE Journal on Selected Areas in Communications 23(12) (2005) 2333–2343

78. Jamjoom, H., Chou, C.T., Shin, K.: The impact of concurrency gains on the analysis andcontrol of multi-threaded internet services. In: INFOCOM 2004: Twenty-third AnnualJointConference of the IEEE Computer and Communications Societies. Volume 2. (2004) 827–837vol.2

79. Almeida, J., Almeida, V., Ardagna, D., Francalanci, C., Trubian, M.: Resource managementin the autonomic service-oriented architecture. In: ICAC ’06: IEEE International Conferenceon Autonomic Computing. (2006) 84–92

80. Carlstrom, J., Rom, R.: Application-aware admission control and scheduling in web servers.In: INFOCOM. (2002)

81. Cardoso, J., Sheth, A., Miller, J., Arnold, J., Kochut, K.: Quality of service for workflows andweb service processes. Web Semantics: Science, Services and Agents on the World Wide Web1(3) (2004) 281–308

82. An, L., Jeng, J.J.: Web service management using system dynamics. In: ICWS 2005: Proceed-ings of 2005 IEEE International Conference on Web Services. (2005) 347–354 vol.1

83. Martens, A.: Simulation and equivalence between bpel process models. In: Proceedings of theDesign, Analysis, and Simulation of Distributed Systems Symposium (DASD’05), Part of the2005 Spring Simulation Multiconference (SpringSim’05). (2005)

84. IBM: Autonomic computing manifesto. Technical report (2001)85. IBM: An architectural blueprint for autonomic computing. Technical report (2003)