27、CORBA与DSA对比及Ada扩展实验

CORBA与DSA对比及Ada扩展实验

1. 异常处理与服务架构

在分布式系统中，异常处理和服务架构是关键的部分。对于异常，如果上游调用者能看到异常，就必须能通过异常名称捕获它。这意味着PCS（分区通信子系统）要能识别未知异常并映射到本地已知异常，比如可动态将新异常注册到运行时环境。

CORBA采用了更分散的服务架构，服务基本是外部定义的。例如命名服务，它将对象名称映射到对象引用，是一个具有标准IDL接口的分布式对象。这种方式看似纯粹，但有性能缺陷。命名服务本身是分布式对象，无法针对特定ORB（对象请求代理）的需求进行优化。而且ORB要定位命名服务自身存在“鸡与蛋”问题，程序员要获取分布式对象的引用（IOR），首先得有命名服务的IOR，该IOR可根据CORBA版本从命令行、文件或调用ORB接口获取。

在异常传播方面，ORB不能传播IDL接口中未声明的异常。虽然这限制了异常的使用，但考虑到CORBA的多语言特性，这种限制是可以理解的。比如当C++异常到达用Ada编写的调用者时，就需要特殊处理。不过，实现时可在CORBA异常消息中提供更多信息，如C++或Ada异常名称。

2. 应用开发

• DSA应用配置 ：DSA（分布式系统附件）未描述分布式应用的配置方式，由用户使用分区工具（其规范不在相关范围内）定义程序分区以及分区在哪些机器上执行。
• GLADE工具 ：GLADE提供配置工具和分区通信子系统来构建分布式应用。GNATDIST工具及其配置语言可让用户对程序进行分区并指定分区执行的机器。GARLIC（通用Ada分区间通信可重用库）是高级通信库，用面向对象技术实现参考手册中定义的分区通信子系统与网络通信层之间的接口。
• CORBA服务 ：CORBA的ORB提供一组核心基本服务，其他服务由具有IDL的对象提供。OMG（对象管理组织）对一些有用服务进行了标准化，如命名、交易、事件、许可、生命周期等服务。CORBA供应商可自由实现这些服务。命名服务可将对象引用与用户友好名称关联，事件服务让服务器和客户端通过匿名对象间的异步事件进行交互。

3. CORBA与DSA对比

特性	CORBA	DSA
框架特点	优秀且流行，IDL语法接近C++，对象模型接近Java，仅定义分布式对象	提供更通用模型，包括分布式对象、常规远程子程序和远程子程序引用
语言相关	使用时需处理生成的代码，要理解宿主语言映射，使用预定义CORBA类型，修改IDL文件后需重新适配代码	Ada 95本身就是IDL，无需处理生成的存根或骨架代码，配置环境自动更新相关文件
异常处理	ORB不能传播IDL接口未声明的异常	异常模型完全保留
类型使用	有一定限制	除访问类型外任何Ada类型都可使用，可通过提供编组操作解决访问类型问题
功能特性	不允许重载	允许重载，可定义通用包并使用混合机制实现多重继承
开发调试	学习曲线高，有性能限制、缺乏可移植性和安全性	用户可在非分布式环境设计、实现和测试应用，再切换到分布式环境，使用pragma All Calls Remote便于在非分布式环境调试
互操作性	实现Common Data Representation（CDR）确保异构系统间安全通信	RM不要求在异构系统工作，GLADE提供类似XDR的编组操作，可因性能原因禁用

4. 互操作性与服务实现

目前DSA编译器间的互操作性不是问题，因为只有GLADE一种实现。但允许用户用第三方PCS替换当前PCS是验证要求，CORBA直到2.2版本才解决此问题，预计未来DSA实现会确保PCS兼容性。

OMG用IDL描述了分布式系统常用的一些通用对象服务（COS），但这些规范多限于IDL描述，大部分语义由供应商决定。DSA缺少用户级库，包括基本分布式软件组件，这也是Ada一直存在的组件库缺乏问题。

