WebLogic Platform 7.0

本文将描述WebLogic Workshop如何快速、有效地解决这三大问题。WebLogic Workshop专为帮助开发人员开发和管理当今复杂的互联网计算而建立。我们首先提供一些背景材料。

客户/服务计算的教训

BEA负责工程的副总裁Adam Bosworth指出，WebLogic Platform的统一目标-- 也是WebLogic Workshop的特殊目标 --就是建立起应用到应用集成的开发者所需要的特定体系结构。为了达到这个目的，了解客户/服务计算的教训非常重要。

客户/服务，即传统的两层体系结构，典型的开发方式是将建立客户端的任务委托给某些开发人员，而另外一些开发人员负责建立数据库。因为数据库将通讯协议提供给客户端，所以客户－服务器应用之间的通讯不存在问题，实际上，客户端必须预先了解数据库设计以及需要的SQL调用。由于它们共享私有的协议，客户端和服务器端组件紧密偶合在一起。当数据库实现发生改变时，客户端代码遭到破坏，需要重新编写。

客户－服务器应用，很大程度上依赖于单条SQL语句进行数据库访问，是一种低效的编程模式。为了说明这种模式的缺点，假定您在经纪公司建立了一个账户，存储了您所有金融记录－包括支票、存款账户、股票证书等。在客户－服务器世界中，需要从数据库中定位行和列并抽取各种金融信息，而这样会使服务器陷入困境。付出的努力太大，而获益很小。

同样，在分布式n－层环境中，如果将所有信息封装为某个对象的属性，并且不得不为每一个数据访问编写方法。那么为了访问所有数据您可能最后调用了很多方法。如果您作为横跨多个组织的代理，需要激活多个过程，资源会开始延伸并且变得细碎。远程调用对象天生就是细颗粒处理。您需要的应用模型，不是相互之间以分布式对象来调用的集合，而是作为应用来调用的集合。简单地说，需要的是一个稳定高效的应用到应用（app2app）的集成。

大粒度通讯

无论是从客户－服务器还是分布式计算获得的教训告诉我们，信息的访问需要以大小合适的块而不是单个数据片进行。换句话说，如果一次能够完成，就决不用多次往返。 不应该有如何引发等待的动作。这在开发互联网应用时尤其明显，可靠的TCP/IP会话不是目前之急需要，而建立连接成本才是最重要的。

在往返效率之上，事务一致性更加重要。在单个事务中采用多个细分的数据请求，将会导致事务时间跨度太大，引发后台处理超时。相反，从事务的角度看，要求后台发送大块的数据可能是获得事务一致性的唯一的途径。所有上述观点都趋向于采用大粒度而不是细分的方式在网络应用之间通讯。在最近对Adam Bosworth的一次采访中，他对这个主题发表了下面的评论：

“设想一下，所有人都进超级市场购买一块黄油，然后回家，再返回购买一夸脱牛奶，回家，再返回购买一条面包，等等。如果每个人都这样做，将是一场灾难。超级市场的长队将会排到门外，这是因为处理单个交易的成本非常高。这就是为什么我们成包购买的原因，那样更有效。”

XML的出现，为采用大粒度消息的集成信息提供了伟大的方式，它利用XML存储和描述对象的持续状态。采用大粒度XML文档与其所支持的业务水平相适应，开发人员能够建立网络服务，该服务集中处理如整个发货单或购买订单相关信息包的发送和接收。

更进一步，XML是松散偶合的基础，这样应用接口能够与应用实现彻底分离。

松散偶合应用

今天的应用以网络服务的形式出现。应用之间是松散偶合的，开发人员确信，通过网络服务改变正在执行的应用，不会中断依赖于此程序的其它应用。这是基于这样的观点完成的：当应用或网络之间相互对话时，并不关心在应用或服务中的对象的具体执行，它们可以是COM也可以是Java. 底层的实现并不重要。

