消息视图中的CatalogItems Overview关系图显示Catalog消息。双击它可打开此视图。

　　图12. Catalog消息模型
 
　　在建模透视图中，将WS响应模板模式从Pattern Explorer Pallet托盘拖放到Catalog Message Model上。在建模视图中，可以使用Rational Software Architect右上侧的快捷视图按钮找到它。如果未在其中找到，请从Windows>Show View中找到Pattern Explorer。图13显示了进行了此操作后的消息模型关系图。

　　图13. 应用WS响应模板模式
 
　　WS响应模板模式接受四个参数：

　　·AnchorMessage参数：消息图的根消息。在我们的示例中，即Catalog消息。
　　·ServiceSpecification参数：将应用WS响应模板模式的服务规范。在我们的示例中，即Catalog Service。
　　·FilterParameter参数：通常，这是允许对子元素进行筛选的子组合消息的属性。在我们的示例中，即为将允许按sku对CatalogItems进行筛选的SKU属性。
　　·WSRTOperations参数：表示服务规范上要让WS响应模板识别的操作。在我们的示例中，使用的是getCatalog()操作。

　　图14显示了应用模式后模型的情况：

　　图14. WS响应模板模式应用到Catalog服务模型后的情况
 
　　应用此模型的结果是，会生成一个新的服务模型emx文件。图15显示了这个新生成的能够识别WS响应模板的服务模型的内部结构。

　　图15. 生成的Catalog服务模型
 
　　通过查看这个生成的服务模型，可以发现以下事实：

　　·消息视图中现在存在与请求和响应模板对应的独立请求和响应包。
　　·请求包中的消息图松散类型化。并不需要对其进行强类型化，因为它仅用于告知服务实现响应中所需的元素。
　　·响应包中的消息图强类型化，因为这引用从服务器返回的实际数据。

　　Catalog服务接口中的方法签名也已发生了更改。getCatalog()操作签名现在采用以下格式：getCatalog(primaryKey, requestTemplate):ResponseTemplate 。此方法返回强类型化的Catalog响应模板实例。此外，此方法现在接受两个请求参数：

　　·标识Catalog的主键。
　　·Catalog请求模板，此请求模板允许用户指定请求中需要哪个（已断开连接的）Catalog信息图子集。

　　可以从这个新服务模型生成能识别WS响应模板的WSDL和XSD。

　　·在服务视图中找到CatalogComponent。
　　·在鼠标右键上下文菜单中找到转换菜单项。使用UML到WSRT的转换。
　　·此转换的对话框将提示用户指定Web项目、生成WSDL和XSD以及WSDL的命名空间。使用http://catalog.retail.ibm.com/作为命名空间。

　　图16. UML to WSRT对话框
 
　　我们将使用WSDL to Java生成器来创建Catalog Web服务的Java实现：

　　·切换到J2EE透视图。
　　·右键单击生成的WSDL文件。必须启用Rational Software Architect Web Service功能。要启用此功能及其他功能，请转到Windows>Preferences>Workbench>Capabilities，并启用Web Service Developer和XML Developer。
　　·禁止对SOAPElement使用数据绑定。Windows>Preferences>Workbench>Web Services>Code Generation>IBM WebSphere runtime。请参见图17。
　　·在WSDL- Java生成对话框中，选中Test the Web Service和Monitor the Web Service。
　　·其余设置可以接受缺省值。
　　·注意：最好在此生成步骤前测试IBM WebSphere? 6.0服务器。

　　图17. 禁止对SOAPElement使用数据绑定

 
　　图18. WSDL to Java转换
 
　　最好在此时使用Web Service Explorer测试这个空实现。图19显示了对“Catalog B”的调用，此时客户机只关心Catalog的名称、说明和开始日期。

　　图19. 使用Web service explorer进行测试
 
　　在SOAP调用中，请求有两个参数：

　　·此例中Catalog的主键是Catalog“B”。
　　·请求模板指示，仅应该返回名称、说明和开始日期。

　　如果在WSDL to Java生成过程中选中了监视Web服务对应的框，SOAP调用请求应该出现在TCP/IP Tunneller中，带空白SOAP响应。