将CORBA服务实现为原生Ada 95分布式对象，利用标准语言特性，可得到更简单、易理解和使用的规范。已用DSA实现了命名服务、事件服务和类似并发服务。开发CORBA服务时发现，尽管IDL文件对服务有很好的规范，但语义模糊，严重影响可移植性。

GLADE团队的另一个主要目标是将DSA服务导出到CORBA世界，通过ASIS将DSA特性转换为等效的IDL特性，让DSA用户可将DSA服务器连接到ORB，也让其他语言编写的应用能调用DSA特性，还尝试为DSA提供DII机制。

5. DSA服务面向CORBA用户

5.1 目标

目前以RT或RCI包实现的服务只能通过DSA机制（远程过程调用和分布式对象）从其他Ada 95代码调用，这限制了DSA在实现分布式服务时的应用范围。为推广Ada 95作为创建分布式服务的竞争平台，要让CORBA应用成为DSA服务的客户端，这需要：
- 自动化工具从DSA包声明生成IDL规范，供CORBA客户端开发者生成调用DSA包导出服务的存根。
- 必要的接口代码，将CORBA请求映射到Ada原语操作调用，该代码要复制到实例化DSA包的每个程序分区，使分布式对象实例能接收来自CORBA软件总线的方法调用请求。

5.2 从DSA规范到IDL文件

ASIS是开放、已发布且与供应商无关的API，用于CASE工具与Ada编译环境交互，定义了工具从编译环境提取已编译Ada代码信息所需的操作。

我们打算用ASIS API和兼容ASIS的编译环境从DSA包声明生成IDL接口规范。ASIS接口让工具开发者利用编译器的解析功能，方便访问编译器根据包规范构建的语法树。

具体步骤如下：
1. 获取Remote Types包中声明的Remote Access to Class-Wide（RACW）类型列表，这些类型代表分布式对象。
2. 检索对应类的属性和原语操作，并将它们转换为IDL接口规范，一个IDL模块对应一个DSA包，一个IDL接口对应一个RACW。
3. 尽可能按照Ada和CORBA构造的标准映射进行转换。
4. 定义RCI或RT包中允许的所有语言构造到IDL构造的映射，开发自动化工具将DSA包声明转换为IDL接口规范，用ASIS与兼容编译系统交互，确保工具与底层环境实现的独立性。

5.3 绑定DSA实体与CORBA

为让CORBA客户端能调用DSA服务，需在运行时将CORBA请求转换为DSA方法调用，采用两步方法：
1. 用传统ORB软件生成Ada的CORBA服务器骨架。使用前面提到的自动化工具生成的IDL定义和现有的IDL转换器，生成Ada的CORBA骨架。在骨架中实现CORBA请求处理，将其作为对DSA对象原语操作的调用。每个Remote Types包实例都伴随一个骨架代码实例，作为CORBA服务器，为CORBA软件总线上的所有客户端提供对本地DSA对象实例的访问。
2. 映射DSA地址空间（RACW，即胖指针）到CORBA地址空间（CORBA对象引用），使每个DSA对象实例在CORBA地址空间可被引用。客户端根据生成的IDL定义向关联的CORBA对象发送请求以获取DSA对象的服务。

我们还将提供自动代码生成工具，生成将CORBA请求映射到DSA对象原语调用的“胶水”代码，以及与底层ORB接口所需的适配代码，包括Ada数据类型到CORBA类型的映射，以及DSA胖指针到CORBA对象引用的转换。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[CORBA客户端]:::process -->|请求| B[CORBA服务器骨架]:::process
    B -->|映射| C[DSA对象]:::process

5.4 使用DSA实现DII

CORBA的接口存储库服务允许客户端在运行时从接口存储库检索方法签名，并使用DII机制调用编译时未知规范的方法。DSA未定义类似机制，但可通过RCI包作为DSA接口存储库、ASIS工具自动化服务注册过程和实用程序包动态构建请求来提供类似服务。

接口存储库是简单的RCI服务器，提供两种服务：
- 为DSA服务提供者（其他RCI或远程类型包）提供注册接口的方式，包括一组原语操作名称及其签名。
- 为客户端提供根据分布式对象引用检索其原语操作描述的方式。

