还有，作为一种用于Web服务开发的框架，WebLogic Workshop还特别为开发者考虑了关键的三个地方：

异步式的消息传送

在本文中，我们将讲述WebLogic Workshop如何从头到尾地帮助开发者管理和操纵当今复杂的Internet事务处理，如何帮助你在具有这三种特性的环境下快速、高效地完成工作。首先，我们简单地了解一些背景知识。

来自客户-服务器处理方法的教训

BEA项目部副总经理Adam Bosworth认为，通用WebLogic Platform和专用WebLogic Platform的目标是为那些需要进行app2app集成的开发者设计一种适用的体系结构。为实现这一目标，我们理解客户-服务器处理方法中的教训是很重要的。

客户-服务器是一种传统的两层体系结构，通常是由某个人建立客户端，另一个人建立数据库。不过，客户-服务器应用通信起来并没有什么不妥，因为数据库为它自身与客户端之间的通信提供了一套约定。实际上，客户端事先就已经知道数据库模式以及所需的SQL调用。由于双方共享了一套专用的约定，客户端和服务器被紧紧的连在一起。如果替换了数据库工具，则客户端将被中断，并且需要重新写过。

Client-server应用访问数据库时常常是用单个的SQL语句，这意味着这种编程模式是效率低下的。为了说明这种缺点确实存在，你可以想象一下，假设你在经纪行有一个帐号，你所有的财务记录都存在这个帐号中，如支票收入、银行存折帐号、股票证券等。在客户-服务器模式下，需通过选择数据库中的某一行某一列来访问数据，通过各种语句获取各种财务信息，这些操作很容易把服务器给搞垮。简直是得不偿失。

粗粒度式的通信

不管是客户-服务器模式还是分布式处理模式，都给了我们这样一个教训：访问信息应该通过规则的块进行，而不是通过一条一条的语句。换句话说，既然访问一次就够了，何必多跑几个来回呢？没有理由留下不必要的隐患。这一法则对在Internet环境下开发应用软件的情况尤其适用，因为在这种情况下可靠的TCP/IP会话早已过时，并且建立连接的开销相当大。

比起来回的效率问题，更重要的是要保证处理的持续性。由于细粒度模式分为许多小段，在一次事务处理的整个过程中，都需要调用数据，这使得一次事务处理占时太久，并且会导致后端超时。相反，只有通过向后端请求一整块的数据，你才可以确保事务处理的连续性。

上述所有论点都说明了Web应用之间的通信应该采用的是粗粒度模式，而不是细粒度模式。在最近的一次采访中，Adam Bosworth对此作了精辟的解释：

"试想，如果每个人都去超市，买一小块黄油，然后回家，接着又来，买一夸脱牛奶，又回家，接着又返回，买一块面包，如此往返。要是每个人都这么做的话，那简直就是一场灾难。超市里排队的队伍就要到门口了，因为处理每桩单独的买卖花费相当的高。这就是为什么你购物时要买满一袋的东西，因为这样效率更高"br>
实际上，用XML通过粗粒度模式的消息传递来实现集成信息是一种很有用的方法，粗粒度模式是利用XML来存放和描述对象的持久状态的。由于粗粒度XML文档比较接近它们所支持的事务处理，通过使用这种文档开发者建立的Web服务就可以注意力放到相关信息如完整的发票或订单的信息包的传送和接收上了。

而且，XML在松散耦合中也是不可或缺的。因为在松散耦合模式下，应用的界面必须与应用的实现完全分开。

松散耦合式的应用

如今，应用都是被放在网上作为Web服务的。如果应用是松散耦合的，开发者就可确信该应用的实现方式的更改不会牵涉到其他可能通过Web服务与之发生依赖关系的另一个应用。这样的方式才是成熟的：如果一个应用或Web服务与另一方对话时，另一方中的对象对它来说是应该是透明的。这些对象可以是COM，也可以是Java对象。底层的具体实现并不重要。

在Web上可以找到这样的例子，amazon.com和barnesandnoble.com两个网站看上去十分相像，在这两个网站上，你都可以通过输入书名或书的ISBN号找到十分相似的有关书的信息。但是，透过表面你就可以发现，这两个网站不但采用了完全不同的操作系统和数据库平台，而且其中一个网站中的对象与另一个网站的对象毫无关系。事实上，这些Web应用是由不同的人开发的，他们用不同的方式来设计对象，由于对象的设计牵涉到实现问题，其他人无需关心这些底层的细节。所有应该关心的只是对象向外界所提供的接口。

