因此，所有这些事情或多或少地组合在一起，并共同为我们带来了今天的局面 ― Java 成为用于构建支持 Web 服务的服务器端组件的良好平台。那是 OGSA 想做的：定义一些标准，以阐明作为客户机如何与这些网格服务交互。
dW：那么，对于您而言，是使用 Web 服务标准的愿望使您选择 J2EE 的吗？
Tuecke：是这个愿望以及 Java 被全面广泛采用的事实这两者的结合所致。澄清一下，我们绝对不是说只能使用 Java。我们还坚决支持用于编程的其它协议、标准和多种工具箱。因此，我们在用于 Web 服务的基于 C 的托管环境方面投入了积极的努力；我们正在和劳伦斯伯克利实验室（Lawrence Berkeley Laboratory）的一个小组紧密合作，共同开发基于 Python 的环境。我们认为所有这些事情都很重要。但是一年以前，当我们开始着手决定开发这个网格服务项目的途径时，实际上只有两个工具箱可以出色地完成开发Web 服务的任务：Apache Axis 和 Java，后来才有了 .Net。Apache Axis 是属于开放源码这一方的，所以我们采用了这个途径。
dW：这只是您为了开发出适用于更广泛社区的网格计算而使用的手段，还是科学社区中的人们也对 J2EE 感兴趣？
Tuecke：可以肯定，科学社区的许多工作都是使用 Java 的。我认为科学社区中的许多人还在设法使用 J2EE。这在某种程度上也取决于您所讨论的是 J2EE 的哪个部分。有些人一想到 J2EE，就想到了 servlet 引擎。其他人则想到了实体与会话 bean。例如，科学社区确实在基于 servlet 的工具箱方面进行了巨大的投资，以利用这些工具箱与他们的科学应用程序进行相互操作。我想我们很少看到采用较为重量级的基于容器的模型，正如您在实体 bean 和会话 bean 中所见到的那样。实体 bean 实际上是为商业关系数据库类型的应用程序设计的。这种性质的应用程序在科学社区中不大多见。
科学领域中的另一个因素（比在商业领域重要得多）是开放源码。许多小组坚持认为开放源码软件是开展其科学工作的基础。部分原因在于它是免费的，另一部分原因是该社区确实具有需要特殊工具的历史，因此他们需要有能力查看源代码并对之进行修改，以使它真正能用于他们的应用程序。对于他们而言，所有这些事情都很不错。
dW：网格标准距离被商业领域采用还有多远？看一下目前的网格计算的实际应用程序，它们似乎都是用于科学应用程序的。
Tuecke：目前已经出现少数商业应用程序开始使用网格计算，但它们中的大多数还是属于周期提取类型问题的类别。我认为其中有两个问题：一个是采用问题，另一个是标准问题。
在标准方面，Globus Toolkit 在过去一、两年中已经成为用于开发许多基于网格的应用程序（尤其是在科学方面）的事实标准软件。但它们还不是协议标准，而我们希望做到这一点。OGSI 是该基础结构的第一层：它接收 Web 服务、在它们之上放置一系列模式、使用标准接口以便使用服务器状态管理、生命周期管理、监控和发现。
我认为您将会在明年看到：包括我们在内的社区会对 Globus 进行巨大的推动，它现在开始充实我们所称的常用服务集。我们将使用该 OGSI 基础，以开始填充标准接口，用于数据访问和资源管理的通信、记录监控服务日志、发现服务及类似操作。为了真正得到广泛的采用，我认为此类工作是必需的。我们正在进行工作，直到可以开始部署网格组件并能将它们捆绑到一起为止。
几个月后，您就可以看到 OGSI 基本功能的交付（来自各个供应商）。我们免费提供该技术快一年了。因此，无论是进行实验，或者如果您尝试构建的应用程序属于对定制程度要求很高的类型，这都为您提供了非常稳固的基础，要获得这个现有的组件架构并不太麻烦，好极了，努力去做吧。您可以使用现有的工具进行工作。
dW：现在，从另一方面来说，网格开发将开始推动 J2EE 标准吗？
Tuecke：恐怕现在下结论还言之过早，但我认为在某些领域中很可能会发生这样的情况。
让我回到先前的话题。提供一个基于 J2EE 的网格环境意味着什么，是否使用该环境人们就可以交付符合 OGSI 的服务？它意味着您提供了一个服务器编程环境，从而使服务编写者能够很容易实现符合 OGSI 标准集的服务。换言之，您正在定义容器。您正在开始定义处理许多生命周期问题的标准容器 ― OGSI 处理的所有方面包括：生命周期管理、监控以及所有诸如此类的事情。因此，如果您研究我们作为 OGSI 实现
<< 上一页 [31] [32] [33] [34] [35] 下一页