Web Services技术、架构和应用第2章.doc

第2章 Web Services带来了什么第2章 Web Services带来了什么2.1 什么是Web Services从技术的角度来看，Web Service可以被认为是一种部署在Web上的对象（Web Object），因此，具有对象技术所承诺的所有优点；同时，Web Services的基石是以XML为主的、开放的Web规范技术，因此，具有比任何现有对象技术更好的开放性。2.1.1 Web Services的概念首先，我们需要来区分两个相似的概念：Web Services和Web Service。刚刚接触Web Services的读者往往对这两个概念毫无感觉，认为是一个东西。初看，似乎一个是复数形式，一个是单数形式。然而，Web Services是指用于架构Web Service的整体技术框架，而Web Service则是使用Web Services技术而创建的应用实例，当然也有很多时候，Web Services的含义也是具体的应用实例，只不过此时是泛指（即复数），因此在本书的其余部分，对于表示架构Web Service的整体技术框架的那个Web Services，我们将使用Web Services技术来阐述，而表示使用Web Services技术而创建的应用实例的那个Web Services，我们一律使用泛指的方式：Web Services。Web Services是描述了一些操作的接口，通过标准化的XML消息传递机制，可以通过网络访问这些操作。Web Services是用标准的、规范的基于XML的WSDL语言描述的，这称为Web Services的服务描述。这一描述囊括了与服务交互所需要的全部细节，包括消息格式（详细描述操作的输入输出消息格式）、传输协议和位置。该接口隐藏了服务实现的细节，允许通过独立于服务实现、独立于硬件或软件平台、独立于编写服务所用的编程语言的方式使用该服务。这使得基于Web Services的应用程序具备松散耦合、面向组件和跨技术实现的特点。Web Services都履行一项特定的任务或一组任务。Web Services可以单独或同其他Web Services一起用于实现复杂的商业交易。2.1.2 Web对象从外部使用者的角度而言，Web Services是一种部署在Web上的对象/组件，它具备以下特征。 完好的封装性：Web Services既然是一种部署在Web上的对象，自然具备对象的良好封装性。对于使用者而言，他能且仅能看到该对象提供的功能列表。 松散耦合：这一特征也是源于对象/组件技术，当一个Web Services的实现发生变更的时候，调用者是不会感到这一点的。对于调用者来说，只要Web Services的调用接口不变，Web Services实现的任何变更对他们来说都是透明的，甚至当Web Services的实现平台从J2EE迁移到.NET或者反向迁移时，用户都可以对此一无所知。 从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如Microsoft的分布式组件对象模型（DCOM）、对象管理集团（OMG）的公用对象请求代理程序体系结构（CORBA）或SUN的远程方法调用（RMI）。通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。 这些系统有一个共同的缺陷，那就是它们无法扩展到互联网上。它们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。这样的系统往往十分脆弱：如果一端的执行机制发生变化，那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。 对于松散耦合而言，尤其是在Internet环境下的Web Services而言，需要有一种适合Internet环境的消息交换协议。而XML/SOAP正是目前最为适合的消息交换协议。 使用协约的规范性：这一特征从对象而来，但相比一般对象，其界面规范更加规范化并易于被机器理解。首先，作为Web Services，对象界面所提供的功能应当使用标准的描述语言来描述（比如WSDL）。其次，由标准描述语言描述的服务界面应当是能够被发现的，因此，这一描述文档需要被存储在私有的或公共的注册库里面。同时，使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到Web Services的聚合、跨Web Services的事务、工作流等，而这些又都需要服务质量（QoS）的保障。我们知道安全机制对于松散耦合的对象环境的重要性，因此，需要对诸如授权认证、数据完整性（比如签名机制）、消息源认证以及事务的不可否认性等运用规范的方法进行描述、传输和交换。最后，所有层次上的处理都应当是可管理的，因此，需要对管理协约运用同样的机制。 使用标准协议规范：作为Web Services，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。这些标准协议具有完全免费的规范，以便由任意方进行实现。一般而言，绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。 高度可集成能力：由于Web Services采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，因此，无论是CORBA，DCOM还是EJB，都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高的可集成性。2.1.3 Web Services体系架构模型Web Services体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。交互具体涉及到发布、查找和绑定操作。这些角色和操作一起作用于Web Services构件：Web Services软件模块及其描述。在典型情况下，服务提供者提供可通过网络访问的软件模块（Web Services的一个实现）。服务提供者定义Web Services的服务描述，并把它发布到服务请求者或服务注册中心。服务请求者使用查找操作从本地或服务注册中心搜索服务描述，然后使用服务描述与服务提供者进行绑定，并调用相应的Web Services实现，同它交互。服务提供者和服务请求者角色是逻辑结构。图 2-1展示了这些操作、提供这些操作的组件以及它们之间的交互。 角色Web Services体系结构中的角色包括如下。 服务提供者（Service Provider）：从企业的角度看，这是服务的所有者。从体系结构的角度看，这是托管被访问服务的平台。 服务请求者（Service Requestor）：从企业的角度看，这是要求满足特定功能的企业。从体系结构的角度看，这是寻找并调用服务，或启动与服务交互的应用程序。服务请求者角色可以由浏览器来担当，由人或无用户界面的程序（例如，另外一个Web Services）来控制它。图 2-1 Web Services体系架构模型 服务注册中心（Service Registry）：这是可搜索的服务描述注册中心，服务提供者在此发布他们的服务描述。在静态绑定开发或动态绑定执行期间，服务请求者查找服务并获得服务的绑定信息（在服务描述中）。对于静态绑定的服务请求者，服务注册中心是体系结构中的可选角色，因为服务提供者可以把描述直接发送给服务请求者。同样，服务请求者可以从服务注册中心以外的其他来源得到服务描述，例如，本地文件、FTP站点、Web站点、ADS文本文件（Advertisement and Discovery of Services）或DISCO文件（Discovery of WebServices）。 行为对于利用Web Services的应用程序，必须发生以下三个行为：发布服务描述、查询或查找服务描述以及根据服务描述绑定或调用服务。这些行为可以单次或反复出现。Web Services体系架构中包含的这些具体操作如下。 发布（Publish）：为了使服务可访问，需要发布服务描述以使服务请求者可以查找它。发布服务描述的位置可以根据应用程序的要求而变化。 查找（Find）：在查找操作中，服务请求者直接检索服务描述或在服务注册中心中查询所要求的服务类型。对于服务请求者，可能会在两个不同的生命周期阶段中牵涉到查找操作：在设计时，为了程序开发而检索服务的接口描述；而在运行时，为了调用而检索服务的绑定和位置描述。 绑定（Bind）：最后需要调用服务。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系和调用服务，从而在运行时调用或启动与服务的交互。而Web Services体系架构中包含如下Web Services构件。 服务（Service）：在这里，Web Services是一个由服务描述语言描述的接口，服务描述的实现就是该服务。服务是一个软件模块，它部署在由服务提供者提供的可以通过网络访问的平台上。服务的存在目的就是要被服务请求者调用或者同服务请求者交互。当服务的实现中利用到其他的Web Services时，它也可以作为请求者。 服务描述（Service Description）：服务描述包含服务的接口和实现的细节。其中，包括服务的数据类型、操作、绑定信息和网络位置。还可能包括可以方便服务请求者发现和利用的分类及其他元数据。服务描述可以被发布给服务请求者或服务注册中心。Web Services体系结构解释了如何以一种可以互操作的方式实现这些操作。 开发生命周期Web Services开发生命周期则包括了设计和部署以及在运行时对服务注册中心、服务提供者和服务请求者每一个角色的要求。每个角色对开发生命周期的每一元素都有特定要求。开发生命周期有以下四个阶段。 构建：生命周期的构建阶段包括开发和测试Web Services实现，定义服务接口描述和定义服务实现描述。可以通过创建新的Web Services，把现有的应用程序变成Web Services和由其他Web Services和应用程序组成新的Web Services，从而提供Web Services的实现。 部署：部署阶段包括向服务请求者或服务注册中心发布服务接口和服务实现的定义，以及把Web Services的可执行文件部署到执行环境（典型情况下，被部署到Web应用服务器）中。 运行：在运行阶段，可以调用Web Services。在此，Web Services完全部署、可操作，并且服务提供者可以通过网络访问服务。现在，服务请求者可以进行查找和绑定操作。 管理：管理阶段包括持续的管理和经营Web Services应用程序。安全性、可用性、性能、服务质量和业务流程问题都必须被解决。2.1.4 Web Services协议栈在前一节中我们已经了解到，为了完成在松散耦合环境下的对象访问，以及在基本对象访问之上的事务、工作流、安全机制等。实现一个完整的Web Services体系需要有一系列的协议规范来支撑。图 2-2展示了当前投入使用的Web Services协议栈：Web Services Stack。图 2-2 目前可以使用的Web Services Stack 网络传输层Web Services协议栈的基础是网络传输层。Web Services要被服务请求者调用，就必须是可以通过网络访问的。Internet上可以访问的Web Services使用已普遍部署的网络协议。HTTP凭借其普遍性，成为了Internet环境下Web Services使用的标准网络协议。同时在某些扩展应用领域，也支持SMTP协议（用于电子邮件）和FTP协议（用于文件传输）。而对于Intranet环境中，Web Services还可以使用中间件作为传输交互的基础架构，比如IBM的MQ Series（目前已经改名为Websphere MQ）和CORBA（Common Object Request Broker Architecture）。Web Services的好处之一在于它能够为Intranet和Internet服务开发和使用提供了统一的编程模型。所以，网络协议和技术的选择对于服务开发者来说是透明的。 数据表现层数据表现层的XML为整个Web Services上层协议提供了数据/信息描述手段，XML是目前全球范围内用于描述数据和交换数据的一种标准方式。可扩展标注语言XML作为Internet上的一种新的数据交换标准，其应用范围从早先的Web信息描述，发展到后来的数据交换的开放标准，乃至目前的服务集成和服务交互的开放技术，XML已经成为开放环境下描述数据描述信息的标准技术。在Web Services的时代，全部的规范、技术同样都是以XML为底层核心和构架基础的。对于Web Services而言，无论是Web Services的调用（SOAP技术）、Web Services界面的描述（WSDL技术），还是Web Services的发现（UDDI技术），都是使用XML作为信息描述和交换的标准手段。 数据模型层在数据表现层上是数据模型层，描述数据结构的数据模型（也称为元数据）。它同样也是一种数据，因此，描述数据结构的方式也是使用基础的数据表现方式：XML。XML Schema已经成为XML世界中的标准数据建模语言，SOAP，WSDL，UDDI的XML语法都是采用XML Schema进行定义和描述的。XML Schema已经成为XML世界中的标准交流工具，这有些类似于UML在软件设计中的地位。 基于XML的消息层在这一层次，使用的是基于XML的消息协议SOAP。消息层是构筑在更低的传输层之上的，这意味着SOAP可以单独使用，也可以与任何传输协议联合使用。所有的SOAP消息都支持我们先前提到的Web Services架构中的发布（Publish）、绑定（Bind）和查找（Find）等操作。SOAP由三部分组成： 一个使用XML信封来描述消息内容的机制； 一组编序规则，用于编码各种类型的数据； 一个提供远程过程调用（RPC）和响应的机制。IBM，Microsoft以及其他的一些公司将SOAP提交给W3C，目前作为XML协议工作组（XML Protocol Working Group）的基础。当W3C发布XML Protocol标准规范的时候，Web Services协议栈将升级，SOAP将被XML Protocol所替代。 服务描述层服务描述为调用Web Services提供了具体的方法。WSDL是一个基于XML格式的定义服务的实现和接口的基础标准。这意味着WSDL将服务的描述分为两部分：服务实现和服务接口。在按照WSDL进行服务实现之前，我们必须先定义服务接口。WSDL仅是一个基本的服务描述手段，要指定业务环境、服务质量和服务之间的关系，我们还需要另外的描述手段。 服务发布层WSDL文档可以由其他服务描述文档来补充，从而描述 Web Services更高级的方面。例如，我们可以使用UDDI数据结构来表示商业上下文。在服务客户生命周期的任一阶段，都可以将WSDL文档提供给服务客户端。当这一操作被涉及后，我们就需要从服务描述层更进一步到达下一个层次服务发布层。在这一层次，服务提供者能够直接向服务客户端发送WSDL文档，一个可能的例子是通过E-mail的形式。这一动作被称为直接发布。同时，服务提供者也可以选择将WSDL文档发布到本地的WSDL注册库，或是公共/私有的UDDI注册中心。服务客户端可以通过这些注册库来获得WSDL文档。 服务发现层服务发现是基于服务发布的。如果Web Services没有或不能被发布，那么它就不能被发现。服务客户端可以在运行时态获取服务描述。例如，服务客户端可以获取一个以本地文件形式存在的WSDL文档，这个WSDL文档是通过直接发布手段发布的。这一操作被称为静态发现。同时，这个服务客户端也可以选择在设计阶段或运行时态通过一个本地WSDL注册库或公共/私有的UDDI注册中心发现WSDL文档。 服务工作流层Web Services工作流语言（WSFL）是协议栈顶层的服务工作流层的标准。与协议栈中的其他标准不同，WSFL针对的是商务流程建模和工作流。WSFL用于描述Web Services在工作流中如何互相作用，以及它们如何处理服务到服务的通信或协同。这意味着Web Services可以是工作流的一部分，也可以动态地被编入工作流，特别是，这个工作流可能发生在买家、卖家以及承运方之间。例如，WSFL允许工作流管理器从一个复合Web Services中，按工作流来定义依据商业流程赋予的各自角色的调用作为其成分的每个个体Web Services，这样的商业流程可能包括财务报表管理、预测支持或5年IT计划，以及一次宾馆预定等。 2.1.5 扩展Web Services协议栈2.1.6 Web Services的类别2.2 Web Services与应用集成2.2.1 什么是企业应用集成2.2.2 企业应用集成EAI的类型2.2.3 商业需求驱动Web Services2.2.4 Web Services和EAIWeb Services提供了一个分布式的计算技术，用于在Internet 或者Intranet上通过使用标准的XML协议和信息格式来展现商业应用服务。使用标准的XML协议使得Web Services平台、语言和发布者能够互相独立，这是EAI解决方案的一个理想的候选者。通过开放的Internet标准：Web Services描述语言（WSDL，用于服务描述），统一描述、发现和集成规范（UDDI，用于服务的发布和集成），简单对象访问协议（SOAP，用于服务调用）和Web Services流语言（WSFL，用来定义工作流，这是IBM开发的一个Web Services标准），Web Services消除了现存解决方案（如CORBA和DCOM）中的互用性问题。Web Services不是EAI或者EAI的一部分，更甚者，Web Services是另外一个技术，Web Services能够使EAI成为真正可能的、便捷实施的，同时又引人注目的解决方案。Web Services能彻底地改变传统的EAI中点对点的集成处理方式。使用Web Services，通过松散的应用集成，一个企业可以仅仅实现EAI的一个子集，即能取得实效。与之相反，EAI要实现一个全盘的方案，来紧密地集成和联系支持公司业务的所有的系统和应用。在公司内部不同的业务系统和技术单体中，可能需要花费数年的持续的努力、高投资以及为之配备的充实的资源。Web Services以这样一种松散的服务捆绑集合形式（也可以说是一个特别的解决方案）：能够快速、低代价地开发、发布、发现和动态绑定应用。就当代Web Services的技术发展水平来看，Web Services可以实现应用程序之间的函数或方法级的集成。它们不是自然地基于事务的，同时仅提供了基本的“请求/响应”功能。然而，在下一代的Web Services中，在功能上和技术上都会更先进，将会提供用户接口封装和安全性，能够包装一个应用程序，并且把它嵌入到其他的应用程序中去。主要关注于应用集成的现有EAI解决方案将不得不因此而改变。在将来，包装好的应用程序将使用XML，SOAP，WSDL和UDDI等技术来把它们的函数或方法作为Web Services的接口来显示。因此，EAI解决方案将不得不提供对服务集成的广泛支持，而不仅仅是应用集成。企业在内部应用程序中使用Web Services来实施应用集成的项目，应当从函数、应用程序接口（API），或者远端过程调用（RPC）级别开始这一进程。这将使企业内使用和实施Web Services的IT技术人员熟悉Web Services技术，当企业将来使用Web Services进行外部集成（B2B集成）项目时，将会有助于项目的有效进行。在Intranet内控制、管理、寻找、执行和维护Web Services相对来说也比通过企业防火墙在Internet上使用Web Services更为容易。进一步来说，它将帮助企业来比较和鉴别，使用标准化和相对便宜的Web Services解决方案相对于昂贵的传统的EAI解决方案到底是不是对提高企业的产出率更有帮助。然而，要求企业抛弃现存的EAI底层架构，并且盲目地转向开发基于Web Services的解决方案来替代它是不太现实的。企业不会停止使用提供完整事务服务的EAI中间件框架。在使用Web Services的场所，不是替代（现在还不是），而是应该使用Web Services来支撑现存的下层结构。经过一段时间，Web Services将逐渐地由一个EAI解决方案进化为一个B2Bi（B2B Intergration）解决方案。 传统EAI解决方案和Web Services解决方案的比较下面是传统的EAI解决方案和Web Services之间的一些基本的不同点。 简单性：毫无疑问，相比于典型的EAI解决方案（也许包括分布式技术，如DCOM和CORBA），Web Services更便于设计、开发、维护和使用。既然开发和使用Web Services的平台框架已经准备好了，创建跨越多个应用程序的商务流程处理将变得相对简单。 开放标准：不像有所有权的EAI解决方案，Web Services是基于开放标准，诸如UDDI，SOAP，HTTP的。这可能是导致Web Services被广泛接受的最重要的因素。事实上，基于现存的开放标准消除了企业潜在地为了支持新出现的Web技术的投资的需要。 灵活性：既然EAI解决方案需要点对点集成，一端的改变必须告知另外一端，这自然使集成变得非常得生硬，同时也浪费开发人员的时间。基于Web Services的集成是非常灵活的，因为它是建立在发布服务的应用程序和使用服务的应用程序之间的松散耦合。 便宜：EAI解决方案，诸如消息中介，其实施是非常昂贵的。而Web Services的实施则会变得便宜而快速。 范围：EAI解决方案，诸如消息中介，把应用程序作为一个单个的实体来集成。然而，Web Services允许企业把大的应用划分为小的独立的逻辑实体并且包装它们。举例来说，企业可以为一个ERP应用的不同的商业组件进行包装。如订单管理、接受购买订单、订单情况、订单确认、账户接受、账户支付等。 高效性：已在前面几点提到的，Web Services允许应用程序划分为一些小的逻辑组件，因为在小粒度基础上集成应用程序，集成将变得更容易。这也使Web Services的EAI解决方案比传统的EAI解决方案更有效率。 动态：Web Services通过提供动态的服务接口来实施一个动态的集成。然而，传统的EAI解决方案都是静态处理的。 一个使用Web Services的EAI示例下面，我们使用一个例子来看看如何通过目前的Web Services主流平台Microsoft.NET和J2EE平台上进行企业应用集成。在这个例子中，零散的小客户以及金融公司内部的客户使用证券投资管理门户监控他们的投资情况。这个门户使用的是Microsoft的技术（ASP+，IIS Web Server，C#等，注意，虽然没有使用最新的.NET Server Series，然而它们在本质上方法是相同的）。这个门户应用提供的一个功能是查询证券最新交易交割。通过使用这个功能，客户可以检索任何股票的实时报价，当客户请求股票报价的时候，请求被从浏览器发送给了Web服务器。报价服务（Quote Service）作为一个Web Services，由公司内部的应用服务器提供给Intranet中的多个客户（指客户端系统）使用，而证券投资管理门户正是这些客户端中的一员。除了这个证券投资管理门户之外，其他客户端可以参阅后面的图示，是一些VB应用，也可以是一些其他应用，取决于企业自身的需要或是合作企业的需要。这个由应用服务器提供的Web Services的相关技术信息可以通过私有的内部UDDI注册中心获得，可以通过企业内部Intranet进行调用。由Web Services界面发布的商业逻辑具体是由应用服务器中包含的一个EJB所提供的。这个应用环境是一个典型的跨平台的基于Web Services的应用集成。频繁被Web Services使用的绑定信息（如请求报价的调用界面）被客户端应用缓存，以避免频繁出现资源密集的和耗费时间的动态绑定。在这个例子中，我们通过松散连接的Web Services技术将证券投资管理应用（基于微软的技术）与商业逻辑中间件应用（基于J2EE）进行集成，而这个商业逻辑中间件应用最终可能需要与大型机上的数据库进行交互并获取报价。在图 2-7中，我们在各个处理环节上标注了序号，下面我们来一一描述这些处理环节的细节。图 2-7 使用Web Services的EAI示例1用户在Web前端界面（Browser界面）上发出针对指定公司的证券报价请求，这个请求被发送给运行在Microsoft IIS服务器中的证券投资管理门户。为了简化描述，我们假设用户已经成功登录到证券投资管理门户中，并且已经建立了合法的会话。2基于.NET技术的门户应用得到由J2EE应用服务器提供的Web Services的技术信息，这些技术信息是.NET平台通过搜索私有UDDI注册中心获得的。3针对指定Web Services的WSDL绑定信息作为基于SOAP的消息被传递到了证券投资管理门户。4证券投资管理门户调用由J2EE应用服务器提供的证券报价Web Services，在调用的时候，股票标识符被作为SOAP消息的一部分传入。5这个Web Services的具体实现由运行在其他J2EE应用服务器（当然也可以就是这个J2EE应用服务器，这取决于企业内部的体系架构）上的EJB来提供，这个EJB通过JDBC API获得数据源中的数据，在这个例子中，数据源是IBM DB2。6这个EJB的 Web Services响应同样以SOAP消息的形式出现，同时，这个SOAP消息被发送回证券投资管理门户。7证券报价响应被格式化为XML/XSLT/HTML的形式回传给基于浏览器的客户前端。8其他的在公司企业网内部的企业VB应用（当然也包括其他开发工具开发的应用）也能够通过Web Services技术调用这个证券报价Web Services，从而成为证券报价Web Services的另外一些客户端，同样，他们之间的调用也是使用SOAP消息完成的。 Web Services与企业资源计划在分析了如何运用Web Services来进行EAI之后，下面将从这些待集成的企业应用的角度着手，以企业资源计划（ERP）为例，来考察一下它们又是如何转变来适应Web Services环境的。我们知道，企业需要的是能产生经济效益，提高投资产出率的软件产品。ERP通过集成财务信息、集成客户订单信息、标准化和加速生产流程、减少仓储费用以及标准化人力资源信息来达到这一目的。对于一般企业而言，如果他想部署ERP，那么他可以选择下面三种模式的一种：1一次性全部将现有系统升级到整合ERP系统；2各个分支机构使用不同的ERP系统，然后进行集成（这个比较适合大型跨国企业）；3一个一个模块逐个购买，并逐个融合入企业的商务流程。我们之前已经提到如何应用Web Services来集成企业应用，企业应用当然包含ERP。那么我们大胆地考虑一下，如何直接将Web Services技术引入ERP系统，使用Web Services的理念来架构ERP，对ERP会带来什么样的影响呢?我们认为，对于ERP而言，Web Services主要能够提供两个好处：易于集成；减少应用部署的代价，同时更为灵活。第一点应该很好理解，就是把原先要在外部实现的EAI的功能部分移植到ERP内部。第二点则是按照以下方式考虑的，我们刚才已经分析过，一个ERP总有很多不同的模块，诸如财务系统、仓储系统等。同时，用户有时候会选择第三种部署模式，即逐个购买模块。将Web Services技术引入到ERP内，可以将应用集成模式带到ERP内部各个模块之间，使得ERP内部模块之间的集成和ERP与其他企业应用的集成使用相同的技术，从而在部署上能够更方便地利用各种硬件平台，在集成上减少技术代价，提高灵活性。目前，大多数主要的ERP厂商已经开始着手将他们的ERP软件升级并支持Web Services技术，其中包括最大的ERP厂商SAP，Oracle，PeopleSoft等。下面的表 2-1是一张ERP厂商对于Web Services技术支持的时间表。表 2-1 ERP厂商对于Web Services技术支持的时间表竞 争 者提 供 环 境期望发布时间当 前 状 态交 付SAP基于相同核心的J2EE和ABAP2002 即将完成R3, mySAP.comOracleJava2002准备发布11i Suite, Java APIsPeoplesoftSOAP/UDDI工具2002即将完成Peoplesoft 8Microsoft.NET和Passport2001已经完成BcentralSiebelBusiness Services2001 已经完成Siebel7下面的表 2-2则对于传统ERP和基于Web Services技术的ERP给出了一个特性对比。表 2-2 传统ERP和基于Web Services技术的ERP的特性对比特 性传统解决方案基于Web Services的解决方案可伸缩性低很好实施时间很长中等维护能力低很好可靠性中等好可移植性低很好进入代价高中等维护代价高低统合代价高低投资收益率中等很高 基于Web Services的EAI实践目前，已经有不少专注于Web Services技术的专业技术提供商提供了各种基于Web Services技术的EAI平台。它们包括：webMethods，Epicentric，Silverstream以及IONA。webMethods Integration Platform：webMethods的这个集成平台运用Web Services技术，提供了对企业应用、数据库及数据仓库、主机系统以及各种传统系统、Web Services等的集成能力，webMethods的特点是对SAP ERP系统有着非常优秀的集成能力。Epicentric Foundation Server：Epicentric的这个企业门户的基础管理平台，为构建企业门户应用提供了强大的支持，通过这个平台，不仅能将内容集成发布，同时也能将应用集成在统一的平台上。Silverstream eXtend：Silverstream的这个产品系列是架构Web Services的一个通用平台，同时，Silverstream在这个平台上提供了对各种应用系统的集成模块，包括CICS RPC，EDI，SAP，JMS等，应该说这是一个支持EAI的Web Services平台。IONA Orbix E2A Web Services Integration Platform：这是一个专注于企业应用集成的平台，提供了对大量外部系统的集成能力，它能够支持J2EE，.NET，COM以及CORBA等各种组件，同时对B2B protocols，OS/390，SAP，Siebel，CORBA，RDBMSs，MQ Series等协议、系统及平台提供无缝集成。2.2.5 Web Services与B2Bi2.3 J2EE与.NET, 对抗与整合2.3.1 J2EE与.NET概述Microsoft.NET与J2EE是目前企业Web Services平台市场的两个最重要的应用框架（Application Framework）。它们都针对分布式N层（N-Tier）应用的设计、集成、性能、安全性和可靠性等诸多方面为用户提供了总体的指南和规范，基于这些指南和规范，技术提供商提供了相应的平台、工具和编程环境。在具体的应用框架中，包括了针对应用的表现层服务、服务器端进程、会话管理、商业逻辑框架、应用数据缓存、应用逻辑、持久化性、事务、安全和日志服务等。技术提供商能够在应用框架的顶部构建应用程序开发工具和应用服务器。应用框架的目标是提供一个统一的软件框架，以减少对企业软件产品的支持、维护和集成的代价。Microsoft .NET是一个由Server，Client和Service组成的平台。.NET框架包括基本的运行库、用户接口库、CLR，C#，C+，VB.NET，Jscript.NET，ASP.NET以及.NET框架API的各个方面。它由以下三个部分组成。 .NET平台：包括构建.NET服务和.NET设备软件的工具和基础框架； .NET产品和服务：包括基于Microsoft .NET的企业服务器（如BizTalk Server 2002 和SQL Server 2000，它们对.NET框架提供支持）； 第三方软件开发商提供的.NET服务：构建在.NET平台上的第三方服务。J2EE（Jave企业版）则是一组规范集，其中的每一个规范规定了Java技术应当如何提供一种类型的功能。J2EE平台为基于多层分布式应用模型的Java应用的设计、开发、装配和部署提供了一个完整的框架。J2EE规范为应用开发和企业系统集成，定义了数目众多的应用编程接口（API）和多种应用编程模型。最新的J2EE规范包括EJB 2.0，J2EE Connector Architecture1.0，JDBC 2.0，JSP 1.2，Servlet 2.3，JTA 1.0.1，JMS 1.0.2，JNDI 1.2，Java RMI 1.0，RMI/IIOP 1.0，JAAS 1.0，JavaMail 1.1和JAXP 1.1等。2.3.2 J2EE与.NET的比较从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web Services技术的烙印，它在市场推广活动中，无时无刻不凸现其作为Web Services的开发和部署平台的特征。可以说，.NET天生就是为Web Services准备的开发平台和部署平台，.NET就是Web Services平台。相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级解决方案的应用领域而制定的一个平台框架规范，随着Web Services的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，是无法回避业界的重大技术革命“Web Services”的。随着Web Services技术的发展，J2EE不断地将Web Services的支持引入进J2EE框架。它们之间的比较基本上可以通过下面的表 2-3来给出。表 2-3 J2EE与.NET的比较标 准J2EE框架.NET框架基本设计和对Web Services的支持通过一组API包（JAXM,JAXP,JAXR,JAX-RPC）对Web Services提供支持Web Services直接构建在平台中，.NET框架提供完整的服务标准如SOAP，WSDL和UDDI实现J2EE的Web Services实现一般是通过EJB来实现的，然而也可以把提供Web Services实现的Java应用独立出来，这完全依赖于设计和构建应用程序的业务处理和数据逻辑层.NET框架中Wem服务的实现一般通过.NET Managed Component（包括Managed Class以及COM/COM+组件）来实现价格与Microsoft的.NET相比，花费较高，然而，如果一个公司已经具有基于J2EE的应用服务器平台，使用现有的基本构架和设备将会比较合适比基于J2EE的应用服务器便宜得多，然而，目前J2EE仍然是企业服务器端应用的较好选择工具和服务器有多家公司已经构建了基于J2EE的集成开发环境（IDE）和应用服务器。它们中的多数已经开始在产品中支持Web Services的创建、部署和运行，对Web Services标准的支持和复杂的程度因产品而异Microsoft进行Web Services开发的基础开发工具（集成开发环境IDE）是Visual Studio.NET，使用Visual Studio能够确保产品的强壮性和易用性。Microsoft同时提供了支持Web Services的服务器软件，包括BizTalk 2000以及SQL Server 2000等企业支持多个独立的公司，包括IBM，BEA，Oracle，HP，SUN等，在它们的基于J2EE的开发工具和应用服务器中正在提供对Web Services的支持。当在这个技术领域中有多个竞争产品时，就意味着没有单个公司的垄断所有的工具、服务器和技术都是由一家公司控制：Microsoft。尽管Microsoft 公司对Web Services技术做出的承诺和稳定性没有任何问题，但是没有竞争，技术的提供和推动也许不是最好的。不过Microsoft刚刚在它的网站上提供了.NET的核心CLI for FreeBSD的源码下载。这也许是一个好的开端平台的成熟度在过去的四年中，J2EE已经被证明是一个稳定的、可扩展的、成熟的平台。新增的对Web Services的支持是这个平台的又一个特征尽管.NET从Windows DNA体系框架中继承了大量的特征，但是它仍然相对较新，需要被证明能够提供企业范围的应用框架在后面，将对各个子项的细节逐一加以描述。 Web Services支持在本节，我们再就两个平台在本文更为关注的Web Services方面的支持性做更详细的比较。从使用者的角度来看，两者都是Web Services的开发和部署平台，在这里，我们将首先来比较一下两者对Web Services的支持力度，比较将从以下四个方面来进行：1服务实现（Service Implementation）2服务调用和执行（Service Invocation and Execution）3服务描述（Service Description）4服务发布、发现与绑定（Service Publishing, Discovery and Binding）1服务实现目前来看，实现一个Web Services，实际上意味着首先要将服务调用所需要指定的操作以及操作所涉及的数据结构化，组织成符合SOAP规范的XML消息文档，然后该Web实现需要能解释和处理这个XML文档。当一个Web Services被实现之后，这个Web Services的客户端就能够向其发送一个SOAP消息，该SOAP消息中包含了需要调用的具体操作以及涉及的数据，这个Web Services接收该SOAP消息并完成处理后，向客户端响应一个SOAP消息，该消息包含了操作的执行结果（返回值）。在J2EE中，通过使用SUN的Java Web Services Developer Pack（在文章的后面部分，将简称为WSDP）中的Java API for XML-based RPC（JAX-RPC），已有的Java类或Java应用都能够被重新包装，并以Web Services的形式发布。JAX-RPC提供了将RPC参数（in/out）编码和解码的API，使开发人员可以方便地使用SOAP消息来完成RPC调用。同样，对于那些使用EJB的商业应用而言，同样可以使用JAX-RPC来包装成Web Services，而这个Web Services的WSDL界面与原先的EJB的方法是对应一致的。JAX-RPC为用户包装了Web Services的部署和实现，对Web Services的开发人员而言，SOAP/WSDL变得透明，这有利于加速Web Services的开发进度。当然，如果开发人员认为这样的透明带来了不灵活性，那么也可以直接使用JAXP来手工地处理XML消息。.NET是一个在J2EE之后出现的平台，所有的重量级技术产品无一例外地都会吸收先前的成功者的优点。.NET大量地吸收了Java平台，甚至是J2EE平台的优点，其中，最重要的一点就是.NET不再完全沿袭Microsoft先前的技术，从.NET开始，.NET应用不再以本地机器代码运行，而是编译成中间代码（Microsoft Intermediate Language），由称为CLR（Common Language Runtime）的虚拟机来运行，这样，.NET也具备了强大的跨平台能力。.NET不但在底层跨平台，而且在开发语言上也能以较小的代价支持更多的开发语言。它支持的所有开发语言，包括VB.NET，C#，C+，JScript等都被编译成相同的中间代码，使用相同的运行库执行。因此，从平台特性而言，.NET平台是迄今为止最“通用”的应用开发和部署平台。在.NET平台上，开发人员可以自由地使用各种语言来开发Web Services，.NET平台同样提供了优秀的快速开发工具，将SOAP/WSDL等繁复的技术点对开发人员透明。当然，开发人员同样也可以使用MSXML来直接处理XML消息。2服务调用和执行SOAP（Simple Object Access Protocol）为在一个松散的、分布的环境中使用XML对等地交换结构化的和类型化的信息提供了一个简单且轻量级的机制。SOAP规范主要由四部分组成； SOAP信封用于包装数据； 可选的编码风格用于表示应用相关的数据类型以及数据； 请求/响应的消息交换模式； 可选的SOAP/HTTP绑定。SOAP是Web Services的主要通信协议。一个Web Services一般而言是以一个SOAP Listener的形式存在。当它收到SOAP消息，会将消息解码，并将其中的数据传给相应的商业处理模块进行处理，处理结果回送给SOAP服务器，SOAP服务器再将处理结果包装成响应消息返回调用者。J2EE使用SUN WSDP中的Java API for XML-based RPC（JAX-RPC）来完成使用SOAP方法，来调用远