Client-server和分布式处理系统的失败之处都在于：它们中的实现都是可见的，相互关联的，或者可能还可以知道数据库的运行情况，或者与ORBS和IDL纠缠不清。

在松散耦合模式下的数据访问方面，惟一真正取得成功的例子只有Web本身。当开发者更改了网站的实现方式时，浏览器还可以访问网站。之所以可以做到这一点，是因为浏览器本来就不关心它访问的站点是如何实现的。浏览器惟一知道的就是线格式（wire format）--通常是HTML--以及线协议（wire protocol）--HTTP。

这也正是Web服务所要达到的目标。Adam Bosworth指出，对客户端进行编码时不应该将应用想象成一套带有方法的对象，而应该将其想象成支持某些已知格式（特殊情况如XML语法）和设计良好的协议的一个站点。Web服务是一种松散耦合式的服务，这些服务将它们的接口作为一套由WSDL描述的XML消息，并且使用了SOAP协议。Web服务应用对另一Web服务应用的实现应该是一无所知的--它只知道线路级（wire-level）协议和它能发送和接收的由WSDL描述的一套XML消息。也就是说，Web服务的体系结构要清楚一个应用所预期的公共约定（要产生或接收的XML），并且这些约定要与各自的实现分开。SOAP是一种用于描述所有这些协议的一个标准的模型。实际上，SOAP既描述了该协议的线格式，又描述了协议本身。

但是SOAP--或更具体来说是SOAP-RPC，通常被被大多数Web服务框架设计成一种同步的，自动映像的协议，在松散耦合式应用中，这种调用具有天生脆弱性。因此，RPC常常出错。例如，RPC认为可以对那些传给XML消息或由XML消息传来的参数或返回类型进行自动映像，而实际上不是这样的。因为这种映像是一种各自实现的细节，因人而异。RPC还认为调用者知道接收者的署名和类，而实际上，这种情况很少出现。最后，RPC还认为可以将收到的XML转换成已知类的参数或用已知类返回的参数，如果真是这样的话，RPC将要求收发双方要有非常好的默契。所有这些都表明，要使基于Web服务的应用集成具备天生的健壮性，松散耦合是关键。

异步式的消息传送

使用异步式的消息传送主要基于三大原因。首先，在Web服务领域，应用并不总是随时可访问的，在你希望访问这些应用时，它们可能没有处在运行状态，它们可能是以批处理模式工作的，或者它们因为需要维修或升级而停止了运行。而如果采用了异步处理方式，这些就不再是问题了，因为这种方式下，消息传送的延时很短。

其次，与第一点差不多，是关于负载的。并非所有的应用都可以处理不可预知的负载。一个典型的例子是网站。举个例子，即使是一个相当健壮的网站，在一台16-cluster的机器上运行，当每个处理器要处理5条线程时，处理器就认为自己已经超载了，从而拒绝请求。负载往往是难于预料的，而比起网站来，Web应用更加经不起不可预料的峰值负载的折腾。如果所有请求都是同步处理的，那么峰值负载将使每个应用都不能处理任何单故障点负载。在app2app环境下，情况还要糟糕得多。因为超载的应用将一次又一次地收到来自其他应用的重试消息，这简直是雪上加霜。如果使用异步处理方式，这种窘境根本不会出现。因为在这种方式下，消息被排成队列，一个接一个地来。

第三点，也是最后一点，使用异步模式是因为大环境使然。在现实中，许多Web应用要处理的任务往往不能实时完成，因为这涉及到一些人和事务的处理。例如，当码头来了一批货时，需要人力来卸货，并在卸货单上作记录。当货物卖出时，记录销售情况的过程也有一些延时。这样的话，应用难于快速作出反应。即使对一些瞬间就可以完成的事务，如检验信用卡，在发出信息之前也还需要人的操作--而且负责这项操作的人可能不舒服或者这样的请求是在周末发出的，这时根本没有人会对次作出响应。在所有这些情况下，如果应用采取同步方式来获取信息，那么这种应用必然是失败的。而这一次，异步模式又十分管用，因为当有事情发生时，每个应用只能向其他应用传送单程的消息。

