英语原文共 108 页，剩余内容已隐藏，支付完成后下载完整资料
摘要
利用紧密耦合的架构（如DCOM或CORBA）来构建分布式系统的问题是这些方法没有提供一个通用的、灵活的适用于当今B2B模式要求的环境。它们十分僵化，维护成本高并且升级到更好的系统几乎是不可能的。相反，XML提供了一种新的松散耦合系统（例如XML-RPC和SOAP），在网络升级方面这是非常通用的，可扩展的和灵活的并且符合当前B2B模式要求。这些方法的基本架构是像RPC和IIOP这些协议，但关于它们的一个显而易见的事情是它们可以使用HTTP作为消息格式的媒体进行通信。
本文的目的是提供松耦合的系统架构的见解和说明如何分别借助XML-RPC和SOAP API将XML用于分布式网络中的HTTP通信。我们将仔细看看实现的细节，最后开发一个网络，运行在Microsoft IIS的ASP客户端能够调用运行在Tomcat Apache Web服务器上的用Java写的远程方法。
介绍
2001年是互联网蓬勃发展的时期。它已经跨越了所有商业对商业（B2B）模式的障碍，甚至我的法国贵宾犬也有一个电子邮件帐户。没有人给他发电子邮件，但那是另一回事。人们从互联网上购买物品，并通过互联网投标。没有什么我们能从购物商店里买到而在网上买不到的东西，从苏打水到机票。互联网催生了一个新的商业领域：电子商务。互联网的无界性正达到高潮，电子商务开发人员和互联网专家正期待着大量的网站流量会爆发，到那时候，我们简单的客户端-服务器架构将失败，因为服务器无法处理这样一个巨大的网络流量和数据通信。有两种可能的解决方案可供处理此问题：购买多个服务器，并在服务器之间共享网络流量或修改底层技术。
购买多个服务器显然是最简单和最昂贵的解决方案，但第二种方法可以为客户机服务器架构带来革命性的改变。我们的目标是探索后一种方案的潜在可能性，一种可能的可能性是分布式计算。一种体系结构，Web服务器、数据库服务器和库存存储库都保存在不同的位置，完全隔离，它们通过来回传递消息彼此交谈。因此，流量自动分配。
这方面的研究很多，并提出了许多新的和有前途的方法。他们中的两个是SOAP（简单对象访问协议）和XML-RPC（可扩展标记语言远程过程调用）。这些方法使用XML作为数据通信底层的媒体，这是在电子商务世界的另一大进步。曾经有一段时间，HTML被称为Web的弗兰卡语言，但XML成为默认标准的日子即将来临。还有其他一些不依赖于XML的分布式计算方法。其中一个是RMI（远程方法调用），百分之一百纯的，老式的，像java解决CORBA分布式计算。RMI IIOP协议的理解：一个非常相似的RPC和它在自己的环境中运行。SOAP和XML-RPC协议是与其他协议结合运行，比使用SMTP（简单邮件传输协议）和HTTP（超文本传输协议）的网站更受欢迎。使用SOAP或XML-RPC不需要建立一个单独的环境。它们可以很容易地集成到任何现有的体系结构中。这种行为也称为开源体系结构。XML产生了与开放层体系结构完全兼容的松散耦合系统。RMI是紧密耦合系统的一个例子，它根本不支持开源体系结构。
动机
松散和紧密耦合的系统意味着什么？什么时候使用更好？使用这些系统的性能要求如何，在什么情况下性能更好？XML是如何与HTTP相关的？XML如何在HTTP上传输数据？什么革命性的变化可能带来电子商务的XMI的设计？我们如何在现有的遗留系统实现XML-RPC和SOAP模型吗？它们的规格是什么？哪个提供了更好的解决方案？我们可以在这些技术之间进行性能评估吗？
准确、准确地回答上述问题是本文的目的。我们将使用这些技术开发一些真实世界的应用程序，并根据我们稍后设置的某些因素（例如速度和带宽消耗）来评估它们。我们将进行需求分析，并尝试总结一些规律，作为部署这些方法的经验法则。
需要指出的是，在当前的这些研究方法规范中，需要进行大量的修改和改进，并与正在进行的研究相关。所以，用百分百的确定性总结出什么这几乎是不可能的，但我们将尝试设置一些指引，根据我们目前的框架。我们将首先介绍RMI和RPC进入图片的一般情况。我们将比较一下两者。然后，我们将改变我们的轨迹，我们的动机将是，XML如何产生松散耦合的系统，以及它如何不同于紧耦合系统。
稍后，我们将看到XML如何在HTTP上使用。一旦所需的背景搭建好，我们会深入讨论XML-rpc和SOAP。首先，我们将讨论它们的规范和它们的实现。然后我们会看到什么样的请求头看起来像使用XML-RPC以及如何不同于SOAP头。哪一个提供了一个更好的松耦合的系统：SOAP或XML-RPC，将是我们讨论下一个话题。最后，作者在撰写这篇论文时，从他本人的亲身经历中得到的一些智慧和想法。
介绍：
有许多技术可如今，分布式计算即微软的DCOM，CORBA（IIOP）、RPC、RMI、XML-RPC和SOAP。每种技术都有自己的优点和缺点。可能出现的最大问题是什么时候使用什么。虽然在讨论XML、RPC和SOAP之前详细讨论所有的技术几乎是不可能的，但是讨论松散耦合的系统比紧密耦合的系统要好的多，我们将提供对RPC和RMI的一般性概述。
什么是RMI：
这三个神奇的字母代表远程方法调用，一词是由Sun公司的java开发项目。体系结构相当简单：RMI允许一个程序调用对象上的方法，这个对象不位于与这台机器上但就像这些程序是定义在本机上一样。这是在java世界的分布式计算的核心和骨干（EJB企业java bean）。不怎么细致地将，RMI使用客户端存根和骨架来描述远程对象可用于调用的方法。客户的作用于这些存根（典型的java接口），RMI负责把存根的请求转换为网络调用。这个调用触发机器上的实际对象的方法，然后将结果返回到网络中。最后，存根返回给原始方法调用的客户机，客户机继续运行。这里的主要思想是客户机通常不担心RMI和网络细节; 存根使用它就像它是一个实现了方法的对象。RMI（使用java的远程网络通信协议）使这一切都发生在幕后，让客户处理一般异常（java RMI。RemoteException）和花更多的时间处理业务规则和应用逻辑。RMI也允许不同的协议如Internet Inter-ORB协议（IIOP）被使用，可以经常在不同的语言如C或C java和CORBA对象之间的通信。
不过，使用RMI确实要付出代价。首先，使用RMI是资源密集型的。有相当多的类，必须使用，虽然这些是核心java开发工具部分（JDK），他们仍然使用内存和资源实例化时。此外，java远程协议提供的性能很差，写一个远程协议来取代它并不是一项简单的任务。当客户端发出RMI调用时，套接字必须被打开和维护，套接字的数量会影响系统性能，特别是当这个系统通过网络访问时。RMI还需要服务器或提供者将对象绑定到。直到对象绑定到这些提供者中的一个名称之后，对象才能被其他程序访问。这就需要使用RMI注册表，轻量级目录访问协议（LDAP）目录服务器，或各种其他java命名和目录接口（JNDI）服务。最后，RMI会涉及到大量的编码，即使使用了所有有用的RMI服务器类，也要编写一个描述可调用的方法的远程接口（如果使用EJB的话，还有其他一些接口）。这也意味着给服务器类增加一个额外的方法会导致接口也要增加一个改变和客户需要重新编译存根，所以有些东西是可取的有些是不可取的。
什么是RPC：
这三个神奇的词代表远程过程调用。在RMI允许你直接与java对象交互，RPC则是建立在多个调度方式下。RPC不处理对象，而是允许您在网络上使用独立的方法。虽然这限制了交互性，但它确实使客户端的界面稍微简单一些。RPC是一种使用在远程机器上服务的方法，RMI允许在远程机器上使用服务器；细微的区别是，当方法被远程调用时RMI通常由客户机驱动。RPC的往往更多地就像一个执行工作任务的类或无客户端干预的类或集合；但是，有时这些类服务于客户和执行客户的迷你任务。
RPC，尽管不像RMI的交互环境，但确实提供了一些显著的优势。RPC允许不同类型的系统一起共同工作，而 RMI允许使用CORBA IIOP的服务器和Java客户一起工作，RPC允许随便任何类型的应用程序间通信因为传输协议可以是HTTP。事实上，现在使用的每种语言都有一些通过HTTP进行通信的方式，RPC对于必须连接到遗留系统的程序是非常交互的。RPC也通常比RMI更轻（特别是当使用XML作为编码）：虽然RMI经常有负荷整个java类的网络（如代码程序和自定义辅助类EJB），RPC只有必须通过请求传递参数和才能得到结果响应，一般是编码为文本的数据。.rpc也很好地与API模型相适应，允许不是该具体应用的系统仍然能够从应用上获取信息；这意味着服务器的变化不会导致其他客户的应用代码更改；通过纯文本数据传输和请求，可以在不进行客户端重新编译的情况下添加额外的方法，而少量的更改足以使用这些新方法。
RPC的问题一直以来就是数据传输，以java用一个很轻量级的容器利用传输文本为例。因为，这些复杂的对象类型可以支持其他java对象类型的数据，数据自动传输就很难编码实现；它还必须保持一种可以被所有不同编程语言使用的格式，否则RPC的优点就会减少了。直到现在，编码的质量和可用性和它的简单性之间一直存在矛盾关系。换句话说，在没有专有扩展和代码的多种编程语言中，它变得更容易表示复杂的对象就变得更加困难。数据的详细文本表示不是标准化的，在每种语言中就需要重新实现。
RMI和RPC哪个更好？
因此，我们可以看到RMI和RPC之间有一个折衷。在挑选哪一个时，没有明确的“是”或“不是”。但是这两种技术之间的共同主题是网络必须足够敏捷，能够分辨出这些技术类似的语言表示什么含义。不可能有一个敏捷的、灵活的、开放的网络架构，它可以使用RMI或RPC。RPC提供了高度可扩展RMI仍然没有一点灵活性。
随着XML的出现，按照当前遗留的方式，XML-RPC为开放源码、独立于体系结构的交互系统提供了一个RPC和XML的完美结合，，并提供了不同语言之间的客户机和服务器。
XML-RPC的连接是XML模型。XML提供了数据抽象，并使得基于IIS的ASP客户端与以Java写的远程方法交互成为可能。XML-RPC领先一步打开分布式计算和简单对象访问协议的新时代的大门，这些我们将在后面讨论。
紧耦合与松耦合系统：
今天的许多应用提供的紧耦合系统能够解析系统之间传递的消息，例如他们是否正在使用DCOM或CORBA（IIOP），例如。另一方面，松散耦合的系统不需要系统之间的严格解析，在XML的情况下，可以看做简单的文本在系统之间的传输。紧密耦合的系统解析它们之间传递的消息的形式，因此减少了开销。另一方面，松耦合的系统在可扩展性、多方法的要求可以被包裹在一个请求，作为反对传统的客户端-服务器模型，要求必须为每个方法调用。可以用下图来理解体系结构：
XML-RPC:
XML-RPC或可扩展标记语言的远程过程调用是一种相对较新的在分布式计算机上调用方法的并返回信息的方式。它使用XML传输结构化消息，封装了对远程系统执行的函数调用，因此我们可以无缝地与本地系统集成远程系统。事实上，XML-RPC工作在纯HTTP，使用XML（纯文本）来传递信息，整个规范是有效的独立的语言。目前的XML-RPC规范可以让我们得到一个使用一组客户通过远程机指定的参数，返回一个特定的方法。我们可以使用它直接从服务器或服务器调用方法。
另一个分布式计算方法：SOAP
SOAP或简单对象访问协议是微软术语XML-RPC 。我们已经明白了XML-RPC的灵活性和可扩展性，所以问题是，为什么我们需要一个新的方法。为什么SOAP？虽然，XML-RPC实现简单和高度可扩展的但它消耗大量的带宽，造成了不必要的网络流量。它增加了一个消耗非常高的数据量（以XML表单标签）的请求到服务器。正如我们已经看到在XML-RPC的一个字符串参数将被表示为：
lt;paramsgt;lt;paramgt;lt;valuegt;lt;stringgt;namelt;/stringgt;lt;/valuegt;lt;/paramgt;lt;/paramsgt;
从前面的例子中可以清楚地看到，添加字符串的额外数据量非常高，可以将带宽消耗增加两倍。
SOAP是在分布式、分布式环境中交换信息的轻量级协议。它是一个基于XML的协议，它由三部分组成：一个信封，它定义了一个用于描述消息中的内容和如何处理它的框架，一组用于表示应用程序定义数据类型的实例的编码规则，以及一个表示远程过程调用和响应的约定。SOAP可以与各种其他协议结合使用，然而，本文中定义的唯一绑定描述了如何使用SOAP与HTTP和RPC相结合。
SOAP提供了一个简单的、轻量级的交换结构化和类型化的信息节点之间在分散的机制，使用3qvil分布式环境。SOAP本身并不定义任何应用程序语义（如编程模型或特定于实现的语义），而是定义了一种表达应用程序语义的简单机制，它提供了模块化打包模型和在模块内编码数据的编码机制。这允许SOAP在各种各样的系统中使用，从消息传递系统到RPC。
XML-RPC与SOAP的共同主题：
正如我们已经了解到SOAP就是XML-RPC 。这不是一个新的领域。它是同一具有更高级的功能和更高的功能和能力的架构。这两种情况下的基本技术都是XML。我们在客户端和服务器端为了破译的HTTP请求都需要XML解析器，无论通过XML-RPC和SOAP。
这两种方法都支持开放架构，也就是说，位于不同平台上的客户机服务器可以在他们说XML的条件下相互交谈。SOAP提供了更好的编码方案。因此，HTTP头会看起来不同于XML-RPC但是客户端和服务器实现SOAP模式将面对SOAP规范。这两个协议都可以与HTTP、SMTP和RPC一起使用。他们的API也有不同的语言，所以开发人员可以在开发SOAP模型时选择一种她觉得舒服的语言。
SO
全文共6622字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[12114]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