ASIS极大简化了服务器端的注册过程，使用ASIS可自动遍历DSA服务器包的规范，生成对接口存储库注册函数的相应调用。注册完成后，接口信息被存储库知晓。例如，分布式对象原语操作注册后，客户端即使编译时对对象一无所知，也可根据访问值检索其原语描述，且在语义上不依赖服务器规范。

最后，一个函数根据从存储库检索的接口描述和客户端提供的实际参数构建请求消息，通过PCS发送到服务器，就像编译器在“静态”服务调用中生成的正常远程调用一样。除生成的注册函数外，服务器端无需特定的IR或DII代码，从服务器角度看，动态构建的请求与传统静态请求处理方式相同。动态接口发现和调用机制局限于DSA接口存储库和客户端动态请求构建库。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[客户端]:::process -->|获取接口描述| B[DSA接口存储库]:::process
    A -->|提供参数| C[请求构建函数]:::process
    B -->|接口描述| C
    C -->|请求消息| D[PCS]:::process
    D -->|发送请求| E[DSA服务器]:::process

6. Ada扩展实验 - Drago与GNAT修改

GNAT（GNU NYU Ada Translator）是Ada 95的前端和运行时系统，由编译器（通过运行时生成目标代码）、绑定器（验证要组装对象的一致性并确定程序单元的有效详细顺序）和链接器（将所有对象组合成一个可执行文件）组成。

编译器前端用Ada 95编写，使用GCC后端作为可重定位代码生成器，包括五个阶段，通过紧凑的抽象语法树（AST）进行通信：词法分析阶段、语法分析阶段、语义分析阶段、扩展阶段（树转换生成接近C的树）和GIGI阶段（将树转换为GCC树）。

Drago是作为Ada扩展开发的实验性语言，用于构建容错分布式应用。其硬件假设为：分布式系统中各节点无共享内存、可靠通信网络无分区、节点故障后不再被系统其他部分感知。该语言是对Isis通信工具包主要概念施加约束并提供语言支持的成果，同时用于实验组通信范式。为帮助构建容错分布式应用，Drago明确支持两种进程组范式：
- 复制进程组：允许…（原文此处未完整描述）
- 合作进程组

为在Drago上进行实验，对GNAT的扫描器、解析器和语义分析器进行了修改，但具体修改细节未在本文详细展开。

通过以上对CORBA与DSA的对比分析，以及Ada扩展Drago和GNAT修改的介绍，我们可以看到不同技术在分布式系统开发中的特点和应用场景。对于开发者来说，可根据具体需求选择合适的技术和工具，以实现高效、可靠的分布式应用开发。

CORBA与DSA对比及Ada扩展实验

7. 技术选择建议

在选择使用CORBA还是DSA进行分布式系统开发时，开发者需要综合多方面因素进行考量。以下是根据上述对比分析给出的一些技术选择建议：

考量因素	CORBA适用场景	DSA适用场景
语言兼容性	当需要实现多语言之间的互操作性时，CORBA是更好的选择。它的多语言支持特性可以让不同语言编写的组件在分布式系统中协同工作	如果开发团队主要使用Ada 95进行开发，并且希望在熟悉的Ada环境中完成分布式应用的设计、实现和测试，DSA会更合适。DSA基于Ada 95，开发过程更加自然流畅
性能要求	如果对性能要求不是极高，并且更注重服务的标准化和通用性，CORBA的服务架构可以提供丰富的标准服务供选择	当性能是关键因素时，DSA可能更具优势。它的分布式边界更透明，减少了不必要的开销，并且可以根据需要禁用编组操作以提高性能
开发难度	开发团队有足够的时间和资源来学习复杂的CORBA标准，并且对分布式系统开发有较高的技术水平，能够应对CORBA的高学习曲线	对于希望快速开发分布式应用，并且希望在开发过程中能够方便地进行调试和修改的团队，DSA的两阶段设计方法和简单的开发流程更具吸引力
组件库需求	如果需要使用大量的通用对象服务（COS），并且希望这些服务有标准化的接口，CORBA的标准化服务可以满足需求	如果应用对组件库的依赖较小，或者开发者希望自己实现特定的服务，DSA的灵活性允许开发者根据需要定义和实现服务