因为这些原因，使用一种基于企业的健壮的Web服务体系结构将可以--如果你不坚持的话--至少可以使开发者更易于进行异步的消息传送。当然，并不是每一种设计模式都必须是异步的。例如，如果你有一个高度可靠的应用来处理只读数据--典型的例子就是股票开盘服务，而且这些数据可以放在高速缓冲存储器里面，那么这个应用就可以保证有非常快速的返回，这种情况下就没有必要强制使用异步模式了。但是，对大多数情况来讲，异步式的消息传送可以确保系统对负载有一定的缓冲能力，为交互提供了一种各组成部分之间松散耦合的方式，并且可以减少出现那些会破坏Web服务运行的单点故障的可能性。

WebLogic Workshop

那么，所有这些跟WebLogic Plagform 7.0有什么联系呢，开发者从中得到的最大的好处是什么呢？换句话说，WebLogic Workshop到底为Web服务开发者带来了什么看得见的好处呢？答案是充分的。首先，WebLogic Workshop这种新的在应用服务器中坐头把交椅的可视化设计和开发环境，是围绕着前面我们讨论过的三大要点设计出来的。它非常便于实现异步模式的消息传送，通过它可以轻松操作粗粒度数据，而且，它使得编写松散耦合式交互的程序非常简单。

一开始，Web服务上的buzz大多数集中在简单的、同步的RPC-型Web服务或者基于HTTP协议的基本的request/response调用。Web服务需要与后端资源如遗留应用（legacy application）、ERP软件包以及数据库系统等进行互操作。为满足在Web上处理业务的要求，Web应用应该是足够可靠的，可用的并且是可升级的。如果资金紧张，而且项目资源有限，那么参与企业IT开发过程的开发者将不得不在比较仓促的时间内开发出Web应用。简言之，Web服务必须适合于进行跨平台的、基于标准的方式的系统集成，这种集成可能在公司内部，而可能在涉及到公司的外部，集成方式非常灵活，而且需要考虑今后的变化。WebLogic Workshop为开发者游刃有余地实现上述目标提供了良好的平台。下面介绍WebLogic Workshop是怎样做到这一点的。

常识

WebLobic Workshop IDE提供了一套完整的、可视化的Web服务应用开发环境，从而为Java和J2EE的新手入门减少了障碍。这套开发环境包含了一些标准的特性，如项目管理、代码生成、标签高亮度显示以及综合调试等。这样一来，开发者就可以将时间和精力直接投入到应用的事务逻辑的设计中去，而不需要关心诸如访问组件所必需的J2EE API、调用EJB或获取JDBC资源等细节问题。Visual Basic开发人员、过程式语言的程序员（从C或者COBOL语言逃出来的）以及熟悉各种脚本语言的工程师将发现，要转入被Workshop环境大大简化了的Java中来，是何等的容易。还有，由于WebLogic Workshop对与企业应用有关的"plumbing"作了如此多的简化，甚至J2EE的专家都通过使用这种可以快速开发Java应用原型的工具尝到了甜头，他们也因此而选用了像vi或emacs这样的编辑器来编写低级功能性的细粒度控件。作为一种集成工具，WebLogic Workshop可用于将整个开发团体带到同一个平台上来，为不同类型的用户提供了用武之地。如果J2EE专家们知道同一团体的所有开发者都可以轻松地访问到他们，他们就可以将注意力放到企业组件或应用的原型开发上来。

JWS文件

在可视化开发环境下，让开发者创建JWS文件是完全可能的。一个JWS文件可以看作是JSP或Web服务。BEA技术传播小组的主管Tyler Jewell将JWS文件描述为使用了一套标准Javadoc标签的Java文件，这些标签用于标注属性、方法和内部类。JWS文件被放在WebLogic或者任何支持JWS的J2EE应用服务器的Web application目录下。在同一目录下，还放有JSP文件。正如JSP文件一样，每个JWS文件都可以通过惟一的URL来引用。当应用服务器收到一个URL请求时，便对该JWS进行解析，然后创建一个新的J2EE应用，这个应用可能由servlet、EJB、JMS队列或JCA适配器组成。这些文件被打包在一个企业应用资源（Enterprise Application Resource，EAR）文件中，并展开到同一个服务器中，作为一个新的Java应用。这个新的应用被用作一个Web服务，供外部的客户端使用。
Workshop运行时框架

Workshop可视化开发为Web服务提供了一种图形化的表现方法，一个代码编辑器，并可以与运行时框架（runtime framework）联系起来。由于运行时框架是开放的、可扩展的，因此其他的IDE，如Jbuilder或TogetherSoft可以和运行时进行交互并且为管理Web服务和JWS文件提供它们自己特有的结构。基本上，运行时框架功能展示出来（通过JWS注释）是为了支持创建企业Web服务。根据WebLogic Workshop产品部经理Carl Sjogreen的说法，这正是Workshop在功能上与我们前面讨论过的赢得开发者青睐的三大要点相吻合的地方。

