第 13 章 GIOP IIOP 和 IOR

1. 第13章 GIOP IIOP和IOR • 13.2 GIOP概述 CORBA规范将GIOP定义为它的基本的互用性框架。GIOP不是一个可以直接用于ORB之间进行通信的具体协议。相反，它描述了特定的协议如何进行创建以适用于GIOP框架。IIOP是GIOP的一种具体实现。GIOP规范主要有一下部分组成： (1) 传输假设：GIOP对执行GIOP协议的底层传输作了大量的假设 (2) 公用数据表示(CDR,Common Data Representation)。GIOP为每个IDL数据类型定义了一个连在一起的格式，这样始发者和接受者在数据的二进制布局中就取得了一致。 (3) GIOP定义了客户机和服务器通信使用的8种消息类型。只有两种用来实现远程过程调用。

2. 13.2.1 传输假设 • GIOP对用于传输消息的底层传输作了如下的假设： (1) 传输是面向对象连接的 (2) 连接是全双工的：可拒绝或接收 (3) 连接是对称的：都可关闭 (4) 传输是可靠的：没发送就返回错误 (5) 传输提供一个字节流抽象：大小不限制 (6) 传输混乱表示失去连接

3. 13.3 公共数据表示 • GIOP定义了一个公共数据表示，为了传输，它确定了IDL类型的二进制格式。CDR具有以下的主要特点： (1) CDR同时支持长字节和短字节表示：CDR编码的数据是标记指示数据的字节顺序。如果始发方和接收方使用不同的字节类型，接收方负责字节变换。这个模型，也称接收方更正模型(receiver makes it right), (2) CDR按照自然边界对齐原始的类型：数据通过存储在内存中数据的指针编组或解组成它的自然二进制表示。要由一些字节流部分填充。 (3) CDR编码的数据是非自识别的：CDR编码需要在始发方和接收方之间有一个关于要交换的数据类型的约定。 CDR编码是一种注重效率的折中方案。

4. 13.3.1 CDR数据对齐 • 原始定长度类型的对齐 • 字符串编码：字符串和宽位字符串编码为unsigned long它用来表示字符串的长度，包括它的终止NUL字节。 • 结构编码：结构按它们在IDL中定义的顺序编码为一个结构成员序列。每个结构成员都按照下表所示的规则进行对齐；为了保证对齐，插入未定义值的填充字节。 struct CD{ char c; double d;} 假定它的起始位置在字节流的头部。流的第一个字节，偏移量为0，它包含结构中成员c的值。接下来是7个填充字节，它的偏移量为1，从偏移量8开始，8个字节结构成员d。 c Padding d 0 1 8

5. CDR数据对齐 • 并非CD类型的结构总是16个字节值。结构的长度是否变化依赖于连接在一起的结构前面的其他数据。例如： interface foo{ void op(in string ss,in CD ds)}; 当客户程序编组一个请求来调用op时，它按照CDR编码规则首尾相连的发送所有的in参数。编码结构如下： 值“Hello”的编码占据10个字节；4字节是长度，6字节是实际的字符串。第二个参数是CD类型的结构，因为成员c是char类型，它可以在任何地方对齐，所以c的值就立即接着字符串进行编码，它的偏移量为10。结构d成员必须对齐到一个8字节的边界，这样接着c后就是一个5字节的填充，接下来的8字节由d占用。 6 Hello\0 c Padding d 0 4 10 11 16

6. 13.4 GIOP消息格式 • GIOP首先由CORBA2.0进行定义－2.1-2.3，因此GIOP的版本有三个1.0-1.1-1.2。在版本1.0中主要附加了对消息存储的支持，在1.2中增加了对双向通信的支持。 (1) 使用消息存储片可以更高效地将连在一起地数据编码。 (2) 双向通信对于通过防火墙进行的通信很重要。

7. GIOP消息格式 GIOP具有的8种消息类型如下： 消息格式 始发方 Request 客户机 Reply 服务器 CancelRequest 客户机 LocateRequest 客户机 LocateReply 服务器 ColseConnection 服务器 MessageError 客户机或服务器 FragMent 客户机或服务器

8. GIOP消息格式 • 客户机是打开一个连接的用户，服务器程序是接收该连接的一个用户，为了调用对象上的一个操作，客户机打开一个连接并发送一个Request消息。然后客户机等待来自连接的服务器程序的一个Reply消息。 • 为了通过线路传输一个GIOP消息，发送端发送一个消息头，接着是消息体。下图是一个GIOP消息的基本结构。消息头在伪IDL中进行描述。 12字节的GIOP消息头 变量长度GIOP消息体 0 12

