Management of service-oriented systems - Semantic Scholar

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 Science University of Saskatchewan, Saskatchewan, Canada Received: date / Revised version: date

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

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

1 Introduction Alan Kay, the recipient of 2003 Turing Award for his contributions to object-oriented programming 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 15th century, 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 essay was invented . . . The commercial computer is now about 50 years old and is still imitating the paper culture . . . we could claim that the computer revolution hasn’t even started.” Although it may not be a revolution from the current point of view, the computer is changing our life to what we cannot even imagine. Among all the computer-related technologies, the Internet has the greatest influence. The use of email and World Wide Web (WWW, or web) 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, entertainment, science, and politics. It even introduces new elements to languages and cultures. The web is considered as the global space of information, where everyone can easily access and publish hypermedia content. Besides information, the functionalities to process information are essential parts of computing. However accessing such functionalities is technically more

2

Dong Liu et al.

Distributed Computing Technology Significant1970 Events

Message | RPC | object

Procedure calls

Messages

Objects

Services?

XML RPC (1998) SOAP 1.2 (2003) RMI (1997) WSDL 1.1 (2001)

CSP (1978) SUN RPC (1984) CORBA 2.0 (1991) REST (2000) Web 2.0 (2004)

C (1978)

1980

C++ (1985)

1990

Java/JVM 1.0 (1995)

2000

2010

JavaScript (1995) AJAX (2005) W3C (1994) HTTP 1.0 (1996) XML 1.0 (1998)

Fig. 1 The development of distributed computing technologies.

