basic和java有什么区别 java和corba啥区别

<script type="text/javascript"> google_ad_client = "pub-8800625213955058"; /* 336x280, 创建于 07-11-21 */ google_ad_slot = "0989131976"; google_ad_width = 336; google_ad_height = 280; // </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

本文选自IBM developerWorks中文网站） 　 概述 Java 和 CORBA 技术， 　　在 1855 年，时年 26 岁的 Joshua Chamberlain 是 Bowdoin 大学的修辞学教授，在一次演讲中讲述了 规则与自由之间的关系，以及二者之间失衡带来的危害。 没有自由的规则是专制，而没有规则的自由是混乱。 　　公司信息系统部门的管理可能会形成过度的规则或 过度的自由。规则过度的一个例子是只适用于一个厂商 的管理指令，这样您的系统在扩展时，或在与潜在的公 司合作伙伴集成时就会有问题。如果自由过多，个人或 者开发小组就会根据他们来选择技术，这样，如果这些 技术高手遇到他们“生疏的”优先认股权这样的话题时 ，扩展或集成又会变得很困难。开发人员可能会受业务 环境不断变化的影响。 　　努力实现环境平衡 　　多种环境因素在决定我们的系统必须遵守的的规则 。存在于一个业务环境中的系统应有足够长的寿命，以 为公司和客户创造价值。持续为一个组织创造长期价值 的系统必须能够应付经常的变化。合并、并购、新的管 理和市场力量在改变系统的环境，以及通过使用该系统 完成业务过程的用户的需求。变化是一个常数，必须将 它添加到评估方程式中。当然，我们无法预知未来，但 我们可以分析趋势并努力设计我们的系统，使之能够接 受大量潜在的变化或系统扩展，同时对组织产生的影响 又可以尽可能小。 　　为了做出正确的决策和评估，我们需要理解支配着 环境的规则，以及我们的应用程序在该环境中应具有的 自由。要理解的最重要的规则是，我们的系统处在不断 发展的组织中，无论是在公司、政府还是教育组织中， 都是业务问题支配技术问题。许多体系结构和平台评估 都将主要问题漏掉了。他们通常会将两项或多项技术并 排放在一起，然后比较技术特性列表。在完成的时候， 大多数参与者会达成一致，因为他们不愿与评估小组中 嗓门最大、最强硬、势力最大的派别争吵。显然，这不 是作出选择的最有效方法。 　　确定关键业务问题 　　将业务问题转换为对组织需要的实际评估意味着应该着重考虑以下问题： 　　组织内的技术力量 　　不抑制程序员的开发环境 　　不对应用程序构成限制的运行时环境 　　运行时环境和开发环境的许可证问题和法律问题（可以说是规则的规则） 　　可找到有经验的开发人员 　　能找到收费合理、有见地的咨询服务公司 　　对组织的客户的影响 　　对厂商或技术合作伙伴的影响 　　组织的文化和策略 　　组织的上级管理联盟 　　“大亨们”是否在讨论并购或合并 　　谁是决策者 　　这些业务问题通常比其他问题（比如采用每个会话 一个线程的并发模型还是每个请求一个线程的并发模型） 更重要。您可以走进老板的办公室， 向他发表足可以充斥一次软件研讨会的技术观点，但是除非您强调了组织的需要， 否则您的观点将显得非常空洞。 　　走近 CORBA 　　现在让我们用 CORBA 来解决这些问题。 CORBA 是一种开放的行业标准，它由参加“对象管理组织 (OMG)”的 600 多家公司支持。 这些公司包括硬件或软件公司、电信公司、金融公司、大学、医药研究所和政府机构 。OMG 并不实现它们自己的规范；它们依靠厂商的实现，这些实现有助于将竟争导向到功能、性能、 价格和令人鼓舞的质量这些方面。OMG 本身是一个充满生机的、活跃的组织， 它的许多官员在各种会议上撰写文章并发表演讲。 只要留心观察，您就会发现，他们总在关注将会对他 们的组织及您的组织造成影响的各种变化。 　　除上述优势外，CORBA 还提供了高度的交互操作性。 这保证了在不同的 CORBA 产品基础之上构建的分布式对象可以相互通信。因此， 大型组织不需要让所有开发工作都使用同一 CORBA 产品。 OMG 一直都在辛勤工作，以期通过加强 CORBA 规范来提供更高级别的可移植性。要知道， 当厂商分化它们的产品以及开发人员添加限制时， 他们往往会忘记源代码的可移植性这回事。 应当指出，可移植性比以前的版本中有了实质性的提高， 并且随着因特网互操作性协议 (IIOP) 形成强大的用户集团和众多联盟， 可移植性将越来越好。 　　我们很快变会转入 Java 技术的讨论，但我们首先应将语言看作一个整体。 信息系统有一个确定的规则，那就是不确定性本身。 Java 编程语言可能是今天的语言，但谁知道下一种更好的语言哪一天会使它暗然失色呢？ 应当知道，就在此时此刻，有人正在他们的车库里加紧编写一种更好的语言 。因此，CORBA 的语言无关性有助于您长期遵守信息系统环境中的这一法则。 CORBA 支持一种经典的、稳定的对象模型， 此模型将继续步入未来。它一直在凭借最新的语言不断发展，并将继续向极好的新语言（如 Python）扩展。 Java 编程语言及其他 　　此环境中可确定的另一点是它的复杂性， 这是我们所不愿看到的，Java 技术正好可以派上用场。它能很好地满足需要， 因为它的简单性将有助于使开发免于陷入底层的复杂性中。 Java 语言在许多方面隐藏了一些基本的细节， 但就整体而言，Java 技术改善从分析、设计到执行的整个过程。 　　在分析和设计阶段要尽可能统一和明确地表示您的系统和设计模式， 这一点极为重要。“统一建模语言 (UML)”事实上已成为表述系统设计的标准语言。 UML 的开发是协作方面的一个极好的故事。UML 的标准化过程也相当引人注意。 UML 的标准化是通过 OMG 来实现的。OMG 认识到需要一种标准建模语言， 以跨语言和环境表示分布式对象模型。Java 对象模型与 CORBA 对象模型几乎完全相同， 从而很容易将您的 UML 设计映射到一种实现， 同时也很容易将 UML 图映射到“Interface Definition Language (IDL)-to-Java 语言”实现。 　　经过分析和设计阶段的对象将有一些接口， 这些接口定义其他组件将如何访问您的服务。 现在需要将那些接口转换为一种实现语言。 Java 技术同样使这一步很容易实现。“IDL-to-Java 语言”映射相当直接。 Java 语言和 IDL 分别提供一个接口关键字， 这个关键字有助于说明用每种语言表示的数据类型之间的紧密关系。 Java 技术提供一种从 Java 接口到 IDL 的反向映射。不管选择哪个方向， 您都应该用 IDL 表示您的接口；这使您能够使用所有其他语言与 IDL 之间的映射， 并为您提供了为了在以后具有更大自由而必需的语言无关性。 　　体系结构案例 　　除了设计之外，系统的体系结构也很重要。 许多系统体系结构问题涉及对现有系统（数据库、旧有系统 、可用对象或可能用其他语言编写的应用程序）的包含。 Java 和 CORBA 语言使得可以（而不是禁止）将这些强有力的系统带给更多的用户。 这是一种解放 -- 许多系统可能许多年来都在发挥着作用。实际上 ，当完成将这些系统带入新世纪的所有 Y2K 以前的工作以后， 在今后几年它们可能还将存在。 由于其编译后的字节码结构，Java 语言将使您很容易创建和分发可移植的对象， 而 CORBA 允许您将这些对象与您计算环境的其余部分进行连接和集成。 　　我并非想用 Java 和 CORBA 技术来排斥 Java 语言的远程方法调用、Enterprise JavaBeans 技术 、Microsoft 的 DCOM 甚至 DCE。Java 和 CORBA 语言最自由的方面是，OMG 正在加紧工作 ，以确保 CORBA 对象能够与大量的对象交互 。当然，这些连接中有些较难实现，并且最终可能会很脆弱 。请记住，这些类型的连接 常常是因体系结构、成本、时间或业务等原因而建立的。 　　小结 　　异构系统环境中的互连和通信应该是我们的目标。 我们要选择使用的规则应该允许自由地将现有的系统与 新系统一起使用以满足组织的需要。 在这个变化的世界中，当变化被强加给您的组织时， 这些规则应该提供最大的灵活性。这些规则 提供了一个限制我们的自由的操作范围，这样就不易陷入盲目开发的境况。 　　 --------------------------------------------------------------------------------