9. GIOP消息格式 • 消息头的组成如下： (1) 消息头的头4个字节总是字符GIOP。 (2) 第4个和第5个是一个8位二进制数字，它是主和次版本号。下图的是GIOP1.1头部，所以主次都是1 (3) 第6个字节是一个标志字节。标志字节的最小有效位数表示其余的消息是长字节还是短字节编码：0为长。第二个有效位表示存储片，数值1表示这个消息是一个存储片，还有其他存储片紧跟着。0表示是一个完整的消息或者是存储片中最后的消息。 (4) 第7个字节表示消息类型。它的值是一个MsgType_1_1枚举类型之一的序数值。数值0表示一个为Request消息。 (5) 第8~11字节是一个4字节无符号值，它表示消息的大小(不计12个字节的头部)。这个值按标志字节的最小有效位所表示的长字节或短字节进行编码。 G I O P 1 1 0 0 4字节消息大小 0 1 2 3 4 5 6 7 8

10. Request消息格式 • 一个Request消息由三部分组成，依次是GIOP头，GIOP Request头和GIOP Request体。 Request头和Request体一起构成了GIOP体。 • Request头的字段如下： (1) service_context：这个序列包含服务数据，它是由ORB运行时默认地添加到每一个请求上的。主要是为了传输某些ORB服务所要求地信息。 12字节的GIOP头 Request头的变量长度 Request体的变量长度 0 12 12+Request头长度

11. Request消息格式 (2) request_id：这个字段由客户机使用，它用来将请求与它地响应相关联。Reply消息也具有一个request_id字段。 (3) response_expected：这个字段是一个Boolean值。对于一个正常同步请求它设置为真，也就是说客户需要对该请求的回答。 (4) reserved：这3个字节留作将来使用。 (5) object_key：是IOR的对象密钥，它用来调用请求。它标识请求所针对的服务器上特定的对象。 (6) operation：这个字符串包含被调用的操作名。 (7) requesting_principal：此字段表示使用BOA调用的客户机的身份。

12. Reply消息格式 • 只要请求的response_expected标志设为真，一个服务器程序就发送一个Reply消息以响应客户机的Request消息。Relply也由三部分组成： • GIOP头后面紧接着一个Reply消息，它由一个Reply头和Reply体组成，Reply体紧跟在Reply头后面。它们一起构成GIOP消息体。 12字节的GIOP头 Reply头的变量长度 Reply体的变量长度 0 12 12+Request头长度

13. Reply消息格式 • ReplyHeader的字段如下： (1) service_context：这个字段用于透明地传送ORB服务所要求的隐含的上下文信息，比如安全和事务处理 (2) request_id：此字段返回于客户请求相对应的ID (3)reply_status：此字段表示请求的结果 (4) No_EXCEPTION：表示请求成功的完成 (5) SYSTEM_EXCEPTION：服务器端ORB或服务器应用程序代码产生了一个系统异常 (6)USER_EXCEPTION：请求产生了一个用户异常 (7) LOCATION_FORWARD：这个应答表示请求不能被这个服务器程序处理，但是客户机应该在一个不同的地址上再次进行尝试。

14. 13.4.3 其它消息格式 • CancelRequest：使用这个请求，一个客户机可以通知服务器它已对一个操作的结果丢失了兴趣。 • LocateRequest：客户可以使用这个请求从一个对象中获得当前的地址信息。 • LocateReply：这是服务器程序响应LocateRequest消息传送的一个应答。它们两个可以降低定位对象的开销。 • CloseConnection：一个来自服务器程序的CloseConnec-tion消息可通知客户机该服务器程序准备关闭该连接。 • MessageError：传送这个消息是为了响应在某些方面畸变的任何GIOP消息。 • FragMent：如果一个GIOP1.1客户机决定以存储片方式发送消息，第一个存储片是用存储片标志设置为真的Request消息。

