访谈
PDF罗杰·塞申斯和特里·科塔的对话
在2004-2005年12月/1月刊的Queue杂志中，罗杰·塞申斯发表了一篇关于对象、组件和Web服务的文章，以及何时应该使用哪种技术的文章（“模糊的边界”，第40-47页），引发了一些争议。塞申斯是国际软件架构师协会董事会成员，六本书的作者，撰写《架构师技术咨询》，并且是ObjectWatch的首席执行官。他持有非常面向对象的观点，但这不一定与Queue编辑委员会成员特里·科塔相同，后者不同意塞申斯在其文章中提出的许多观点。科塔是一位活跃的开发者，他在组件框架方面有着丰富的工作经验。他是Silicon Chalk的产品和战略副总裁，Silicon Chalk是一家位于加拿大不列颠哥伦比亚省温哥华的初创软件公司。Silicon Chalk广泛使用Microsoft COM来构建其应用程序。科塔之前曾在Open Text工作，在那里他架构了基于CORBA的基础设施，以支持公司的企业产品。
我们决定让这两位在论坛上进行辩论，这可能对我们所有的读者都有用。我们邀请了另一位Queue编辑委员会成员，Sendmail Inc.的首席技术官埃里克·奥尔曼，来主持我们预期会是一场相当具有挑衅性的讨论。我们的预期完全正确。
埃里克·奥尔曼 我曾与从事面向对象工作的人交谈过，他们读过您的“模糊的边界”文章，罗杰，他们每个人都首先不同意对象、组件和Web服务之间的区别是基于位置的。
他们中的许多人谈到面向对象的RPC（远程过程调用），这不太像是组件。它们是组件，它们共同存在于一个进程中等等。由于那是您文章的基本观点，您能否评论一下？
罗杰·塞申斯 遗憾的是，这些术语都没有得到很好的定义。我们都在按照我们理解的方式使用这些术语。我们的一些分歧可能仅仅是语义上的。
组件行业始于CORBA。CORBA的开发者试图解决一个问题：分布式。他们并没有试图让对象在同一个进程中协同工作。是的，你可以让CORBA对象在同一台机器上，甚至在同一个进程中运行，但这并不是CORBA关心的主要问题。
就Web服务而言，我们可以说，是的，Web服务可以在同一个进程或同一台机器上。它们可以在相同的环境中。但是Web服务试图解决的本质问题是什么？它是关于异构环境的。它是关于让一个.NET系统与一个WebSphere系统协同工作，例如，而不是让一个.NET系统与另一个.NET系统协同工作。
特里·科塔 在我看来，很难用这种理由来区分Web服务、CORBA和EJB，因为这三个系统都具有开放或至少是标准化的和可用的协议。我当然可以让我的WebSphere与适当的CORBA实现互操作，该实现具有用于执行EJB的映射。我可以使用各种不同的标准跨越技术边界。
罗杰·塞申斯 如果您使用的是J2EE标准，例如基于IIOP（互联网内部ORB协议）的RMI（远程方法调用），那么您主要是在单个供应商的系统（例如WebSphere系统）中执行此操作。如果您要从WebSphere系统转到WebLogic系统，那么实现互操作性的最佳途径是通过Web服务。为什么？因为您正在跨越技术边界。
特里·科塔 您是说基于IIOP的RMI实际上不起作用？
罗杰·塞申斯 它在跨技术边界的互操作性方面不起作用。
特里·科塔 似乎有人让它工作了。当然，早在我在CORBA工作的时候，不同供应商的ORB（对象请求代理）彼此互操作并没有问题。我们在Open Text使用了三到四个ORB，并且在这些环境彼此互操作方面没有任何困难。
罗杰·塞申斯 只要您是从CORBA到CORBA，它就能正常工作。但当您试图让CORBA系统与非CORBA系统协同工作时，就不是这样了。
特里·科塔 但是从WebSphere到CORBA领域的其他EJB供应商之一（例如WebLogic），可能有五六个不同的主要ORB供应商在市场上流通，更不用说几个开源项目了，所有这些都彼此很好地互操作。
罗杰·塞申斯 CORBA到CORBA。它们都运行在CORBA技术的相同基本核心之上。Web服务与此的不同之处在于，对于Web服务，与CORBA不同，完全没有关于底层技术是什么的假设。
特里·科塔 这不对。有一种假设，即一个人正在使用一组特定的协议；否则，它就无法工作，我的意思是CORBA也是一样——一组标准的协议。没有人说你必须实际实现CORBA stuff的服务器端方面才能通过互联网互操作。每个人都这样做了，因为那是他们定义标准的方式。
罗杰·塞申斯 您可以对DCOM或RMI说同样的话。虽然所有这些都支持通信协议，但它们与CORBA一样，不仅仅是关于通信协议。它们是关于一个平台。CORBA 95%是API，5%是互操作性。Web服务是零API和100%互操作性。
特里·科塔 这部分我完全同意。这可能是CORBA的失败之处。
罗杰·塞申斯 这正是CORBA的失败之处，这也将是J2EE的失败之处。他们没有从那个错误中吸取教训。
埃里克·奥尔曼 Web服务本质上不只是另一种交互标准吗？世界已经确定了CORBA协议，而不是CORBA实现。如果世界同意只使用CORBA协议，它不会产生完全相同的效果，甚至可能更好吗？
罗杰·塞申斯 这很有可能，但世界并没有这样做。CORBA缺乏重点。Web服务的工作除了互操作性之外还有很多重点。
Web服务和CORBA之间的最大区别在于，Web服务人员从一开始就说：没有API。我们标准化的唯一事情是消息如何从一个系统传递到另一个系统以及围绕它的协调。CORBA 95%是关于客户端如何绑定到系统。那是它的失败之处。
特里·科塔 当然，从程序员的角度来看，这不一定是失败，而是一个缺点。CORBA提供了非常好的拦截器架构，一种基本的调度机制，Web服务领域中的每个人都必须从头开始重建。您可以看到这现在在各种Web服务标准中出现。
由于适当的拦截器机制、对全局线程ID的支持等等，我们能够在CORBA之上构建OTS（对象事务服务）实现。当然，这项工作在Web服务领域花费了大量时间，因为没有人拥有它的基础设施。
罗杰·塞申斯 我一生中投入了相当多的时间在CORBA上，其中有一些非常好的想法。不幸的是，有太多的包袱，以至于这些好想法从未被允许蓬勃发展。
希望我们已经从这些错误中吸取了教训。CORBA唯一成功的部分——这项大规模努力，花费了数百万美元的部分——是与互操作性相关的极小部分。
特里·科塔 不仅仅是互操作性。那是很大一部分，但是关于拦截和在实际实现方面的调度的标准机制的概念也非常成功，因为它允许人们以合理的方式部署像OTS这样的东西，而无需每个人都基本上从头开始重新发现如何做那种事情。
罗杰·塞申斯 现实情况是，CORBA主要与API有关，但没有人使用这些API。
特里·科塔 我同意。我也参与了CORBA世界，并且在所有的接口规范和垂直领域中，很少有东西有任何意义。但我认为，尽管历史上说CORBA背后的驱动因素之一是这种使事物在网络上以可互操作的方式相互通信的愿望是正确的，但现实情况是，当人们开始使用CORBA时，他们发现了标准化基础设施提供的力量。基本的服务器端架构，包括调度机制、拦截器机制、对象生命周期和对象标识的标准，对于实际交付工作系统的开发人员来说是一个极其强大的工具。
罗杰·塞申斯 只要双方都同意他们处于CORBA世界中，CORBA中的很多东西都能很好地工作。
Web服务世界肯定在借鉴CORBA的想法，就像CORBA借鉴了早期技术的想法一样。他们在Web服务中试图做的是借鉴CORBA中实际成功的少数想法。
埃里克·奥尔曼 罗杰，我得到的明显印象是，您的态度是CORBA失败了，而Web服务成功了。然而，CORBA被用于许多非常真实的事物。
例如，CNN使用CORBA。大多数电话系统使用CORBA。而Web服务的海报示例是Google。在我看来，CORBA比Web服务更成功。
罗杰·塞申斯 我完全不同意这种说法。我会说，相对而言，很少有CORBA应用程序取得了成功。任何在CORBA架构上投入资金的人都在犯一个大错误。
最初促成CORBA的任何主要参与者都没有在其未来进行投资。IBM没有在CORBA上投入任何资金。Sun没有在CORBA上投入任何资金。微软从未关心过CORBA。那么谁在投资它呢？某个地方的一些边缘玩家。
当您提到Google时，您谈论的是一个非常具体且有限的应用程序。当您查看Web服务时，您真的需要将其分为两种类型的应用程序：企业间或企业内。Google是企业间的一个例子。
我的立场一直都是，企业间是Web服务的一个边缘领域。这是微软和IBM在与所有人谈论此事时兜售的领域。但是Web服务更重要的领域——在许多地方使用的领域——是在同一企业内实现不同技术系统的互操作。
埃里克·奥尔曼 罗杰提出了相当有说服力的说法，即微软从未关注过CORBA。我可以提出一个合理的论点，即CORBA失败了，而Web服务“成功了”——我尚未承认这一点——是因为微软对世界的霸权吗？我建议的是，如果微软支持CORBA，我们根本不会谈论Web服务吗？
罗杰·塞申斯 不，因为微软不是杀死CORBA的原因。J2EE杀死了CORBA。如果您想责怪某人杀死CORBA，请责怪IBM和Sun，因为最初将CORBA视为其救世主技术的所有主要参与者都放弃了它，转而使用J2EE。
特里·科塔 我实际上完全同意罗杰的观点。但在我看来，我们拥有大量涌现的Web服务 stuff的原因之一是，我们在微软的朋友们使构建Web服务变得非常简单，从某种意义上说，您只需构建.NET实现，然后说，“嘿，我想让这些Web接口可用。”
您认为这是真的吗？使Web服务对开发人员基本透明的工具是否是它们如此受欢迎以及我们看到企业内部出现大量这些服务的部分原因？
罗杰·塞申斯 这有一定的道理。当然，如果您查看主要的企业参与者，在我看来，它们是BEA、IBM和微软，它们都在尽最大努力使Web服务的使用尽可能透明。
他们对组件也做了类似的事情。他们试图使使用它们变得非常容易，问题是人们实际上从未理解这些技术之间的根本区别：对象、组件和Web服务。
在某种意义上，使某物成为Web服务的透明能力实际上并不是一件好事，因为要创建有效的Web服务，需要更深入地了解成为Web服务的意义。组件也是如此。这些工具没有给您这些。它们给了您在某些代码之上添加SOAP接口的能力，仅此而已。
埃里克·奥尔曼 您认为这将如何影响Web服务的演变？鉴于人们将使用这些工具，这是否会导致一段时期内出现极其糟糕的架构，因为人们只是将Web服务草率地添加到现有的架构解决方案之上？
罗杰·塞申斯 是的，这是我的预期。我们今天有很棒的工具来构建Web服务，但几乎不了解为什么、何时以及何地我们应该构建Web服务。
埃里克·奥尔曼 我对开发人员在构建系统时的世界观感到好奇。显然，您认为人们必须看到您所说的对象、组件和Web服务之间的边界。但是，在您看来，这些差异是否实际上转化为非常具体的不同实现技术？对象真的与组件不同，还是仅仅是关于某物在系统中扮演的角色的设计区分？
罗杰·塞申斯 我认为这更像是一种设计区分。仅举一个简单的例子：状态管理。如果您有一个对象，那么将状态长期保存在对象中是完全可以的。只要对象存在，它就可以在其中包含状态。在组件中，您不能这样做。您必须将状态从中取出，否则您的组件将无法扩展。没有任何工具告诉您这一点。您必须知道这一点，并且必须相应地设计系统。
仅仅因为您可以使用对象来实现您的组件，并不意味着对象和组件在语义上是等价的。状态管理是一个例子，但还有许多其他例子。这些是设计问题，而不是技术问题。
埃里克·奥尔曼 现在您已经引入了语义元素。对象有很多语义——多态性、封装、继承——您可以将其构建到Web服务中，也许就像我可以编写面向对象的C一样，但它不是一回事。
罗杰·塞申斯 甚至不清楚这是否是一个好主意。在我看来，在Web服务之上进行继承可能是一个坏主意。
在“模糊的边界”文章中，我说区分对象、组件和Web服务的定义特征是位置和环境边界。但是位置和环境边界在安全性、事务和其他设计问题方面具有许多含义。
埃里克·奥尔曼 这篇文章给人留下了非常非常强烈的印象，那就是如果我要使用组件，我永远不会考虑在同一进程中的东西中使用组件。但是我现在已经与许多人交谈过，他们说，“胡说八道，我们一直这样做，这是我们灵活性的一个重要点。”
罗杰·塞申斯 那么他们实际上是在为他们正在做的事情使用错误的技术。他们应该只为此使用对象技术。
特里·科塔 不，那是错误的。定义组件架构的要素之一是拦截点。即使我的东西在同一进程中通信，这也是非常有用的，因为它使我有机会例如跟踪调用模式，而实际上不必完全扰乱我的架构。
我们实际上对我们在Silicon Chalk构建的产品执行此操作。我们透明地引入一个调试代理层，并获得各种跟踪信息，这些信息大大提高了我们调试系统的能力。如果我们用C++构建它，而没有一些要处理的基类噩梦，我们就无法做到这一点。
因此，组件技术提供拦截点这一事实实际上被证明对开发人员来说是一个非常宝贵的工具。
罗杰·塞申斯 也有提供这种功能的对象系统。您正在挑剔特定语言的缺点，并以此来谴责所有面向对象的系统。这不公平。如果您需要拦截，如果这是一个有用的工具，那么您应该选择提供拦截的对象技术。
特里·科塔 作为现实世界中的开发人员，我没有这些选择。有时您必须使用特定的语言或系统。那是我生活的土地，这也是大多数开发人员的现实。组件系统为我提供了构建产品并将其交付给客户所需的能力。现在确实如此，如果我一直在Smalltalk中编程，我可以进入那里并摆弄调度机制。但我没有那个选择。
罗杰·塞申斯 那很不幸。您选择了错误的语言。
特里·科塔 考虑到我处理的世界的其他现实，我选择了唯一有意义的语言。谈论对象和组件之间的区别，就好像人们可以完全自由地选择如何实现事物一样，这很好，但现实世界并非如此运作。作为负责实际将产品交付给客户并让客户满意的负责人，您不能因为它们恰好满足对什么是合适的纯粹主义概念而选择任意技术。
罗杰·塞申斯 如果您说您正在使用一种特定组件技术的某个特定方面来弥补对一种特定编程语言的令人遗憾的约束，那么这没问题。做您需要做的事情。但是仅仅因为您正在使用拦截，并不能使它成为组件和对象之间的一个决定性差异。这只是您恰好在其中工作的约束的特定产物。
埃里克·奥尔曼 好的，先生们，让我们稍微改变一下方向。在这次讨论过程中，我们已经接触到各种已经出现或正在发展的标准化工作。例如，WS安全性和WS事务、WSDL（Web服务描述语言）和UDDI（通用描述、发现和集成）正在发生很多事情。我很好奇想听听罗杰对这些事情中哪些是好的，以及我们应该在哪些方面做不同的事情的看法。那里有很多标准，坦率地说，它们至少和某些CORBA规范一样难以理解，如果不是更难的话。
罗杰·塞申斯 我同意Web服务标准比大多数CORBA规范更难理解，但是这些规范与CORBA规范之间存在一个根本区别。CORBA规范必须由开发人员理解。Web服务标准则不然。除了微软和IBM之外，没有人需要理解Web服务标准，因为这些标准是关于微软和IBM将如何相互通信，而不是关于开发人员将如何做任何事情。
埃里克·奥尔曼 那么，除了微软和IBM之外，没有人会进行交互吗？
罗杰·塞申斯 正在构建平台的人员是关心这些标准的人员。这些标准与Joe或Jane Developer无关，完全无关。
特里·科塔 您的意思是Joe或Jane Developer永远不会使用任何使用UDDI的东西？
罗杰·塞申斯 他们将使用利用UDDI的东西，但是UDDI将处于比他们将看到的任何东西都低得多的水平。
特里·科塔 您是说他们永远不会看到UDDI？
罗杰·塞申斯 他们将看到其特定供应商用于使用UDDI的工具。但是他们不会看到UDDI本身。这就像Web开发人员担心TCP/IP一样。是的，他们将使用它，但他们不会看到它。
特里·科塔 因此，再次从开发人员的角度来看，我将构建一个面向服务的架构，基本上您是说我不需要了解任何关于Web服务标准的知识，但是我需要了解Web服务作为一个抽象概念，以便使我的架构正确。
罗杰·塞申斯 您需要从架构上理解您需要做什么才能构建有效的Web服务，但是就Web服务标准如何移动信息而言，那不是您的问题。
特里·科塔 性能问题呢？
罗杰·塞申斯 您需要知道您的供应商支持什么。这些标准不是关于开发的。它们是关于不同供应商平台之间的互操作性。
看看这些标准。给我一个标准的例子，它会渗透到开发人员？在所有Web服务中定义的，会渗透回开发人员的一个API？没有！
特里·科塔 听起来您是在说，自动提供Web服务接口的工具实际上是绝对必要的，因为它们是开发人员和底层协议之间的绝缘层。与此同时，它们是导致可能生成架构不良系统的罪魁祸首。双刃剑？
罗杰·塞申斯 即使您没有这些工具，仍然完全有可能实现糟糕的系统。实际上，这可能更容易，因为您会有更多的事情可以搞砸。
也许您可以争辩说，如果没有这些工具，您将必须了解很多关于Web服务的知识，以至于您必然会在某种程度上获得一些设计技巧。我认为解决这种困境的答案不是摆脱这些工具，而是通过像Queue这样的杂志来教育人们，向他们展示构建这些东西的正确方法。
最初发表于Queue杂志第3卷第7期—
在数字图书馆中评论本文
更多相关文章
凯瑟琳·海耶斯，大卫·马龙 - 质疑非加密哈希函数的评估标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。加密哈希存在许多标准，这些标准是出于各种安全需求而提出的，但在非加密方面，存在一定的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
妮可·福斯格伦，伊里尼·卡利亚姆瓦库，艾比·诺达，米凯拉·格雷勒，布赖恩·豪克，玛格丽特-安妮·斯托里 - DevEx在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者直观地接受，良好的开发者体验可以实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进DevEx的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
若昂·瓦拉乔，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来提供关于该主题的新见解，以研究生产力方面的差异。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
伊瓦尔·雅各布森，阿里斯泰尔·科伯恩 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在其快速前进的步伐中，它容易受到时尚的支配，并且可能会忘记或忽略已证明的解决它所面临的一些永恒问题的解决方案。用例，于1986年首次引入并在后来普及，就是这些已证明的解决方案之一。
© 保留所有权利。