difficult than accessing information via the web. Based on the model and technologies of the web, can we develop a technology that enables easy access of the information-processing functionalities? Will the technology lead to the formation of a space of interconnected functionalities? A service refers to a concrete autonomous technical functionality of retrieving and processing information. There are already numerous “services” running in enterprise and personal 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 heterogeneous platforms, languages, and ownership. It is a theme of distributed computing to develop technologies that enable easy access and integration. Distributed computing technologies can be roughly classified into two categories by communication methods: distributed shared memory, and message passing [3]. Systems using message passing can be more open and scalable than those based on distributed shared memory since messages make the distributed nodes more loosely coupled with each other than shared memory [4]. In the category of message passing, a “D´ej` a Vu” was observed [5], and it has continued: messages in 1970’s, remote procedure calls (RPC) in 1980’s, objects in 1990’s, and XML-RPC, SOAP, and REST since late 1990’s. As shown in Fig. 1, distributed computing technologies have been largely shaped by programming languages and paradigms. Therefore, many distributed computing technologies are tightly coupled with languages and platforms supporting those languages. The situation changed with the extensive adoption of XML (Extensible Markup Language) and HTTP (Hypertext Transfer Protocol). XML is an application-independent way to serialize and encode structured data. HTTP provides a communication infrastructure independent of languages, platforms, and vendors. SOA (Service-Oriented Architecture) is a paradigm for designing, implementing and utilizing 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 with other(s) by providing and/or consuming services. Such a system is often formed by evolution rather than by design. Openness is an essential advantage of SO systems. A software system is considered open if it implements open standards and technologies and it is easy for an alien component to join and become part of the system. However, the openness can bring 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 on some service endpoints can change dramatically with time. A SO system can show emergent behaviors that may have never been considered during design. Enterprises have to consider management 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 management, configuration management, performance management, and security management, or operation, administration, maintenance, and provision of SO systems. It also implies developing systems that can carry out those management tasks. The rest of the paper is structured as follows. Section 2 reviews the concepts and technologies of SOA and web services. Section 3 reviews the principles and techniques of general systems management. Section 4 discusses the challenges of service-oriented systems management, and reviews the state of the art of SO systems management. Section 5 concludes the paper, and discusses future directions. 2 Service-oriented systems The fundamental concepts and principles of SOA are reviewed in Section 2.1. Section 2.2 and 2.3 are reviews of XML and web services. Section 2.4 introduces the concept of service composition. 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 organizing and utilizing distributed capabilities that may be under the control of different ownership domains” [6]. It is also referred as “a model in which automation logic is decomposed into smaller, distinct units of logic” [7]. Note that SOA does not refer to any specific architecture. Don Box summarized the essential common principles of SOA into four tenets [8]: – Boundaries are explicit. Services need to communicate across boundaries of different geographical zones, ownership and trust domains, and operation environments. In order to reduce the cost of cross-boundary communication, explicit message passing is applied for services rather than implicit method invocation. Explicit service boundaries also reduce the cost of communication between developers and development organizations. – Services are autonomous. Services are independently deployed. A deployed service does not assume the existence of its consumers. The topology of a service-oriented system is dynamic, i.e. changing with time. New services may be introduced to the system without advance acknowledgements. The applications consuming a service can leave the system or fail without notification. A service need to handle the issues of authentication and trust for the incoming service requests. – Services share schema and contract, not class. Services interact by message passing. Message structures are specified by schemas, and message-exchange behaviors are specified by contracts. – Service compatibility is determined based on policy. The semantic compatibility of a service, i.e. its capabilities and requirements, is based on explicit policies. 2.2 Loose-coupling A common goal of the four tenets is to developing loosely coupled distributed systems based on 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 if one module calls the other (normal coupling), they share the same common data (common coupling), or one module refers to the inside of the other (content coupling). Common coupling and content coupling are considered bad designs because one module depends on the other so much that even a minor change of the depended module may result in the dependent module not working properly. It is difficult to quantify the coupling between two modules in a multi-module program. The terms of “loose” and “tight” are used to qualify the degree of coupling. Loose-coupling is a design requirement for multi-module programs that can be easily maintained and evolved. In object-oriented programming, the consumers of a class’s operations are loosely coupled with its implementations by relying on the provided interface [10]. In distributed computing, two applications are considered loosely coupled when they communicate by message passing rather than memory sharing [3]. In web services, a service and its consumers are loosely coupled by using explicit message passing instead of implicit method invocation [11]. There are also examples of loose-coupling in everyday life. Lego blocks are loosely coupled, since any block can be easily connected to other blocks in the same set. Electrical devices are loosely coupled with the power supply, and they can be plugged into standard outlets to get power. An effective design principle to achieve loose-coupling is to emphasize and make use of the simplest and standardized interfaces. In SOA, contract sharing is an application of this principle. Coupling was originally used to denote the interdependency between two modules at the same abstraction level, e.g. two functions, two objects, and two services. It is also used to denote the interdependency between two entities of different levels of abstraction in some contexts, e.g. the coupling between a system and its components, and the coupling between a system and its environments [12]. There are always constraints of coupling for any technology in every design. When SOA principles are applied to reduce the coupling between distributed components and applications, some other types of coupling will be introduced, e.g. the coupling between service implementation and service contract, and that between service consumer and service contract [13]. 2.3 XML The EXtensible Markup Language (XML) is a subset of the Standard Generalized Markup Language (SGML), an ISO standard1 , originally designed for large-scale electronic publishing. XML is popular for data exchanging on the web and among applications2 . XML provides a method for encoding and serializing structured data that is independent of applications and vendors. XML is a natural choice for distributed applications to accomplish loose-coupling. XML is one of the most fundamental technologies of web services. The applications of XML are ubiquitous in service implementation: messages, service schemas and contracts, and policies. An XML document represents and stores information in elements that are assembled in a structure. An element is specified by tags and attributes. When the data represented by XML documents or streams are exchanged on the web or among applications, the documents or streams should be validated to ensure that the information can be uniquely understood. 1 2

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


5

Security

WS-Security (OASIS)

Process

BPEL (OASIS), WSChoreography (W3C)

Metadata

WSDL (W3C), UDDI (OASIS), ...

Management WSDM (OASIS), ...

Resource WSRF (OASIS), ...

Messaging SOAP (W3C), WS-Addressing (W3C), ...

Information representation XML (W3C)

Communication HTTP (W3C, IETF), FTP (IETF), SMTP (IETF), ...

Fig. 2 Web services standards.

The validation of an XML document can be carried out according to either a Document Type Definition (DTD) or an XML schema specifying its structure and the types of each element. Although DTD appeared earlier than the XML schema, the schema is more widely used, and offers more powers of data expression. Moreover, the XML Schema definition language (XSD) is itself represented in XML. The abilities of XML to represent both data instances and metadata including structure, content, and semantics make it favoured in web services technologies. 2.4 Web services Although web services are closely related to SOA, they are different. SOA refers to a paradigm based on which a service-oriented system can be developed, and web services technology is just one of the technologies that can be used to develop those systems. According to W3C [14], a web service is “a software system designed to support interoperable machineto-machine interaction over a network.” Web services are the implementations of a number of 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 fundamental standards in the stack are those for communication and information representation like HTTP and XML. Fig. 3 shows several interaction scenarios between web services. When a service consumer wants to find web services of interest, it will ask the service registry for suggestions. The service registry has the metadata of services and supports enquiry and registration of service entries. UDDI (Universal Description, Discovery, and Integration) [18] is a group of service 3 4

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

6

Dong Liu et al.

Message (SOAP) Message (SOAP)

Message (SOAP)

Message (SOAP)

Service B

Service A

Service description (WSDL)

Service consumer agent


Message (SOAP)


Service registry (UDDI)

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 services provided; that for “where” is the services URL’s or email addresses; and that for “how” is about interfaces to interact with the services. When a service consumer has the information about “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 message to 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 in 1998 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 message exchange paradigm” [19]. WSDL (Web Services Description Language) is a language in XML to describe the shared schema and contract of a web service. The WSDL document of a web service includes entries for service name, service interface, endpoint name, endpoint address, 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 developers tend 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 SOA context. In fact, SOAP is also good for document-style messaging in which the entries of an XML message do not, by default, map to the corresponding methods. The usage of SOAP raises many debates since some developers consider SOAP as one of the essential technologies to implement services while others disagree and use plain XML messages instead. Some developers prefer the RESTful services that rely on plain XML or JSON (JavaScript Object Notation) 5 and HTTP. 5

See json.org .


7

REST (Representational State Transfer) is a software architecture style for distributed large-scale systems [20,21]. Roy Fielding coined the term based on his experiences in the development of the HTTP protocol and Apache HTTP server project. The modern web is considered an instance of REST. The RESTful services emphasize the URL (uniform resource locator) and standard operation interfaces of Post, Get, Put, and Delete. E.g. to access an order 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 support RESTful service interfaces. 2.5 Service composition SO principles emphasize service composability, by which a set of services can be composed to achieve desired functionalities. Service compositions are also called service assemblies [7]. A service participating in a composition is called a composition member. It is important to note that service orchestration and service choreography are two fundamentally different approaches for composition. Service orchestration depends on a central conductor or controller service that executes a plan/workflow that defines when and how the members are to act. Service choreography, on the other side, does not have a central service and is based on the idea that the members are able to interact according to a previously agreed choreography description. Consequently, choreography assumes that the members are collaborative enough to be able to achieve a common goal while the members of a service orchestration do not need to know any details about the orchestration and is therefore much easier to implement. Not surprisingly, service orchestration is the dominant approach for achieving service compositions. The WS-BPEL (Web Services Business Process Execution Language) specification [22] defines a language to specify service orchestration. The WS-CDL (Web Services Choreography Description Language) [23] is a language to specify service choreography. Service compositions offer diverse compound functionalities and flexible cost-benefit choices based on available services. A service composition can be easily developed according to its functional and nonfunctional requirements based on the determined schemas and contracts of member services no matter whether or not those member services are already implemented. This is valuable for the development of large distributed software systems, when the components for high-level functionalities and those for the low-level functionalities are required to be developed in parallel for timely delivery. Service composition introduces business opportunities for small vendors to deliver their services quickly by composing the services supplied by major service providers in IT industry. There are many such business applications 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, and trust domains. It is impossible to have a centralized system to control or manage all the members in a system. Multiple firewalls and authentications can be involved in interaction between services and their consumers.

8

Dong Liu et al.

– Homogeneous and yet Heterogeneous. Services and their consumers in a service-oriented system interact according to the shared message schemas and contracts. They speak a common language and communicate in the same manner. At the same time, they run on different platforms and virtual machines, and/or are implemented in different programming languages. – Open. There are few organizational, geographical, or domain obstacles for service providers and consumer to become part of a service-oriented system. Services communicate on the basis of standards. Service contracts and policies are explicit. – Dynamic. The structure of a service-oriented system can change with time. The changes of a service’s business logic should not interrupt its interactions with consumers when the shared contract remains unchanged. – Hierarchical and Heterarchical. Service composition forms hierarchies, in which the services at higher positions consume those at lower positions. The hierarchy reflects the dependency 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 consumers in 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 pairs of services and their consumers. It can also be very large in scale due to its openness and service composability. 3 Systems management This section gives an overview of systems management — concepts, principles, and techniques. The simple network management protocol (SNMP) provided a good example to understand the basic concepts and principles of systems management. Those concepts and principles 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 organizations, 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 to keep their competence on the market and eventually make more revenue. However, improving 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 peopleto-people relationships and interactions are the theme of business management, machineto-machine interactions are more emphasized in systems management. In order to define systems 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 systems management, where the axes are management function purpose, management system building block, and management scope respectively. The TMN (Telecommunications Management Network) reference model defined five function categories by their purposes for network management: Fault, Configuration, Accounting, Performance, and Security (FCAPS) [25,26]. Fault management is about monitoring a system’s operating status, event logging, fault diagnosis, and recovery from failure.

9

Communication

Representation

y e rit cu nc Se rma rfo g Pe ntin n u co atio Ac gur fi on C t ul Fa

Logic


Business Service Infrastructure (network/device)

Fig. 4 Facets of systems management.

Configuration management is about initialization and revision of configurations of infrastructures and services. Configuration management is often related to fault management, performance management, and security management, because improper configuration changes are often the sources of fault, security and performance issues. Most systems provide services to their customers for revenues, and accounting management is to ensure the customers getting proper service according to their payments. Performance management is about monitoring system performance and tuning the system to achieve an expected performance goal. Note that monitoring tasks in fault management and performance management target different information, i.e. fault events and performance measures respectively. Not all the management functions can be well classified using the FCAPS reference model. Some management tasks like monitoring can be classified into two or more categories of FCAPS. In some cases, only some of the five categories are addressed by a management system, e.g. autonomic computing [27] focuses on fault management(self-healing), configuration management(self-configuration), performance management(self-optimization), and security management(self-protection). The details of autonomic computing will be discussed later in Section 4. Operation, Administration, Maintenance, and Provision (OAM&P, or OAMP) is another way to categorize management functions like FCAPS according to their purposes [25]. Systems management can be classified into categories of business, service, and infrastructure 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 system to customers, and it is different from the ‘service’ in service-oriented sense. Business-scope management has to rely on service-scope and infrastructure-scope management at lower layers to achieve business goals, and the FCAPS functions details are carried out mainly at lower layers. Management goals are achieved by operations of deployed management systems. A management system is composed of three conceptual building blocks, i.e. management information communication, management information representation, and management logic. Since a management system is by itself a distributed system in most cases, communication and representation are the basis for different parties of a management system to talk to and understand each other. Management logic is responsible for analysis and decision making of the FCAPS or OAM&P functions based on collected information of managed systems. How

10

Dong Liu et al.

Manager

Sensor Actuator

Agent

Managed element Fig. 5 The anatomy of a management system.

much human effort is required in the logic block depends on the complexity of a management task and the implementation of a management system. An element to be managed and an element to perform management are two basic roles in a systems management context. A component or subsystem of the latter role is often called a manager. As shown in Fig. 5, an agent resides at the managed element, and it is responsible for providing management information to the manager and executes the management actions decided 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 less difficult if they are provided with manageability. A system’s or component’s manageability refers to its capability to be managed. A system’s manageability includes how much an agent can report and change the system’s state, and the easiness of interacting with the agent through sensors and actuators. The manageability of a system depends on the manageability of its subsystems and components. It is impossible to manage a large-scale SO system if services offer no manageability. Developing services with built-in manageability is indispensable for composing manageable SO systems. The manageability of a service depends on the manageability features of its platform and its design. Most modern operating systems, database systems, and application servers afford manageability features. Windows (2000 and later version) and SUSE Linux enterprise server have built-in management components implementing the Web-Based Enterprise Management (WBEM)6 , a group of standards in the DMTF. The Windows WBEM implementation is the Windows Management Instrumentation (WMI)7 . The current WMI is accessible by the .NET technologies, and supports communication through DCOM and SOAP8 . Operating system virtual machines (OPVM’s) can provide to users virtualized homogeneous operating systems regardless of the underlying physical hardware and/or host op6 7 8

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


11

erating systems by means of software [29,30]. A management solution developed for one operating system can be easily ported to other operating systems with OPVM’s installed on them. In this way, the manageability of operating systems is leveraged by software virtualization. The introduction of application virtual machines (AVM’s) has made software development and integration across different platforms much easier. It is straightforward to take the advantage of VM for management of heterogeneous infrastructures. E.g. the Java Management Extensions (JMX) [31,32] technology supplies tools for management of resources on 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 JMX agent that performs the management of a resource. The manageability consumers can remotely 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 principles to management problems to help managers make better decisions” [33]. Although systems management is not an area that management science focuses on, the problem solving techniques of management science are applicable to systems management problems. How to model and solve a management problem depends on the problem’s nature. Table 1 lists some commonly used management science techniques. Basically, the techniques can be grouped into four categories: policy, linear/nonlinear/integer and dynamic programming, probability modeling, and simulation. The first two are more suitable for deterministic situations, while the third is for uncertain situations. Simulation is a group of techniques to address management problems when experiments with the real systems and/or analytic modeling are either impossible or expensive. Simulation is able to model variability and provide transparent dynamic view of a system [34]. Some management solutions may be classified into two or more of these categories. These techniques are applied in SO systems management, 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 network management standard that is specified by a number of RFC’s (Requests for Comments) of IETF. So far, it has three versions, version 1 since 1988, version 2 since 1993, and version 3 since 2002. The SNMP can be used for management of both network devices like routers and switches and servers like DNS’s (Domain Name Servers). Most network device and operating system venders implement SNMP in their products. There are two kinds of entities in SNMP-capable systems: agents and managers. An SNMP agent is deployed on a managed device or system. It can send management information to an SNMP manager either proactively or interactively. An SNMP manager is often a server that communicates with a number of agents and performs management functionalities. A manager is also called network management station (NMS). The SNMP describes the details about management information communication and modeling. 9

See mx4j.sourceforge.net .

Dong Liu et al. 12

Table 1 Commonly used management science techniques Technique

Details

Target problem

Policy

Policy is the most straightforward approach to reasoning and making decisions for familiar situations. Basically, a policy contains two parts: the condition(s) and the action(s). The evaluation of policies is triggered by certain event(s). An inference engine is required when a policy base becomes complicated.

Decision making

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

Some programming problems can be represented as a system of constraint equations/inequations and an objective function with a number of variables. If all the constraint equations/inequations and the objective function are linear, it is a linear programming problem, and otherwise a nonlinear problem. Some network flows problems can be solved by linear programming. If the solution space is a set of integers, the problem is an integer programming problem. Search algorithms are often applied to solving linear/nonlinear/integer programming problems. Some other programming problems can be represented as a multi-stage decision process whose optimal solution is a sequence of decisions. Dynamic 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 common in real-life management. The widely applied probability techniques include parameter estimation, hypothesis testing, Bayesian inference, risk analysis, Markov chain, and queueing theory among others. Systems involving services and waiting lines can be modeled as queues or networked queues. Queueing theory studies queue length, waiting and residence time, service utility, throughput and other measures with given arrival rate, service time, and topology of queues.

Estimation, prediction, inference, and decision support

Simulation [34, 40]

A simulation aims to produce a system’s behaviour and final state in a long time period and/or across a number of nondeterministic initial and transient states by generating random variables and processes that would regulate the model’s state transitions. Simulation can be used to analyze systems when no analytic approaches will work without rigorous assumptions. Simulation is friendly to managers or administrators by intuitive and animated presentations of a dynamic system.

Prediction and decision support


13

Request Message (UDP)

Manager

Agent

Manager

Response Message (UDP)

Poll

Notification Message (UDP)

Agent

Trap

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

The User Datagram Protocol (UDP) is chosen as the transportation protocol for information 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 of messages. UDP is therefore more lightweight than other protocols like TCP (Transmission Control Protocol). This means that the communication between agents and managers will hardly 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 and the agent responds according the request. A trap refers to the action that an agent notifies the manager about some events proactively. No acknowledgement of receiving is expected for a trap by an agent. Fig. 6 shows the message exchange patterns of poll and trap. The three 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 from agents, and Set is for changing parameters of agents. Trap, Notification, and Inform are trap operations. Note that Inform was introduced in SNMPv2 in order to enable acknowledgement 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 vocabularies for network management. The MIB defines the management information objects by using SMI syntax. The SMI can be considered as the schema or metadata of MIB’s. The information structured by the SMI is formed as a tree. The vendors of devices and systems define MIB’s for specific applications and purposes. In order to ensure the NMS’s and agents developed by different vendors to work together, a vendor needs to publish the MIB’s of its products. How the managers should act according the management information obtained by polls and traps depends on the specific application logic. Most NMS’s implement policy-based management techniques. The SNMP is a comprehensive framework for network management. Since there are fewer and fewer difference between network management and systems management in present IT industry, the framework is a good reference for developing management protocols and systems of service-oriented systems. Many common aspects can be found between SNMP and 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 both IT industry and research areas [44,45,46,47]. The characteristics of SO systems raise the following problems for systems management. – Distributed management. It is impossible to apply a non-distributed management approach to SO systems. A manager needs to communicate with the managed nodes through multiple firewalls and authentications. – Unification of services management and infrastructures management. From a pure service point of view, the management of a SO system is composed of management of services in the system. On the other side, the management of a system involves management of web servers, application servers, databases, and other infrastructures. Service management and infrastructures management should be unified to achieve the goals of SO systems management. – Management integration. Managers and agents may run on heterogeneous platforms and virtual machines where the services are deployed on, and they need to be integrated together. – Dynamic management. A management system needs to adapt to the changes and faults of services, especially partial failures. – Consistency of management of service compositions and member services. The management goals of service compositions need to be achieved by management of the member services. – Management scalability. The management approach needs to be scalable for systems of diverse 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 service context, 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 in order to provide acceptable service quality to service consumers according to the agreement of price and time constraints [28]. Quality of Service (QoS) is a technology-centred measure of the performance of a service [49], e.g. response time and failure rate. SLM appeared earlier than 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 systems management can be classified into infrastructure-scope, service-scope, and business-scope approaches from bottom to top similar to general systems management [28]. SLM is an example 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 represented in WSLA is composed by three parts: the parties, the service definitions, and the obligations. The part of parties describes the service participants’ names, contact information,


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 definitions describes the service operations and operation groups specified in the SLA. Each operation or operation group is defined by their schedules, SLA parameters and the metrics of these parameters. The part of obligations describes service level objectives and the actions to perform while the service level objectives are not satisfied. A service level objective defines the service quality, the validity period of the objective, and the methods to measure the service quality. The management applications of web services are able to automatically evaluate and monitor the SLA’s represented by WSLA other than natural languages. Dan et al. applied WSLA to automated web services management [52]. They proposed a framework to perform dynamic resource provision, and workload management based on WSLA. The framework monitors the performance of a managed service, and provisions the service resources according to the associated SLA’s based on performance prediction. The service execution management component of the framework measures the resource usage, and tries to 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 to automated SLA monitoring for web services [54]. SLA-based approaches imply flexibility and negotiability of the service levels between providers and consumers. However, it is sometimes inconvenient for both service providers and service consumers to institute and apply formal SLA’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 choose and 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 composing the services that are consumed by the subscribers of service offerings [58]. Pricing is important for service participants including providers and consumers in both B2B and B2C contexts, where time and quality aspects of services are directly associated with the corresponding prices. In enterprise computing environments, service consumption is sometimes not charged within the same organization, where the quality is the key of the whole service level management. Wang et al. presented an approach to integrating messageoriented 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 “to unify management infrastructures by providing a vendor, platform, network, and protocol neutral framework for enabling management technologies to access and receive notifications of management-enabled resources.” The Management Using Web Services (MUWS) specification [61,62] is the first part of WSDM, and describes how to represent the manageability of resources 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 manageability of web service endpoints and how to access the manageability. The WSDM is developed on the basis of the OASIS Web Services Resource Framework (WSRF), a group of 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.

Communication Modeling

OASIS

DMTF SML

MOWS MUWS

CIM

WSRF

MUWS WSRF

WSML ITIL SNMP

WS-M SNMP

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 to construct 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 software and hardware management using web services maintained by the DMTF (Distributed Management Task Force) 11 . The WS-Management specification defines constraints of webservice-based approaches for management of hardware and software systems including web services. The WS-Management focuses on management information communication, and it does not address management information modeling like WSDM. The contributors of WS-Management are developing the Service Modeling Language (SML) [67], a language to modeling complex IT services and systems. The SML covers many management aspects including configuration, deployment, monitoring, policy, health, capacity planning, target operating range, service level agreements, and others. The SML was submitted to W3C for standardization in 200712 . Both WSDM and WS-Management lack popular implementations currently, and the major drawback of these two approaches is that they depend on a large web services standards stack. Light approaches like SNMP could be favoured in a long run. The Common Information Model (CIM) standards [68] define management information for systems, networks, applications, and services. The DMTF provides a specification for binding the CIM to the WS-Management [69]. The ESSI WSMO working group13 developed the Web Service Modeling Language (WSML) and submitted it the W3C14 . The WSML is based on logical formalism and can be used for modeling semantic web services. There are other standards that can be applied to SO systems management like the Simple Network Management Protocol (SNMP) [41] and the IT Infrastructure Library (ITIL)15 . All these 11 12 13 14 15

See See See See See

www.dmtf.org . www.w3.org/Submission/2007/01 . www.wsmo.org . www.w3.org/Submission/WSML . www.itil.co.uk .


17

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

4.3 Management science techniques used in SO systems management There are many scenarios in SO systems management in which management science techniques can be applied. Table 2 listed the techniques reported in literature and the management 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

Policy

Dynamic 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/integer programming & dynamic programming

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

Probability modeling

performance prediction by queueing theory and Markov chain [78, 77], capacity planning [79], QoS prediction of service compositions [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 vendors try to decrease the costs of SO systems management while the efficiency and reliability of the management approaches still need to be satisfied. In 2001, IBM began to advocate and work on a technology named autonomic computing that addresses the observed increasing software complexity crisis [84,27]. The nature of autonomic computing is to develop selfmanaging systems that can self-configure, self-heal, self-optimize, and self-protect. A selfmanaging system is composed of self-managing components. The conceptual structure of a self-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 managed element through the sensors bounded on it. The manager monitors the state of managed element, analyzes obtained information, plans the actions that the managed element should take, and then execute them by the effectors on the managed element. The monitor-analyzeplan-execute control loop is based on the knowledge about managed element. It is natural to apply self-managing technologies to SO systems management, where the managed elements are service endpoints. Some major IT vendors, like IBM, HP, and CA, are pushing towards this 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, though the term of “autonomic computing” may not be used. E.g. all the approaches mentioned in Section 4.1 [52,53,57,59] adopt automated control mechanism to ensure the service levels. A self-management process is very similar to a control loop: the control components or managers get run-time information from the managed services, and then change the services’ configurations according to some control mechanisms. How to implement the control mechanisms differs from one approach to another. Policy-based reasoning was applied for control mechanisms in some approaches [70,72,59]. The rules in [70] were constructed in the form of event-condition-action. Other approaches [79,77,74] modeled SO systems based on queueing theory, and developed control mechanisms based on mathematical optimization methods. An and Jeng [82] applied system dynamics to modeling SO systems in order to anticipate system behaviors under different control configurations. Autonomic computing is a promising direction to developing management systems that are able to address the dynamics, 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 major challenges of SO systems management. A number of management approaches have been proposed 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 have limited control of its member services that belong to different organizations. The management information that can be obtained from member services is constrained by their contracts and policies. How to conduct successful management of a service composition with such constraints is an open problem. For service orchestrations, central controller services 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 technologycentred QoS. The user-centered service experience will attract more and more attention


19

in SO systems management. Service experience is the measure of service quality during human-service interaction from the end-customer’s perspective. Service experience is affected by QoS and usability of a service and the interest of the customer. How to evaluate service experience and how to improve it are open questions. (3) Self-management of SO systems. A SO system evolves when new service consumers join in and new service hierarchies and heterarchies are formed. To maintain a centralized management solution for an evolving system is difficult. A SO system deals with parties across organizational and ownership boundaries. There is no one-for-all management solution satisfying diverse interests of those parties. Practically, there is no one responsible for developing and maintain such a solution. Self-managing services is a promising solution to lower the complexity order of the management problem. The questions that follow are whether the aggregation of self-managing services results in a self-managing SO system, whether a self-managing service performs the same through the evolving process of a system, and whether self-management solutions from different parties can work together. Services and service compositions with built-in manageability is the basis of self-managing SO systems.

6 Acknowledgements This work was supported by the Natural Sciences and Engineering Research Council under Grant Number ???. We would like to thank Nathaniel Osgood, Eric Neufeld, Rick Bunt, Chris Zhang, and anonymous reviewers for their valuable comments and discussions of our work 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’t happened yet. In: EMSOFT ’04: Proceedings of the 4th ACM international conference on Embedded 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. fourth edn. Addison Wesley (2005) 5. Waldo, J., Wyant, G., Wollrath, A., Kendall, S.: A note on distributed computing. Technical 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 indigo. 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.: ObjectOriented 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–223 13. 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 Understanding 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–150 22. 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–50 28. Casati, F., Shan, E., Dayal, U., Shan, M.C.: Business-oriented management of web services. Commun. ACM 46(10) (2003) 55–60 29. 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. Addison 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 Network Management Protocol (SNMP and SNMP Version 2). M & T Books (1997)


21

44. Papazoglou, M., van den Heuvel, W.J.: Web services management: a survey. IEEE Internet Computing 9(6) (2005) 58–64 45. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., Kr¨ amer, B.J.: Service-oriented computing: A research roadmap. In Cubera, F., Kr¨ amer, B.J., Papazoglou, M.P., eds.: Service Oriented Computing (SOC). Number 05462 in Dagstuhl Seminar Proceedings, Internationales Begegnungs- und Forschungszentrum fuer Informatik (IBFI), Schloss Dagstuhl, Germany (2006) 46. Papazoglou, M.P., Heuvel, W.J.: Service oriented architectures: approaches, technologies and research issues. The VLDB Journal 16(3) (2007) 389–415 47. HP, IBM, CA: Management using web services: A proposed architecture and roadmap. Technical 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 WebBased 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 agreements for 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 monitoring for web services. In: DSOM ’02: Proceedings of the 13th IFIP/IEEE International Workshop on 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 web service offerings language (wsol). Information Systems 30(7) (2005) 564–586 57. Tosic, V., Lutfiyya, H., Tang, Y.: Extending web service offerings infrastructure (wsoi) for management of mobile/embedded xml web services. In: The 8th IEEE International Conference on and Enterprise Computing, E-Commerce, and E-Services, The 3rd IEEE International Conference 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 Eighth IEEE 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 for networked enterprise systems. In: 2005 Ninth IEEE International EDOC Enterprise Computing Conference. (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: Proceedings of the 2007 International Workshop on Software Engineering for Adaptive and Self-Managing Systems, 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–782 71. 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 autonomic application 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 adaptive services for pervasive computing. In: ICAC 2004: 1st International Conference on Autonomic Computing, New York, NY, USA, IEEE Computer Society (2004) 248–255 73. Menasc´e, D.A., Ruan, H., Gomaa, H.: Qos management in service-oriented architectures. Perform. 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 Engineering Workshops. (2003) 140–148 75. Tseng, J.C., Wu, C.H.: An expert system approach to improving stability and reliability of web 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-aware middleware 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-based web 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 and control of multi-threaded internet services. In: INFOCOM 2004: Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies. Volume 2. (2004) 827–837 vol.2 79. Almeida, J., Almeida, V., Ardagna, D., Francalanci, C., Trubian, M.: Resource management in the autonomic service-oriented architecture. In: ICAC ’06: IEEE International Conference on Autonomic Computing. (2006) 84–92 80. Carlstr¨ om, 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 and web service processes. Web Semantics: Science, Services and Agents on the World Wide Web 1(3) (2004) 281–308 82. An, L., Jeng, J.J.: Web service management using system dynamics. In: ICWS 2005: Proceedings 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 the Design, Analysis, and Simulation of Distributed Systems Symposium (DASD’05), Part of the 2005 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)