CORBA provides reliability of software application--Essay代写范文

Essay代写范文:“CORBA provides reliability of software application”，这篇论文主要描述的是CORBA指的是公共对象请求代写体系，随着越来越多的开发人员开发着分布式的应用程序，需要对分布式进行相应的计算，因此CORBA软件应运而生，这些软件为开发人员们提供着接口及动态调用接口的功能，可以总结为是一种接口定于的语言。

INTRODUCTION

Many modern applications are distributed. As distributed computing has grown, standards have emerged.Among these is the Common Object Request Broker Architecture (CORBA) [1]. CORBA provides application developers with an interface to build distributed object-oriented applications.The Object Management Group (OMG), the developers of CORBA,were able to solve or mollify several common problems that occurred during distributed application development. Their achievements include an interface definition language that is both programming-language-and platform-independent.They also provide a dynamic invocation interface to allow distributed communication interfaces to be executed and discovered at run-time. CORBA also sets a standard for services to the application such as naming, event, and life cycle services.However,CORBA does not provide a simple architecture to allow distributed applications to be fault tolerant.

Fault Tolerance

Many of the concepts introduced in this section are taken from the Delta-4 project [2].A system failure is occurs when the service delivered by the system no longer complies with its specification. An error is that part of the system state that is liable to lead to failure. The cause of an error is a fault. An error is thus the manifestation of a fault in the system, and a failure is the effect of an error on the service.Fault tolerance is the ability to provide service complying with the specification in spite of faults. Fault tolerance is achieved by error processing and by fault treatment.Error processing is aimed at removing errors from the computational state, preferably before a failure occurs. Error processing may be carried out either by error detection and recovery or by error compensation. Fault treatment is aimed at preventing faults from being activated again. Whereas error processing is aimed at preventing errors from becoming visible to the user, fault treatment is necessary to prevent faults from causing further errors. Fault treatment entails fault diagnosis, fault passivation, and, if possible, system reconfiguration to restore the level of redundancy so that the system is able to tolerate further faults. Fault diagnosis is the process of determining the cause of observed errors. Fault passivation is preventing diagnosed faults from being activated again.When designing a fault-tolerant system, it is important to define clearly what types of faults the system is intended to tolerate and the assumed behavior (or failure modes) of faulty components. If faulty components behave differently from what the system's error processin and fault treatment facilities can cope with, then the system will fail. In distributed systems, the behavior of a node can be defined in terms of the messages that faulty nodes send or do not send. The most common assumption about node failures is that nodes are fail-silent (also called crash failures). A crash failure occurs when a node stops sending out messages and when the internal state is lost. Value faults occur when the message arrives in time but contains the wrong content. A time fault includes delay and omission faults. A delay fault occurs when the message has the right content but arrives late. An omission fault occurs when no message is received.

AQuA

The Adaptive Quality of Service for Availability (AQuA) [3] project aims to provide fault tolerance to CORBA applications through software replication. Software replication means that a software process is instantiated in multiple locations throughout the system to tolerate faults in one or more of the instances (replicas). AQuA provides mechanisms to process errors and treat different types of faults. For many applications, fault tolerance is handled in an application-specific way. This often leads to embedding the code providing the fault tolerance within the code that achieves the functional requirements. As a result, there is an increase in development costs and development time. This is because software engineers have to develop code that is cognizant of the fact that it is replicated. The software engineers therefore have to be experienced in fault tolerance, an uncommon skill, and have to develop more code.

A CORBA Object Request Broker (ORB) simplifies development of distributed applications by automatically generating the code for communicating between remote objects based on a specification in the interface definition language (IDL). Similarly, AQuA aims to provide the code for achieving fault tolerance so that the application developer does not have to develop code that is cognizant of its fault tolerance. Since different applications need to tolerate different types and numbers of faults, AQuA provides the application developer a simple interface to specify the fault tolerance desired for the application.Many distributed applications have dynamic requirements. Consequently, the services provided to distributed applications also need to be dynamic. Therefore, another goal of AQuA is to provide fault tolerance that can be reconfigured dynamically at run-time.Additionally, it is not possible to assume that the system always has the resources available to provide the desired level of fault tolerance. Therefore, the AQuA system aims to adapt to changes in the system configuration while providing fault tolerance.The AQuA architecture is layered. The four layers, from top to bottom, are the CORBA application itself, Quality Objects, Proteus, and Maestro/Ensemble[6, 7]. Each layer only communicates with the layer immediately above or below it. The QuO layer provides the CORBA application with an interface to specify its fault tolerance requirements at a high level. Proteus aims to translate the high-level requirements of the application into a system configuration, provide fault tolerance, and adapt to changes inputted by the QuO layer and the Maestro/Ensemble layer. Maestro/Ensemble is a group communication system that provides services to Proteus to manage the system.

Other work has been done to provide dependability to distributed CORBA applications. The OpenDREAMS project [8] aims to provide software replication as a true CORBA service. The OpenDREAMS approach has the potential to become an official CORBA service, because it was built using CORBA communication and is therefore interoperable and heterogeneous. The approach can easily be used with any CORBA 2.0-compliant ORB to provide reliability and high availability. The Eternal project [9] takes the interception approach to providing dependable communication to CORBA applications. With the interception approach, CORBA invocations are intercepted before they leave a host. The intercepted messages are sent using reliable group communication and then delivered as CORBA invocations to the correct CORBA objects. Eternal uses a different underlying group communication system from AQuA (Totem) and has a goal of completely hiding fault tolerance from the application. Electra [10] is a specialized CORBA ORB that provides availability to CORBA applications. One drawback to this approach is that it does not allow the application developer to choose any CORBA ORB.AQuA takes an approach similar to Eternal, but has a different emphasis.

51due留学教育原创版权郑重声明：原创留学生作业代写范文源自编辑创作，未经官方许可，网站谢绝转载。对于侵权行为，未经同意的情况下，51Due有权追究法律责任。

51due为留学生提供最好的服务，亲们可以进入主页了解和获取新西兰essay代写的相关资讯 提供以及美国作业代写辅导服务，详情可以咨询我们的客服QQ:800020041哟。-xz