在部署阶段配置Web服务端点地址

在 IBM 产品中确定端点地址

IBM 的 WebSphere Application Server 和 WebSphere Studio 工具支持这种特性。例如，Application Developer 目前在确定被服务请求程序使用的服务提供程序的端点地址的选择范围内支持两个方向：

• 在开发阶段：WebSphere Studio 工具产生出许多被请求程序用来与提供程序进行交互的客户端构件。这些构件就硬编码一个默认的被请求程序使用的端点地址。
• 在运行阶段：在调用服务提供程序之前，请求程序使用某些机制去为特定的服务提供程序的实现来派生（derive）它们需要的端点地址，然后覆写（override）默认的端点地址。关键在于要动态地派生所需要的端点地址。有许多可行的机制可以达到这一点：UDDI、LDAP、本地配置文件和其他定制的机制。

模式概要

WebSphere Application Server 允许一个管理员来配置不同的资源提供程序，就像接下来我们将要详细阐述的那样。特别地，应用程序服务器支持对 URL 提供程序的配置，这些 URL 提供程序是为应用程序提供 URL 地址用的。使用 URL 是识别 WEB 服务端点地址的一种理想方式。资源可以从一个使用 Java Naming and Directory Interface (JNDI) 的 Java ^TMExtended Edition (J2EE) 应用程序中被引用，并且应用程序管理工具允许开发者将 JNDI 引用映射到由 URL 提供程序生成的 URL 。

更进一步，由 WebSphere Studio 工具（如 Application Developer）生成的客户端 WEB 服务构件支持覆写默认端点地址的方法。这种组合允许你在单元测试时期使用开发阶段服务提供程序开发服务请求程序，然后在集成测试阶段使用不同的服务提供程序。最后，已完成的服务请求程序可以在开发中被配置用来使用产品服务提供程序。经过在开发阶段的一些启动后，你可以使用 Application Server 管理工具对其进行必要的改变。在接下来的部分中阐述了如何定义 URL 资源和资源引用的方法，还有在访问 WEB 服务时如何使用 URL 资源引用获得所使用的 URL 。

使用 WebSphere Application Server 配置提供程序

你可以为许多不同的资源使用 Application Server （在 5.1 版本中有所描述）来配置提供程序。在众多的资源提供程序中有一个是 URL 提供程序。 URL 提供程序实现了一些功能，这些功能通过一个特定的协议使得应用程序可以与网络连接资源进行通信。既然我们需要一个为 WEB 服务端点地址提供 URL 的一种机制，URL 提供程序看起来很自然的符合我们的需求。

WebSphere 提供三种不同的 J2EE 容器：Web 容器、EJB 容器和应用程序客户端容器。由用户来管理 Web 及 EJB 容器，相关资源由 Application Server 管理控制台来管理。可以通过应用程序客户端资源配置工具（Application Client Resource Configuration Tool）来管理客户端应用程序容器和资源。在下面的部分当中将讲解这两种管理机制。

使用管理控制台

图１显示了 Application Server 管理控制台的一部分。您可以看到控制台左侧的主菜单，菜单上的资源项可以扩展来显示资源提供程序。在靠近列表底部的地方是 URL 提供程序项。

在图 1 的右侧显示了 URL 提供程序版面，列出了唯一一个被称为 Default URL Provider的 URL 提供程序，他被包含在了初始 Application Server 配置里面。这个默认 URL 提供程序使用随 Application Server 一起安装的 IBM JDK 提供的 URL 支持。并且这个默认 URL 提供程序可以处理任何的基于 J2EE 协议的 URL 资源，例如：HTTP、FTP或File协议。虽然也可以配置定制的 URL 提供程序去实现其他协议，但那超出了我们所讨论的范围。

按照下列方式使用管理控制台配置提供程序：

1. 点击 Default URL Provider可以查看默认 URL 提供程序的属性，如图 2 所示（红线表示有些区域被省略了）。
2. 点击 Additional Properties 表格中的 URLs 查看在默认 URL 提供程序中定义的 URL 。
   
   图 2：Application Server 管理页，显示 Default URL Provider 属性
   
   
   
   除非您已经为默认 URL 提供程序定义了 URL ，否则您只能看到一个空的列表，如图 3 所示。
3. 点击 New 添加一个 URL。
   
   图 3：Application Server 管理页，显示 Default URL Provider 属性
   
   
   
   如图 4，您将看到一个对话框，在其中您可以填写有关 URL 的信息。在对话框中必须填写的区域已经用红色的星号标示出来了( *)。
   
   图 4：Application Server 管理页，显示 Default URL Provider 属性
   
   
   
   