网络上已经有很好的这样的例子：amazon.com 和 barnesandnoble.com 两个网站看起来几乎完全一致。在两个站点上都能通过书名或ISBN搜索书籍，查看图书信息，而且使用起来非常相似。但深入里面就会发现，它们不仅操作系统和后台数据库不同，就连各自站点所用的对象也毫无关系。事实上，网络应用是由不同的人员基于对对象不同的视角所建立，对象只是执行的一部分，没有人关心其底层细节。对象呈现在外的公共接口才是重要的。

客户端－服务器的形式以及分布式计算在这点上都没有成功。无论是通过复杂的数据库操作，还是通过ORB与IDL之间的相互依赖，它们都表现出了执行的相互关联性。

迄今为止，在松散偶合领域最成功的例子就是网络自身。开发人员改变站点的执行，浏览器照样能够浏览站点。之所以能够这样是因为浏览器对它所访问的站点的实现未作任何假设。浏览器知道的唯一的事情就是框架格式－通常是HTML，及框架协议－通常是HTTP。

这也是隐藏在网络访问之后的目标。Adam Bosworth 指出，客户端代码不应将应用想像为具有方法的对象的集合－应将应用设想为一个站点，支持已知的框架格式（例如，特定的XML语法）以及已定义好的协议。网络访问是松散偶合的服务，它们的接口以XML消息的集合形式出现，XML消息利用SOAP协议经由WSDL描述。

网络服务应用无需关心其它应用的实现，它了解的只是框架级协议以及WSDL描述，并且能够发送和接收的XML消息。这就够了。因此，重要的是网络服务体系结构具有应用期望的、清晰的公共协议（即，能生成或接收XML格式），并且保持与具体实现彻底分离。SOAP就是这样一种标准和协议的一个描述模型。 事实上，SOAP既描述了协议的框架格式，也描述了协议本身。

但是，SOAP,或者再具体点SOAP-RPC,是大多数网络服务架构典型实现的同步的、自动映射的协议。这种调用在松散偶合的应用世界中具有其天生的弱点。由于这个原因，RPC经常中断。例如，RPC意味着能够自动地在XML消息与参数或返回类型之间成功映射。但事实上并非如此。这种映射是一种私有实现细节，每个人的实现可能不同。RPC也隐含着调用方了解接收方的签名和类，但实际很少是这样的。最后，RPC隐含能够精确地将所有收到的XML转换为已知类变量，或从已知类的返回值转换为XML。说来道去，RPC方式要求发送方与接收方紧密相关。 所有这些归结为一点，松散偶合是稳健的基于网络服务的应用集成的本性。

异步消息通讯

采用异步消息通讯方式的主要原因有三。第一个原因，在网络服务世界，应用并非永远可用。它们可能在您想访问时未启动运行，也可能正处于批作业模式，或可能关闭进行维修和升级。异步处理并不会出问题，只是消息分发所花时间长些而已。

第二个原因与第一相似，与负载有关。并非所有应用都能处理不可预计的负载。最经典的例子是网站。甚至一个由16台机器集群组成、每台处理器运行5个线程这样一个相当稳健的网站，也会发现在某个超载点会开始拒绝请求。负载只是不可预计。而网络应用（Web applications）比网站对于未预见到的负载峰值事件表现更脆弱。在负载高峰时，同步处理请求使每个应用都无法处理负载，从而成为单点故障。在应用到应用（app2app）情形时这种情况会更加混乱，超载应用可能不断收到其它应用一次又一次的重试消息，使已经不利的情况变得更加恶劣。异步处理时不会出现这种情况，队列只是涨落而已。

第三个或最后一个采用异步通讯的原因可能也是最引人注目的。因为在真实世界中，很多指望网络应用的任务需要人为干预和业务处理，不能实时完成。如，货物到达装卸码头时，人们需要卸载货物，并在货物清单上签字。当货物售出以后，销售佣金通常要滞后一段时间才可以计算出来。在这种情况下，应用的快速响应就受到了抑制。甚至是在实时事务的场合，象信用卡支付，在信息被放行之前，也需要人们的干预－负责干预的人员可能生病了，或者请求刚好是在周末无人值守时。在所有这些情况下，如果应用发出同步调用想获得信息，就会发生单点故障。这样，异步模式在此时就会运行良好，因为在相关事情发生时，每个应用只要向其它应用发送单向消息即可。

