• Nenhum resultado encontrado

Dynamic Reconfiguration of Object-Middleware-based Distributed Systems

N/A
N/A
Info
Descarregar agora
Protected

Academic year: 2023

Share "Dynamic Reconfiguration of Object-Middleware-based Distributed Systems"

Copied!
98
0
0

Carregando.... (Ver texto completo agora)

Descarregar agora ( 98 páginas )

Texto

This thesis addresses the dynamic reconfiguration of distributed applications running on top of an object-middleware infrastructure. Dynamic reconfiguration involves operations for replacing, migrating, creating, and deleting these entities at runtime.

The Object Model

The first key specifications produced by the OMG—the Object Management Architecture (OMA) [22] and its core, the Common Object Request Broker Architecture Specification [16]—provide an architectural framework that. The target object is implemented by a programming language construct that performs the computing activities necessary to process the request.

The Object Management Architecture

The core ORB is the part of the ORB that provides basic object representation and request communication. Security is an example of a service with ORB functionality and Object Service interfaces, with the ORB functionality being related to transparent message authentication and access control.

Figure 3 – Interface categories and the ORB
Figure 3 – Interface categories and the ORB

Process overview

This chapter introduces some important terminologies, definitions, and concepts used to discuss dynamic reconfiguration, and presents and compares some of the current approaches to dynamic reconfiguration. Reconfiguration constraints are predicates on the reconfiguration process that constrain its execution, such as "the reconfiguration process must be completed within 10s", or.

Reconfiguration design activities

Changes are defined in terms of entities and operations on those entities and are applied under the control of change management functionality, causing the system to evolve from the current configuration to the resulting configuration. This functionality must ensure that (i) the specified changes are ultimately applied to the system, (ii) the correct (usable) system is obtained, and (iii) the reconfiguration constraints are met.

Change Management

In the first case, the availability of the safe state depends on the behavior of the application. Application state invariants are predicates that include the state of (a subset of) entities in the system.

Figure 5 – Reconfiguration approaches and preservation of mutual consistency In the classification on Figure 5, approaches that preserve some form of mutual consistency fall into two categories: the ones that reach the reconfiguration-safe state by obs
Figure 5 – Reconfiguration approaches and preservation of mutual consistency In the classification on Figure 5, approaches that preserve some form of mutual consistency fall into two categories: the ones that reach the reconfiguration-safe state by obs

Current Reconfiguration Approaches

When all members of the original BSet are blocked, the components of the extended BSet can be unblocked. A system is driven into this safe state by algorithms that disrupt the system's execution.

Figure 7 – A system with dependent transactions
Figure 7 – A system with dependent transactions

Motivation

The approach adopts the object model presented in Chapter 2, and addresses each of the correctness aspects identified in Chapter 3. Finally, Section 4.5 discusses the limitations of the approach, and Section 4.6 compares it with the approaches found in the literature.

Requirements

Supported Reconfiguration

Object substitution allows one version of an object to be replaced by another version while preserving the object identity​​​​. The new version of an object may have functional properties that differ from the old version. In addition, the new version of an object can run in a different execution environment supported by the object middleware platform.

The goal of the reconfiguration approach is to provide swap transparency, which hides the swap of an object from the objects that communicate with it.

Figure 10 – Object creation 4.3.2 Object Replacement
Figure 10 – Object creation 4.3.2 Object Replacement

Change Management

This means that when the system is in a safe-for-reconfiguration state, none of the affected objects are processing requests or waiting for outgoing ones. We ensure that a safe state can be reached by interfering with the system's activities. The state of affected objects can be inspected and used to derive the state of objects being deployed.

The increment is limited by the duration of the longest pending invocation in the set of affected objects at the moment.

Figure 16 – Non-conforming Replacement (i)
Figure 16 – Non-conforming Replacement (i)

Limitations

Considering the absolute increase in response time, the approach seems to be best suited for applications with short-term interactions. Ultimately, the maximum acceptable increase in response time during reconfiguration is determined by the environment in which the affected object is placed.

Comparison with Studied Approaches

A disadvantage of prescribing an ADL or CL for application design is that the conventional development process must include the production of a description of the application using the specific formalism or language. In this approach, the reconfiguration infrastructure maintains a representation of the system's configuration through a directed graph of objects connected by links. This chapter presents the DRS from the perspective of the service users.

This chapter is further structured as follows: Section 5.1 provides an overview of the service's architecture, Section 5.2 describes the change designer's view, and Section 5.3 describes the application developer's view.