15. 13.5 GIOP连接管理 • CORBA客户机和服务器所见到的交互模型是无连接的；当一个客户机需要时，它只是简单地发送一个请求，该请求将会调用服务器程序上的一个虚函数。客户机和服务器应用程序代码都未曾打开会关闭一个连接。但是，GIOP请求在一个面向连接的传输上被调度，这样CORBA运行时环境必须以客户机和服务器名义来负责管理连接。CORBA规范并不要求ORB的任何特定的连接管理策略。相反，GIOP只是确定了足够的连接管理以允许实现之间的互用性，并且它在协议中提供了足够的挂钩允许ORB供应商在简单的和复杂的连接管理策略之间进行选择。

16. 13.7 IIOP综述 • GIOP指定了客户机和服务器之间进行通信所必需的大部分协议细节。GIOP与具体的传输无关，它是一个抽象的协议，而IIOP明确为TCP/IP，它是GIOP的一个具体实现。为了将GIOP转换为一个具体的协议，IIOP只需要指定IOR的编码。一个IOR由三部分组成：仓库ID，终点信息和对象密钥。IIOP只是指定一个IOR如何编码在一个IOR内的TCP/IP寻址信息，这样客户机就可以建立一个到服务器程序的连接来发送一个请求。 • 在IIOP中有一个结构体ProfileBody_1_1，此类型的结构完全能识别一个请求的目标对象：可以找到宿主和端口号在哪一个服务器上，并且请求是针对这个服务器上的对象。

17. IIOP综述 • 此结构中的字段说明： (1) iiop_version字段表示协议的版本信息 (2) host和port字段指定了哪一个服务器上的宿主和端口号监听请求。宿主可以编码为十进制数加上点号的形式(比如234.234.234.234)或一个宿主名(如acme.com) (3) object_key字段是一个八位字节序列，它用来识别具体的目标对象。 (4) componects字段包含一个标记组件序列(只对于IIOP1.1)。每一个标记组件是一个包含两个字段的结构。第一个字段标记字节类型，第二个字段包含组件的数据。 一个ProfileBody_1_1类型的结构只应用于IIOP并对一个客户机如何定位一个请求的目标对象进行编码。

18. IOR的结构 • CORBA使用可互用的对象引用作为识别一个对象的通用手段。对象引用对客户端应用程序代码来说是不透明的，并且完全封装了发送一个请求所必需的内容，包括使用的传输和协议。 • IIOP是CORBA使用的主要的可互用的协议，并且每个ORB声称支持互用性都必须支持IIOP，CORBA还规则定了另一种协议，即DEC Common Inter-ORB Protocol (DEC-CIOP)。该协议是可选的，并且它使用DEC－RPC作为它的传输。IOR可以扩展为含有将来协议的协议信息。 • 一个IOR还可以包含多个相同协议的配置文件。因此可进行选择，则就提供了负载平衡。 Repository ID Data for protocol 1 Data for protocol 2 ... Data for protocol n 一个IOR的主要结构

19. 13.9 双向IIOP • 为了支持双向通信，CORBA2.3中添加了GIOP1.2和IIOP1.2。这样客户机和服务器就可以转换角色而不需要打开一个可能被防火墙阻塞的独立的连接。

20. 第14章 实现仓库和绑定 • 14.2 绑定模式 通常，ORB支持两种绑定模式：直接绑定和间接绑定。所有的ORB都支持直接绑定。间接绑定与一个外部定位代理有关，这个外部定位代理也就是实现仓库，它是CORBA的一个可选组件(大多数通用的ORB都有一个实现仓库)。 • 直接绑定和间接绑定都是协议指定的，具体来说，嵌入在一个IOR中的寻址信息与所使用的传输有关。

21. 14.3 直接绑定 • 每当一个服务器应用程序创建一个对象引用时，服务器端运行时就将支持绑定的信息嵌入在对象引用中。尤其是，一个IOR包含一个IP地址(或主机名)、TCP端口号和一个对象密钥。如果一个服务器将自己的地址和端口号插入到一个引用中，该引用就使用直接绑定。 • 一个ORB可以对暂态引用和持久引用直接绑定。只要与它关联的POA存在，一个暂态IOR将持续地工作。在撤消该POA或它的服务器程序关闭后，一个暂态引用就永久失去功能；它再也不会工作，即使它的POA重新被创建或它的服务器程序重新启动。相反，一个持久地IOR将持续地代表一个对象，即使它的服务器程序关闭和重新启动。