4. 填写为管理引用所用的 URL 名字，为引用 URL 所用的 JNDI 名字。IBM 红皮书 IBM WebSphere Application Server V5.1 System Management and Configuration推荐 JNDI 名字由 url/的开头。
5. 在 Specification字段内，输入一个合法的 URL ，这个 URL 在 URL 提供程序被引用时被创建。
6. Scope属性也是一个必填项，但已被自动填写上。
7. 最后，您可以填写可选的描述和类别项。
8. 点击 Apply保存配置，然后重新启动 Application Server 使更改生效。

注意：您也可以在 WebSphere Studio 工具单元的测试环境服务器中启动管理控制台。这么做是允许开发人员在开发时可以为 Web 服务定义 URL 。

使用 Application Client Resource Configuration Tool

您可以使用 Application Client Resource Configuration Tool (ACRCT) 来管理和 J2EE 客户端应用程序相关的资源。ACRCT 是随 Application Server 一起安装的由 clientConfig批处理文件或脚本启动的程序。当您编辑客户端应用程序的 EAR 文件时，您会发现 WebSphere J2EE 客户端应用程序运行时环境将不像在 Application Server 中那样提供一个默认 URL 提供程序。因此，您首先要做的事情就是要创建一个和在 Application Server 环境中提供默认 URL 提供程序的等价环境。

图 5 显示了在标准客户端应用程序环境中的资源提供程序。注意，这里没有 URL 提供程序。

按如下方法添加一个默认 URL 提供程序：

1. 右键点击 URL Providers然后从弹出的菜单上选择 New 。如图 6 所示将显示出 URL 提供程序属性对话框。
   
   图 6. ACRCT 版面，添加默认 URL 提供程序
   
   
   
   
2. 在 Name字段内填入名字。
3. 如果想使用其它容器内的默认值，那么就保留其它字段为空，然后点击 OK。
4. 展开 URL Providers 可以查看刚刚创建的 AC Default URL Provider.
5. 展开 AC Default URL Provider。您将看到提供程序的一个空 URL 文件夹。
6. 右键点击 URL 文件夹并选择 New 。URL 属性对话框将显示在下面。
   
   图 7. ACRCT 版面，向 URL 提供程序中添加 URL 。
   
   
   
   就像在应用程序服务器管理控制台中一样，这里也有三个必填字段。但在客户端应用程序中有一个很重要的限制，那就是 name字段内的内容与 JNDI Name字段内的内容必须是相同的。
7. 在填写完各字段内容之后，点击 OK 保存 URL 定义。ACRCT 将显示如图 8 所示。
   
   图 8. ACRCT 版面，显示完整的资源提供程序配置
   
   
   
   
8. 添加 URL 提供程序和 URL ，然后保存客户端配置。

目前，WebSphere Studio 工具并没有为 ACRCT 提供一个能与其等价的功能。然而，您可以从被 ACRCT 修改的客户端应用程序的 EAR 文件中提取适当的文件，并将其用于 WebSphere Studio 工具中。在接下来的部分将讲解如何去做。

配置 J2EE 应用程序资源引用

J2EE 应用程序在部署描述符中可以定义对资源的引用。Application Developer 部署描述符编辑器使得创建资源引用变得很简单。各个容器类型之间有着轻微区别的部署描述符，在接下来的内容当中将讲解各相应的编辑器。

Web 应用程序

对于 Web 应用程序部署描述符来说，完成如下几步：

1. 双击 J2EE Hierarchy 透视图中的 Web 模块，或者是从其它透视图中打开 web.xml 。编辑器将如图 9 所示。
   
   图 9. Web Application 部署描述符编辑器，显示资源引用
   
   
   
   
2. 点击编辑器窗口下方的 References 标签，然后点击编辑器窗口上方的 References 标签。您将看到资源引用的一个列表，这个列表可能会是空的。
3. 要添加对某一 URL 的引用，那么点击 Add添加如我们上文所讲述的引用。由于这个引用的名字将会被用在应用程序里，所以建议您用一个有意思的名字来代替这个默认的名字（在样例中用到了 wsURL，但是重用 JNDI 名也是可行的并且对应用程序客户端来说是更兼容的，正如下所述）。
4. 在 Type字段内，点击 Browse。然后在弹出的窗口内输入 url，点击 OK指定选择 java.net.URL。
5. 在 JNDI Name字段内输入名字，这个名字和在我们前文中在创建默认 URL 提供程序时在 JNDI Name字段内输入的名字相同。在本例中为 url/MyURL。
6. 保存对部署描述符的任何更改，然后重新启动应用程序。

如果您愿意通过直接编辑 web.xml来建立资源引用的话，下面显示了引用所遵循的格式。

在文件 web.xml 中：

<resource-ref id="ResourceRef_1078719620465">

<res-ref-name>wsURL</res-ref-name>

<res-type>java.net.URL</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