Figure 20 shows a refinement of the model presented in Chapter 3, obtained by decomposing configuration information into configuration information obtained at design-time and obtained at run-time
Figure 20 shows a refinement of the model presented in Chapter 3, obtained by decomposing configuration information into configuration information obtained at design-time and obtained at run-time

Overview

DRS uses the mechanisms presented in Chapter 4, implementing the proposed approach on the CORBA platform and supporting both the application developer and the change designer. A Reconfigurable Object Factory implements the Factory design pattern, creating and removing versions of reconfigurable objects on behalf of. The change designer can access the Dynamic Reconfiguration Service service to request execution of reconfiguration steps.

The application developer supplies configurable, application-specific object factories that conform to the interfaces defined by the service.

Change Designer’s View

The create_object() operation allows the application to request the creation of an object by specifying the identifier of the object's type and the criteria to be used in the creation. interface GenericFactory { typedef any FactoryCreationId;. in TypeId type_id, in Criteria the_criteria, .. out FactoryCreationId factory_creation_id. The replace_object() operation requires the user to specify the object entity. replace and the criteria to be used in the creation of the new version of the object. The replace_type() operation requires the user to specify the type to be replaced, the new type, and the criteria to be used in the creation of the new version of objects.

If no state mapping is specified for a particular type, the identity function is used, i.e. the state does not change.

Application Developer’s View

This context information, called the DRS context, contains the invocation path of the request being handled and the identifier of the object handling the request. The DRS context contains the invocation path of req1 ({O1, . … ON}) and the identifier of the OM object handling req1. The parameters to register_thread() are the adapter identifier of the object in which the object resides and the identifier of the object used by that adapter.

These properties are the location-independent object reference to be used by the instance of the object (a property called IOR) and its reconfigurable object identifier (a property called Id).

Figure 22 – The DRS context and the propagation of the invocation path The DRS context is accessible through the ReconfigurationCurrent local object
Figure 22 – The DRS context and the propagation of the invocation path The DRS context is accessible through the ReconfigurationCurrent local object

Location-independent Object References

This chapter is further structured as follows: Section 6.1 discussed the implementation of a location agent to obtain location-independent object references, Section 6.2 discusses the implementation of selective queuing, and Section 6.3 describes how DRS coordinates its components to perform reconfiguration operations. , which provides additional details on the implementation of each component. The first time a client issues a request, the location agent is invoked. A location agent is implemented with a server locator that maintains a registry that maps a reconfigurable object identifier to a regular location-dependent object reference.

The restoration of the binding follows the same procedure as for the first establishment, transparent to the client application.

Figure 27 – Transparent binding establishment
Figure 27 – Transparent binding establishment

Selective Request Queuing

Another alternative is to embed the picker and queue in the middleware infrastructure. Selector and queue are implemented as extensions of ORB server and ORB client, respectively. This solution requires more communication overhead than in the case of a pure server-side solution.

In the wait-and-try policy, Configuration Manager sends a time interval to the Reconfiguration Agents for the affected objects.

Figure 31 – Overview of Application with Reconfigurable Objects 6.2.2 Allocation of Selector and Queue Objects
Figure 31 – Overview of Application with Reconfigurable Objects 6.2.2 Allocation of Selector and Queue Objects

Performing Reconfiguration Steps

It may seem that using an event service (or notification service) would be appropriate for communication between Reconfiguration Manager and blocked clients. Initially, the Reconfiguration Manager delegates the creation of a new version of the object to the local. After that, the reconfiguration manager notifies the affected reconfigurable object and its reconfiguration agent about the initiation of reconfiguration (5, 6).

The reconfiguration agent constrains the behavior of the affected object and notifies the reconfiguration manager when the object is ready for reconfiguration (7).

Figure 34 – Object Creation
Figure 34 – Object Creation

Portability and Interoperability Considerations

Evaluation

This section provides an estimate of the overhead introduced by the dynamic reconfiguration service during normal operation and an estimate of the impact of reconfiguration on performance. From the results obtained, we can also conclude that more than half of the delay added by the dynamic reconfiguration service is caused by the implementation of portable interceptors. Nevertheless, we neglected the overhead introduced by the reconfiguration service for coordinating the reconfiguration.

The delay introduced by the reconfiguration service forms a lower bound for the increase in response time during reconfiguration.

Table 2 – Delay introduced by the middleware platform in invocation mediation
Table 2 – Delay introduced by the middleware platform in invocation mediation