22. 14.3.1 暂态引用地直接绑定 • 暂态引用总是依赖于直接绑定。当一个服务器程序使用一个具有TRANSIENT生命范围策略地POA创建一个POA时，服务器端运行时将绑定信息嵌入到IOR中。 (1) 配置文件中的地址和端口号设置为服务器自身的地址和端口号。 (2) IOR的对象密钥设置为包含两个元素。 1. 用于创建IOR的POA名称：暂态POA必须有一个名称，这个名称在一个ORB域中的所有其他的POA的空间上是唯一的。为此ORB可以使用一个通用唯一标识符(universally unique identifier,UUID)来确定任何一个暂态POA都唯一。 2.在相关联的POA范围内唯一的一个对象ID。

23. 暂态引用地直接绑定 • 当一个客户程序接收到一个暂态引用并调用第一个请求时，客户端运行时从IOR的配置文件中提取出地址和端口号，并尝试打开一个连接。打开这个连接的尝试可能会遇到如下几种情况。 (1) 服务器程序运行在引用指定的主机和端口号上 (2) 在该引用所指定的主机和端口号上没有进程在监听 (3)创建该引用的原始服务器程序已经关闭，在同一端口号上，与原始服务器程序相同的另一服务器程序已经开始运行。 (4) 原始的服务器程序已经关闭但稍后重新启动，并且碰巧获得了相同的端口号。

24. 14.3.2 持久引用的直接绑定 • 一个ORB有许多不同的选项用于如何生成持久的对象引用。最简单的机制依赖于直接绑定。 • 当一个服务器程序使用一个具有PERSISTENT生命范围策略的POA创建一个引用时，该ORB运行时为IOR创建包含服务器程序的地址和端口号的配置文件。但是，因为该引用使用一个持久的POA，ORB就不向它的名称添加一个UUID以保持名称的唯一性。相反，当它创建该POA时，它使用由应用程序指定的POA名称。 • 持久引用的直接绑定依赖于以下几个方面： (1) 当创建POA时，服务器程序必须总是对相同的POA使用相同的名称。 (2) 当它为该对象创建一个IOR时，服务器程序必须总是对一个具体的CORBA对象使用相同的对象ID。 (3) 服务器程序必须总是以相同的主机和端口号启动。

25. 持久引用的直接绑定 • 当创建一个POA或一个IOR时，通过使用相同的POA和对象ID就可以很容易地满足前面两条。的三条没有规定，因此就需要指导服务器程序如何从ORB到ORB地变化总是以相同地主机和端口号。通过ORB_init，服务器运行时可以知道端口，所以运行时可以将服务器安排到一个特定地端口。一些ORB还允许使用一个配置应用程序来存储服务器程序应该使用地端口号。 • 持久引用地直接绑定是简单有效，但还有些缺陷： (1) 不能用一个不同地主机启动一个服务器程序而不断开客户机拥有的引用与服务器程序上的持久对象之间的连接。 (2) 服务器程序必须在一个固定的端口号监听请求，该端口号只能赋给服务器程序一次，此后该端口号不能在不断开引用的情况下进行更改。 (3) 当一个客户机发送一个请求时，服务器程序必须运行。否则失败。

26. 14.4 通过实现仓库的间接绑定 • 间接绑定解决了与持久引用的直接绑定相关的问题，它是以稍微降低从客户机到服务器程序的第一次请求的性能为代价来实现的。 • 14.4.1 实现仓库的标准一致性 CORBA规范没有标准化实现仓库，它只是建议了一些供应商可以用来实现的函数。 (1) 实现仓库是与它们所使用的平台密切相关的。 (2) CORBA规范允许ORB的实现适用于从嵌入式系统到全球性的企业系统各种环境。 (3) 一些特性，比如对象迁移、可扩展性、性能和负载平衡都与实现仓库有关。

27. 14.4.2 实现仓库结构 • 实现仓库具有如下的职责： (1) 它维护一个已知的服务器程序的注册表 (2) 它记录在哪一个主机以及哪一个端口号上哪一个服务器程序当前正在运行。 (3) 如果它们用自动启动注册，它就按要求启动服务器程序。 每一个实现仓库运行时必须像一个监听固定主机和固定端口号上请求的过程一样。此外，实现仓库必须永久地运行，实现仓库是守护进程，通常由一个启动脚本在引导时启动。 为了跟踪服务器程序，实现仓库维护一个数据结构，也就是服务器程序表。

