1. Introduction1.1. Service-oriented Management1.2. Generic Management2. Architecture2.1. Resource2.2. Service Adapter2.3. Manager2.4. Registry2.5. Messaging Node2.6. Bootstrap Service2.7. User3. Performance Evaluation3.1. Maximum message rates3.2. Runtime State3.3. Runtime Response Cost3.4. Amount of Management Infrastructure Required4. Application to a Grid Messaging Middleware4.1. State managed per Broker Resource4.2. Deployment Costs5. Fault Tolerance in Distributed Systems5.1. Replication5.2. Check-pointing5.3. Fault-tolerance in Object-based Distributed Systems6. Conclusion and Future WorkReferencesScalable, Fault-tolerant Management in a Service Oriented Architecture Harshawardhan Gadgil, Geoffrey Fox, Shrideep Pallickara, Marlon Pierce Community Grids Lab, Indiana University, Bloomington IN 47404 (hgadgil, gcf, spallick, marpierc)@indiana.edu Abstract With the emergence of Service-based architectures, management of an application which comprises of a large number of distributed services becomes difficult as resources appear, move and disappear across the network. As service components span different network boundaries, constraints such as network policies, firewalls and NAT devices further complicate management by limiting direct access to the resource. Services and resources may exist on different platforms and may be written in different languages, which promotes use of proprietary solutions thus affecting interoperability. In this paper we present a novel architecture that leverages “publish-subscribe” principles for enabling scalable and fault-tolerant management of a set of distributed entities. We make management interoperable by leveraging service-oriented principles. Our empirical evaluation shows that fault-tolerance overhead is about 1% in terms of additional resources required thus making the approach feasible. Keywords: Scalable, Fault-tolerance, Service Oriented Management, Architecture 1. Introduction With the explosion of the internet, a new class of Web-based applications has emerged. These applications have connected end users to existing, traditional, centralized services. Distributed applications today are composed of multiple distributed components and are increasing in complexity. As the individual components get widely dispersed, they tend to span different administrative domains. Differing network and security policies restrict access to application components while resource management access is further limited due to presence of network firewalls and Network Address Translation (NAT) devices. Further, different services may be running on different platforms and could have been written in different languages. As application complexity grows, the need for an efficient management system emerges. Various system specific management architectures have been developed and have been quite successful in their areas. Examples include SNMP (Simple Network Management Protocol) [1] CMIP [2] and CIM [3]. The Java community has introduced JMX [4] (Java Management eXtensions) which enables any Java-based resource to be automatically manageable. WMI [5] (Windows Management Instrumentation) from Microsoft enables local and remote monitoring and management of Microsoft Windows based machines. A main lacking feature among these management systems is interoperability. In this paper we propose a simple, universal mechanism for managing a set of distributed entities. Every entity implicitly has or can be explicitly augmented with a Web service interface. The only assumption in providing fault-tolerance is the existence of a scalable and reliable database for storing system state. Our current implementation leverages the WS-Management [6] specification, but could very well use WS – Distributed Management (WSDM) [7]. WS - 1 -Management was primarily chosen for its simplicity and also to leverage an existing implementation of WS-Eventing [8] in the NaradaBrokering [9] project. 1.1. Service-oriented Management To address interoperability, the distributed systems community has been orienting towards the Web Services architecture which is based on a suite of specifications that defines rich functions while allowing services to be composed to meet varied QoS (Quality of Service) requirements. Proposals [10] that leverage the Web Services management principles in context of existing management frameworks already exist. The service-oriented architecture provides a simple and flexible framework for building sophisticated applications. The use of XML in implementing Web Services facilitates interactions between services implemented in different languages, running on different platforms and communicating over multiple transports. WS Management and WSDM are two competing specifications in the area of management using Web Services architecture. Both specifications focus on providing a Web service model for building system and application management solutions, specifically focusing on resource management. This includes basic capabilities such as creating and deleting resource instances and setting and querying service specific properties and providing an event driven model to connect services based on the publish / subscribe paradigm. WSDM breaks management in two parts, Management using Web Services (MUWS [11]) and Management of Web Services (MOWS [12]). MUWS focuses on providing a unifying layer on top of existing management specifications such as CIM, SNMP and OMI (Open Management Interface) models. MOWS presents a model where a Web Service is itself treated as a manageable resource. Thus, MOWS will serve to provide support for the management framework and support varied activities such as service metering, auditing, SLA (Service Level Agreement) management, problem detection and root cause failure analysis, service deployment, performance profiling and life cycle management. WS Management on the other hand attempts to identify a core set of Web Service specifications and usage requirements to expose a common set of operations central to all management systems. This minimum functionality includes ability to discover management resources, CREATE, DELETE, RENAME resources, GET and PUT individual settings and dynamic values, ENUMERATE contents of containers and collections, SUBSCRIBE to events emitted by managed resources and EXECUTE resource specific management actions. Thus the majority of overlapping areas with the WSDM specification are in the MUWS