本文简要介绍了在高度分布式系统中同时使用多语言应用程序环境的方法。不感兴趣吗？没关系，肯定有人会这样，请耐心阅读!

如果注意观察一下绝大多数大公司的IT 系统，会发现它们大多都结构雷同且陈旧，在 J2EE 的外表下，是支持层成段的 C++ 代码，再往下看，能够发现从前 C 和 Unix 占统治地位时留下的痕迹。似乎还能够看到一些 COBOL（或 PL/1）的遗迹，它使我们想起了已经淡忘的微型计算机，幸运的话，还能够找到一些真正的汇编程序。但考古线索到这里就中断了。在进行真正进行考古时，位于不同地层的生物都已死亡。而在许多（或许是绝大多数）IT 商店中，历史上每一个阶段的生物共处一室。它们共同工作，使业务得以运转。这样的事实真让人惊恐不已。

简言之，异构是很正常的事。请不要大惊小怪，这正是 Web 服务技术和面向服务架构尝试共同解决的问题， 它希望能够提供类似世界语的东西和规则，使所有这些系统都可以相互交流（几年前，人们提出了一种与定义字符串的自定义字节相比，费用更低、且更灵活的方 案，但这种方案的控制难度大大增加）。当然，随着层出不穷的新技术趋向于掌握在技术人员手中，他们越来越因所掌握的业务知识而变得不可或缺，更不用说他们 的业务应用程序知识，但明年的新闻就很难这样了。“那个留着胡须、穿着灯芯绒裤子和 Arran 上衣的家伙是干什么的？”（我们还未谈及客户端或小规模系统及其相关内容。）

“显而易见，这是奇谈怪论”，您一定会哈欠连天地这样说,“这与 Weblogic 和事务又有什么关系呢？”我马上就会讲到。

好，请保持注意力，不要不耐烦。

BEA具备在 Unix 系统中解决 J2EE 和 COBOL/C/C++两方面问题的应用程序-服务器技术，这应该是读者所关注的范畴。众所周知，WeblogicServer 是业界出色的 Java 应用程序服务器，如许多人所知，Tuxedo同时也是业界非主框架应用程序服务器方面技术领先的 C/COBOL/C++ ，那么这还有什么争议呢？大公司都迫切希望具备 Java 和非 Java 开放系统环境方面的专门技术（以解决这两方面的问题）。很明显，利用开发人员创造价值的最佳方式是让他们做自己擅长的工作，无论培训教材多么完善，您都不能指望 C/Unix 方面的专家一夜之间成为 J2EE 方面的好手。最好还是让他使用它精通、热爱并使用了很长时间的 C 编程，然后迁移到现今的 Java 环境。无论他处于什么阶段，BEA 都能够为他提供应用程序服务器，以肯定他所作的工作，使他在将注意力集中于业务规则的同时，具备所要求的伸缩性和可靠性，他的努力将使业务的价值增加。以下就是一个技术迁移的方案。

打开端口并侦听 HTTP 请求不能解决问题

大公司也可以寻求将基于服务的界面融合到以往的 Unix 代码中的方法，以便以性价比更高的方式将基于服务的界面包括在新的互连世界中。对于它将使用的语言来说，Web 服务是关键，但运行时特性又会怎样呢？如果新的面向服务的界面对以前的逻辑发出了大量的请求，那么仅仅打开一个端口并侦听 HTTP SOAP 请求并不能解决问题。需要运行时基础架构来限制并平衡负载，这时我们不可能在运行过程中对生成的在线系统进行控制。一个好的办法是将以前的 C/COBOL/C++ Unix 代码迁移到应用程序服务器环境。我们都认为（我早已宣称并引述过）Tuxedo 是出色的 Unix 非 Java 应用程序服务器环境。所以我们引入 Tuxedo 来为现有的业务逻辑提供新级别的可伸缩性和可见性――一种技术更新的方案。

两个方案之间共同的线程是这两个方案都具备 Java 应用程序服务器（且您的用户只选择 WebLogic），并且 Tuxedo 共存于一个可操作的环境中。

所幸 BEA 了解这一点。WebLogic Server 具备一种名为 WebLogic Tuxedo Connector (WTC) 的技术。其唯一目的就是允许您（从运行时的角度）以单个逻辑平台的形式查看 Tuxedo 和 WebLogic――在管理配置定义了连接性之后，消息能够根据需要来回传递。在技术迁移方案中，这样做能够从已开发的资产中获得最大的回报――在Tuxedo 中使用 C 或 C++ 开发的内容现在不需要使用 Java 来代替，因为可以在 Java 代码中使用它们。混合了不同技术的开发团队可以使用新的（或现有的）以 Java 和非 Java 语言实现的应用程序无缝地结合起来。对于技术更新方案来说，连接性是一个明确的要求，正是它促成了整体协作。

有人在议论：“等等，我认为 SOAP 是集成技术的方法，您怎么能够违背事实大讲特讲 WTC 呢？应该是 WLS，我还知道有第三方提供的基于 Java 2 Connector Architecture 的、富有竞争力的产品！”趁您还没有较真，我来讲一下这个问题。

WTC构建于 J2EECA 之后，但从这个意义上讲，它不可能是 J2EECA 的一个实现，我在开始已经讲过，它是双向的（这点与标准的不同），至于 SOAP 和 Web 服务，我们不打算使用标准的，因为它们目前缺少企业级解决方案所需的某些功能。其中缺少的一项（最后我将在我的专栏中将其作为一个主题来讨论）就是事务！

最后谈一谈 WebLogic Tuxedo Connector 能够在 BEA WebLogic 和Tuxedo 环境之间传播两阶段提交事务。我认为在使它们成为逻辑上合为一体的平台（我想这只是我的看法）上，这一点是隐含的。我不知道市场上有什么替代产品（虽然他们声称这些产品是基于标准的）能够完成这一工作。他们都声称支持事务，但他们的意思是可以从 Java 端启动 Tuxedo 事务，而不是传递其中的事务（或向它传递事务）。在迁移方案中，需要同时进行原子类型的更新，其中这两种技术已经计算出要持久保存的数据，要知道该方案与混合使用不同技术的开发团队有关。我需要完全采用两阶段提交技术，并且希望它能够跨这两种技术起作用。WTC 能够做到这点。如果所有将进行互连的系统都能够以足够松散的耦合方式存在，并且它们根本不需要存在于同一个事务中，那将是很理想的情况。但事实并不总是如此，在WS-Transaction 实施方案面世之前，我们只能使用 WTC。

哦，别忘了客户端，即小规模的情形。如果它们能够将其PowerBuilder/Delphi/VisualBasic 之类的技术应用于此联合的应用程序环境，岂不是一件美妙的事情？抱歉，我肯定忘记了这一点……那就是它们完全可以这样做。有了BEA WebLogic Workshop，它们不仅能够通过一种开箱即用控制技术访问基于Tuxedo 的资源，而且因为它们的劳动成果运行于 WebLogic 之上，它们的事务可以像其他任何人一样在以往和新的技术环境中传递。

总之，WebLogic Tuxedo Connector 是一项功能强大的技术（可能有些夸张）。它能够利用事务（和安全性）将 WebLogic 和 Tuxedo 环境连接起来，它最大限度地为您提供了这样一种能力，那就是在使开发人员工作量最小的前提下，充分利用在 Java 和非 Java 环境下的开发成果。