　　现在，让我们充实这个实现，以实际返回一些东西。在getCatalog()实现中，进行以下步骤：

　　·调用获取Catalog的遗留Catalog应用程序，通常其签名为getCatalog(key):Catalog。
　　·调用导航器。本文提供了一个不受支持的导航器参考实现（请参见下载部分），必须将其包含在已部署的应用程序中，以将Catalog请求模板和Catalog值对象（来自遗留Catalog应用程序）转换为Catalog响应对象。
　　·下面给出了这个服务器端实现的完整清单（为Catalog服务生成的框架接口和实现）。
　　·必须在开发期间和运行时提供wst.server（参考导航器代码）和遗留Catalog应用程序（实际获取Catalog的应用程序）。请参见下载部分。对于开发工作，请确保这两个项目都包含在构建路径中。对于运行时，必须首先将这些项目添加到父EAR文件，然后在Catalog服务WAR文件中作为独立JAR引用。

　　以下清单显示了为Catalog服务生成的框架接口和实现：
　　清单1. Catalog服务框架接口
               
　　/**
　　 * IWSRTTireCatalog.java
　　 *
　　 * This file was auto-generated from WSDL
　　 * by the IBM Web services WSDL2Java emitter.
　　 * o0505.16 v2605125559
　　 */

　　package com.ibm.retail.catalog;

　　import com.ibm.awsdc.wst.core.InvokerException;
　　import com.ibm.awsdc.wst.core.WriterException;

　　public interface IWSRTTireCatalog extends java.rmi.Remote {
　　    public javax.xml.soap.SOAPElement getCatalog　　(javax.xml.soap.SOAPElement key,
　　    javax.xml.soap.SOAPElement requestTemplate) throws 　　java.rmi.RemoteException,
　　    InvokerException, WriterException;
　　}
 
　　清单2. Catalog服务实现
                  
　　 * IWSRTCatalogSpecificationBindingImpl.java
　　 *
　　 * This file was auto-generated from WSDL by the
　　 * IBM Web services WSDL2Java
　　 * emitter. o0526.04 v62905175048
　　 */

　　package com.ibm.retail.catalog;

　　import javax.xml.rpc.ServiceException;
　　import javax.xml.rpc.server.ServiceLifecycle;
　　import javax.xml.rpc.server.ServletEndpointContext;

　　import com.ibm.awsdc.wst.core.InvokerException;
　　import com.ibm.awsdc.wst.core.Navigator;
　　import com.ibm.awsdc.wst.core.WriterException;

　　public class IWSRTCatalogSpecificationBindingImpl implements
   　　com.ibm.retail.catalog.IWSRTCatalogSpecification,ServiceLifecycle {
　　 private ServletEndpointContext context;

　　 public javax.xml.soap.SOAPElement getCatalog(
    javax.xml.soap.SOAPElement key,
    javax.xml.soap.SOAPElement requestTemplate)
    throws InvokerException, WriterException {
  Object catalog = null;
  String keystr = ((javax.xml.soap.Node) 　　key.getChildElements().next())
   .getValue();
　　  System.out.println(keystr);
  // Get a refer to the legacy catalog application
  com.ibm.retail.entity.catalog.LegacyCatalogApp 　　catalogImpl =
   new com.ibm.retail.entity.catalog.LegacyCatalogAppImpl　　　();
  catalog = catalogImpl.getCatalog(keystr);
  // Nagivate the catalog to return a response template
  return Navigator.navigate(requestTemplate, catalog, 　　context);
　　 }

 /*
  * (non-Javadoc)
  *
  * @see javax.xml.rpc.server.ServiceLifecycle#init(java.lang.Object)
  */
 public void init(Object arg0) throws ServiceException {
  context = (ServletEndpointContext) arg0;

 }

 /*
  * (non-Javadoc)
  *
  * @see javax.xml.rpc.server.ServiceLifecycle#destroy()
  */
 public void destroy() {
  // TODO Auto-generated method stub

 }
　　}
 
　　使用Web Service Explorer测试实现。图20显示了对“Catalog A”的调用，此时客户机只关心Catalog的名称、说明和开始日期。

　　图20. 使用Web service explorer进行测试
 
