|
|
WebLogic应用服务器的最新版本可以以您梦想的方式将企业联为一体。作为BEA公司CTO的Mark Carges揭示了对共享服务的期望和希望
Mark Carges新就任BEA公司CTO数月之后，WebLogic应用服务器的9.0版本Diablo问世。BEA公司将Diablo描述为“即将发行的WebLogic Platform 9.0的基石”，将为互相连接的不同系统和运行的任务关键型应用程序提供下一代集成组件。在这篇WebLogic Pro的独家专访中，您可以了解到除了满足客户在SOA、共享服务、管理和组织模型方面的需求之外，Carges就技术背后细节的更多谈话内容。
WebLogic Pro：您最近谈到了服务问题和共享服务概念的含义——是一种宏大的方法。也许您能够描述一下在BEA公司时和这之前，您个人所从事的工作。
Mark Carges：
在来到BEA公司之前，我在Novell公司工作，在那里我使用的后台全部是Tuxedo。20年前，当我在贝尔实验室工作时，我参与了Tuxedo的创建工作。后来我又在UNIX System Labs工作了一段时间，然后再次回到了Novell。1996年，Novell想再次出售Tuxedo，而BEA决定购买它，这个时候，我作为Tuxedo的一员加入了BEA公司——但之后，我很少过问Tuxedo方面的事情。大部分时间，我都在介绍新的工作产品，把我们和我们的门户团队所获得的成果融会贯通。呆在销售团队中的最后两年时光里，我们开始实施我们的全球账户计划，即基本上与我们在世界范围内的前20家客户的销售团队打交道。然后到了8月份，我就转而担任现在这个技术职位。
WebLogic Pro：我们想试着弄清楚中间件的角色，请您站在发明者的立场谈谈它在整个面向服务架构中所处的位置。
Carges：
根据我的经验，我非常清楚客户如何考虑采用SOA，以及我们必须帮助他们完成的事情。我们的一些客户并不热衷于技术。对于他们之中的一些来说，技术只不过是它们需要用来转向SOA的一小部分。不必让这些人深信它的优点。他们知道SOA的问题，因为他们面临这个问题已经很多年了——事实上有几十年了。之前他们已经尝试过要这样做，但是现在只有通过技术才能达到目的。但是当他们进行尝试的时候，他们又遇到了各种其他的问题，比如管理，比如组织模型不够用。
CIO们通常会问，“如果我准备进行共享，那么谁会为此付帐呢？”让我们试着看一个例子。我们假定有三家企业，同时我有一种准备提供的服务。我是服务企业，您是销售企业，而那边是营销企业。我可能会说，“与其让其余的公司使用这项服务，不如让我们每家公司都配备它，但是如果我这样做，而你们开始使用它，它将对CPU提出新的要求。我可能必须从软件厂商手中购买更多的许可证。谁将为此付帐呢？”我公司的管理模型会说，“这就是我们如何为其缴税或者为其提供资金或者……”事情就是这个样子。您参与了所有这些十分有趣的事情。
另一个始终要面对的问题是组织模型。如何针对SOA进行组织呢？我们给出了这个问题的答案。BEA是技术提供者，而且我们进行了像下面这样的对话，“您能在其他公司在管理方面已做的工作方面给我一些帮助吗？”这与技术无关，但是它关系到必须采取那些最初的步骤，以便跨企业共享服务——在组织和设置它们之前，而且它们的整个管理模型都以竖井（silos）为中心。他们不得不终止这些，而技术不过是其中的一部分而已。他们都必须步调一致。如果技术过多地领先于管理，它就不会得到采纳。
WebLogic Pro：有一个因素可以减轻那些财政责任监督人对于谁该付帐这个问题的担心，即从IT最近三四年以来所经历的事情发展而来的税收趋势的可能性。使用Web service和松散耦合类型的架构能够从成本中心转换为收入模型。您见过这种情况发生吗？
Carges：
情况并不是这样。服务类型正好可以作为那种情况没有发生的有力例子。公司往往以一种相当黑白分明的模式转入SOA。通过共享像安全性、单点登录和日志记录这样的水平通用服务——应该重用而非重新发明的现今企业的任何功能部分而转入SOA。这些内容与业务没有很大的关系，它们也不会与税收趋势有任何关系。但是，因为您可以共享它们，而且只需要编写一次，就可以在整个企业中使用它们，这样就削减了IT预算的很大一部分成本。我将这些称为水平的通用服务。
业务域服务当然不止这些。例如，如果我是一家银行，而且假定我想享受某项信誉调查服务，那么银行有多少个部门已经编写或使用过这种服务？如果我享有集中式信用审核、贷款批准或者其他类似服务，这些服务更特定于某些业务，而且更加靠近业务更关心的内容。它可能更近似于税收，无论它是什么，在这种情况下，可以及早对其进行调整。
但是，正如我从刚进军SOA的公司（它们通常从一些通用服务开始着手）中所看到的，SOA通常会给IT发展带来帮助。已经有了一些对SOA的反馈，“哇！我们将安全服务放在网上，现在，每个人都可以共享相同的安全服务，真的很有帮助。接下来我们可以做什么呢？”也许他们会一头扎进这些纵向业务领域。
或者说他们真的让整个公司开了眼界，他们说，“看，我们现在只需要通过一个贷款批准过程。这就是您要的东西。这就是服务，您可以将它用到所有您能用到的地方。我们要维护它。我们了解拨款模式。”随后他们又说，“如果您能解决自己的信用审核问题，那么我们是否也能解决我们自己的信用审核问题呢？”然后，他们从业务服务开始着手，可能随后还添加了一些通用服务。事情往往都是这样的，2.10s版本中的某一特性似乎赢得了公司的最初印象，因为如果它工作得很好，组织会为它制定一个蓝图。他们说，“这就是三年来我们想要的东西。我们想享受所有不同种类的服务。”
不过，我从没见过任何组织仅仅为了做SOA而做SOA。您绝对不会听到一个CIO说，“我下个月将做一个SOA项目。”他们保留了四五个大的项目。“我们正在进行销售自动化，无论怎样，我们打算付请这些新的应付帐款。”作为这其中的一部分，他们打算做SOA并结束该项目，然后离开。“现在，我们将这三项服务看作是实现这个SOA项目的一部分，并且让其他任何人可以使用它，这样，我们就可以做另一个项目了。我们可以利用该项目中的一两项服务，然后再生成两项服务。”
因此，它是一个蓝图模型，管理人员可以从中获得今后两三年内需要做什么的一个蓝图，然后他们可以用一种逐步发展的、一个项目接着一个项目的方式来实现这个蓝图。这种技巧就是服务的意义所在，您可以公开这些服务，以便以后重用，或者将以前项目中的服务组合成新的服务。新的服务会很好用，正如我们所见到的那样。
WebLogic Pro：在销售领域呆了一段时间以后，您又回到了生产领域。如何构造Diablo来提高促进或鼓励Radius发展的能力呢？
Carges：
有两件事要说明。首先，因为目前人们把扩建Web 服务作为基本的表示这些面向服务的架构的方法，所以已经有了一些来自BEA平台和其他平台的非常常见的标准，这些标准定义了什么是Web 服务的基本SOAP消息和WSDL。但是当一些企业试图进行更复杂的通信时，并非所有事情都只是一个简单的请求和应答可以解决的。
例如，与其说您可能想拥有一个对话类型的方法，不如说您可能想拥有一个更能持久不变类型的消息传递方法，在对话类型方法中，问题并不仅仅是一个请求和一个响应。我们必须在WebLogic Server中构建新的功能来支持一些新的Web service，确保我们已经获得客户想要和需要的基础架构，这些新的功能包括可信赖的消息传递、新的安全服务和新的Web service策略等。在应用程序开发人员开始扩建其服务，并且想在自己的企业中利用这些服务做更多的事情，以满足他们必须满足客户的一些灵活需求时，他们可以这样做。因此，必须通过应用服务器和Web service堆栈公开的技术堆栈必须更丰富一些。
WebLogic Pro：这是基于（比方说）JMS的。那么JMS是SOA的主干吗？
Carges：
是的，JMS实质上确实是SOA的主干。我们必须确保自己在一组Web service标准之上，因此，JMS是给出提示、发送和接收消息、存储和转发消息、持久存储消息等方面的主干——所有这一切都是基于JMS的。我们已经投入Diablo的许多投资都是围绕着如何使JMS更好、如何使其更快而进行的。我们添加了一些存储和转发功能，这样，您就可以让不同的应用程序和不同的域共享消息，而无需担心阻抗错配问题。如果我发送了太多的消息，而您还没有准备好接收它们，那么我可以存储和转发这些消息，而您可以适当地采用拉（pull）或推（push）操作。当您对诸如新的Web service标准之类的事物进行分层时，这类功能可以使互操作变得更容易一些，当您可能无法总是与您的信使（messenger）进行实时通话时，这类功能还可以使您获得可靠的通话质量。
WebLogic Pro：如何向开发人员公开这一点？通过Workshop？还是说这更像是Framework要解决的问题？
Carges：
可以用多种方式公开它。其中包括编程API，所以我可以使用JMS编程来公开它，但是，也可以用一些行政方法来公开它，这些方法对编程人员而言是透明的。
WebLogic Pro：这些方法更具声明性吗？
Carges：
是的，并且您总是需要单独考虑这一点。您必须考虑标准方面的某些事项，这些标准必须是标准兼容的。还有一些您希望能够配置、声明和说明的管理功能，“好了，这就是我想让存储和转发进行工作的方式。”一些开发人员可能甚至不知道正在发生什么。他们只想“Fire and forget（发后不理）”：发送消息之后，确保该消息将发送到正确的地方，然后就不再理它。如果从管理的角度，沿着某人配置消息的路径来处理存储和转发问题，或者处理持久性问题，那么您可能希望所有问题都是以配置为中心的。您或许不想去开发它，因为明天您可能想更改它，并且仍然想让程序继续工作，即使今天它具有更为紧凑的耦合形式，但它明天可能具有更为松散的耦合形式。我们想让开发人员解放思想。
WebLogic Pro：我要问您一个具有竞争性的问题。实际上您已经使用IBM和全球服务作为IBM的监视平台，那么您怎么还要从自动功能到为开发人员提供的功能，对这些进行攻击呢？您为一些低级基础架构上的开发人员提供服务，允许他们创建更易于监控和转出的开发框架吗？
Carges：
最终，解决这个问题的最好办法是让事情变得更简单、更易于实现，而不管通过管理功能、配置工具或管理工具获得的程序界面如何，这样会需要更少的员工、更少的编程人员和更少的编程工作。在处理客户需求的时候，BEA软件必须提供完全开放的标准，这样客户才有使用我们的技术的权利，但是，如果客户想将他们的应用程序移动到其他地方，那么还需要能够随后转移这些权利。
客户想让他们可以做的事情得到保证，因此我们还要为他们提供一些从其他地方无法获得的保证，因为我们的软件是开放的，并且客户是可以移动的。我们不销售硬件，并且我们没有与IGS等效的产品，所以我们的目标不是在站点上投入更多的硬件和更多的人员。这意味着我们可以销售软件，这不需要太多的硬件，并且需要较少的人员就可以把工作做完。我们认为这也正是吸引客户兴趣之所在。
在BEA，我们可以看到，“我们如何做一些事情，让编程所需的时间更少？”您可能熟悉最近的一些研究。Gartner查看了这类节省出来的时间，节省出来的时间是在集成的应用程序平台套件和集成的IDE之间，对比不止一处，Gartner发现，公司至少节省了20%的时间，差别在于花4天时间完成一个项目还是花5天时间完成一个项目，对于IT预算来说，这个差别是非常不可思议的。我们一直在寻求如何帮助您从平台中获得更多好处的方法，以及一些事半功倍的方法。
WebLogic Pro：这些是开发方的考虑事项。部署方又如何呢？
Carges：
部署方也一样。我的意思是说，在整个领域都一样。我们已经在Diablo中放入了一个新的管理框架，该框架以我们的门户技术为基础。我们将告诉全世界，为什么对于在适当时间拥有适当权限的适当人员而言，使用门户获得正确的内容是如此重要，这是门户的所有特点，也是人们喜欢门户的原因；您可以个性化、定制和实际加工信息，以便将它提供给适当的用户。
同样的主题也可以应用于管理员、操作人员和那些与应用程序生活在一起的人们，因为如果您愿意的话，您可以花6个月的时间构建一个应用程序，然后花6年到16年的漫长时间与它呆在一起。好的应用程序在生产阶段就要花很多年的时间。在与该应用程序一起生活的这段时间，您可能希望确信自己拥有一个非常健壮的管理、维护、监控和推动应用程序向前发展的环境。
如果仔细观察Diablo，您就会发现，我们在您需要的应用程序质量上投入了大量的关注。比如说，我们适当地添加了一个基于门户的新的管理环境，这意味着您可以进行诸如对应用程序的不同方面进行个性化访问之类的操作，规定谁可以看见哪些内容，等等，您还可以利用一个非常常见的、众所周知的框架（门户结构）来完成这类操作。我们做我们的，客户做客户的；这种感觉好极了。
我们在Diablo中做的第二件事是我们喜欢称之为“自由分裂（disruption-free）”的应用程序升级。人们在企业中碰到的最大问题之一是生产应用程序，不知何故，人们对它有点操之过急，一些企业想使用一些新的应用程序，或者说它们将修改自身应用程序中的一些bug。它们想生产新的应用程序，并且不想有任何停机时间。在回过头来察看我自己的编程职业生涯时，我发现，在创建Tuxedo的时候，用大型机可以做到这一点。也就是说，“我们如何可以在这个新建的基于Unix LAN的环境中做到这一点，这样我们就可以获得与大型机相同的质量，因为它们都在数据中心里。”好了，我们已经在Tuxedo中做到了零停机时间，现在，通过使用Diablo，我们在数据中心中也可以做到这一点。
您可以查看一些新的Java技术，这些技术至今已经有八九年的时间了。人们期望从这些技术中获得更多的东西。好了，我已经安装了所有这些基于Java的应用程序，并且安装了所有J2EE应用程序，它们将陪我度过很长一段时间。我需要某种与大型机或Tuxedo相同的质量。
如果您想了解现在正在流行什么，Diablo的回答如下所示，“我想在相同领域、在与当前集群相同的集群中生产新版本的应用程序，同时还想并行地进行重新部署，这样，我就可以使用这个新的应用程序，并且可以抓住所有用户，让他们使用新版本的应用程序，让老版本的应用程序退休。如果新版本有问题的话，我可以收回它，让所有人仍然使用以前的系统。”这些就是投入新的应用程序生产时您期望在数据中心中发生的事情，无论该应用程序是用COBOL语言、C语言还是Java语言编写的。这些也正是我们在Diablo中提供的一些品质。
WebLogic Pro：这有某种蒙事的感觉，可以重新糅合这种想法，只要不让站点倒闭就行。
Carges：是的，就像在卡车开着的时候给它换轮胎一样。
WebLogic Pro：
将这些带入下一步，谁在站点上实际改进或测试新的功能？
Carges：通常，IT组织所采用的方法是：开发人员开放并测试其应用程序，但随后有一个试制区，在这个区域中，开发人员有时可以集成测试环境或试制环境，然后在这些环境中生产应用程序，并且必须在那里进行分级（staging）。我们必须注意客户通过测试应用程序并分阶段生产这些应用程序、在他们的开发过程中这样做的方式，因此，我们为他们提供了他们所需的工具和能力。这超出了开发人员应做的范围。也就是说，“作为负责将这些应用程序投入生产、然后维护并增强它们的人员，我能以某种不妨碍我的业务、不需要大量员工、不会带来大量停机时间或者其他可能不好影响的方式来实现这些吗？”所以，我们关注的重点在于此，而不在于我们的竞争对手，他们实际上不重要。
WebLogic Pro：如何将这项技术与Diablo中已经实现的技术进行比较，并将它与WebSphere和其他您认为在市场中很重要的技术进行比较？
Carges：
我们已经走在前沿。我并没有看到我们的竞争对手已经注意到这类问题，并且我们打算设置障碍来阻止他们赶超我们，不管这些障碍是性能障碍还是可用性障碍。您可能经常听到我谈论RASP：可靠性、可用性、可伸缩性和性能。我们的客户有他们自己的应用程序，并且他们可能从没停止使用自己的应用程序。如果那些应用程序不那么有价值了，我们就会赢得这些客户，但客户对他们以前使用的应用程序很有感情，这一点是我们无法取代的。
我们要做的就是对他们说，“您可以从WebLogic应用服务器的9.0版本中，也就是从Diablo中找到一些方法，您不但可以升级应用软件，还可以升级系统软件。” 我们公布了9.X，这是一个新的特性版本，在将来的某个时间，我们还将公布9.1版本。用户可以开始将这个版本引入相同的集群，开始慢慢地替换其集群的各个部分。他们可以将Diablo全面向前推进，并且可以跨越任何他们想要的时间长度。他们可以用9.0版本替换任何东西，并且可以让9.0版本全部变成9.1版本，或者是9.X版本。假如能够更改系统级部件、应用程序级部件（所有更改都是发生在一切都在变化的时候），或者能够进行故障转移、能够备份，等等，那么这项技术将真的引领市场前沿。
WebLogic Pro：您是如何看待这种趋势对虚拟化、Great Computing和自主计算的影响？
Carges：
这是一个大的话题。
WebLogic Pro：您个人而不是公司对此所持的观点是什么？
Carges：
这里的目标是更好地利用您所拥有的硬件资源。典型的环境是：当您已经获得一组已经跨所有CPU部署好的应用程序的时候，以及在任何您想获得一幅快照的时候，只有20%的时间CPU在被利用。因为您具备应对高峰期的能力，所以，当高峰来临的时候，您可以确信自己能够战胜它。因此，这里的问题是，“如何才能更多地利用所有这些技术以及所具有的CPU能力？如何才能利用应对峰值的能力？”
更有效地使用这种能力的目的是为了有效使用所拥有的计算机，在这些计算机上使用更多的应用程序。这里存在的问题之一是：如果动态地在某一台机器上装载了许多应用程序，并且其中的一个应用程序开始出错的话，会不会影响到其他应用程序？通常，这个问题会让人们蠢蠢欲动，他们会说，“好了，我只想要我的那20%，而不是要全部，因为如果某个应用程序出错的话，我不想让它影响到其他所有应用程序。”
WebLogic Pro：您提到了RASP。
Carges：
是的：可靠的、可用的、可伸缩的和性能。我们曾开玩笑说应该将这些纹到所有工程师的左肩膀上。
WebLogic Pro：在开始的时候，您曾提到过在您的另一个肩膀上纹上“开放标准”，那样做有什么意义？
Carges：
无论是J2EE标准或是Web service，也无论它是开放系统、开放标准支持，或是协议标准和XML标准，我们都会提供这些标准的实现。因为它们是开放标准，所以我们必须提供市场上所拥有的最好的实现；如果我们不能提供和其他竞争对手不同的最好实现，那么我们将没有东西好销售，我们的竞争对手会销售别的东西，或者用其他东西作为他们的主要业务模型，比如说服务或硬件。如果我们不能在市场上提供这些标准的最好实现，那么人们为什么还要来BEA呢？
WebLogic Pro：这有点类似于Borland公司对工具的论调，是某种相似的类推吗？
Carges：
我只是在谈论开放标准。我不知道其他对这些标准的同等评价是什么。
WebLogic Pro：Oracle已经进行了一些投资，如果您愿意的话，您会围绕工具加工在开放标准方面进行一些尝试吗？或者说，其中有些游戏的成分在里面？
Carges：
如果观察一下应用服务器，您就会发现，您所依赖的主要编程标准是J2EE标准。去支持那些最新的J2EE标准吧，比如说Diablo中的那些标准；或者说去支持1.4版本，它是比较合适的最新的J2EE模型。
WebLogic Pro：还有其他一些1.5兼容的技术。
Carges：
是的。
WebLogic Pro：那些技术是什么，举例说明一下，为什么选择这些技术？
Carges：
人们期望获得所有Web service堆栈。支持可靠消息传递、安全性、策略和大量新的Web service标准在这里很重要，并且，通过在适当的地方建立这些标准，当客户去BEA的时候，他们总是期望从那里获得一个标准兼容的应用程序平台，在该平台上构建应用程序。这需要Java技术，还会需要一些Web service技术，等等。比如说，在门户空间中，我们看到，门户空间中不仅包含应用服务器，还包含一些新的标准，比如WSRP、Web service远程门户等。我们已经在8.1产品中获得了这方面的支持。在未来的9.0产品的门户版本中，会有更多改进。
WebLogic Pro：9.0版门户的名字是Diablo，那是什么？
Carges：
Diablo是应用服务器的代码名。9.0版门户最终将公之于众，它会对WSRP之类的东西提供更多的支持。还有一些来自Java Community Process的门户标准。我们倾向于采用现有的标准，或者将我们的创新引用到标准体中，然后展示它们。例如我们已经提到过的注释标准Diablo 181，这些标准是从围绕Workshop中的注释而进行的工作中得出的，它们可以使在Java应用程序中创建Web service这类操作更容易一些。然后，我们将这一思路用在了Java Community Process上，于是就产生了JSR 181。
WebLogic Pro：是BEA在领导那个工作组？
Carges：
是的。当然，这些实现在进入标准发展过程中时，经历了塑形和改造，因为您让其他人产生了他们的想法。我们必须确保即使有一个实现，该实现也是当前最新的实现。9.0版本可以更好地支持181。如果您想回到那一点上去，标准从某个方面来说意义重大，但是，如果我们提供一个基于标准的产品，而该产品不可伸缩、不可靠、不能指望并且性能不好，那么该产品不会十分有用。
WebLogic Pro：所以，从竞争方面考虑，您必须拥有该实现，并且必须是这一领域的第一（个）。
Carges：
是的。这就是它们具有可靠性和可用性的原因。开发人员要进行两次纹身：在一条手臂上纹上开放标准，在另一条手臂上纹上企业可以指望的一个真正的实现：RASP。当您向依靠我们销售给他们的产品来运营的企业销售2000个全球帐号时，这东西必须好用，因为我们已经没有其他任何东西可以卖给他们了。我们在自己的整个企业中实现了这一点，想一想我们是怎么做的，最终，其他公司和IT组织也会构建或购买自己的软件。如果他们购买软件，他们会去外面购买已经打包好的软件。他们说，“这是一种战略，这很重要。我不需要自己构建软件，可以去外面购买一个节约我大量时间和金钱的软件包。然后将这个软件包安装在适当的位置，一切都妥当了！我不需要花钱开发一个新的HR系统，我可以购买一个ERP系统。”
但这是他们的战略，他们必须构建软件时采用的策略。当您考虑到BEA所建立的功勋（从Tuxedo到WebLogic）的时候，当用户编写代码的时候，无论是编写C代码、COBOL代码、Java代码，还是目前通过元数据和所有这类信息使用XML来编写代码，BEA基本上会在所有企业发展所需要的地方都为他们提供了最佳容器。当然，还需要逻辑和数据。
现在来谈一下数据…，我们并不是在一些数据库企业中，这些企业是指Oracle、DB2和Microsoft，他们都拥有所有的数据。当企业开始编写业务逻辑或以某种方式构造业务逻辑时，他们选择编写业务逻辑但并不构建它，这正是BEA要做的事，我们在这些地方提供了最佳实现。这就是我们转向应用程序服务空间的原因。为什么我们要转向门户市场呢？当人们开始编写门户，并将他们想让其JSP如何做的逻辑添加到流程、页面流和Struts模型中之后，BEA必须提供用于这些方面的最佳实现。然后，在需要使用标准的地方，我们添加了社区，帮助人们进行运作，现在，这些标准既可以是Java标准，也可以是WSRP标准，它们正被许多组织所采用。
WebLogic Pro：根据对BEA正在进行的整体推进的介绍，站在中间件一方的立场上，您是如何看待在消息传递一方获得某种基础架构的可靠性和可伸缩性的这种转换？这类转换依靠大型机来启用Tuxedo。BEA在转向Web service领域方面是多么成功啊，这是根据你们的核心发明进军面向服务的架构的开始？
Carges：
我们已经发现了这一点。通常，我们的做法是：观察所有不同技术领域和可用的标准，查看如何将它们引入到生产当中，对客户而言，这会带来显著的差异。如果观察8.1平台，您会发现，围绕它的主题是，“任何才能有一个允许我轻松构建并消费Web service的平台，这样就可以考虑拥有一个面向服务的架构，可以用自己的面向Java的工具和类似Workshop的工具来创建服务并将其公开，或者从组织的其他部门、甚至完全从其他组织来消费服务？”
我们添加了许多对新的Web service标准的支持，并适当地添加了一些Workshop工具，还通过该框架将不同部分紧密地结合在了一起。而后，随着8.1的推出，我们发现，一些组织在开始采用新的方法来迁入SOA的同时，他们发现自己遇到了新的问题，尤其是一些技术方面的问题。如果将管理、组织和类似的问题推到一边，置之不理，另外一些问题又会跑出来，如果有一些应用程序，而这些程序都在生产和消费服务，那么，作为IT管理人员，我要怎样做才能知道我的组织正在干什么呢？我如何了解这些情况呢——如果我让每个人的用于借贷源（loan origination）的计数器回到实用程序模式下，如何做才能确保这样一直有效呢？如果每个人都使用它，如果我处于孤立状态下，而应用程序又出错，那么您和我都将无法工作。其他一些应用程序开始走向没落，但我们的应用程序仍将继续。
WebLogic Pro：他们都使用共享服务？
Carges：
大约八分之一的人将构建和创建服务。我们将在9.0版本中构建一些服务和一些我们将使用的其他技术，比如Quicksilver，所有这些都将帮助您管理、部署和可视化所有您现在想要部署并与之交流的那些服务。
Quicksilver（打个比方）实际上有点与BEA背道而驰，它不是一个适用于Java开发人员的工具。它是一个用来配置和管理将放置在一起的Web service的工具。从某一方面来说，它可能是您已经在8.1平台上构建的一个基于Java的Web service。而从另一方面来说，它可能是某种您正在构建的东西。它可以是网络，或者是公开为Web service的某个已打包的应用程序。您所需要的是可见性，因此，它并不仅仅是spaghetti，在spaghetti中，仅有一个服务将调用另一个服务，并且您不能对此进行任何处理。
一些IT组织说，“好了，如果出现这种情况，并且开始共享更多的服务，那么我需要在这方面有更高的可见性。”Quicksilver允许您配置这些端点；它允许您查看不同的策略，比如安全策略。在什么地方设置安全策略以及某些事情没有发生时出现的异常？您一定不想在端点上处理这类事情，可以在外部处理它们，这样您就具有管理它们的灵活性。Quicksilver将企业服务总线或ESB类型技术与Web管理技术放在一起同时提供，因为在人开始更多地使用SOA的时候，我们发现，他们将需要这项技术。我们会在提供Quicksilver的同时提供这些功能。
WebLogic Pro：在对新的一年的十大预测中，我读到了一点不好的东西：企业服务总线被过分夸大并且表现不佳。是真的吗？我并不真的认同这种推测，但我很有兴趣想知道您是如何看ESB的。因为IBM支持ESB，ESB现在已经进入社区，它只是某个厂商的想像事物的虚构吗？或者说它是您将要看到的一些事物的更基础的东西？
Carges：
像绝大多数事物一样，它们是一些前沿技术和前沿方法的基础元素，对此，很多人发表评论说，“在我们使用企业服务总线和类似的东西时，它们和我们平时用的东西有什么不一样吗？”但是，其中还有一些新的元素，这些元素通常是由新技术和新标准的加入带来的。
WebLogic Pro：这些新技术及新标准与什么东西比较类似？
Carges：
在特殊情况下，它们类似于Web service标准，但之前，企业中并不真的具有这些标准。请考虑这样一种情况：我拥有所有这些应用程序，然后突然间，不管是已打包的应用程序、大型机应用程序，还是Java、Tuxedo或.Net应用程序，如果所有这些应用程序都可以公然声称，“这是我提供的，这是我的服务，您可以来我这，把它拿去用，”并且它们能够以某种常见的方式做到这一点，那么它们与WSDL是类似的：它们都遵守一组Web service标准。如果突然间公开了所有的通信类型（这正是我想通过spaghetti表达的），而IT组织没有跟进并管理这些类型，那么您会发现，所有的事物都开始相互指责、相互依靠。
耽误您一会功夫，让我们来举个例子，假如您购买了一个服务并公开它，然后您想更改它，或者将它束之高阁收藏起来，同时您甚至并不知道我正在使用您的服务，这会为企业带来一大堆的麻烦，因为我停止了构建自己的服务，在使用您的服务。这地方比较新鲜，因为现在您拥有决定是否进行共享的权利，并且您确实需要一个控制共享的方法，这样，您才可以获得更好的性能和更大的吞吐量，并依靠服务水平协议和其他类似协议将一切安排妥当。
WebLogic Pro：将管理问题先放到一边，因为在公司内部的某些级别上，这是CTO的职责，比如，他们会说，“是的，这是我们的资源，是我们的共享服务，并且这就是将分配这些资源的方式。”现在转向技术方面，用BEA平台，特别是Quicksilver，来解决这个问题怎么样？
Carges：
Quicksilver尤其具备配置通信的能力。Quicksilver配置的是关键字。我不想编写代码，也不想让开发人员为了那些服务应该如何与其他服务挂上钩而烦恼。也就是说，我想与服务通信，但不想进行一些数据转换。我想使用Quicksilver在这些服务之间进行一种格式到另一种格式的转换。也就是说，我想为服务设置安全策略，决定哪些人将使用它，还想实现粒度安全策略，例如，可以这么说，“好了，我们可以使用它，但是，某些元素您可能可以看见，而另一些元素您可能看不见。我该在哪儿进行配置呢？”
您可能想在代码中嵌入某些东西，并配置另外一些东西，Quicksilver允许您采用这些服务、添加策略、进行数据转换和设置异常。如果服务不可用的话，您希望发生什么？在通信量正常的情况下，又将发生什么？您在哪些地方设置了异常？
您可能并不想要求所有端点都将代码放入其应用程序中，而只是想让那些将要配置的端点这样做。在Quicksilver中，解决这个问题的方法是制造一条流水线，这条用于配置的可视流水线是将要涉及的所有元素的流水线。可以将安全策略看作是流水线的一个元素，将任何数据转换看作其他元素，并查找它们必须通过的某些地方，获得用来存储任何种类的过滤结果的目的地，或者获得用来存储您可能已经有的任何东西的目的地。可以将所有这些东西放在一起，您将真正配置一条流水线。那并不是说“我已经有了一个JMS总线，并且有一些主题和线索，因此它们就可以彼此通信。”从某种意义上说，确实如此，有了一条总线之后，您就可以配置它。
顺便说一下，可以在您可能已经有的总线上运行Quicksilver。我可以在JMS上运行Quicksilver，也可以在其他可能已经有的总线上运行它。我还可以让专有服务与Web service进行互操作，因为可以进行这类数据转换，所以我可以引进还没有制定标准或者还不兼容的一些标准。这是一个非常有效的方法，并且是一个企业型方法，该方法优于我的Java端点、已打包的应用程序或大型机。
WebLogic Pro：它是企业服务总线的控制台。
Carges：
的确如此。我的意思是说，通过它，可以将总线汇集在一起，而且它可以将管理和配置那些将被共享的不同服务的能力结合起来。我们可以像查看平台8.1那样来查看这个控制台，而且我们还为您提供一个构建和消费端点服务的方法。但通过使用Quicksilver，现在允许企业将所有这些放在一起。二者都是您所需要的：您不仅需要一个平台来构建或消费服务，还需要一个平台来管理这些服务。 |
|