28. 实现仓库结构 • 一个实现仓库地服务器程序表 逻辑服务器名 POA名 启动命令 主机和端口号 CCS2 the lzw.guali.com:1700 CCS ther lzw.guali.com:1700 CCS con rsh lzw/opt/CCS/CCS-svr lzw.guali.com:1799 NameService ns_poa /opt/myorb/bin/name_svr-v Payroll PR_V1 l1:guali.com:1233 Stock dept_1 Stock dept_2

29. 实现仓库结构 • 对于每一个服务器程序，实现仓库记录如下： (1) 逻辑服务器名：逻辑服务器名标识我们认为什么是一个“服务器”。也就是说，当它被实例化为一个运行进程时，它标识为实现一个或多个POA的一个进程 (2) POA名：在绑定期间，POA名起到了表中的主关键字的作用，而逻辑服务器名主要起到一个服务器的所有信息的管理句柄的作用，POA名在对象引用中出现，并且它标识了在什么地址可找到它的服务器。 (3)启动命令：如果一个客户程序调用一个请求时，服务器程序并没有在运行，启动命令记录了一个服务器程序如何按要求进行启动。单个的逻辑服务器可以使用几个POA。因此也就可以只注册一个启动命令。启动命令注册是一个可选项。如果没有，就必须手工启动。 (5) 主机和端口：该列记录了当前正在运行的服务器程序的地址。在此类中没有的项表示该服务器程序当前是关闭的。

30. 14.4.3 定位域 • 对于持久引用使用间接绑定的每个服务器程序必须知道在何处可以找到它的实现仓库。依赖于ORB通过环境变量、配置文件或命令行选项，服务器程序定位实现仓库。最主要的一点是，每一个服务器程序知道它的仓库的主机和端口号。 • 定位域是机器或服务器进程组，在相同的定位域中的所有机器或服务器程序进程创建的对象引用通过相同的仓库进行绑定。

31. 14.4.5 通过实现仓库的绑定 • 当一个服务器程序创建一个持久引用时，在它的IOR配置文件中设置了地址和端口号，以便暗示实现仓库负责服务器程序，服务器程序通过在它的配置信息中查找就可以知道使用哪一个主机和端口号。此外，通常IOR包含POA名和对象ID。 • 当一个客户第一次使用IOR时，它就尝试打开一个与它在配置文件中找到的主机和端口号的连接。对于间接绑定，主机和端口号是实现仓库。 • 如果客户成功的连接到实现仓库，它就可以简单地发送由应用程序调用的请求，实现仓库不能处理该请求，因为实际的目标对象存在于一个不同的服务器过程中。但是，因为服务器程序和实现仓库使用了相同的ORB，实现仓库知道如何解码有客户发送过来的请求中的对象密钥。仓库接下来从对象密钥中取出POA名，并将它作为它的服务器程序表的一个索引。

32. 通过实现仓库的绑定 • 如果POA名不能在服务器程序表中找到，目标服务器程序会仓库来说是完全未知的。OBJECT_NOT_EXIST • 如果POA名是已知的，但对应的伺服程序没有运行，并且没有一个注册的自动启动命令行，仓库返回一个TRANSIENT异常给客户。 • 如果POA名是已知的，并且对应的服务器程序没有运行，但注册了一个命令行，仓库通过执行命令启动该服务器程序进程。 • 如果服务器程序正在运行，仓库返回一个LOACTION_FORWARD值为reply_status的Reply消息给客户。

33. 通过实现仓库的绑定 • 假设实现仓库运行在机器coco的端口2133上，并且当客户调用请求时，CCS服务器程序没有运行。绑定的步骤如下： (1) 客户机调用控制器上的find操作。找仓库的地址。 (2) 仓库使用POA名在它的服务器程序表中进行索引，并发现该服务器程序没有运行(有注册命令)。 (3) 服务器程序发送消息告诉仓库它的机器名(coco),它创建的POA名和它们的端口号，并且它现在准备接收请求。 (4) 实现仓库构造一个新的引用对象，在该对象引用中包含主机coco、端口号2133和原始对象密钥 (5) 客户机打开一个到端口2133上的coco连接，并第二次发送请求 (6) 服务器程序使用POA名来定位包含该请求伺服程序的POA。 (7) 该伺服程序完成find操作并返回它的结果，将该结果在一个Reply消息中编组返回给客户。