　　以下是对应的SOAP调用请求。此请求具有两个参数：

　　·此例中Catalog的主键是Catalog“A”。
　　·请求模板指示，仅应该返回名称、说明和开始日期。

　　如果在WSDL to Java生成过程中选中了监视Web服务对应的框，SOAP调用请求应该出现在TCP/IP Tunneller中，带空白SOAP响应。请参见图21。

　　图21. TCP/IP Tunneller
 
　　请参见下载部分，其中提供了最终的Rational Software Architect项目，打包为项目交换文件。要导入Rational Software Architect，请选择File>Import>Project Interchange。

　　我们实现的结果

　　图22显示了应用于Catalog服务模型时WS响应模板模式的序列关系图。

　　通过分析此序列关系图，可发现以下事实：
　　
　　·客户机将通过使用提供的可识别WS响应模板的WSDL调用服务。请求方将使用密钥和请求模板调用WS响应模板实现。
　　·密钥唯一地标识所需的值对象。
　　·请求模板告知服务实现响应中需要哪个（已断开连接的）信息图子集。
　　·服务实现查询使用密钥的提供程序，并获得与该密钥关联的对应值对象。
　　·现在将调用称为导航器的运行时组件（模式中提供了一个不受支持的实现）。导航器将获取作为输入的请求模板和值对象，并返回响应模板。
　　·响应模板中包含类型安全的值对象信息图子集，这些信息是用户在请求模板中请求的。响应模板返回给请求方。

　　图22. getCatalog()WS响应模板序列关系图
 
　　此时，通过将WS响应模板模式应用到Catalog服务，我们认识到大部分工作都涉及到了解问题、标识其范围并随后使其通用化，以便在将来再次应用。

　　我们还看到了最基本的更改是，方法签名从getCatalog(primaryKey):Catalog更改为了getCatalog(primaryKey, catalogRequestTemplate):CatalogResponseTemplate。

　　请求方现在对从服务器返回的响应中的数据具有细粒度的控制，就传递网上的信息量而言，服务调用现在的性能更好了。这与WS调用特别有关系，在WS调用中，由于契约在本质上是基于ASCII的，因此增加了交换的细节。

　　我们的解决方案利用所使用的工具的现有功能，大部分工作都是了解问题、标识其范围并随后使其通用化，以便在将来再次应用。

　　结束语

　　在本文中，我们应用了一个模式，以得到灵活的服务模型来帮助满足该服务的一些非功能需求。我们还从更广泛的意义上说明了模式通常如何满足非功能需求。最后，通过使用WS响应模板，我们得到了一个为客户机提供细粒度访问（最初是粗粒度接口）的服务，并同时保持了网络最优化，并通过允许在不影响客户机的情况下进行实体更改，从而在服务接口中提供了所需的灵活性。

　　作者简介

　　He Lei(Joyce)是位于中国北京的IBM Enterprise Integration Design Center的高级软件工程师。她于2003年取得北京航空航天大学的计算机科学硕士。自从加入IBM以来，He一直在从事Grid Computing Group of CSDL的China Grid项目方面的工作，并参与了若干EIS设计中心的客户项目。她目前在进行IBM SOA支持工具方面的工作。
 
　　Sun Ying Lin(Neo)是位于中国北京的IBM Enterprise Integration Design Center的一位软件工程师。他于2005年获得北京航空航天大学计算机科学硕士学位。从加入IBM以来，Sun先生一直在从事IBM SOA工具方面的工作。
 
　　Tian Chen(Simon)是位于中国北京的IBM Enterprise Integration Design Center的一位软件工程师。他于2004年获得北京航空航天大学计算机科学硕士学位。从加入IBM以来，Tian先生一直在从事IBM SOA工具方面的工作。
 
　　Eoin Lane博士是高级解决方案工程师，负责对主要IBM SOA工作的应用程序开发模式进行收集和制订，并通过IBM模式控制流程对这些模式进行处理，以促进其推广应用。Eoin也是用于帮助SOA开发的模型驱动的开发（Model Driven Development，MDD）、基于资产的开发和可重用资产规范（Reusable Asset Specification，RAS）方面的专家。