由于这些理由，对于开发人员来说，一个稳定的，基于企业的网络服务体系结构，如果不是坚决要求的话，至少也是轻而易举地会采用异步消息传送。当然，并非所有的设计方案都得是异步的。如果某个高可靠的应用需要操作只读数据－如快速股票行情服务－这些数据利用缓存以便确保应用能够尽快返回，此时，就不必采用异步结构。但是，在大多数场合，异步消息能确保系统根据负载进行扩展，为组件提供松散偶合的交互方式，减少了由于单点故障引发的网络服务操作失败。

WebLogic 工作间

那么，WebLogic 7.0平台与这一切有什么联系呢？对开发人员有哪些大的诱惑呢？换句话说，WebLogic 工作间把这些都替网络服务的开发人员考虑到了吗？回答是非常肯定的。首先，WebLogic 工作间－一个新的，可视的设计和开发环境，是从应用服务器的高度，围绕我们所讨论过的三点进行设计的。使异步通讯易于实现是设计的出发点之一。另一点是使大颗粒数据更容易操作。第三点是使松散偶合交互容易编程。

对网络服务的初始炒作，大部分集中在简单的，同步的RPC式的网络服务，或者是通过HTTP的基本的请求/响应调用。但是，在不远的将来，网络服务将因其容量而在集成企业应用方面大显身手。网络服务需要与后台资源，如遗留应用，ERP软件包及数据库系统交互操作。网络服务为了满足网络业务处理的需要应该充分考虑到可靠，可用，可扩展。网络服务还必须在企业IT部门内，在时间紧，预算少，资源受限制的情况下开发出来。一句话，网络服务要求跨平台，基于标准，与公司的内外系统灵活集成，设计为可变化的。WebLogic工作间即提供了这样的工作平台，使得开发人员能够尽量有条理的完成所有这些任务。下面将具体描述。

人人须知

WebLogic Workshop IDE（集成开发环境）降低了开发人员进入Java和J2EE的门槛，提供了一个完整、可视化开发网络服务应用的环境。它包含了所有标准特性，如项目管理、代码填充、标记加亮、集成化调试等。这样，开发人员可以将时间和精力集中于业务逻辑，而不是访问组件所需的J2EE API细节、或调用EJB步骤、或获得JDBC资源。

Visual Basic开发人员、过程编程人员（从C或COBOL转过来)以及熟悉各种脚本描述语言的工程师们会发现，通过Workshop环境过渡到Java容易得让人不可思议。进一步，由于Workshop使企业应用如此简化，甚至J2EE专家也能受益，他们采用工具快速建立Java应用原型，然后采用vi、或emacs编辑器对底层功能进行微调。作为集成化工具，WebLogic Workshop最终可能将整个开发机构采用同一平台，对不同类型用户提供具有吸引力的支持。J2EE专家能够集中精力利用应用知识构建企业组件原型，使机构的所有开发人员能够容易地访问。

JWS文件

通过可视化开发环境，开发人员能够创建JWS文件,JWS文件可以看作网络服务的JSP。BEA技术推广总监Tyler Jewell将JWS文件描述为标准化的Javadoc标记集，用于标记属性、方法以及内部类。JWS文件在WebLogic Server的Web应用目录下，或在任何支持JWS的J2EE应用中。这个目录与JSP文件所在目录相同。 象JSP文件一样，JWS文件可以通过URL引用。当应用服务器最终接收到URL请求后，服务器将对JWS文件进行解析，并创建一个新的J2EE应用，可能包括servlet、EJB、JMS队列或JCA适配器。然后将这些文件打包成企业应用资源（Enterprise Application Resource，简称EAR）文件并作为新的Java应用部署到同一服务器上。新应用以网络服务方式提供给外部客户端访问。