8. 未来发展趋势

随着分布式系统的不断发展，CORBA和DSA也可能会有不同的发展趋势：

• CORBA ：虽然CORBA已经是一个成熟的标准，但它的复杂性和性能问题可能会限制其在一些新兴领域的应用。未来，CORBA可能会在一些对兼容性和标准化要求较高的传统行业继续发挥作用，同时也可能会进行一些优化和改进，以提高其性能和易用性。
• DSA ：由于DSA基于Ada 95，并且具有简单、灵活的特点，它可能会在Ada社区中得到更广泛的应用。随着Ada语言在安全关键系统和嵌入式系统中的应用不断增加，DSA有望在这些领域发挥更大的作用。同时，GLADE团队将DSA服务导出到CORBA世界的努力，如果取得成功，将进一步扩大DSA的应用范围。

9. 总结

本文对CORBA和DSA在分布式系统开发中的应用进行了全面的对比分析，同时介绍了Ada扩展Drago以及对GNAT前端的修改实验。

• CORBA ：提供了一个优秀且流行的框架，具有多语言互操作性和丰富的标准化服务，但存在性能缺陷、学习曲线高和可移植性问题。
• DSA ：提供了更通用的模型，基于Ada 95，开发过程简单，异常处理和类型使用更灵活，适合在Ada环境中进行分布式应用开发。
• Drago ：作为Ada的扩展，为构建容错分布式应用提供了新的思路和方法，通过对GNAT的修改可以在该语言上进行实验。

开发者在选择技术时，应根据项目的具体需求，如语言兼容性、性能要求、开发难度和组件库需求等，综合考虑CORBA和DSA的特点，做出合适的选择。同时，随着技术的不断发展，我们也期待CORBA和DSA能够不断改进和创新，为分布式系统开发带来更多的可能性。

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A[项目需求分析]:::process -->|多语言互操作| B[选择CORBA]:::process
    A -->|主要使用Ada 95| C[选择DSA]:::process
    A -->|高性能要求| C
    A -->|低学习曲线| C
    A -->|依赖通用服务| B
    A -->|自定义服务需求| C

10. 实践案例分析

为了更好地理解CORBA和DSA在实际应用中的表现，下面通过两个简单的实践案例进行分析。

10.1 CORBA实践案例

假设我们要开发一个分布式电商系统，该系统由多个不同语言编写的组件组成，包括前端的Java界面、后端的C++业务逻辑和数据库的Python管理模块。由于需要实现多语言之间的互操作性，我们选择使用CORBA。

开发步骤如下：
1. 定义IDL接口 ：根据系统的功能需求，定义各个组件之间的接口，使用IDL语言进行描述。
2. 生成存根和骨架代码 ：使用CORBA的IDL编译器，根据IDL接口生成各个语言的存根和骨架代码。
3. 实现组件逻辑 ：在各个语言中实现组件的具体逻辑，并使用生成的存根和骨架代码进行通信。
4. 配置和部署 ：配置CORBA的ORB和命名服务，将各个组件部署到不同的服务器上。

通过使用CORBA，我们可以方便地实现不同语言组件之间的通信和协作，提高系统的可扩展性和维护性。

10.2 DSA实践案例

假设我们要开发一个嵌入式分布式控制系统，该系统主要使用Ada 95进行开发，对性能和实时性要求较高。我们选择使用DSA。

开发步骤如下：
1. 设计分区 ：根据系统的功能和性能要求，设计系统的分区，确定各个分区的功能和运行位置。
2. 定义服务包 ：使用DSA的RCI和RT包定义各个分区之间的服务接口。
3. 实现服务逻辑 ：在各个分区中实现服务的具体逻辑，并使用DSA的远程过程调用机制进行通信。
4. 配置和调试 ：使用GNATDIST工具配置系统的运行环境，进行调试和测试。

通过使用DSA，我们可以在熟悉的Ada环境中进行开发，充分发挥Ada语言的优势，同时利用DSA的分布式特性实现系统的高效运行。

通过以上两个实践案例可以看出，CORBA和DSA在不同的应用场景中都有各自的优势，开发者应根据具体需求选择合适的技术。