The rise and fall of CORBA
作者Michi Henning，2006.6.5
我们可以从CORBA的错误中学到很多
主要历史
在90年代早期，要使不同机器上的程序相互之间通信是一场恶梦，特别是不同的硬件、操作系统和编程语言都存在的环境：程序员要么使用socket靠自己来写整个协议栈，要么他们的程序之间就完全不能通信。（其它早期中间件，如Sun的ONC，Apollo的NCS以及DCE，都是基于C语言和UNIX操作系统的，并不适合于异构的环境）。
CORBA 1.0并不成功，因为它不能互操作，并且只提供C语言的映射。OMG在1997年发布了CORBA 2.0，它提供了标准协议，以及C++语言的映射，1998年提供了Java语言的映射。CORBA 2.0使得开发者可以相对容易地构建异构的分布式应用。CORBA很快就流行起来，很多任务关键的应用都用CORBA来构建。CORBA的前景看上去非常乐观。
在经历了90年代中后期的增长后，一些主要的变化影响了计算的前景，最为著名的就是Java与Web的出现。CORBA提供了Java语言映射，但是并没有涉及到爆炸式增长的Web。商业公司并没有等待CORBA给出解决方案，它们转向了其它技术，并且开始构建他们基于Web浏览器、HTTP、Java和EJB的电子商务基础设施。
除此之外，有经验的CORBA开发者发现编写实用的CORBA应用程序相当地困难。许多API都很复杂，不一致，甚至完全让人感觉神秘，使得开发者必须关注许多细节问题。想比之下，组件模型的简单性，比如EJB，使得编程简单得多（虽然不那么灵活），因此对CORBA组件模型的呼声越来越大。但是组件模型的到来花了很长的时间。始于1996年的工作基于CBOF（通用业务对象设施），但是那个努力因为公司行政策略上的斗争陷入了困境，不久就被放弃了，取而代之的是CORBA组件模型CCM。1999年CCM的规范终于发布，但是很大程度上确成为了雷声大、雨点小的事。
规范巨大而复杂，许多都未曾被实现过，甚至概念性的证明都没做过。阅读文档就可以清楚知道CCM技术上是不成熟的；部分根本不可实现，即使实现，也无法提供可移植性。
非商用的CORBA厂商承担了实现CCM的义务，却使其成为了夭折的孩子。即便在CCM发布的时候实现已经可以获得，也太迟了。机会已经过去了：EJB已经进入了产业，其它技术已经没有机会取得成功。CCM的失利并未增加CORBA客户的信心，这些客户正陷于CORBA复杂技术的泥潭。
同时，工业界对于中间件的需求出现了前所未有的高涨。在使用HTTP、HTML和CGI 构建了电子商务系统之后，使用这些方式构建分布式系统出现了明显的严重缺陷。没有适当的类型系统，应用被迫解析HTML来提取语义，这与抓屏一样没什么价值。这导致系统非常脆弱。另一方面，EJB拥有正确的类型系统，但是局限于Java技术，并不适用于许多环境。
商用CORBA实现一般每个开发席位都会花费几千美元左右，加上许多情况下的运行时版税（每个应用部署后收取）。对许多潜在的客户来说，CORBA这样的平台限制对他们来说太昂贵了。
CORBA平台的学习曲线陡峭，技术复杂，不容易正确使用，这些因素导致了开发周期长，易出错。早期的实现常常充满Bug并且受苦于缺乏有质量的文档。公司不容易找到他们需要的有经验的CORBA程序员。微软并没有使用CORBA，取而代之的是推出自己的DCOM。这使得市场要么选择中立要么使用DCOM，但是DCOM未能赢得中间件之战，因为它仅仅能工作在Windows平台上。（Software AG做了一个UNIX的移植，但是没有获得进一步的动力）。微软在几次扩展DCOM应用范围的尝试失利以后，最后放弃了DCOM。那时，中间件市场处于支离破碎的状态，许多技术在竞争，但是没有哪一个技术能够获得足够的份额来统一分布式系统的开发。
另外一个导致CORBA下降的重要因素是XML。90年代后期，XML成为了计算工业新的银弹：几乎所有只要是定义为XML的东西都是好的。在放弃了DCOM之后，微软并没有把电子商务市场留给竞争对手，微软没有再参与一场不可能打赢的战争，而是使用XML 来开辟了新的战场。在1999年年末，工业界看到了SOAP的发布。SOAP由微软和DevelopMentor发布，随后提交给W3C作为标准，SOAP使用XML作为远程过程调用的线上编码方式。
SOAP有严重的技术缺陷，但是，作为一种市场策略，它是巧妙的一招。随着大量的厂商都想分一杯羹，并且从CORBA转向萌芽的Web服务市场，市场变得更加的分化。对客户来说，这增加了CORBA生存能力的不确定性，在许多情况下，使得他们更加投资于有把握的技术。
当2002年Internet泡沫破灭时，CORBA遭到了另一个打击。工业界的金融崩溃使得许多软件公司退出市场，幸存者必须重新集中它们的资源。结果导致了大量商用CORBA 产品的损耗。在崩盘之前，几个厂商已经停止或者边缘化了它们的CORBA产品，并且在崩盘后，更多的CORBA产品随之并停止。在90年代中期到后期一片繁荣景象的许多有竞争力的产品忽然成为了市场的边缘，并且只有极少的厂商、客户和投资者。那时，可以获得CORBA的开源实现，这部分重建了市场的信心：CORBA不再是业界心爱的孩子。
今天，CORBA大多用于连接公司内部网络的组件，与外部世界的通信由防火墙进行保护。CORBA也用于实时和嵌入式开发，在这个领域CORBA确实在增长。整体上说，CORBA 的使用在减少，但是仅仅作为一个适得其所的技术，其它什么也不是。
考虑到仅仅几年前，CROBA被认为是先进的中间件，被提出来革新电子商务，现在令人惊奇的是技术如此快地被边缘化，为此种失利分析其更深层次的原因是有益的。Technical Issues 技术因素
很明显，大量的外部因素导致了CORBA的失利，比如Internet泡沫的破灭以及其它技术的竞争，比如DCOM,EBJ和Web服务。人们可以说CORBA是工业趋势的受害者。在
计算工业中，特定技术的技术优势常常对其成功贡献很少，份额和市场是更加重要的因素。
但是这篇辩论文并不能完整说明CORBA为何失利。毕竟，如果技术像原来的设想的
一样引人注目，客户不会抛弃它而选择其它的替代技术。
技术优势并不是成功的充分条件，但是，长期来看，它是一个必要条件。不管有多少工业幻想，如果一种技术有严重的技术缺陷，它最后还是会被放弃的。这也是我们所发现的CORBA失利的主要原因。
Complexity 复杂性
最明显的技术问题就是CORBA的复杂性--特别是，API的复杂性。许多CORBA的API比起所需要的来说要复杂得多。例如，CORBA的对象适配器要求大于200行的接口定义，其实30行的定义就可以实现同样的功能--其它170行对于功能来说没什么用，它们只能造成CORBA运行时严重复杂的程序交互。
其它的问题是C++语言的映射。映射不易使用，包含许多导致bug的缺陷，特别关于
线程安全性、异常安全性和内存管理的部分。大量的其它过度复杂和设计糟糕的API在CORBA规范中随处可见，比如名字服务、交易服务和通知服务，它们提供的API都是易错的、不容易使用的。类似地，CCM的配置也是如此复杂以致如果没有使用附加工具的支持，难以产生有效的结果。
设计糟糕的接口和语言映射是任何技术非常明显的部分，因为他们是软件开发的“面子”：他们是开发者和平台相会的点，他们的易用性和安全性对于开发时间和错误累计有很重要的影响。明显地，任何受困于特定复杂性的技术都使得它自己对开发者来说较少具有亲密性，对于管理来说就更是如此了。
复杂性也来源于体系结构的选择。例如，CORBA的IOR（互操作对象引用）是不透明的实体，内容对于开发者来说是不可见的。由于以下三个原因，这导致了不利：不透明的引用几乎强制使用名字服务，因为客户端在没有外部服务的帮助时不能创建对象引用。这不仅复杂化了系统的开发和部署，也将冗余状态引入到了系统中（伴随着状态出错的危险），并且创造出了另外的失效点。
不透明的对象引用在相当的程度上复杂化了API。例如，CORBA的拦截API应该能够简化很多，对象引用也可以透明。不透明的对象引用要求远程调用比较对象标识符。对许多应用来说，这些调用的负载是禁止的。
其它导致复杂的原因是类型系统。例如，CORBA的接口定义语言提供了大量的类型，比如无符号整型，定点和扩展精度浮点数，有界和无界序列以及数组和能存储任何类型值的Any类型。
支持这些类型复杂化了许多API（特别是，反射和动态调用的接口），导致了微妙的移植性问题。例如，Java不支持无符号类型，因此当Java客户端与C++服务器端通信时，在接口中使用无符号整数可能导致溢出问题。类似地，在没有本地定点或双精度浮点数支持的平台上，实现必须模拟这些类型。模拟难以用跨平台的统一方式实现，它们也需要额外的API。这导致了更多的复杂性，而且是一个难以诊断的互操作问题的根。
最后，一些OMG的早期对象服务规范，比如生命期规范、查询规范、并发控制、关系和集合服务规范，不仅仅是复杂，而且根本没什么用。它们仅仅在已经复杂的规范集合上增加了更多的噪音，使得客户迷惑，并且加强了CORBA难以使用的名声。
Insufficient Features 不足的特征
CORBA提供了大量丰富的功能，但是没有提供两种核心特征：
安全性。CORBA的流量是不加密的，这使得它容易被窃听以及遭受插入式攻击，而且每个服务都要求防火墙打开一个端口。这与企业安全策略是相冲突的。（附带提一下，CORBA的这个缺点是导致SOAP声名鹊起的一个主要原因。SOAP不需要在企业防火墙上打开一个端口，所以信息都通过80端口传递，这被看做主要优点，尽管这个想法非常幼稚。）OMG数次努力制定CORBA的安全和防火墙穿透，但是由于技术缺陷以及防火墙厂商的冷漠而放弃了。
版本。部署商业软件要求中间件可以用后向兼容的方式逐步升级。CORBA没有提供任何版本机制（除了派生的版本控制，这完全不够）。升级一个CORBA应用常常会破坏客户端和服务器之间的线上协议。这强制许多已经部署的应用必须一次性替换，这是不可行的。（CORBA的这个缺点是导致SOAP流行的另外一个主要原因。XML所设想的松散耦合本质被视作解决问题的方法，尽管这个想法与通过80端口传输所有通信的想法一样幼稚。）对于商用的电子商务基础设施来说，缺乏安全和版本控制是相当简单的暂停--许多潜在的电子商务客户仅仅因为这些原因拒绝使用CORBA。
Other Technical Issues 其它问题，大量的其它技术问题折磨CORBA，其中：CORBA互操作协议的设计缺陷使得它不可能建立一个高性能的分布式服务。
CORBA的线上编码包含大量的冗余，但是协议并不支持压缩，这导致了大面积网络的性能缺陷。
规范几乎完全忽略了线程，因此线程应用是内在不可移植的（而线程对于商业应用来说是最基本的）。CORBA不支持异步服务器端分派。
C#和VB没有对应的语言映射，CORBA完全忽略了.NET。
以上的问题列表仅仅是一个简单的取样，在相当程度上可以被扩展。这样的问题仅仅影响小部分的用户，但是它们增加了CORBA的负面新闻并且限制了CORBA的市场
rocedural Issues 流程问题
技术问题是CORBA失利的核心原因。令人疑惑的是，世界上最大的软件联盟OMG为何会受限于这些缺陷。结果很明显，技术问题只是症状，而不是原因。
OMG是一个基于成员一致同意来发布技术的组织。从根本上来说，成员通过投票来将RFP变成规范。成员公司提交草案规范作为回应，OMG的成员们通过投票来决定是否将提案接受为标准。理论上，这是一个民主、公平的过程，但是实际上，它并不能起作用。
标准化过程中没有什么准入资格。一些贡献者是领域专家，但是，令人感到挫折的是，大量的成员几乎不理解他们所要投票的技术。这导致了具有严重技术缺陷的提案被采纳为标准。
RPF常常提出未经证明的技术。OMG的成员可以分成两组：技术用户组和技术厂商组。典型的情况是用户组想要扩展CORBA以增加某个能力来解决一个具体的问题。用户
希望厂商能对他们的具体问题提出解决方案，这驱动了RFP的发布。但是用户常常对CORBA实现的内部细节知之甚少。最好的情况下，这常常导致RFP包含了很难实现的需
求或者带来了对性能的负面影响。在最坏的情况下，这导致RFP弄得来跟要求厂商变魔法一样荒谬。这样的RFP没有得到标准化最佳实践的目的，反而试图去革新，但是却没有以前的实践经验。
厂商即使知道技术有缺陷，也会响应RFP。这种结果令人惊奇。毕竟，为什么厂商会
支持有技术缺陷的提案成为标准呢？原因就是厂商之间对客户的竞争，持续地相互碰撞。所以厂商会承诺支持RFP，即便这些RFP包含严重的技术问题，这是厂商赢得用户好感（以及订单）的方式。
厂商在标准化的时候相互之间有冲突。对于厂商来说，标准化是一把双刃剑。一方面，标准化是具有吸引力的，因为它能够促进技术的销售。另外一方面，太多的标准化被认为是有害的，因为厂商想要保持那些可以使他们的产品在竞争中处于优势的特长。
厂商有时候试图阻碍标准化过程，只要这个过程会要求厂商改变他们已有的产品。这导致了应该被标准化的特征保持了私有化，或者模糊地指定而毫无用处。一些厂商也忽略了标准特征和私有特征的区别，因此客户迷失在实现相关的区域而毫无警示。结果就是，将CORBA应用移植到不同厂商的实现上会花费相当大的代价；客户常常发现尽管有很多标准，他们自己还是被锁定在一个特定的产品上。
RFP常常由几个草案规范来回应。OMG成员通常的回应不是选择一个有竞争力的规范，而是要求提交者将他们的特征合并为单一的规范。这个步骤是导致CORBA复杂性的主要
原因之一。在合并特征的过程中，规范最终被定格为具有许多人提出的特征的厨房洗碗槽。这不仅仅使得规范毫无必要地越来越大，越来越复杂，也增加了不一致的风险：不同的特征是独立的，很容易在相互的交互中引起语义冲突。
主要的厂商偶尔会停止会议，直到他们视作宠物的那些特征被合并进标准。这使得技术过程退化成了立场混战，导致了违反规则的妥协，延迟了规范的发布。例如，第一次对于组件模型的努力就是这种混战的受害者，正如第一次对C++映射的努力一样。所有的努力都
陷入困境，它们必须被放弃，随后再重新开始。
OMG没有要求规范的参考实现被采纳。这种做法导致规范成为空中城堡。好几次OMG 发布了后来被证明是部分不可实现甚至完全不可实现的规范，原因是其中严重的技术缺陷。也有其它的情况是规范可以实现但是实际上不可用，因为强加了许多不可接受的运行时负担。这样反复出现的问题令人尴尬，磨掉了客户的信心。对于参考实现的要求会强制提交者实现他们的建议，这样可以避免许多这样的问题。
整体上，OMG的技术采纳过程应被视作CORBA失利的核心原因。这个过程鼓励了委员会和各方立场移动到一个点，这个点很难获得技术上的平常水平，更不用说杰出的技术表现了。因此，增加脱节的技术特征导致了体系结构观点的逐步腐蚀。（例如，体系结构关于不透明引用的概念在2000年一次规范的更新中被忽略掉了，所产生的结果就是引用开始透明，但是API仍然背负着将引用视作不透明的重担）。
CORBA的几个技术缺陷累积到一个点上，就很难修复或者增加一些东西而不破坏另外一些东西。例如，每次CORBA的互操作协议的修订都必须做不兼容的改变，许多补丁和
澄清要重写几次，因为不可预见的特征交互在不断地增加。
Can We Learn From the Past? 我们可以从过去学到什么？
一个民主的过程，比如OMG的，对于创建好的软件来说是完全不合适的。尽管这些流程上的问题已经广为人知，但是，工业界仍然倾向于依靠大的组织来生产技术。Web服务，当前的中间件银弹，使用了类似于OMG的流程，在许多方面，也受苦于混战、分裂、缺乏体系结构的一致、由委员会来设计以及特征膨胀等问题。看上去Web服务也不可避免经历类似于CORBA的历史。
我们应该采取什么步骤来开展较好的标准化过程以及产出较好的中间件呢？考虑到流
程的失败是技术失败的根本原因，我建议至少以下几个措施：
标准化组织需要铁甲纪律来确保他们标准化的是最佳实践。在标准化的过程中没有革新的空间。把“仅仅是额外的小特征”放进标准，将不可避免地引起不可预见的技术问题，尽管目的是好的。
没有参考实现的标准不应被通过。这会给将要标准化的内容提供首要的健全检查。（没有人可以聪明到一看到规范就可以确定规范不包含隐藏的错误，如果没有实现过这个规范的话）
没有用于实现几个真正复杂的工程，标准不应被通过。这对于清除设计糟糕的API是
必要的：我们常常看见API的实现者从来没有真正使用过他们自己的接口，这导致了可用
性不高的灾难性结果。
有趣的是，比起工业标准化组织来说，开源社区则坚持这些原则做了许多更好的工作。
开源革命常常遵从达尔文物竞天择的过程。不同的开发者实现他们关于某个系统应该如何运行的想法，其它的人试图使用这些特征，或者批评或者提高它们。通过这种方式，软件在相当的程度上被细察和测试过，仅仅最“合适”版本生存了下来。（许多开源软件工程规范
化了这个过程，通过交替的试验版本和产品发布：试验版本的发布作为测试床和进化的过滤器。）
为了创造有质量的软件，学会说“不”常常比起说“是”更加重要。开源通过“慈善专政”的方式来实现这一点：即使许多人做出了贡献，只有一个专家（或者一个小的专家团）最终会拒绝或者接受每个提交的变化。这保持了原始的体系视角，停止了众所周知的“太多的厨子会坏了一锅汤”。
在这些开源实践的中心是两个基本的假设：合作和信任。没有合作，演进的过程不能工作；没有信任，就没有专家小集团能做出最终的仲裁。但是这正好使软件组织找到了生存的方式。将相互竞争的厂商和客户放进一个组织，并且希望他们能够产出高品质的产品，这是幼稚的做法。商业的本质将使得合作和信任在参与者的大脑中是最后考虑的事情。
当然，软件组织对于演进过程的贡献与开源工程一样。只是商业市场成为了测试床和演进过滤器，而且是客户，用他们的钱包，来扮演（一般不怎么慈善）的仲裁者。这跟工业界抛出银弹，客户像旅鼠一样跳过悬崖一样。除非我们改变这个过程，否则统一的商用中间件将像过去一样久久不能到来。
MichiHenning(***************)是ZeroC公司的首席科学家。从1995到2002年，他作为OMG体系结构委员会的成员，以及ORB的实现者，咨询师和培训师。与Steve Vinoski 合作，写了《基于C++的CORBA高级编程》(Addison-Wesley, 1999)一书。从加入ZeroC 开始，他从事ICE的设计与实现，ICE是ZeroC的下一代中间件，在2003年合著了《使用ICE进行分布式编程》一书。他获得了澳大利亚昆士兰大学计算机科学的荣誉学位
Corba的原理和实现 编写人：杜航航 编写时间：2011/1/18
目录 引言 (3) 1 CORBA历史 (3) 2 Corba的原理和特性 (4) 2.1 CORBA体系结构 (4) 3 IDL(Interface Definition Language) (5) 3.1 OMG IDL的语法规则 (6) 3.2 OMG IDL词法规则 (6) 3.3 数据类型 (6) 3.4 常量 (7) 3.5 构造数据类型 (7) 3.6 数组类型 (7) 3.7 模板（template）类型 (7) 3.8 接口（interface） (8) 4 java环境下的Corba实现 (8) 4.1 环境 (8) 4.2 编码 (8) 4.2.1 IDL接口定义和实现 (8) 4.2.2 接口实现类的编码 (9) 4.2.3 服务器端编码 (9) 4.2.4 客户端编码 (10) 4.3 运行 (10)
引言 爱立信的很多产品都广泛采用Corba协议作为系统集成的标准接口，比如OSS产品内部是Corba，OSS和NBI以及NBI和综合网管之间也是corba接口。因此研究一下Corba接口对以后的工作会有极大的帮助。 1 CORBA历史 CORBA是由OMG（Object Management Group）负责制定和维护的一组规范。OMG成立于1989年，是一个非营利的国际性软件组织，主要致力于为分布式计算提供解决方案并制定规范。除CORBA外，OMG还制定了如UML(United Modeling Language, 统一建模语言)、CWM等其他重要规范。OMG目前已有世界上760多个成员，东南大学是中国唯一的OMG成员。 CORBA自1990提出并被OMG采纳以来，已历经多个版本。分别称为CORBA 1、CORBA 2和CORBA 3。其中CORBA 1是对CORBA 1.x的统称，CORBA 2是对CORBA 2.x的统称。目前CORBA 3规范还在制订中，不久便可面世。 下面是CORBA版本的更新历史。 CORBA1 ： CORBA 1.0 90-12，提出CORBA框架 CORBA 1.1 91早期，定义了IDL及ORB Interface。 CORBA 1.2 92-93, 修订 CORBA定义了ORB的一些基本特性，但是没有定义而ORB间的通用协议。CORBA 2主要解决这一问题。 CORBA 2： CORBA 2.0 94-12, 定义了GIOP和IIOP CORBA 2.1 97-08 CORBA 2.2 98-02, 增加了POA。 CORBA 2.3 98-12 CORBA 2.3.1 99-10, 一些Change bars. CORBA 2.4 00-10, 具备CORBA 3的雏形，包括：QoS Specification, Asynchronous Messaging, Minimum CORBA, Real-Time CORBA, CORBA Components, Notification Services, Firewall Specification等。 CORBA 2.4.1 00-11 CORBA 2.4.2 01-02
CORBA Programming with TAO - 1.Start（基本概念） 摘要： 简要介绍CORBA的基本原理，并解释POA、stub、skeleton、servant等重要概念。 一、CORBA及TAO简介 CORBA是一个为简化跨平台应用而提出的规范，它独立于网络协议、编程语言和软硬件平台，支持异构的分布式计算环境和不同编程语言间的对象重用。CORBA可以作为不同平台应用间信息传递的中间件，CORBA通过引入经过充分验证的有效的框架结构和通信手段，最大限度地简化了网络通信相关应用的设计与开发，使得我们可以专注于业务逻辑的实现，而无需关心通信的细节。CORBA曾在无数文章中被称作“软总线”，以表明它作为数据传递通道的基本特性。 现在存在众多CORBA实现，既有商用的ORBacus、VisiBroker，也有一些优秀的开源实现，如：TAO、omniORB、MICO等。由于各实现遵从相同的规范，接口基本一致，所以在熟练应用一种CORBA实现后，转而使用其它实现时，一般不会存在太大的障碍。 TAO（The ACE ORB）是美国华盛顿大学的Douglas C. Schmidt教授领导开发的一个实时CORBA平台，它是一个免费的开放源码项目，用C++语言开发，符合CORBA2.6规范。 支持语言: C++ 支持平台: Win32，常见的各种Unix/Linux，实时操作系统如VxWorks等等。在所有的CORBA实现中，TAO 支持的平台是最多的。 支持的服务: Naming、Event、Notification、Security、Time、Scheduling、Logging、Lifecycle、Trading、Concurrency、Lifecycle、A/V Streaming、Load balancing等。 本系列文章将以当前最新的ACE-5.5+TAO-1.5+CIAO0.5为例，简要介绍如何应用TAO进行CORBA C++编程，其中部分内容（尤其是编译器配置相关的内容）是Windows平台特有的，但其它大多数信息在各平台上都是相同或者类似的。 二、基本概念 本文不打算深入介绍CORBA相关的理论基础（已有很多书籍、文章讨论了这些内容），但在进入下一主题前，为了便于后续问题的讨论，这里简要介绍一下CORBA的基本原理，并对几个重要的基本概念进行解释，以便为没有相关知识的朋友扫清障碍。下图是CORBA的基本模型：
CORBA技术在分布式智能网中的应用 (华北电力大学计算机系，保定，071003) 摘要: 随着新业务需求的增加以及涉及智能业务的呼叫在电信业务中所占的比重不断增大,传统的集中式智能网在处理能力上的瓶颈将越来越突出。本文分析了现有智能网体系结构在分布式计算方面存在的缺陷,给出了一个基于CORBA技术实现未来的分布式IN系统结构的全局视图,并着重讨论了将智能网与CORBA技术结合的若干关键问题。 关键词:智能网；CORBA ；分布式 电信领域正朝着开放的计算环境方向发展,采用由对象管理组织OMG(ObjectManagementGroup)制订的分布式对象技术,如公共对象请求代理结构CORBA(CommonObjectRequestBrokerArchitecture)[1]建立适合电信领域的可扩展的、分布的、跨越多个平台的系统,目前正成为一种趋势。 OMG还为CORBA在电信领域的进一步推广专门成立了电信技术组。CORBA技术也是一个非常适合实现增值电信网络的基础架构。基于CORBA技术的分布式智能网的研究已成为目前下一代智能网研究的一个重要发展方向。国内外许多通信厂商和研究机构,如Lucent、Alcatel 和HP等一些跨国电信公司,都在和OMG一起积极开展CORBA在智能网中的应用 研究[2][3],并提出了一些初步的解决办法。 一、技术概述 CORBA是一个用于在分布式异构环境下实现可重用、可移植、可交互的面向对象软件系统的规范。其重点在于对象间的互操作规范,以及对象对运行过程的支持。CORBA的核心思想是采用标准的接口定义语言(OMGIDL)将软件接口与软件实现相分离。采用ORB(对象请求代理)实现异构环境下对象透明地发送请求和接收响应的基本机制。CORBA以面向对象方法为基础,将Client、Server模式作为基本处理机制,为分布式环境中各类网络互相访问、协同工作提供了一个一致的服务平台。但它又不同于普通的Client、Server模式,一个客户可以透明地向一个服务对象发出请求,并且不需要知道这个服务对象在网络中的位置,及其编程语言和操作系统等。CORBA的这一特征为在分布环境中异类系统应用的互操作提供了保证。由于ORB屏蔽了底层细节,使开发基于对象的大型应用系统的过程大幅度地简化。 CORBA技术非常适合电信领域,有两方面的原因:一是CORBA的技术特点,如采用先进的软件总线和面向对象技术,容易实现与遗留系统的集成,符合标准的处理流程,系统的开放性适应新技术的发展;二是电信领域的需求特点,即超强的分布式处理需求,这正是CORBA的优势所在。 二、传统智能网在分布计算方面的不足 智能网的基本思想是将电信网络的交换功能与控制功能分离。交换机仅完成基本的交换和业务接入功能,而把原来位于各个交换机的业务控制功能集中到了业务控制点上SCP(高性能可靠性计算机),从而实现了业务由智能网集中提供。在智能网建设初期,由于需支持的增值业务还很少,基本上可以满足用户需求。但随着对新业务需求的增加,涉及智能业务的呼叫在电信业务中所占的比重也将不断增加。同时,提供个人化业务的需要预计也将汇入到对高性能智能网系统的需求中。特别是象号码携带这样一类的业务,对业务控制点处理能力的冲击很大,会出现SIP成为业务的瓶颈和SIP扩展性能差阻碍增加业务量的矛盾。针对集中式控制的弊端,我们需要寻求一种分布式的智能网服务结构。于是,将CORBA技术引入智能网便自然地成为研究热点。
新浪微博：https://www.doczj.com/doc/1819335424.html,/csx1998（放牛长大） 1、web service体系结构 首先客户端从服务器的到WebService的WSDL，同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WebService服务器进行Request 和Response 当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。这就是WebService的一个运行过程。 Web Service大体上分为5个层次: 1. Http传输信道 2. XML的数据格式 3. SOAP封装格式 4. WSDL的描述方式 5. UDDI 2、RCP 客户机对服务器的RPC调用,其内部操作大致有如下十步： 1.调用客户端句柄；执行传送参数、 2.调用本地系统内核发送网络消息、 3.消息传送到远程主机 4.服务器句柄得到消息并取得参数、 5.执行远程过程、 6.执行的过程将结果返回服务器句柄 7.服务器句柄返回结果，调用远程系统内核、 8.消息传回本地主机、 9.客户句柄由内核接收消息、 10.客户接收句柄返回的数据 3、webservices/corba/jms/rpc/rmi区别 web service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。webservice服务端是运行在web服务器上的，不过也可以使用Remoting命名空间，创建c/s式的服务，比如CORBA就是c/s的方式提供服务
简单的CORBA通信代码解析 今天我想跟大家一起分享一下关于corba应用程序的建立，对于下面的代码中关于“远程过程调用”的运行机制并不是很明白，很多东西在omniorb的背后就已经帮我们完成了，但是出于对技术的热爱如果有对这方面清楚的朋友或有什么参考资料请不吝赐教，之所以写下这篇文章也是为了能跟跟多的朋友一些分享一起进步。 以下代码均在我的机器上运行测试并通过，开发环境是vc6.0+windows. 写一个最简单CORBA代码所要做： 1:) 定义一个IDL； 2:) 建立服务器端代码； 3:) 建立客户端代码： IDL：dl编译器使用的是omniorb4.0.5版本的。 首先选在vc6.0,建立Project/Utility Project: 新建MyTime.idl 文件并将其加入到创建的工程中，MyTime.idl内容如下: typedef struct strTimeOfDay { short hour; //0 - 23 short minute;//0 - 59 short second;//0 - 59 }TimeOfDay; interface Time { TimeOfDay get_gmt(); }; 在工程中选择IDL文件，选中General选项卡：在Always use custom build step前打勾。然后选择Custom build并对其作如下设置： Command: ..\..\omniORB_4.0.5\bin\x86_win32\omniidl -nf -bcxx -Wba -Wbh=.h -Wbs=.cpp -Wbd=_skel.cpp -I. -I..\..\.. -C..\Output\IDL\src $(InputName).idl OutPuts: ..\Output\IDL\src\$(InputName).h ..\Output\IDL\src\$(InputName).cpp ..\Output\IDL\src\$(InputName)_skel.cpp 编译后会生成三个文件：MyTime.h，MyTime.cpp，MyTime_skel.cpp. 第二步：生成服务器端代码：
CORBA和Tao的语法规则 1)注意，在IDL当中定义的数据类型和Ｃ＋＋当中的数据类型有一个映射关系，它并不会 直接使用在IDL当中所定义的类型。 2)简单的基本类型 TAO支持的IDL数据类型及其C++ Mapping关系，TAO支持以下简单基本数据类型（%TAO_ROOT%/tao/Basic_Types.h）： 以上各简单基本类型对应的C++类型只是对应平台上基本类型的typedef。为了保证程序的可移植性，应该总是使用CORBA命名空间中的类型标识。没有我们熟悉的C++基本类型byte（被Octet取代）、int（被Long取代）。 3)复杂的基本类型（Tao说支持的数据类型） 4)应该总是使用TAO提供的（也是CORBA规范规定的）如下字符串操作函数： char * string_alloc(ULong len); char * string_dup(const char *); void string_free(char *); WChar * wstring_alloc(ULong len); WChar * wstring_dup(const WChar *); void wstring_free(WChar *); (w)string_alloc/(w)string_dup后必须调用(w)string_free来释放分配的资源，为了避免忘记(w)string_free带来的麻烦，有些情况下，我们可以考虑使用String_var类型。String_var 是String类对应的智能指针类，除了TAO本身支持的智能指针类型外，tao_idl在生成代码时会自动为每个Object添加一个对应的var类型）。