34. 14.4.6 绑定优化 • 显式定位解决方案：一个客户机可以通过发送一个LocateRequest消息来显式解决一个服务器程序的定位问题。 • 避免间接绑定：通过实现仓库的间接绑定可能会大大降低系统的性能。 • 高速缓存服务器程序的出生地址：出生地址优化降低了实现仓库的负荷，尤其是如果服务器程序是长生命周期的。 • 服务器程序和实现仓库之间的专用协议：一些ORB在服务器程序和仓库之间使用一个基于UPD的协议。简化了配置，也提供了简单的容错，同时使用UPD与仓库进行通信还可能更有效，因为UPD与IIOP相比开销更小。 • 负载平衡：一些仓库提供了简单的负载平衡。

35. 14.6 激活模式 • 激活模式如下： (1) 共享激活：对同一服务器程序上的对象的所有请求直接指向同一单个服务器程序进程 (2) 每个客户机激活：仓库创建与不同客户进程一样多的服务器程序进程。 (3) 每个用户激活：仓库为每个访问服务器程序的不同用户创建一个新的服务器程序进程。 (4) 每个请求激活：使用这种激活模式，不管来自任何的每个请求都会产生一个新的服务器程序进程。 (5) 持久激活：使用这种激活模式，在仓库自身启动后，需要连续运行的服务器程序由实现仓库立即启动。

36. 14.7 竞争状态 • 14.7.1 激活期间的竞争状态 一个具有多个POA的服务器程序使用共享激活模式时，在激活期间就可能产生竞争状态。 • 14.7.2 关闭期间的竞争状态 服务器程序事件一旦终止，该服务器程序就不再接收请求，所以现实仓库必须为来自客户机的新的请求启动另一个服务器程序实例，这就产生了一种潜在的竞争状态。 • 14.7.3 服务器程序关闭和重新绑定 当一个服务器程序事件循环终止后，向每一个连接发送一个CloseConnection消息后，服务器端运行时关闭所有打开的连接。CloseConnection消息通知客户机在它们向该服务器程序发送更多的请求前必须使用实现仓库进行重新绑定。在这种情况下，就有可能产生竞争。

37. 14.8 安全性考虑 • 14.8.1 服务器程序的权限 实现仓库如何启动服务器程序进程，取决于不同的ORB。 • 14.8.2 远程仓库访问 一个典型的实现仓库提供了两个远程接口。一个接口由客户机用于绑定。另一个接口通常由管理命令使用。 • 14.8.3 通过防火墙的IIOP 在一个固定的端口号启动服务器程序并且据此配置你的防火墙(许多仓库允许为每个服务器程序设计一个端口号)。

38. 第15章 any类型的C++映射 • any类型与C中的void *比较如下： 经常将any类型与C中的void *进行比较。像一个指向void的指针一样，一个any值可以表示任何类型的数据。但是，有一个重要的差别：void *说明一个完全无类型的值，它只可以由它类型的先验知识进行解释，而any类型值保持类型安全。比如，如果发送方将一个字符串值放到一个any中，接收方就不会作为一个错误类型值提取出字符串。将any的内容处理为一个错误类型的尝试会产生一个运行时错误。

39. any类型的C++映射 • 基本类型插入 为了将一个基本IDL类型插入到any，可使用重载<<=插入运算符。例如： CORBA::Any a a<<=(CORBA::UShort)99;//插入一个无符号的短整型99 a<<=“Hello”;//插入深层次拷贝的“”Hello a<<=(CORBA::Double)3.14;//释放“Hello”，插入3.14 向any中插入一个值要进行两件事情：它将该值的一个拷贝存储到Any，并且它将any中的类型代码设置为插入值的类型代码。这意味着类型转换是必须的。 a<<=99;//错误

40. any类型的C++映射 • 基本类型的提取 为了提取基本类型，C++映射提供了重载>>==运算符。提取运算符期望一个数值的引用作为右端参数并返回一个Boolean量。当对一个any类型值使用提取运算符时，提取运算符检查any中的类型代码是否与它右端操作数的类型相匹配。如果匹配，则运算符提取该值并返回真。否则，提取失败，并返回假。

41. any类型的C++映射 例如：下面的代码中使用assert宏来测试提取是否成功和提取出的值与原始插入的值是否匹配。 CORBA::Any a as<<=(CORBA::Long)99; // 插入长整型99 CORBA::Long val; assert(a>>=val); // 返回真 assert(val= =99); //测试通过 CORBA::Short val1; Assert(!a>>=val); //提取操作返回假