您还应该像下面所示的那样，在 IBM 扩展文件 ibm-web-bnd.xmi中添加资源引用与 JNDI 名之间的连接。您也可以以同样的方式从一个 EJB 模块中引用 URL 引用。最重要的区别是必须为使用引用的每个 EJB 添加引用。

在文件 ibm-web-bnd.xmi 中：

<resRefBindings xmi:id="ResourceRefBinding_1078719620465" jndiName="url/MyURL">

<bindingResourceRef href="WEB-INF/web.xml#ResourceRef_1078719620465"/>

</resRefBindings>

应用程序客户端容器

对于应用程序客户端来说，可以按照如下方法去做：

1. 双击 J2EE Hierarchy 透视图中的应用程序客户端模块名字来启动部署描述符编辑器，或者是从其它透视图中打开 application-client.xml 。编辑器将显示如图 10 所示。
   
   图 10. WSAD - 应用程序客户端资源引用配置
   
   
   
   
2. 点击编辑器窗口下方的 References 标签，您将看到资源引用的一个列表，这个列表可能会是空的。
3. 点击 Add添加一个对 URL 的引用。
4. 把默认的 Name内容改为 JNDI 名所使用的您已经用 ACRCT 定义过的 URL（ url/MyURL）。
5. 在 Type字段内，点击 Browse。在弹出的窗口中输入 url，然后点击 OK指定选择 java.net.URL。
6. 在引用的 JNDI Name字段内，输入与在使用 ACRCT 创建默认 URL 时在 JNDI Name字段内输入的名字相同的名字。
7. 保存所有修改。

现在，客户端应用程序可以使用 url/MyURL名字从默认 URL 提供程序中接收 URL 了，因为已经为这个 URL 建立起了在那个名字和 JNDI 名之间的一个连接。

如果您愿意通过直接编辑 application-client.xml来建立资源引用的话，下面显示了引用所遵循的格式。

在文件 application-client.xml 中：

<resource-ref id="ResourceRef_1079384497740">

<description/>

<res-ref-name>url/MyURL</res-ref-name>

<res-type>java.net.URL</res-type>

<res-auth<Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

您还应该像下面所示的那样，在 IBM 扩展文件 ibm-application-client-bnd.xmi中添加资源引用与 JNDI 名之间的连接。

在文件 ibm-web-bnd.xmi 中：

<resourceRefs xmi:id="ResourceRefBinding_1079384497740" jndiName="url/MyURL">

<bindingResourceRef href="META-INF/application-client.xml#ResourceRef_1079384497740"/>

</resourceRefs>

目前，WebSphere Studio 工具并没有为 ACRCT 提供一个能与其等价的功能。然而，您可以通过以下的过程使用 WebSphere Studio 工具去对应用程序客户端进行调试：

1. 创建一个应用程序客户端工程和其相关的 EAR 文件；您也可以执行 Web 服务的存取码来实现，我们将在下面讲解。
2. 按照上面的讲解，添加资源引用。
3. 导出应用程序客户端 EAR 文件。
4. 按照上面的讲解，使用 ACRCT 向应用程序客户端 EAR 添加默认 URL 提供程序和资源的定义.
5. 如果有可能，运行应用程序客户端来确保初始化操作的正确。
6. 检查已经修改过的应用程序客户端 EAR 文件，将文件 client-resource.xml拷贝到在文件夹 META-INF下的应用程序客户端工程中。

WebSphere Studio 工具 Web 服务构件

使用 WebSphere Studio 工具创建服务请求程序时，通常要先创建一套合适的 JAX-RPC 构件，为的是使服务请求程序与服务提供程序在交互上能变得简单些。通常，这意味着要以提供程序的 WSDL 描述符为开始，并使用 Web 服务向导来产生这些构件。这里，很重要的构件是 工厂和 存根。请求程序使用工厂的一个实例去生成存根的一个实例，然后存根再与提供程序交互。

例如，假设向导以 WSDL 描述一个简单的只返回一个字符串的 Web 服务开始。那么它将有一个服务端点接口，如下所示：

public interface Echo extends java.rmi.Remote {

public java.lang.String echo(java.lang.String s) 

throws java.rmi.RemoteException;

}

向导创建了一个工厂接口类和一个工厂实现类，分别叫做 EchoService、 EchoServiceLocator。向导还创建了一个存根类（假设 WSDL 包括 SOAP/HTTP 的绑定） EchoSoapBindingStub，这个类实现了在上文中定义的 echo 接口。工厂从初始的 WSDL 文件实现 Web 服务提供程序端点地址的硬编码作为默认端点地址。请求程序方面在缺少任何其它动作时，存根就将默认值用作端点地址。下面的代码片断显示了一个简单的在 J2EE 容器环境中使用这些构件去引用那个 echo Web 服务的例子。注意，在一些 WebSphere Studio 工具的版本中，Web 服务向导也为便利性创建一个叫做 代理的构件，这个构件实现一些查找和端点复杂设置的工作。

