|
|
BEA是Java世界的有生力量，其产品系列包括WebLogic Server、Portal、Integration和Workshop，以及早期的Tuxedo应用程序管理环境。BEA对许多.NET开发小组都很重要，因为他们经常被要求将应用程序（特别是.NET客户端）与基于Java的服务器和Web Services（例如BEA或者IBM的）集成在一起。异构系统表现出了严重的安全性问题，而BEA的Fortune 500客户列表意味着公司不得不积极地寻求基于标准的安全解决方案。BEA已经是这一领域的领袖了，因此.NET Magazine与CTO Scott Dietzen就有关.NET/Java在集成和安全方面的巨大差异进行交谈非常有意义。
在Web Services模型中，缺乏安全已经成为企业接受它们的巨大障碍。在这一领域中，许多标准的引入看来正在为极大地改变利用Web Services的方法创造条件（无论是在防火墙的内部还是外部）。.NET Magazine采访了Scott Dietzen（BEA的CTO），了解他有关未来Web Services安全的局内人看法，这可能正是您希望了解的。
.NET Magazine：行业中的调查表明集成是IT部门主要关注的事情。您认为Web Services拥有能够减轻他们对集成的关注所需要的一切吗？
Scott Dietzen：当然，随着时间的推移，我相信会是这样。我们实际上创造了一个新的术语“Web 2.0”来论述Web Services的动向。到目前为止，Web仅仅是关于用户接口的——在数据和应用程序前端放置的一个浏览器。但据统计，70%可自由支配的IT资金转向了集成系统。我们观察到我们的客户群变得更加复杂。现在，在他们购买或者构建应用程序之前，他们想了解让该应用程序与他们的其他环境一起工作所需的集成成本。
因此，现在IT具有想了解得更深一点的迫切需要。如果您愿意，存在没有“Microsoft的集成”，因为这是如此巨大并且广泛的业务。我们需要标准来使它工作——就像我们围绕Web所做的工作一样。
我们深信Web Services代表了那种动向。但公平地说，还有许多工作要做。我常常告诉客户，他们将发现在Web Services Interoperability Organization（WS-I; 参见 www.ws-i.org）批准的核心Web Services栈内部，.NET和Java世界之间的互操作性是会得到完美的安全保障的。现在，SOAP和XML架构以及WSDL（Web 服务描述语言）就结合得很好。
事实上，最近针对高级的架构，我对我们用户群中高端的40位用户做了一项特别的调查。他们全部声称在他们的产品中有Web Services，用于事务和查询。更为有趣的是，他们中的三分之二声称，利用Web Services，其产品中.NET和Java之间具有互操作性。看来这一点令人激动和满足。
但另一方面，现在仍有缺陷。我们最靠近WS-Security Extension（包括 Policy、Trust、Secure Conversation和Security Policy）所论及的内容。我们还致力于保证传送，又称为可靠消息（Reliable Messaging）。WSRM规范将使您能够发送订单或者（股票）交易，并保证另外一端正确接收——即使通过Internet也一样。现在，Web Services还无法这样做。支撑规范 WS-Addressing将对其有帮助。
我们认为关键的安全扩展是WS-Policy。WS-Policy帮助我们围绕Web Services定义质量更高的服务标准，因而我们知道一个系统可以与其他系统通信，而且可以保证他们无缝地协同工作。
.NET Magazine：目前，提供您客户讨论的.NET-Java互操作性需要做多少工作？
Scott Dietzen：WS-I继续存在，用以定义配置文件。配置文件限制互操作的范围。我们预见实际上正在实践中使用的标准是主流。Microsoft、BEA和IBM创建了该论坛，现在许多其他的公司也参与了进去。
但它是最好的实践论坛以及证据点（proof point）。我们开发商聚在一起进行互操作性测试。事实是大多数开发商在WS-I之前用.NET做这样的测试。例如，今年早些时候我们发布了WS-Security的实现。最近Microsoft把它的实现投入了市场。现在，我们正回头做一些工作以保证我们可以互操作。我同Microsoft开玩笑说：“我们先推出，因此你们应该在投放市场之前，先与我们的产品进行互操作性测试”。但这不是企业的运作方法。
.NET Magazine：安全是所有IT从业人员所关心的一个重要问题，许多人仍然没有将Web Services看作是传递敏感数据的十分安全的方法。这样的理解正确吗？如果正确，还需要做哪些工作？
Scott Dietzen：这有些使人迷惑。但我们应该相信SSL（Secure Sockets Layer），它已经取得了巨大的成功。我相信在Internet上还没有出现过对SSL的成功攻击——只有在实验室设置中有过。
然而，SSL只能保证保密性，对Web Services来讲这还不够。WS-Security 架构优于SSL，包括对委托安全的支持，因此一个系统可以将自己的安全证书借给其他系统。那样，可以以某一具体用户的名义进行交易。这就是您进行单一登录的方法——对EAI（Enterprise Application Integration）技术来说也许至关重要，因为发生的事情是在防火墙的后面。
WS-Security还包括对不可否认性的支持。任何时候，当您提交交易时，有些交易将赚钱，而另外一些可能不赚钱。您需要能够确认并保证该交易是由您的合作伙伴提交的。因此，如果他们做了一笔赔钱的生意，以后他们无法否认它。这是需要解决的一个至关重要的问题，并且将在WS-Security中解决。
为XML文档选择保密也是WS-Security的一个重要特性。例如，我们曾从金融服务客户和联邦政府的一些情报员那儿听到关于这一点的详情。它让人们偷看一下，比如说，帐号而不是这次交易的美元值。这样，即使在业务和金融服务共享计算机和网络时，也能保证他们的独立性。私有信息可以得到比非私有信息更强有力的保护。
.NET Magazine：您认为现在能在防火墙外边部署安全的Web Services解决方案吗？
Scott Dietzen：能。我们有许多客户现在已经这样做了。它的确需要确保端点受到保护。没有与每个端点相关联的强大安全策略，所有的端点都不应暴露在Internet上。您必须保证仅向指定的客户提供访问。总之，围绕运行事务的安全问题比围绕查询的安全问题稍微复杂一些。因而，客户需要看到他们正在做什么。如果它是气象服务，则几乎不存在安全问题。但如果您正在接受业务伙伴的转帐请求，您最好确保所有的安全问题。现在，这是可行的，但客户必须增加投资。
.NET Magazine：在互操作环境中又如何？
Scott Dietzen：当然，也很好。尽管没有完全可以在Internet上互操作的WS- Security ，但客户有时必须要面临一些问题的挑战，但我们解决了这些问题。现在，在我们的产品中，Microsoft和EBA都发布了WS-Security，而我们解决了互操作问题。今天，到大约第3季度，构建新项目的人可以确定他们没有互操作安全问题。那些事情将会解决。然而，可靠地传送和异步消息传递中的一些问题需要花更长的时间。
.NET Magazine：您知道有谁在为需要高度安全的事务使用Web Services吗？例如贸易。
Scott Dietzen：在我对我们最大的客户群的特别调查中，他们全都在运行事务，而三分之二的客户在运行.NET和BEA WebLogic之间互操作产品。我们面临的挑战与Microsoft面临的挑战相同。Web Services是我们投入市场的每一种产品的一部分，而且我们有在WebLogic上运行成千上万个应用程序的客户。因此，找出谁究竟在做什么非常困难。
我最近看到的互操作大部分是.NET客户端与WebLogic服务器通信。那是我们期望看到的采用主流。显然，BEA的力量是在服务器端。Microsoft在客户端方面则占主导地位，在服务器方面份额也在上升。
.NET Magazine：为了在产品中提高安全性，BEA采取了哪些步骤？
Scott Dietzen：我认为我们是第1个在出售的产品中支持WS-Security的主要产品 供应商。我们也在WebLogic平台中嵌入了全面的安全框架，以保护对部署在WebLogic内的所有业务服务的访问。因为它是基于权限的，所以首先在高一层次上实现。默认情况下，我们拒绝访问而不是同意它。市场上的某些技术是基于访问控制列表的，在客户完成使他们隔离（tighten them down）必需的所有安全步骤之前，他们实际上并不安全。我们更喜欢以假定没有访问开始，并在合适的时候同意它。
为了可行地完成它，您必须跨越大粒度应用程序组件实施策略引导的访问。在我们的环境中，客户可以选择整个应用程序或者一个重要的子集，立即为那部分应用程序中的所有组件设置安全策略。然后，在单独的组件中仔细调整安全授权过程。
这使得程序员基本上失去了对安全的控制。我们不要求WebLogic的开发人员了解需要进行的授权。所有这一切都在容器中。因而，程序员既不能故意地也不能（很可能）漫不经心地犯错误，从而导致出现安全漏洞或者弱点。所有这一切都由容器保证。
我们已经做了很多工作——关于世界各地我们的金融服务客户和联邦政府（美国是他们的领袖）是最值得注意的——在于批准我们的安全架构的详细资料，确认它满足电子商务的标准。这是BEA长期关注的一个焦点：自公司成立以来，我们一直在保护高端业务关键型系统的安全。例如，我们曾在SWIFT消息传递网络（www.swift.com）中运行技术，它将数万亿的美元在金融机构中流通。我们对安全的长期关注对BEA的成功至关重要。我认为在我们的产品家族中，从来没有大的安全漏洞。
.NET Magazine：在异构的.NET/BEA环境中工作，安全问题如何变得复杂了？
Scott Dietzen：问题再一次主要集中在互操作上。我们了解利用SSL将WebLogic与Explorer整合在一起的过程。我们认为Web标识的主要技术——特别是Microsoft Passport和Liberty Alliance——将继续发展。但我们喜欢提出一个更统一的Web标识模型，因而我们不必明了所有这些系统的密码。对当前的架构而言，那看来的确像更为安全的选择。
我认为现在关注最多的焦点是Web Services的互操作性，而且Web问题相对好理解。WS-Security是推动Web Services前进的基础。我们非常高兴，我们将彻底地验证与.NET安全架构的互操作性，以便我们可以支持单一登录。那意味着同WebLogic Java 应用程序一样，.NET应用程序在数据库内使用相同的授权可以访问一个数据库。在用户不必做许多额外工作的情况下，WS-Security对实现那一级的共享至关重要。
.NET Magazine：已经与Microsoft合作了吗？
Scott Dietzen：当然合作了。Microsoft对该版本Web Services的承诺是从基本上认可：尽管Microsoft公司很大，但Web更大。Microsoft技术开始与其他技术一起很好地发挥作用。如果这样，对于BEA卖Java，Microsoft 卖.NET，我们将创建更大的IT市场。
的确，在有关协议如何工作的问题上，我们并非总是如我们所愿那样迅速好转。总是有改进的空间。一部分挑战是约束这些规范。WS-Security 是OASIS（www.oasis-open.org）的一部分。OASIS规范不像我们希望的那样严格。只要某一规范的实现符合该规范的文字和规定，它应该自动能互操作的。相反，规范更像计划。他们保留了一些浮动空间。我们和Microsoft以及其他供应商努力工作，目的是尝试约束所有的东西以确保互操作性。Microsoft在台式机方面占据主导位置这一事实是一种很大的压力，因为所有的服务器供应商都必须在桌面上与Microsoft良好协作。并且这样有助于确保我们这些服务器供应商能合作得很好。
.NET Magazine：让我们后退一步，更多地谈谈标准。很多企业表示，在建立Web Services标准方面的连续不断的困难可能阻止他们采用该服务，您认为是这样吗？
Scott Dietzen：这是理所当然的。到达核心标准极其关键阶段的大门将是Web Services的采用。您可以拿出十足的理由将Web构建在如下4个标准之上：HTTP、 HTML、安全的SSL和URI（Uniform Resource Identifiers）命名模型。关于Web Services，我们也有适当建立的核心：SOAP、WSDL、XML架构 …，我们接受WS-Security。
WS-Reliable Messaging、WS-Addressing和至少WS-Policy的某些组件也将是组成Web Services核心所必需的。而且在我们能够看到围绕Web技术的大爆发之前，我们需要该核心。我们的所有努力——我认为Microsoft、IBM和其他开发商的许多努力——集中在扩建并保证这一核心可用方面，并且是可以互操作的。当我们将Web Services包装之后，我们将看到它的快速增长。我想我们快了。
我也是我们所接受的这一模型的一个忠实信徒，借此我们保证在我们设法完全标准化Web Services规范之前，会有技术发布并且可提供商业实现。因而我认为，尽管遇到一些挫折——但Microsoft、IBM和BEA之间协作为企业提供了很好的服务，以便定义这些规范、在我们的产品中实现他们、证明互操作性是令人满意的，然后在标准体中采用他们——不是在开始的时候，而是在利用这些技术获得一些商业经验之后。这样可避免委员会的设计危险，在委员会中，30或40或者50个公司试图一起从零建立一个标准，比起从有80％～90％的方法已经是标准的东西开始，这种方案成功的可能性要小的多。
.NET Magazine：确定（dueling）标准体有问题吗？
Scott Dietzen：有一些。现在，问的最多的问题是World Wide Web Consortium（W3C）和OASIS之间的问题。实际上，所有主要的工作属于两大组：一些Web Services工作在W3C中进行，一些则在OASIS中。现在，WS-I很少有重叠，因为WS-I几乎就是最佳实践了，以确保来自其他体产品（body work）的标准。我们与Microsoft密切合作，设法阻止OASIS和W3C工作中所有可能的有害冗余。我们正在通过Microsoft、IBM和BEA之间的秘密合作，用许多好的技术催生这些标准体。
.NET Magazine：与Web Service-Choreography相比，您认为Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL4WS）规范怎样？
Scott Dietzen：这是标准体之间可能重叠的领域之一，但我们正在与Microsoft、IBM和其他主要公司中的同仁一起努力设法避免重叠。关于这一点，WS-Choreography目前的规章还没有明确。我们正在为劳动的自然分解尽力：BPEL是定义工作流的编程语言，而我们更愿意看到WS-Choreography定义表示互连BPEL工作流的消息流方法。因此，如果您采用需要相互转换的两个基于BPEL的不同工作流，则可以提供规范来保证这些工作流一起良好运转。组合的工作流等价于WSDL。该模型应该工作得很好，但我们要销售有关这一方法的能力，还有许多工作要做。
.NET Magazine：有时间表吗？
Scott Dietzen：有关WS-Choreography方面还太早。我们一定会和BPEL一起发展下去。而且使相对规定得更好的BPEL为我们在WS-Choreography方面取得更大的进步打下基础。
.NET Magazine：作为一个中间人、一位权威人士或者其他的什么人，您怎样看待BEA在标准化进程中的作用？
Scott Dietzen：我们是比Microsoft、IBM或者Oracle小得多的开发商。但是，因为我们的战略伙伴关系，我们起着相当漂亮的平衡作用。BEA与惠普（Hewlett Packard）和 Intel结成了紧密的联盟，使BEA有幸成为它的所有Intel架构的Java平台入选者，无论是Windows还是Linux平台。我们与Sun、Dell、Accenture和其他与IBM竞争的公司有着密切的合作关系。
所以，尽管BEA是一家较小的公司，但我们的keiretsu（日本的有关母公司和他们的供应商之间亲密关系的业务概念），如果您愿意，让我们用优美的、强有力的声音说话。我想，我们和Microsoft 和IBM都被认为是Web service领域的共同市场领袖，在Web平台竞争中走在前面。这还赋予我们某种优势，我们会试图用它来保持我们的地位。
我们在感觉需要发生的事情方面有我们的优势，目的是为了保护投资并为我们所有人开拓更大的市场。标准对市场有极大地影响。Web是目前人们最了解的一种标准，但SQL对开辟更大的市场也有着意义深远的影响。而且，我们正在设法重新炮制Java的成功以及围绕Web service的成功。
.NET Magazine：在面向过程的应用程序开发中，作为一家企业，我们期望看到哪些创新？
Scott Dietzen：我想最大的事情是置入Web Service的面向服务的架构的影响。IT想要这样一个环境：他们可以在业务处理这一级上——如果您愿意，在工作流一级上——以及门户或者页面流一级上（这是我所谓的用于集成应用程序的Web流）工作。您得到一个使业务流程自动化的面向任务的方案——在这种情况下是工作流——或者您想让终端用户参与的面向任务的方案——在这种情况下是用户接口。
这些任务可能涉及2个、5个、或者10个不同的底层应用程序。但您不想让业务流程的开发者和全面检查用户接口的终端用户了解其复杂性。这就是这些技术的全部。
IT内部发生的事情中，关于应用程序集成和设计的工作比关于必须参与并编写应用程序代码完成相同的工作要多得多。这就是集成，这些是组合应用程序。但对我们来说，显然IT想尽可能少地做编程工作就可以将这些应用程序集成在一起，而且IT想更多地进行面向任务的开发。他们喜欢管理性地处理很多事情。例如，能够改道发送Web请求或者改道发送Web Service请求，由于订单价值太高，所以风险很大，因而需要特殊级别的票据交换。只要能够处理，无论何时他们都想处理类似这样的管理性命令和控制问题。当然，我们自己的产品正在向着这个方向发展，并且当您每次想修改工作流或者Web流时，可使您远离其内部以及修改业务逻辑。这些事情比基础业务组件和应用程序需要更大的灵活性。Web Service便于分解劳动，而分解劳动对IT来讲威力非常大。
.NET Magazine：在你们的站点上，有一篇文章标题为“WebLogic and .NET: Making Web Services That Work”的文章，是Guy Molinari写的。这篇文章指出：Web service模型的普遍性要求仍然达不到实用要求。特别是，它的注意力主要集中在WSDL互操作栈问题上和SOAP互操作栈问题上。你们就自动化您的技术支持人员之一在这篇文章中描述的解决方案上做了哪些工作？
Scott Dietzen：我们尽量从我们的客户输入中学习，发现并了解他们在集成化过程中遇到的挑战。我们将这些输入反馈给我们的产品队伍，反馈给Microsoft和确定我们需要做什么的标准体。有人曾用WS-I已经支持的方法更好地处理处于边界上的情况吗？如果您能用它逃脱，那是一种典型的简化。
或者，他们正在做我们实际上没有办法的工作吗？我们最好扩展WS-I中的配置文件，以保证其他客户不再遇到该问题。或者，标准中这一基本缺陷必须在标准体或者我们正在与Microsoft 或IBM合作实现的规范中解决？这是一个正在进行的过程。
客户应该对该承诺有信心，因为所有这一领域的主要的供应商都承认集成是发展平台业务的最好机会。.NET的影响范围和WebLogic的影响范围正在戏剧性地膨胀，因为我们使他们变成了集成化技术——不仅仅是构建Web应用程序的平台。许多资源加入其中，但却只在我们扩展的这种互操作价值标准范围内起作用。Microsoft很好地适应了它，并掌握了它。这就是您看到对互操作和Web Service的这一坚定承诺的原因。
在可移植性方面，我将挑战Microsoft。.NET做了很多工作来支持Windows应用程序。因而，您的读者需要知道这些互操作方面的问题，因为至少十年内，您的服务器环境将是异构的。我们已经注意到在扩建Web的过程中，所有RISC Unix平台的膨胀。现在，我们正观察Linux的增长，并且没有偏离主框架。因此，服务器环境是异构的，我们需要互操作，以实现这样的集成。
想向企业进行推销的独立软件开发商正在使用Java，因为他们希望能使Solaris、AIX、HP-UX、Linux以及Windows所接受。Java技术的价值主张可提供这些，.NET则不行。但所有这些技术将在企业中获得成功。
我告诉我们的所有大客户：.NET和Java将会共存。但在市场占有率上有一场恶战，而且竞争带来对IT更好地服务。相互竞争地结果是Java和.NET 都是更好的平台。.NET借鉴了我们在Java社区中的一些创新，我们也借鉴Microsoft的一些创新。假设我们可以继续承诺互操作，竞争将推动成本的降低和服务质量的提高。我认为任何一个开发商——即使是Microsoft——也不能轻视该承诺。我们看到来自Microsoft的所有东西都反映他们在互操作方面的可靠承诺。
.NET Magazine：从.NET应用程序如何集成Tuxedo服务？仍然在积极地开发Tuxedo吗？在什么场合，人们用它来代替可能更为松散耦合的基于Web service的系统？
Scott Dietzen：自从20年前Tuxedo第1次投放市场以来，Tuxedo实际上具有基于消息的面向服务的架构。Tuxedo是分布式或者商用Unix系统中应用程序平台市场的领袖。客户主要用C和C++编写Tuxedo应用程序。还有一个巨大的COBOL安装库。WebLogic是 Java 的中心，即使Java和WebLogic业务在过去5年中急剧增长，但BEA继续在Tuxedo上开展业务。
但Texedo在继续艰难地提高。我们的一些客户有10年的产品测试标准。对某些业务极度关键型系统，他们部署的都是10年来商用业务关键型产品中已有的技术。没有限定是Java、Web还是.NET技术。WebLogic通过该测试仍需要大约3到4年。这是人们继续购买Tuxedo的原因。Tuxedo还允许他们跨平台进行C/C++开发。
后来，我们在WebLogic和Workshop中，将Tuxedo集成到我们的Web service环境中。我们有一个在Workshop中运行的Tuxedo组件，使得建立任何Tuxedo服务的Web service包装器都很容易。并且由于Tuxedo服务是围绕面向服务的架构而设计的，所以为Tuxedo服务生成SOAP/WSDL绑定很简单。
一旦我们在总体上完成了，Tuxedo开发者就需要做出一些决定：导出服务好到什么程度？由于确实了解接口契约的重要性，我们不想使它完全自动化。Tuxedo或者.NET开发者可能做出哪些决定，然后将他们作为.NET应用程序、Java应用程序或者任何其他基于Web service的应用程序可以利用的WSDL导出。您甚至可以将Tuxedo事务的结果插入Excel那样的电子表格中。
.NET Magazine：这一切与.NET开发社区有何关系？
Scott Dietzen：Tuxedo服务输出Web service实际上不是编程问题。大多数情况 下是使用此工具和XML来指定您想让绑定看起来像什么。在此工具中，我们通过生成WSDL来方便Tuxedo服务的导出。然后，将该WSDL导入.NET环境，以调用某个Tuxedo应用程序。从Tuxedo角度看，与调用一个Java应用程序没有差别。总之，我们在导出WSDL通用语言的东西。可以导入WSDL并直接与.NET应用程序绑定。此后，很容易生成由WebLogic或者Tuxedo接收的、进行SOAP调用所必需的存根。许多其他系统与他们做相同的事情。大型的ERP系统——SAP、PeopleSoft、Siebel——现在也参与了进来，并定义了相同的绑定。很有趣。Siebe将运行在.NET以及WebLogic上。PeopleSoft将运行在WebLogic上，SAP运行在Java容器上。这一点对.NET开发人员是透明的这一事实又一次证明了这种Web Service架构的强大威力——不必处理交叉平台和交叉语言问题就可以实现互操作。
.NET Magazine：为了愉快地合作和密切开发者之间的关系，Oracle的Web站点有一部分内容是针对.NET开发者和IT支持人员的，它有助于这些人员使用Oracle的产品。这部分内容由Oracle内专注于.NET/Windows的支持小组提供支持。在BEA的Web站点上我找不到相同的内容，该站点上有吗？如果没有，有提供这一部分内容的计划吗？如果没有，原因是什么？
Scott Dietzen：我认为这是一件合理的事情，尽管也有文档。从.NET互操作WebLogic的方法与其他基于Web Service的应用程序没有区别。要点不在于您必须将.NET到WebLogic作为特殊的一次性事物处理，但互操作是有关Web Service的。当您想和任何支持Web service的系统，例如WebLogic、Tuxedo、WebSphere、Oracle、SAP、PeopleSoft 或Siebold通信时，.NET开发者会面临相同的问题——这就是它的工作方式。我认为，我们应该更多做一些工作，以便共享那些方面的知识。
使该任务变得更容易也是Microsoft的责任。他们应该告诉.NET的开发者，与和.NET支持相同Web Service栈的非基于.NET的应用程序连接是多么地容易。
.NET Magazine：业务如何能够帮助Web Service更接近于实现他们的承诺？
Scott Dietzen：有关这一基于XML的Web Service架构的挑战是XML架构的激增。我不得不忍受针对Customer和Order已经有超过100种架构的IT公司。现在，那些架构中一些是基本的。如果您有一家像Citigroup那样的大公司，“Customer”表示许多不同的事情。它可以表示个人、表示公司，因而他们不会相同。但这种膨胀中的一些是无理由的、是起反作用的，因而在使用不同表示方法的系统之间移动XML文档的时候，我们必须集中大量的精力和聪明才智来转换他们。
因而，为了帮助实现Web Service的承诺，各个公司最好去做的事情之一是考虑当这些实体在系统之间移动时，表示它们的合适的业务架构。并且，如果我们能得到那部分权限、以及对架构的重新考察和各企业的某些共同性，则我们开发商可以做得比支持集成更多。
当然，开发商仍然必须做很多。我们必须使XML易于转换和集成。我因Xquery而激动（作为Microsoft的朋友），Xquery是使其发生的XML查询技术。但Xquery的确又重现了优秀的应用程序架构。将来，优秀应用程序架构的主要原则之一集中在获取合适的业务XML架构上，因而他们可能经久耐用，并可以跨企业共享他们，而不用每个人都开发他们自己的。
.NET Magazine：有哪种标准体对此起作用吗？
Scott Dietzen：这些事情是统管生产和销售全部过程的人所关注的。与金融服务 相关的与Telco无关。即使在金融服务中，投资银行所需要的资料与商业银行所需要的资料也不同。因而，您得到许多统管生产和销售全部过程的人所关注的标准体，试图建立B2B活动的架构。而且，其中的一些比另一些的功能强。
在其他情况下，具有市场支配力的公司正在尝试支配。例如，在汽车工业，美国的一些主要制造商正在说“看，这就是我们要获得的方法，因此如果您想向我们销售，如果您想我们能够接入您的网络，您应该开始支持这些Web Service标准（这些绑定）。”
我认为这一过程有点像语言发展和进化的方式。它会变得有点难以对付——特别是在企业内部。但企业必须使妨碍公司内部交流的各种方言的随意膨胀完全停止。我认为这是我们可以很快解决的主要问题之一。在企业内部引入新的架构之前，企业关于架构的重新考察可能非常严格。如果我们进一步做一些工作，支撑外部的一些事情会更容易一些。
.NET Magazine：您还想让我们的读者知道 BEA目前正在做什么和如何让他们受益吗？
Scott Dietzen：我认为关键的论点已经赢得赞同：实际上，所有读者都会遇到基 于Java的应用程序，或者是内部构建的或者他们公司的标准商用应用程序。大多数商用企业应用程序将使用Java，原因很简单，他们需要能够跨平台销售。同时，我们深信有一些.NET应用程序正在企业中运行。.NET的架构是坚固的。我认为它与像WebLogic这样的产品架构共享很多技术，他们之间的竞争是有益的、良性的。读者将要面临的挑战是创建企业内部的方案：多少构建在.NET上，多少构建在Java上？我认为在未来数月内，这样的竞争将是非常令人激动的故事，并且只要我们继续保持互操作，它就将服务IT。
关于Scott Dietzen
Scott Dietzen博士是BEA Systems公司的首席技术官。他帮助创建了BEA WebLogic（该公司基于Java的应用服务器），并继续积极地开发形成了一个完整的应用程序基础结构平台。他帮助推出了Java 2 Enterprise Edition （J2EE）的服务器端Java标准。Dietzen博士也是Java标准化组织（Java Community Process）的一个关键成员。现在，它的团队也一直在通过XML和Web Service技术帮助推动应用程序集成的标准化。 |
|
