通用对象请求经纪架构
缩写 | 科尔巴 |
---|---|
地位 | 出版 |
年开始 | 1991 |
最新版本 | 3.4 2021年2月 |
组织 | 对像管理组 |
网站 | corba.org |
公共对象请求经纪架构( CORBA )是由对像管理组(OMG)定义的标准,旨在促进在不同平台上部署的系统的通信。 CORBA可以在不同操作系统,编程语言和计算硬件上进行系统之间的协作。 Corba使用面向对象的模型,尽管使用CORBA的系统不必以对象为导向。 CORBA是分布式对象范式的一个例子。
概述
CORBA启用以不同语言编写的软件和在不同计算机上运行的软件之间的通信。来自特定操作系统,编程语言和硬件平台的实施详细信息都从使用CORBA的开发人员的责任中删除。 Corba将位于同一地址空间(应用程序)或远程地址空间(同一主机或网络上的远程主机)中的应用程序对象之间的方法通话语义归一化。 1.0版于1991年10月发布。
Corba使用接口定义语言(IDL)指定对象存在于外部世界的接口。然后,Corba指定了从IDL到C ++或Java(例如C ++或Java)的映射。对于ADA , C , C ++ , C ++ 11 , Cobol , Java , Lisp , PL/I , Object Pascal , Python , Ruby和Smalltalk存在标准映射。对于C# , Erlang , Perl , TCL和Visual Basic的非标准映射存在由对象请求经纪人(ORB)为这些语言编写的。 IDL版本的变化很大,随着注释取代一些布拉格斯。
CORBA规范规定,应用程序将通过该球与其他对象相互作用。这就是实践中实施的方式:
- 该应用程序初始化了球体,并访问内部对象适配器,该适配器维护参考计数,对象(和参考)实例化策略和对象寿命策略。
- 对象适配器用于注册生成的代码类的实例。生成的代码类是编译用户IDL代码的结果,该代码将高级接口定义转换为OS和语言特定的类基础,以供用户应用程序使用。为了强制执行CORBA语义并提供与Corba基础架构接口的干净的用户流程,这是必要的。
某些IDL映射比其他IDL映射更难使用。例如,由于Java的性质,IDL-JAVA映射非常简单,并且使Corba在Java应用程序中的使用非常简单。 IDL到Python映射也是如此。 C ++映射要求程序员学习早于C ++标准模板库(STL)的数据类型。相比之下,C ++ 11映射更易于使用,但需要大量使用STL。由于C语言不是面向对象的,因此IDL到C映射需要C编程器手动模拟面向对象的功能。
为了构建使用或实现基于CORBA的分布式对象接口的系统,开发人员必须获取或编写将面向对象的接口定义为系统将使用或实现的逻辑的IDL代码。通常,ORB实现包括一个称为IDL编译器的工具,该工具将IDL接口转换为目标语言,以在系统的该部分中使用。然后,传统编译器编译生成的代码以创建用于应用程序中的可链接对象文件。该图说明了如何在Corba基础架构中使用生成的代码:

