控件可以让开发人员专注于编写应用程序逻辑和委派基础性架构问题，如异步消息传送、会话和与远程资源的连接。但仍有很多复杂问题使这些应用程序难以管理。 在本文中，我们将使用内建的Weblogic Workshop控件开发一个基于Web services的示例应用程序，并用它来说明管理面向服务的应用程序的挑战。最后，我们将演示Confuluent Software公司如何给开发人员和IT人员提供可能的Web services管理解决方案，该方案与BEA WebLogic 8.1 Platform集成在一起。
为什么要面向服务？ 很少有应用程序还在独自运行。相反，大多数应用程序经常被集成到应用程序到应用程序互连的复杂“网络”中。这些应用程序网络通常是完全异构的、链接不同公司所开发的应用程序、运行在不同的平台上、以不同的语言实现，并且保护也各异。
更糟糕的是，利用现今紧密耦合的集成方法，每个应用程序都敏锐地知晓其他应用程序的特性。这样，一个应用程序的任何改变将会在整个网络中引起一系列的级联变化。出现天文数字的开发和维护费用也不足为奇。同时，管理层会怀疑IT仍否重要，并逐年削减IT预算——总有一天，这就是紧密耦合的代价。
面向服务的构架（SOA）提供了一个出路。面向服务的应用程序通过利用基于标准的Web services技术来连接异构环境。通过在应用程序间实现松散的耦合，它们消除了变化管理上的恶梦，也就是，改变一个应用程序的实现而不会中断其他应用程序。
WebLogic Workshop控件 BEA WebLogic Workshop通过为分布式组件的组装提供易用的工具，使得构建面向服务的应用程序变得很容易，并且方便了在组件间往来的XML消息的长久会话。
在WebLogic Workshop中，任何应用程序的核心构建块是控件。控件就好像简单的组件（具有方法和事件），通过属性可自定义该组件的行为。控件隐藏了J2EE底层问题，这些问题包括连接远程数据库、Web services、EJB对象和消息队列。有了控件，通过设置属性，而不是调用API，就可配置这些外部资源的连接。通过促进轻松组装松散耦合的应用程序组件，控件也为实现面向服务作出了贡献。
为了进一步增强松散耦合，WebLogicWorkshop 8.1也提供了可视化的编辑器（和XQuery支持），用来建立XML接口和底层对象间的映射。
让我们剖析一个简单的Web services应用程序，看一看WebLogic Workshop是如何消除创建类似应用程序的苦恼的。
订单管理应用程序示例 即使实现一个简单的业务场景，例如我们订单管理Web service示例，也会有大量的技术复杂难题：
Web service必须和给客户端用户使用的WSDL定义文件一起部署在上。
该服务依赖并使用多种后端组件，包括数据库、EJB和其他远程Web services。
该服务必须强制按照被调用操作的次序执行。
该服务必须允许多个客户端并发调用。
订单管理Web服务的示例显示了如下操作：
用户能够检查未决订单的状态：
queryOrderStatus(String inAccountNumber, String inOrderNumber)
用户可以创建一个新订单：
createOrder(String inAccountNumber, String inOrderNumber)
用户可以提交一个新创建的订单：
commitOrder(String inAccountNumber, String inOrderNumber)
首先创建订单，如果创建成功，则提交该订单。createOrder和commitOrder必须按顺序执行。对于每个方法的调用，服务将会从客户帐户中扣除一定费用。用户帐户作为EJB建模。订单在JDBC兼容的数据库中。对于每一个新创建的订单，commitOrder将通知远程（通过一个Web service调用）。
通过使用BEA WebLogic Workshop，并利用控件这一强大的概念，解决在创建像此类Web service的固有复杂性问题时是很容易的。图1显示了示例服务的设计视图及其所用控件。
图1：示例的设计视图 首先，在WebLogic Workshop中创建、部署和展示Web service的过程是很直接的。简单地创建一个Web service工程、添加所有的方法、编写逻辑并放置“Play”按钮。此外，WebLogic Workshop自动创建一组Web页面来测试和运行该Web service（参见清单1）。
清单 1
/**
* @common:operation
*/
public String queryOrderStatus(String inAccountNumber, String inOrderNumber)
然后对后端组件的访问，如EJB、数据库，或者甚至是远程Web services，则只是一个拖放动作（参见清单2）。一旦将使用的组件拖到项目中，它将作为一个对象出现在“代码视图”窗格中，并且可以很容易地集成到自定义代码中。
清单 2
/**
* Remote Web services
* @common:control
*/
private service.NotifyOrderServiceControl serviceNotify;
第三，确认在WebLogic Workshop中能够以给定顺序调用各种方法。从Web service所提供的每个操作能被标记为会话的一部分。这个标记也表明了操作涉及到会话中的哪个部分，这样强制必须调用这些操作中的订单（参见清单3）。
清单 3
/**
* Create a new order
* @common:operation
* @jws:conversation phase="start"
*/
public void createOrder(String inAccountNumber, String inOrderNumber)
最后，WebLogic Workshop会话能够为多个用户保持环境。会话标记指出要在会话期间保持环境信息（状态）。使用这种机制，订单管理服务能够同时处理多个客户端。
部署面向服务的应用程序也带来了新的挑战
不幸的是，世上没有免费的午餐。面向服务的应用程序大幅削减了开发和维护的费用，但代价就是管理复杂度的增加：
监视应用程序的健康状况，不仅仅是组件
单管理应用程序示例。当前的管理工具仅仅监视单个组件和组件的低级基础架构。基于这点，我们没办法验证一个分布式Web services应用程序是否工作正常。如果应用程序使用外部Web services（如合作伙伴的报价服务），那么只会激化这个问题。由于没有方法管理外部公司所运行的服务器，所以常规的监视方法完全没用了。因此在被愤怒的经理训斥前，您如何检测正在出现的问题？
不知道去哪里排除故障
一旦你开始每过几分钟就被不高兴的销售副主管所训斥，因为订单管理应用程序出错了（在季度结束前两天），您应该到哪里去查找罪魁祸首呢？是提供访问由制造IT部门所管理的存货系统的WebLogic Workshop控件吗？是这个应用程序所依赖的众多Web services之一吗？更糟的是，您怎么知道应用程序依赖哪个Web services和外部资源？随着训斥频率的增加，您仅有的资源都用来开始记录多个系统的众多日志上了。
记录审核和记帐的请求和响应 要求内部IT部门追踪软件应用程序的使用也在日渐增加，以便不同的业务部门支付其公平的IT投入份额。同样，任何跨越公司边界实现业务流程自动化的应用程序也必须拥有一个计划，用来解决发送者和接收者之间的拒付纠纷。在调用程序和被调用程序时的一致消息日志记录，是处理这些审核和记帐需求的关键。IT经理如何确保所有的开发人员在所有的入口点和退出点都实现正确级别的日志记录？对于使用XML加密进行加密的消息，您如何确保当消息被清除时没有记录（这会破坏公司的保密政策）？对于由打包应用程序本身所发布的Web services，如何完成消息日志记录？
确保始终如一地执行策略
即使在简化的示例应用程序中，一份文档也会在应用程序组件间传送多次。当调用createOrder操作时，客户端程序发送一个P.O；一旦该订单被提交，这个PO最终会被送到不同的Web service。为了确保端到端的保密性和完整性，开发人员可以使用WS-Security、XML加密和XML签名（BEA WebLogic 8.1支持WS-Security）。拥有这些能力是很好的，但是如果没有坚持使用，就没有购买意义了。安全构架师如何确保所有的企业间Web services在处理消息前都验证了消息的数字签名呢？
在开始将松散耦合的、分布式的应用程序向行业范围中部署时，这只是IT人员需要应对的某些新挑战。为了简洁，这里我们选择只关注几个关键问题。顺便还提及了很多其他问题——包括实现故障切换和处理传输层故障的重试规划、实现单点登录和服务版本控制。
评估用于管理SOA部署的新管理工具 现在，您应该确信成功部署Web服务最初需要处理一大堆棘手的管理问题。即使现今您的Web services仍然处于试验阶段，您也不应该推迟考虑管理方面的问题。好消息就是很多管理工具多已着眼于此。坏消息也是这样。很多新的Web services管理工具、应用服务器管理工具、系统管理工具、XML工具、管理器的管理工具等等，“Web services”这个单词似乎要揭露出它所有的数据表。
下面看一看为管理您所创建的、新的面向服务的应用程序找寻评估工具时要注意的几件事情。
它能非侵入地监视所有WebLogic控件和Web Services的调用吗？
在BEA WebLogic 8.1中，使用控件访问所有外部资源。这样监视延迟和所有控件调用的输入/输出的管理工具就能可视化地提供应用程序依赖的所有组件。该工具应该能“探察”任何Web services，而不管用于发布这些服务的平台是什么（J2EE应用服务器
【责编:admin】
--------------------next---------------------