会话和消息缓冲

在异步编程模式下，会话（Conversiation）和消息缓冲(Message Buffering)总领一切。会话指定了某个操作的开始、中间和结束，这便于开发者在长时间的事务处理过程中维护交互状态。采用一个消息缓冲区可以为在不可变队列中安置请求和响应提供了便利，这样就可以确保这些请求和响应最终都得到处理。Workshop框架在一次会话中的消息之间自动地管理异步消息关系和状态管理。通过使用Workshop可视化环境，开发者可以简单地将方法标记为会话的开始、中间和结束，而由框架来管理细节问题。为标识会话，这里自动生成了一个惟一的ID，在Web服务中定义的状态将通过实体Java bean来持续地管理。同时，Workshop IDE可以用于设置一个属性，该属性允许消息缓冲，允许框架透明地以JMS队列的形式有线传送，以确保能够合理地管理消息。

值得注意的是，正如Adam Bosworth经常指出的那样，Workshop框架不但支持JMS作为一种透明地管理异步的机制，而且可以作为一种企业级的可靠的消息传送协议。目前SOAP还没有可靠的发送协议，而Workshop克服了这种标准的不足，因为Workshop支持JMS上的SOAP作为一种可靠的发送范例。

XML映像

专用的松散耦合，以及通用的粗粒度消息传送，它们都得益于Workshop产品所具有的XML映像的特性。

为确保松散耦合性，开发者必须能够轻松地将Java堆栈中的对象的内部描述形式转换成XML，后者最终将离线。大多数开发者在松散耦合的交互环境下，都不大考虑对象的串行化和反串行化。Workshop XML映像允许开发者独立于底层的Java实现来编辑XML界面，从而具有了松散耦合性。这种对复杂的XML文档的强大支持，使得开发者可以快速而自信地建立应用和服务。

Workshop环境提供了简单的、可公布的XML映像，这样可以使内部的Java代码与Web服务之间的XML消息交换联系起来。Workshop映像使开发者可以轻松地由一个Java署名来建立XML，这样一来，当Java方法返回一个对象时，就可以建立一个与之对应的公共约定。反之，如果一个XML消息传了进来，该消息带来了一个公共约定，开发者就可以从中提取出适当的部分并将之作为Java的一个方法的参数。另外，如果这种映像是不完整的，或者是有缺陷的，Workshop运行时将产生一个编译错误。所以，开发者如果不遵守这个约定，就不可能建立一个系统。

一些其他比较成熟的映像技术，如ECMA脚本，也可以用于映像定义中。Workshop为XML的扩展提供了扩展了的ECMA脚本，从而简化了对XML的访问，并且支持复杂架构或数据的转换。ECMA可以毫无异议地采用上述扩展。最后，Workshop IDE支持XML映像的定制，这使得开发者可以导入XML模板，并创建可生成粗粒度XML文档的Web服务，这些粗粒度文档可以是订单、适合各种业务的发货单以及服务级协议等。

总结

目前，大多数关于Web服务以及与之相关的开发工具都集中在简单、同步的RPC-型实现工具上。然而，这难于跟上时代潮流，因为Internet处理已经发生了翻天覆地的变化--发展到了企业应用集成（Enterprise Application Integration）。对于那些大规模的企业运作来讲，简单的Web服务既不够健壮，也不够可靠。

简单Web服务缺少了一种综合的环境，只有在这样的环境下开发者才可以在应用提供的公共约定和底层实现之间建立松散耦合。而且，简单Web服务还缺少了一种允许开发者建立支持复杂业务处理的粗粒度文档的框架和设计工具。WebLogic Workshop大刀阔斧地改进了这些不足，不管是新手，还是专家，WebLogic Workshop都为他们提供了一套妙不可言的工具，去迎接下一波集成Web应用的浪潮。

原文URL：http://dev2dev.bea.com/articles/406.jsp

作者简介
	Tom Clements是一位资深的技术作家，自由诗人。他专门研究Java API文档、Web服务、XML/XSLT技术、设备驱动程序的编写以及无线通信等领域。先后在JavaWorld和Byte杂志上发表文章，同时还是Oracle、Sun、JavaOne以及BEA等网站的专栏作家。