javax.naming.InitialContext ic = null;

EchoService factory = null;

Echo stub = null;

try { // get the factory

ic = new javax.naming.InitialContext();

factory = 

(EchoService) ic.lookup("java:comp/env/service/EchoService");

} catch (NamingException e) {

}

try { // get the stub

stub = factory.getEcho();

} catch (ServiceException e) {

}

try { // invoke the service

String result = stub.echo("My message");

} catch (RemoteException e) {

}

您想把默认端点地址变成什么呢？ JAX-RPC 规范为存根定义了一个基本接口，这个接口支持一个允许请求程序在调用服务前更改端点地址的方法。下面的代码片断细化了前面的代码片断，并且用另外一个硬编码的端点覆写了默认端点。

Echo stub = null;

String realEndpoint = "http://serverX/Services/Echo">; 

try { // get the stub

stub = factory.getEcho();

((javax.xml.rpc.Stub)stub)._setProperty(

"javax.xml.rpc.service.endpoint.address", realEndpoint);

} catch (ServiceException e) {

}

由向导生成的工厂实现提供了一个简化操作，就是允许覆写基本的工厂方法，因此当存根被创建时 URL 就可以被传递到工厂。工厂使用传递到方法的端点地址返回一个存根。下面的代码片断展示了这项技术：

EchoService factory = null;

Echo stub = null;

String realEndpoint = "http://serverX/Services/Echo"; 

try { // get the stub

java.net.URL endpointURL = new java.net.URL(realEndpoint);

stub = factory.getEcho(endpointURL);

} catch (ServiceException e) {

}

虽然两种技术都不可能在已展示的方式中使用，但两者都说明了从缺省硬编码到工厂端点地址的修改原理。

模式的最后一部分内容就是从 URL 提供程序中取得实际的端点地址。下面的代码片断显示了取得的方法。注意，JNDI 查找使用了在应用程序部署描述符中定义的资源引用名。对于 Web 和 EJB 应用程序来说虽然它们可以和 JNDI 名相同，但是那是没有必要的；然而，对于 J2EE 应用程序客户端来说，它必须是 JNDI 名。在本例中为 url/MyURL，这是对先前应用程序客户端配置的一个校正；对先前 Web 应用程序的配置来说，这个值应该是 wsURL 。

try {

javax.naming.InitialContext ic = 

new javax.naming.InitialContext();

java.net.URL url = (java.net.URL) 

ic.lookup("java:comp/env/url/MyURL");

} catch (NamingException ex) {

}

最后，综合以上的技术，您可以找到端点地址并使用它取得使用恰当端点地址的存根而不是使用默认端点地址的存根，正如下所示：

javax.naming.InitialContext ic = null;

EchoService factory = null;

Echo stub = null;

java.net.URL realEndpoint = null;

try { // get the factory and endpoint address

ic = new javax.naming.InitialContext();

factory = 

(EchoService) ic.lookup("java:comp/env/service/EchoService");

realEndpoint = 

(java.net.URL)ic.lookup("java:comp/env/url/MyURL");

} catch (NamingException e) {

}

try { // get the stub

stub = factory.getEcho(realEndpoint);

} catch (ServiceException e) {

}

try { // invoke the service

String result = stub.echo("My message");

} catch (RemoteException e) {

}

您也可以使用可配置的端点地址，即使存根是使用默认端点地址创建的，如下所示。这对使用相同的存根实例直接请求不同的端点来说可能有用。

javax.naming.InitialContext ic = null;

EchoService factory = null;

Echo stub = null;

java.net.URL realEndpoint = null;

try { // get the factory 

ic = new javax.naming.InitialContext();

factory = 

(EchoService) ic.lookup("java:comp/env/service/EchoService");

} catch (NamingException e) {

}

try { // get the stub

stub = factory.getEcho();

} catch (ServiceException e) {

}

try { // invoke the service with real endpoint

realEndpoint =

(java.net.URL)ic.lookup("java:comp/env/url/MyURL");

((javax.xml.rpc.Stub)stub)._setProperty(

"javax.xml.rpc.service.endpoint.address", 

realEndpoint.toString());

String result = stub.echo("My message">);

} catch (Exception e) {

}

结束语

本文讲解了一个允许您使用 Web 服务提供程序创建应用程序的设计模式，该提供程序的端点地址可以使用 Application Server 管理控制台配置。这个模式简单、避免使用者配置方案还有良好的性能。该模式支持在部署阶段配置端点地址。只有一点需要注意，那就是既然可以通过管理控制台改变端点地址，那么只有在应用程序重新启动后或是应用程序所在的 Application Server 实例（对 Web 和 EJB 应用程序来说）重新启动后它才能响应变化。

（责任编辑：城尘）