Workshop运行架构

Workshop可视化开发环境提供了网络服务的图形化表示、代码编辑器、以及与运行架构接口功能。由于运行架构开放并且可扩充，其它IDE集成开发环境，如Jbuilder或TogetherSoft，能够与运行架构进行互动，并提供自己的结构管理网络服务和JWS文件。实际上，运行结构通过JWS注释提供了特殊的功能，支持企业网络服务设计支持。WebLogic Workshop产品经理Carl Sjogreen先生认为，WebLogic Workshop的功能与前面讨论的赢得开发人员的三大关键相吻合。

会话和消息缓冲（Conversations and Message Buffering）

在异步编程模式下，会话和消息缓冲是两个孪生概念。会话说明了操作的开始、进行中、和结束，使开发者能够保持交互状态贯穿长时间运行的处理过程或事务。消息缓冲将请求和应答放入可靠队列中，以保证最终得到处理。Workshop架构自动管理异步消息关联性和贯穿会话的消息状态管理。采用Workshop可视化开发环境，开发人员只需将方法标记为会话开始、继续、或结束，其余细节交给架构处理。会自动生成一个唯一的ID标识会话，网络服务中的任何状态由实体bean进行持久管理。 沿着同一技术路线，Workshop IDE能够设置属性，将消息进行缓冲，由架构自动导入JMS队列以保证消息得到适当的管理。

值得注意的是，如Adam Bosworth先生经常指出的那样，Workshop架构对JMS的支持不仅是一种透明管理异步机制，而且是一种能够保障企业级可靠消息通讯的传输协议。目前，SOAP还没有可靠分发协议。Workshop通过支持SOAP在JMS上可靠分发架构，克服了标准的缺陷。

XML映射

大粒度通讯，特别是松散偶合，均受益于Workshop产品的XML映射特性。

为了保证松散偶合，开发者需要能够不费力地将Java层面的对象内部表示翻译成最终通过网络传输的XML。在松散偶合交互方面，大多数开发人员不考虑对象的序列化和反序列化。Workshop XML映射编辑器能够支持开发人员独立于底层Java实现的方式编辑公共XML接口，从而获得松散偶合。这种对复杂XML文档强有力的支持，使开发人员能够快速、充满信心地建立应用和服务。

Workshop环境提供了简单、声明性XML映射，将内部Java代码和网络服务之间交换的XML消息相互关联。Workshop使开发者从Java签名建立XML非常容易。这样，当Java方法返回对象时，可以从它建立一个合适的公共协议。 相反，当XML消息进入时，代表了一个公共协议，开发人员可以从中抽取合适条目转换为方法的Java参数。进一步，如果映射不完整或有缺陷，Workshop运行时将产生一个编译错误，使开发人员不可能建立违反协议的系统（contract）。

对于复杂类型的映射，ECMA脚本代码可以包含在映射定义中。Workshop提供了扩充的ECMA脚本，采用XML扩展简化对XML时间的访问，能够支持复杂结构或数据转换。ECMA已进行了无记名投票采纳这些扩充。

最后，Workshop IDE定制的XML映射允许开发人员输入XML模版并建立网络服务以生成大粒度XML文档，如对各种业务或服务层协议合适的购买订单或发货单。

结论

大多数目前关于网络服务以及相关开发工具的讨论集中于简单的、同步RPC型实现。这些讨论脱离了实际互联网计算的时代标志－－企业应用集成。简单的网络服务既不能够充分满足应用需要、对于全面的企业运作的可靠性也不能令人信服。

简单网络服务缺少的是集成基础结构为开发人员提供机制创建应用展现的公共协议与底层实现的松散偶合。另外还缺少应用相互之间可靠的、协议清晰的异步交互的途径。最后缺少的是一个架构和设计工具，允许开发人员建立大粒度文档支持复杂的业务流程。WebLogic Workshop经历了很长的历程修补这些遗漏，为开发人员，无论是初学者还是专家，带来了一个极具创造性的集成网络应用开发工具。