该图说明了使用Corba的远程解释通信的高级范式。 CORBA规范进一步解决了数据键入,异常,网络协议,通信超时等。例如:通常服务器端具有便携式对象适配器(POA),将调用调用的呼叫重定向到本地仆人,或者(将负载平衡)其他服务器。 CORBA规范(以及此图)将分布式系统的各个方面留给了应用程序,以定义包括对象寿命(尽管应用程序可以使用参考计数语义),冗余/失败,内存管理,动态负载平衡和应用程序- 面向导向的模型,例如显示/数据/控制语义之间的分离(例如,请参见模型 - 视图 - 控制器),等等。
除了向用户提供语言和平台中立的远程过程调用(RPC)规范外,Corba还定义了通常需要的服务,例如交易和安全性,事件,时间和其他特定领域的接口模型。
版本历史
该表介绍了Corba标准版本的历史记录。
版本 | 版本日期 | 强调 | CORBA IDL版本 | |
---|---|---|---|---|
1.0 | 1991年10月 | 第一个版本,c映射 | ||
1.1 | 1992年2月 | 互操作性,C ++映射 | ||
1.2 | 1993年12月 | - | ||
2.0 | 1996年8月 | 标准的第一个重大更新,也称为Corba 2 | ||
2.1 | 1997年8月 | - | ||
2.2 | 1998年2月 | Java映射 | ||
2.3 | 1999年6月 | - | ||
2.4 | 2000年8月 | - | ||
2.5 | 2001年9月 | - | ||
2.6 | 2001年12月 | - | ||
3.0 | 2002年7月 | 标准的第二个重大更新,也称为Corba 3 CORBA组件模型(CCM) | 3.0 | |
3.0.1 | 2002年11月 | - | ||
3.0.2 | 2002年12月 | - | ||
3.0.3 | 2004年3月 | - | ||
3.1 | 2008年1月 | - | ||
3.1.1 | 2011年8月 | 采用为2012年ISO/IEC 19500 | ||
3.2 | 2011年11月 | - | ||
3.3 | 2012年11月 | 添加Ziop | ||
3.4 | 2021年2月 | 注释 | 4.2 |
请注意,随着注释(例如@unit,@topic),IDL更改已取代一些pragmas。
仆人
仆人是包含用于处理远程方法调用的方法的调用目标。在较新的Corba版本中,远程对象(在服务器端)被分为对象(暴露于远程调用)和仆人(前者将方法转发为方法调用) 。它可以是每个远程对象的一个仆人,也可以是与给定的便携式对象适配器关联的几个(可能是所有)对象。每次调用该对象上的方法(仆人位置)时,每个对象的仆人都可以设置或“永远”(仆人激活)或动态选择。仆人定位器和仆人激活剂都可以将呼叫转发到另一台服务器。总的来说,该系统提供了一种非常有力的手段来平衡负载,在几台机器之间分配请求。在面向对象的语言中,从面向对象的编程的角度来看,远程对象及其仆人都是对象。
化身是将仆人与corba对象相关联的行为,以便它可以服务。化身为虚拟Corba对象提供了混凝土仆人形式。激活和停用仅是指corba对象,而术语的化身和空灵化是指仆人。但是,物体和仆人的寿命是独立的。在调用activate_object()之前,您始终将仆人化身,但是反向也是可能的,create_reference()在不化体仆人的情况下激活对象,然后随后与仆人经理一起按需进行仆人的化身。
这便携式对象适配器(POA)是负责将服务器端远程调用处理程序分配到远程对象及其仆人的CORBA对象。对象暴露在远程调用中,而仆人包含实际处理请求的方法。在两种情况下,都可以通过静态(一次)或动态(对于每个远程调用)选择每个对象的仆人,在两种情况下都允许调用转发到另一台服务器。
在服务器端,POA形成了类似树状的结构,每个POA负责提供一个或多个对象。该树的分支可以独立激活/停用,具有仆人位置或激活的不同代码以及不同的请求处理策略。
特征
以下描述了Corba可用于促进分布式对象之间通信的一些最重要的方法。
通过参考对象
此引用是通过串制的统一资源定位器(URL),名称服务查找(类似于域名系统(DNS))获得的,或者在呼叫过程中作为方法参数传递。
对象引用是匹配真实对象(远程或本地)接口的轻质对象。在等待答复,成功或失败时,方法在随后的呼叫中调用参考结果,并在线程上阻止线程。参数,返回数据(如果有)和异常数据由ORB根据本地语言和OS映射在内部进行封储。
按值进行数据
CORBA接口定义语言提供语言和OS中性的对象间通信定义。 CORBA对像是通过引用传递的,而数据(整数,双打,结构,枚举等)则按值传递。逐个引用对象和逐个数据的组合提供了在编译客户和服务器时执行出色数据键入的手段,但保留了Corba问题空间中固有的灵活性。
按值(obv)按值
除远程对像外,Corba和RMI-IIOP定义了Obve and ValueTypes的概念。默认情况下,在本地执行ValueType对象的方法中的代码。如果从遥控侧收到了OBS,则所需的代码必须是双方已知的先验代码,要幺是从发件人中动态下载的。为了实现这一目标,定义OBLE的记录包含代码库,该代码库应下载该代码的空间分隔列表。 OPP还可以具有远程方法。
CORBA组件模型(CCM)
CORBA组件模型(CCM)是CORBA定义家族的补充。它是使用Corba 3引入的,它描述了Corba组件的标准应用框架。尽管不取决于“依赖语言的企业Java Bean (EJB)”,但它是EJB的一种更通用的形式,提供了四种组件类型,而不是EJB定义的两种。它提供了可以通过名为端口的名称的界面提供和接受服务的实体的抽象。
CCM具有一个组件容器,可以在其中部署软件组件。该容器提供了组件可以使用的一组服务。这些服务包括(但不限于)通知,身份验证,持久性和交易处理。这些是任何分布式系统所需的最常用的服务,并且通过将这些服务的实现从软件组件转移到组件容器中,组件的复杂性大大降低。
便携式拦截器
便携式拦截器是Corba和RMI-IIOP使用的“钩子”,以调解Corba系统最重要的功能。 CORBA标准定义了以下类型的拦截器:
- IOR Interpectors调解了当前服务器提出的远程对象的新引用的创建。
- 客户端拦截器通常会在客户端(呼叫者)侧介导远程方法调用。如果对象仆人在调用该方法的同一服务器上存在,则它们还会调解本地调用。
- 服务器拦截器介导服务器(处理程序)端上的远程方法的处理。
拦截器可以将特定信息附加到发送的消息和正在创建的IORS上。稍后可以由遥控侧的相应拦截器读取此信息。拦截器还可以提出转发异常,将请求重定向到另一个目标。
一般互环协议(GIOP)
GIOP是一个抽象协议,通过该协议,对象请求经纪(ORB)通信。与协议相关的标准由对像管理组(OMG)维护。 GIOP体系结构提供了几种具体协议,包括:
- Internet Interbob协议(IIOP) - Internet Inter-Interb协议是通过Internet使用的GIOP的实现,并在GIOP消息和TCP/IP层之间提供了映射。
- SSL Interbob协议(SSLIOP) - SSLIOP在SSL上是IIOP,提供了加密和身份验证。
- 超文本间介质协议(HTIOP) - HTIOP在HTTP上是IIOP,提供了透明的代理绕过。
- Zipped IOP(ZIOP) - 杂志的拉链版本可减少带宽的用法。
VMCID(供应商次要代码ID)
每个标准的CORBA异常都包含一个指定异常子类别的次要代码。较小的异常代码是未签名的类型长,由20位“供应商次要代码ID”(VMCID)组成,该(VMCID)占据了高阶20位,而适合占据低订单12位的次要代码。
标准例外的次要代码由分配给OMG的VMCID(定义为未签名的长恒定CORBA :: OMGVMCID),该代码的VMCID分配给OMG占据了高阶20位。第3-58页的表3-13中与标准异常相关的次要异常代码与OMGVMCID相关,以获取在EX_BODY结构中返回的次要代码值(请参阅第3.17.1节,“标准”第3 -52页和第3.17.2节,“标准次要异常代码”,第3-58页)。
在供应商分配的空间中,将值分配给次要代码留给供应商。供应商可以通过将电子邮件发送到[email protected]
。可以在OMG网站上找到当前分配的VMCID列表: http://www.omg.org/cgi-bin/doc ?vendor-tags
VMCID 0和0xFFFFF保留用于实验用途。 VMCID OMGVMCID(第3.17.1节,“标准异常定义”,第3-52页)和1至0xF保留用于OMG使用。
Corba位置(Corbaloc)
CORBA位置(Corbaloc)是指看起来与URL相似的Corba对象的弦乐对象引用。
所有Corba产品必须支持两个OMG定义的URL:”Corbaloc:和“ Corbaname: ”。这些目的是提供人类可读和可编辑的方式来指定可以获得IOR的位置。
Corbaloc的一个示例如下:
- corbaloc :: 160.45.110.41:38693/standardns/nameserver-poa/_root
Corba产品可以选择支持“ HTTP: ”,“ FTP: ”和“ file: ”格式。它们的语义是它们提供了如何下载串联IOR的详细信息(或递归下载另一个最终提供串起的IOR的URL)。某些球确实提供了该球体专有的其他格式。
好处
Corba的好处包括语言和独立的语言,不受技术连接的实现的自由,强大的数据范围,高级别的可调性以及摆脱分布式数据传输细节的自由。
- 语言独立性
- Corba旨在使工程师免于将设计与特定软件语言耦合的局限性。目前,有许多语言由各种Corba提供商支持,最受欢迎的是Java和C ++。还有一些C ++ 11,仅C-仅C-,SmallTalk,Perl,Ada,Ruby和Python实现,仅提及一些。
- OS独立
- Corba的设计旨在与OS无关。 CORBA可在Java(独立于OS)中以及Linux/Unix,Windows,Solaris,OS X,OpenVM,HPUX,Android,Lynxos,VXWorks,threadX,Integrity等。
- 摆脱技术的自由
- 主要的隐含好处之一是,Corba为工程师提供了一个中性的竞争环境,以便能够使各种新的和旧系统之间的接口归一化。当将C,C ++,Object Pascal,Java,Fortran,Python和任何其他语言或OS集成到单个凝聚系统设计模型中时,Corba提供了平整现场的手段,并允许不同的团队开发系统和单元测试,以稍后可以使用这些系统和单位测试共同加入整个系统。这并不排除对基本系统工程决策的需求,例如线程,时机,对象寿命等。这些问题都是任何系统的一部分。 CORBA允许将系统元素归一化为单个粘性系统模型。
例如,使用Web服务器中的Java Servlet以及包含业务逻辑并包装数据库访问的各种CORBA服务器,使多层体系结构的设计变得简单。这使得业务逻辑的实现可以更改,而在任何其他技术中都需要处理接口更改。例如,为了改善磁盘使用情况或性能(甚至全尺度数据库供应商更改),由服务器包裹的数据库可以更改其数据库架构更改,而不会影响外部接口。同时,C ++旧版代码可以与C/Fortran旧版代码和Java数据库代码进行交谈,并可以向Web界面提供数据。
- 数据量
- CORBA提供灵活的数据键入,例如“任何”数据类型。 Corba还强制执行紧密耦合的数据键入,从而减少了人类错误。在传递名称值对的情况下,可以想像服务器提供了预期字符串的数字。 CORBA接口定义语言提供了确保用户代码符合方法名称,返回,参数类型和异常的机制。
- 高可调性
- 许多实现(例如OrbExpress(ADA,C ++和Java实现)和OmniorB(开源C ++和Python实现))具有调整线程和连接管理功能的选项。并非所有的ORB实现都提供相同的功能。
- 免于数据传输详细信息
- 处理低级连接和线程时,Corba在错误条件下提供了高度的细节。这是在CORBA定义的标准异常集和实现特定扩展异常集中定义的。通过例外,应用程序可以确定呼叫是否出于“小问题”之类的原因而失败,因此请重试”,“服务器已死”或“参考是没有意义的”。一般规则是:未收到异常意味着成功呼叫成功完成。这是一个非常强大的设计功能。
- 压缩
- Corba以二进制形式将其数据纳入了数据,并支持压缩。爱奥娜(Iona),补救措施和telefónica已为Corba Standard的扩展提供了压缩。该扩展名为ZIOP,现在是正式的OMG标准。
问题和批评
尽管Corba在编写代码和构建软件的方式上提供了很多方式,但它一直是批评的主题。
对CORBA的许多批评源于对标准本身的标准的实施不力,而不是缺陷。标准本身的某些失败是由于创建了CORBA规范的过程,并且撰写了许多竞争性实施者来撰写的通用标准的妥协。
- 最初的实施不兼容
- Corba的初始规格仅定义了IDL,而不是线路格式。这意味着源代码兼容性是几年可用的最好的兼容性。随着Corba 2和后来的此问题,解决了问题。
- 位置透明度
- 科尔巴的位置透明度概念受到批评。也就是说,驻留在同一地址空间中的对象和简单函数调用可访问的对象与位于其他地方的对象(同一机器上的不同进程或不同的机器)相同。这是一个基本的设计缺陷,因为它使所有对象访问与最复杂的情况一样复杂(即,远程网络呼叫具有一系列故障,而本地呼叫中无法实现)。它还隐藏了两类之间不可避免的差异,因此应用程序无法选择适当的使用策略(也就是说,具有1 µs延迟和保证回报的调用将与带有1S延迟的呼叫的通话方式有很大不同,其中交货状态可能未知,可能需要30秒钟的时间)。
- 设计和过程缺陷
- 委员会的设计过程也经常引用Corba标准的创建。在冲突的提案之间或决定要解决问题的层次结构之间没有仲裁的程序。因此,该标准是通过在所有提案中的特征结合而不考虑其连贯性来创建的。这使得规范复杂,完全实施,通常是模棱两可的。
- 由实施供应商和客户组成的设计委员会创造了一系列兴趣。这种多样性使很困难成为凝聚力的标准。标准和互操作性增加了竞争,并减轻了客户在替代实现之间的移动。这导致了委员会内的许多政治战斗,并经常发布了Corba标准的修订版,而某些ORB实施者确保没有专有扩展就难以使用。较少道德的Corba供应商鼓励客户锁定并取得了强大的短期结果。随着时间的流逝,鼓励便携性的ORB供应商接管了市场份额。
- 实施问题
- 通过其历史,科尔巴(Corba)遭受了贫困球体实施的缺点的困扰。不幸的是,许多批评Corba标准的论文只是对Corba Orb实施特别糟糕的批评。
- Corba是具有许多功能的综合标准。很少有实施试图实施所有规格,并且初始实施是不完整或不足的。由于没有提供参考实施的要求,因此会员可以自由提出从未经过实用性或可实施性测试的功能。标准的总体趋势是冗长的,进一步阻碍了实施,并且通过采用所有提交的提案的总和来妥协的常见做法,这些建议通常会产生不连贯且难以使用的API,即使个人建议是完全合理的, 。
- 过去,Corba的强大实现非常困难,但现在更容易找到。 Sun Java SDK附带了Corba内置。已经发现一些设计不佳的实现是复杂,缓慢,不兼容和不完整的。强大的商业版本开始出现,但价格巨大。随着高质量的无质量实施,不良的商业实施迅速消失了。
- 如果客户端位于非常限制的防火墙或透明的代理服务器环境后面,该环境仅允许HTTP连接到外部通过端口80,则可能是不可能的,除非有问题的代理服务器也允许HTTP Connect方法或袜子连接。一次,甚至很难强迫实施使用单个标准端口 - 他们倾向于选择多个随机端口。截至今天,当前的球体确实有这些缺陷。由于遇到困难,一些用户对Web服务而不是CORBA进行了越来越多的使用。这些通过端口80使用XML / SOAP进行通信,该端口通常通过组织内的HTTP代理打开或过滤,以通过HTTP进行Web浏览。但是,最近的CORBA实现支持SSL ,并且可以轻松地配置为在单个端口上工作。某些球体,例如Tao ,Omniorb和Jacorb也支持双向GIOP,这使Corba具有能够使用回调通信而不是Web服务实现的投票方法特征的优势。此外,大多数现代防火墙都支持GIOP和IIOP,因此是对Corba友好的防火墙。
也可以看看
软件工程
基于组件的软件技术
- Freedesktop.org D-Bus - 当前的开放跨语言跨语言对像模型
- GNOME BONOBO - 弃用的GNOME跨语言对像模型
- KDE DCOP - 弃用的KDE解释和软件分支机构通信系统
- KDE KPARTS - KDE组件框架
- 组件对像模型(COM) - 仅Microsoft仅Windows跨语言对像模型
- DCOM (分布式com) - 扩展使COM能够在网络中工作
- 通用语言基础架构- 当前.NET跨语言跨平台对像模型
- XPCOM (跨平台组件对像模型) - 由Mozilla开发用于基于IT的应用(例如Mozilla应用套件, Seamonkey 1.x)
- IBM系统对像模型SOM和DSOM - 来自OS/2和AIX中IBM的组件系统
- 互联网通信引擎(ICE)
- Java远程方法调用(Java RMI)
- Java平台,企业版(Java EE)
- 爪哇
- 露天
- 远程过程调用(RPC)
- Windows Communication Foundation (WCF)
- 软件通信体系结构(SCA) - 嵌入式系统,跨语言,跨通道,跨平台的组件