Reconfiguration of a Banking Application

The get_state() operation returns the state of the object encoded as a sequence of octets. The create_object() operation of the local factory creates objects on behalf of the Reconfiguration Manager. The local factory's delete_object() operation deletes objects on behalf of the Reconfiguration Manager.

The location refers to the location where the new factory creates objects, and the version identifier refers to the version of the created objects.

Figure 38 shows the initial configuration of the banking application.
Figure 38 shows the initial configuration of the banking application.

Load-balancing Manager based on Migration

We have implemented a Load Agent in Java that obtains a simple estimate of the load of the location where it is running. Our Load Agent has a load gauge that continuously estimates the load of the location. Therefore, we take the negative of the number of iterations as our estimate of the load.

The Load Manager periodically queries the Load Agent for each location registered to obtain the load of the location.

Figure 43 – Change of configuration with the addition of locations The average response times perceived by clients for the hello() operation lie in the range [2.0; 2.5]s for the configuration with one location, in the range [1.0; 1.5]s for the configu
Figure 43 – Change of configuration with the addition of locations The average response times perceived by clients for the hello() operation lie in the range [2.0; 2.5]s for the configuration with one location, in the range [1.0; 1.5]s for the configu

Main Contributions

This chapter presents the main contributions of this thesis, draws some relevant conclusions from our work and identifies areas where further investigation is needed. This chapter is further structured as follows: Section 8.1 presents the main contributions of this thesis, Section 8.2 presents general conclusions, and Section 8.3 identifies some further work. The main limitation of the approach is that it ignores the preservation of architectural properties of an application, assuming that reconfiguration design activities produce changes that are validated a priori.

We submitted the approach presented in this thesis in Lucent Technologies' [32] response to the Request for Information (RFI) on Web Upgrades issued by the OMG in September in the hope that this approach will become.

General Conclusions

In this approach, the reconfiguration of objects involved in long-term interactions can lead to a high increase in the response time experienced by the clients of the affected objects. The approach has been used in the design of a dynamic reconfiguration service for CORBA, which has been validated by implementing a prototype. Some preliminary test results are presented to assess the overhead introduced by the DRS during normal operation.

The Dynamic Reconfiguration service has proven useful in various application scenarios, including a banking application example and a load balancing application.

Future Work

Transparent dynamic reconfiguration for CORBA, in Proceedings of the 3rd International Symposium on Distributed Objects and Applications (DOA 2001), Rome, Italy, September 2001 (to appear). A language for implementing generic dynamic reconfigurations of distributed programs, in Proceedings of the 12th Brazilian Symposium on Computer Networks, 1994. Architecture-based runtime software evolution, in Proceedings of the International Conference on Software Engineering, April 1998.

Using message reflection in a management architecture for CORBA, in Proceedings of the 11th IFIP/IEEE International Workshop on Distributed Systems: Operations.

The ReconfigurationService Module

This appendix lists the OMG IDL interfaces that should be standardized for portability, as identified in Section 6.4. exception CannotMeetCriteria { Criteria unmet_criteria;. in TypeId type_id, in Criteria the_criteria, .. out FactoryCreationId factory_creation_id. ReconfigurationStep create_reconfiguration_step() raises (UnderReconfiguration);. in TypeId type_id, in Criteria the_criteria, .. out FactoryCreationId factory_creation_id. FactoryCreationIds replace_type( . in TypeId current_type_id, in TypeId new_type_id, in Criteria the_criteria.

Imagem

Figure 1 shows the interaction between a client and a target object, and the role of the middleware infrastructure in supporting this interaction
Figure 3 – Interface categories and the ORB
Figure 4 – Dynamic Reconfiguration model
Figure 5 – Reconfiguration approaches and preservation of mutual consistency In the classification on Figure 5, approaches that preserve some form of mutual consistency fall into two categories: the ones that reach the reconfiguration-safe state by obs
+7

Referências

Descarregar agora ( PDF - 98 páginas - 1.41 MB )

Outline

Change Management Comparison with Studied Approaches Change Designer’s View Application Developer’s View Selective Request Queuing Evaluation Reconfiguration of a Banking Application Load-balancing Manager based on Migration

Documentos relacionados

Herói controverso : aproximações entre Capitão Nascimento e Batman na construção de uma identidade heroica

O presente trabalho é uma tentativa de explorar as possibilidades de encontros entre a antropologia visual, os estudos culturais e o cinema de ficção no intuito de