Web Services 以其开放、标准接口、独立于平台和语言等特点受到广大开发者的青睐，Web
Services 的成功应用离不开相关的 Web Services 安全机制。WebSphere Application
Server（以下称为 WAS） V6.1 支持基于 JAX-RPC 的 Web Services
并提供了相应的安全策略 WS-Security，支持开发环境下针对 Web Services 的安全配置。WAS
V6.1 Feature Pack for Web Services 支持基于 JAX-WS 2.0
的 Web Serivces 并兼容基于 JAX-RPC 的 Web Serivces，在 WAS
V6.1 的基础上扩展了对 Web Services 安全策略的支持，提出策略集(PolicySet)的概念，使得用户除了在开发环境下配置
Web Services 的安全策略外，也可在管理控制台上配置安全策略集。WAS V7.0 支持并改进了
WAS V6.1 Feature Pack for Web Services 提供的所有功能，并增加了对更多的安全策略的支持，大大提高了产品的易用性。
本文着重描述 WAS V7.0 环境下如何分别通过管理控制台和开发工具 Rational Application
Developer（以下简称为 RAD） V7.5 为基于 JAX-WS 2.0 的 Web Services
和 Web Services Client 配置安全策略集。
在 Service Oriented Architecture (SOA)理念开始深入人心的时候，Web
Services 作为实现 SOA 的首选技术备受业界关注。随着 Java EE 5 的出现，Web Services
编程模型、标准和规范也不断推新。基于注释的新编程模型 JAX-WS 2.0（Java API for XML
Web Services）简化了 Web Services 应用的开发，其数据模型 JAX-B 2.0（Java
Architecture for XML binding）所提供的 XML 和 Java 数据的绑定规则使得
XML 到 Java 对象的转换更加简洁易用。此外，MTOM、SAAJ 1.3、StAX 1.0、SOAP
1.2 等标准和规范，有效地扩展了 Web Services 的功能和易用性。
然而，离开安全机制，Web Services 便无法成功应用于生产环境。通常，可以由以下两种机制确保
Web Services 环境的安全：
HTTP 是最常用的 SOAP 消息传送机制，而 SSL(HTTPS)可以保证 HTTP 消息（包含SOAP消息）在传输层的安全性，进而保证
SOAP 消息的安全性，包括：认证机制、机密性和完整性。但是 SSL 有以下几点局限性：
- 只适用于 HTTP，不适用于 JMS,SMTP 等其他消息传送机制；
- 只提供点对点(Point-to-Point)的安全性；
- 只能对整个消息进行加密，不能针对消息的某一部分进行加密。
2002 年，IBM 与 Microsoft 联合发布了 WS-Security v1.0 的草案，后来这一草案被OASIS[1]
看好，并进一步修改，2004 年发布为正式的 WS-Security 规范。WS-Security 通过认证(Authentication)、加密(Encryption)和数字签名(Digital
Signature)等方式保证了 Web Services 在消息级别的认证机制、机密性和完整性。并且，跟
SSL 相比，WS-Security 具有以下优势：
- 提供端到端(End-to-End)的安全性。
- 独立于传输方式，可用于 HTTP, JMS, SMTP, FTP 等。
此后，出现了很多其他的 Web Services 安全规范，包括：WS-Addressing、WS-Reliable
Messaging、WS-SecureConversation、WS-Privacy、WS-Policy、WS-Trust、WS-Federation、WS-Authorization
等，它们分别从不同的角度和范围来保证 Web Services 的安全性。
WAS 从版本 6.0 开始支持基于 JAX-RPC 的 Web Services 及 WS-Security
这一安全规范。下面我们将分别简要介绍 WAS V6.1、WAS V6.1 Feature Pack for
Web Service、WAS V7 中对 Web Service 安全性的支持程度。
WAS V6.1 对 Web Services 安全的支持
WAS V6.1 支持 WS-Security，并对其进行了扩展。
- 除了使用 Username Token 和 X509 Certificate Token，用户还可以使用定制的安全
token，比如：LTPA token。
- 允许在签名和加密中加入时间辍标记。
- 支持证书缓存，进而提高效率。
Web Services 开发人员可以在开发环境下配置 WS-Security，来提供消息认证机制、完整性和机密性。
- 通过 webservices.xml 修改 web services 以下两个文件：
ibm-webservices-ext.xmi
ibm-webservices-bnd.xmi |
- 通过 web.xml 修改 web services client 以下两个文件：
ibm-webservicesclient-ext.xmi
ibm-webservicesclient-bnd.xmi |
注意：Web Service 与其 Web Service Client的 WS-Security 配置必须对应一致，比如：Web
Service Client 以 Username Token 作为 token 类型做认证，Web Service
端设置的 token 类型也必须是 Username Token。想了解详细步骤，请阅读参考资源中的相关链接。
应用部署到 WAS V6.1 后，WAS V6.1 内嵌的 Security Handler 会支持和实现应用中设置的WS-Security
安全机制。
WAS V6.1 Feature Pack for Web
Services 对 Web Services 安全的支持
WAS V6.1 Feature Pack for Web Services(以下简称 Web Services
Feature Pack)是可选安装的，它扩展了 WAS V6.1 的功能，支持 Java EE 5，提供了一些新特性，主要表现在异步性(Asynchronously)、可靠性(Reliably)、安全性(Securely)及与其他软件产品的交互性(Interoperably)。
Web Services Feature Pack 支持基于 JAX-WS 2.0 的 Web Services，以及
WS-Security 和一系列扩展安全策略：WS-SecureConversation, WS-ReliableMessaging,
WS-Addressing, WS-Transaction 等。
Web Services Feature Pack 中提出了一个新的概念——策略集(Policy Set)，即一组策略的集合。用户为应用程序选择和关联不同的策略集，即选择了不同的服务质量(Quality
of Service, Qos)。例如：Username WSSecurity default 策略集，就是由
WS-Addressing 和 WS-Security 两个策略组成。
策略集可重用，为将来构建新的、更复杂的策略集提供了基础。值得一提的是，应用程序跟策略集是分离的，因此可以根据需要灵活地为某个应用程序选择不同的策略集而无需改动应用程序的代码。开发人员也只需专注于开发业务逻辑本身，而无需考虑安全部分的实现；部署和管理人员通过管理控制台或
wsadmin 脚本来设置安全策略。当然，RAD V7.5 等 J2EE 开发工具也支持为 Web Services
应用配置安全策略。
WAS V7.0 对 Web Services 安全的支持
WAS V7.0 支持并改进了 Web Services Feature Pack 提供的所有功能，并增加了对更多的安全策略的支持，大大提高了产品的易用性。接下来的章节中，我们将着重向您描述如何通过
WAS V7.0 管理控制台和开发工具 RAD V7.5 为基于 JAX-WS 2.0 的 Web Services
和 Web Service Clients 配置安全策略集。
WAS V7.0 和 Web Services Feature Pack 支持从管理控制台上设置安全策略。通过服务->策略集->应用程序策略集，我们可以看到
WAS V7.0 缺省定义了一组应用程序策略集，每个应用程序策略集由一个或多个策略组成。您可以使用这些已有的应用程序策略集及其缺省绑定，也可以创建自定义的策略集及自定义的绑定。用户可以将服务、服务端点或服务操作连接到某个策略集，然后选择使用缺省绑定，或设置自定义的绑定。
WAS V7.0 强调了 Web Services 应用与其安全策略的分离。开发人员只需关心业务逻辑，无需了解安全相关的细节或者写任何跟安全相关的代码。管理员可以在应用部署之后，根据需要在管理控制台或以
Jython 或者 Jacl 脚本的方式为服务、端点或操作配置适当的策略集。当该应用的安全需求发生变化时，同样无需改动应用程序的代码，只需重新配置策略集即可。
注意：策略集只适用于基于 JAX-WS 2.0 的 Web Service 及其 Client
应用。
本节将介绍如何通过 WAS V7.0 管理控制台配置 Web Services 安全策略。
示例介绍
WAS V7.0 自带了一个基于 JAX-WS 2.0 的样本应用，在 <WAS_HOME>/samples/lib/JaxWSServiceSamples
目录下可以找到它的应用包：JaxWSServicesSamples.ear。您可以通过以下方式安装和使用它（假如在Windows平台上）：
1. 安装 JAX-WS 2.0 样本应用 JaxWSServicesSamples。
打开 cmd 命令行，在 <WAS-HOME>/samples/bin 下，执行 install.bat
–samples JaxWSServicesSamples；
这样，JaxWSServicesSamples 被安装到缺省的 server1 上，重启 server1
使之生效。
2. 为 EchoService 服务提供者连接策略集及绑定。
WAS V7.0 定义了若干个缺省的应用程序策略集，这里我们以 Username WSSecurity
default 为例，将 JaxWSServicesSamples 提供的 EchoService 及其
Client 连接到该策略集上来。
登录管理控制台，服务->服务提供者-> EchoService；
全选服务、端点和操作，点击”连接策略集”，选择”Username WSSecurity default”；
选中下图 1 中的三个复选框，点击“指定绑定”，选择“Provider sample”，保存。
图 1：EchoService
提供者连接的策略集及绑定
3. 为 EchoService 服务客户机连接策略集及绑定。
从管理控制台，服务->服务客户机->EchoService；
全部选中 EchoService/EchoServicePort/echoOperation，点击“连接策略集”，选择
Username WSSecurity default；
全选中下图 2 中的复选框，点击“指定绑定”，选择“Client sample”，保存。
图 2：EchoService
客户机连接的策略集及绑定
4. 为服务客户机设置 Username Token 认证令牌。
从管理控制台，服务->策略集->常规客户机策略集绑定->Client sample->WS-Security->认证和保护；
点击“认证令牌”下的 gen_signunametoken（见图3），再点击“回调处理程序”，输入基本认证信息，即
WAS 启用安全性时所使用的用户名和密码（见图 4），保存。
图 3：客户机的
Username Token 认证令牌
图
4：客户机所使用的 Username Token 信息
5. 验证结果，步骤如下。
重启 server1，使之前的所有设置生效；
在浏览器中打开http://<hostname>:<port>/wssamplesei/demo；
选择“Synchronous Echo”作为 Message Type，随意输入一串 Message
String，然后点击“Send Message”；
从下图 5 可以看出，消息发送成功，并得到一个响应。同时，在 server1 的 SystemOut.log里可以看到如清单
1 所示的日志记录。
图 5：EchoService 应用 UsernameToken WSSecurity default
策略集后的运行结果
清单
1. SystemOut.log 日志记录
[08-9-9 10:52:59:758 CST] 0000001b SystemOut O >> SERVLET: Request count = 1
[08-9-9 10:52:59:768 CST] 0000001b SystemOut O >> SERVLET: Request index: 1
[08-9-9 10:52:59:898 CST] 0000001b WSSecurityBin W CWWSS7053W:
找不到任何 Web Service 安全性定制绑定。将使用缺省绑定。
[08-9-9 10:52:59:948 CST] 0000001b WSSecurityBin W CWWSS7053W:
找不到任何 Web Service 安全性定制绑定。将使用缺省绑定。
[08-9-9 10:52:59:968 CST] 0000001b WSSecurityBin W CWWSS7053W:
找不到任何 Web Service 安全性定制绑定。将使用缺省绑定。
[08-9-9 10:53:00:008 CST] 0000001b SystemOut O >> CLIENT: SEI Echo to http://localhos
t:9090/WSSampleSei/EchoService
[08-9-9 10:53:00:308 CST] 00000015 SystemOut O >> SERVICE: SEI Echo JAX-WS Service: R
equest received.
[08-9-9 10:53:00:308 CST] 00000015 SystemOut O >> SERVICE: SEI Echo Input String 'tes
t EchoService with UsernameToken WSSecurity default'
[08-9-9 10:53:00:388 CST] 0000001b SystemOut O >> CLIENT: SEI Echo invocation complet
e.
[08-9-9 10:53:00:388 CST] 0000001b SystemOut O >> CLIENT: SEI Echo response is: JAX-WS
==>>test EchoService with UsernameToken WSSecurity default |
在上面的例子里，EchoService 使用了 WAS V7.0 提供的缺省策略集 UsernameToke
WSSecurity default，并使用 WAS V7.0提供的缺省策略集绑定 Provider sample
和 Client sample。
应用程序策略集的选择
WebSphere 环境中，策略集的设置是 Cell 级别的，但是绑定信息是应用级别的。选择应用程序策略集时，有以下几种方式：
- WAS V7.0 定义了若干个缺省的策略集，可供用户使用。
- 用户拷贝某个缺省策略集，并修改之，使之成为可用的新策略集。
- 用户完全自定义一个策略集。
从管理控制台，服务->策略集->应用程序策略集（见图 6），您可以查看、新建、删除、复制、导入或导出策略集。这里有
9 个缺省的策略集，它们是只读的，用户无法修改这些缺省的策略集。上节的例子中使用的就是缺省策略集 UsernameToke
WSSecurity default。
图 6：应用程序策略集
若要修改某缺省策略集（比如 Username WSSecurity default），可以先复制该策略集，生成一个新的可编辑的策略集进行修改。具体方法如下：
1. 点击复制，为新复制的策略集定义一个新名称（比如：my Username WSSecurity default），保存，得到一个可编辑的策略集（见图
7），用户可以对该策略集进行修改。
图 7：用户自定义的策略集
2. 点击该策略集，可以看到一组策略列表，用户可以在这里添加、删除、启用或禁用某策略（见图8）。
图 8：自定义策略集my Username WSSecurity default的策略列表
3. 点击 WS-Security，可修改该策略设置，包括主要策略和引导策略的设置。主要策略指定如何将消息安全策略应用于请求并对响应执行这些策略。要配置如何建立安全对话，请使用“引导策略”链接。要配置引导策略，要先确保主策略使用的是对称签名和加密策略以及安全对话令牌(security
token)，而不是非对称签名、加密和令牌。
4. 点击主要策略，可以看到消息级保护包含令牌、签名、加密、时间辍等的设置（见图 9）。
图 9：WS-Security的主要策略
缺省情况下，签名和加密都使用非对称令牌 X.509。
- 借助非对称令牌，发起方可用自己的私钥对消息进行签名，接收方用发起方的公钥对签名进行验证。
- 借助非对称令牌，发起方可用接收方的公钥对消息进行加密，而接收方将使用自己的私钥解密。
消息部件保护定义了请求和响应消息中需要保护的部分，请求令牌策略和响应令牌策略指定了认证所使用的令牌类型。其中，消息部件保护利用
Xpath 表达式、QName 等方式指定了需要加密（见图 10）或签名（见图11）的消息部件。通常来说，可加密的部件包括：主体、安全令牌、数字签名等；可签名的部件包括：主体、时间辍，安全令牌、签名和加密所使用的密钥、addressing
等。用户可以根据的自己的应用需求修改消息部件保护设置，比如：只对 SOAP 主体进行加密；或不需要加密，只使用签名；或不需要签名，只使用加密等等。这里作为示例，我们将要签名消息部件的前两个
addressing 元素除去。
图 10：要加密的消息部件
图 11：要签名的消息部件
除了用户名和 X.509 两种基本令牌类型，WAS 还支持 LTPA 和定制的令牌类型。图 12
中，请求消息使用缺省的用户命令牌 token_auth。
图 12：WAS 支持的令牌类型
为服务提供者和服务客户机设置自定义策略集及自定义绑定
选择好策略集后，用户可参考“示例介绍”那一节，为 EchoService12 的服务提供者和服务客户机连接策略集
my Username WSSecurity default。注意：必须为服务提供者及对应的服务客户机连接相同的策略集。
登录管理控制台，服务->策略集->缺省策略集绑定（见图13），可以看到 WAS V7.0提供了两个缺省绑定：
- Provider sample——用于服务提供者
- Client sample——用于服务客户机
图 13：WAS
V7.0 提供的缺省策略集绑定
这两个缺省绑定使用 Username Token 的认证方式，并利用 WAS V7.0 提供的一组缺省的证书库支持消息的签名和加密，您可以在
<WAS_HOME>/etc/ws-security/samples 下找到这些证书。想了解关于这两个缺省绑定的详细信息，请参看参考资源中的相关链接。
注意：建议在生产环境下不要使用缺省绑定及其证书库。
WAS V6.1 缺省策略集绑定指的是 Web Services Feature Pack 中的缺省策略集绑定，Web
Services Feature Pack 中的缺省策略集绑定只是针对服务提供者的。
用户可使用缺省绑定，或创建自定义的绑定。创建自定义绑定的步骤如下：
登录管理控制台，服务->服务提供者->EchoService12；
选中服务、端点和操作，点击指定绑定->新建特定于应用程序的绑定，创建新的自定义绑定名称 EchoService12CustomBinding；
添加当前策略集中的某个或某些策略，比如：WS-Security，表明将为 WS-Security 策略设置自定义绑定；
进入“认证和保护”，对令牌和消息部件中为策略集所必需的定制绑定进行配置（具体步骤见参考资源），并保存（见图
14）。
按照类似的步骤，可为服务客户机新建自定义绑定 EchoService12ClientCustomBinding。
图
14：为 EchoService12 服务提供者新建的自定义绑定
注意：要保证自定义绑定的“认证和保护”页面上，所有的状态都是“已配置”。
为 EchoService12 的服务提供者和服务客户机连接策略集和绑定之后，可以通过以下两种方式在管理控制台查看结果：
- 进入应用程序->应用程序类型-> WebSphere企业应用程序-> JaxWSServicesSamples
->服务提供者策略集和绑定（或服务客户机策略集和绑定），可以看到该样本应用的所有服务、端点及操作（包括
EchoService12）已连接的策略集和绑定设置。
- 还可以通过进入“服务->策略集->应用程序策略集-> my Username
WSSecurity default->已连接的应用程序”，查看连接到该策略集的所有应用（包括：JaxWSServicesSamples）。
配置了同一个自定义策略集 my Username WSSecurity default 的 EchoService12
的服务提供者和服务客户机，通过各自的自定义绑定 EchoService12CustomBinding 和
EchoService12ClientCustomBinding，可以安全地进行交互。
IBM RAD V7.5 支持 JAX-WS 2.0 Web Service 的开发，同时也提供了向导为
Web Service或 Web Service Client 添加策略集连接。
这里，以 JaxWSServicesSamples 的一个 Web Client 应用 SampleClientSei.war
为例（在JaxWSServicesSamples.ear 包中），为其配置 UsernameToken
WSSecurity default 策略集，使之与 EchoService 服务提供者安全地进行交互。
1. 将 SampleClientSei.war 导入 RAD V7.5，其所在的工程为：SampleClientSeiEAR。
你可能会看到 SampleClientSei 导入后有两个错误，右键点击 SampleClientSei，选择“属性”，在弹出的界面上选择“Java
构建路径”，将 <WAS_HOME>/runtimes/com.ibm.jaxws.thinclient_7.0.0.jar
作为外部 jar 添加到 Libraries，这两个错误就会消失。
2. 在 Java EE 视图中，选择“服务”，展开 JAX-WS->客户机，右键点击 EchoService，选择“管理策略集连接…”（见图
15），即可得到为Web Service客户机配置策略集的界面（见图 16）。或者，您也可以通过以下方式到达该界面：新建->其他…->
Web Services->策略集连接，点击“下一步”，选择“连接策略集到 Web Service
客户机”，其他保持不变，点击“下一步”。
图 15：为 JAX-WS Web Service 或 Web Service 客户机新建策略集连接
图
16：为 Web Service 客户机配置策略集
3. 选中 EchoService，点击下一步，在“应用”下面点击“添加…”，为 EchoService
客户机选择 Username WSSecurity default 作为策略集，可以使用 RAD V7.5
缺省的 Client sample 绑定，也可以自定义绑定。这里，因为 EchoService 用的是服务提供者的缺省绑定
Provider sample，所以，我们用对应的服务客户机的缺省绑定 Client sample（见图
17）。
图 17：在RAD V7.5中为EchoService服务客户机设置缺省策略集及绑定
当然，我们也可以自定义绑定，直接在 Binding 处输入自定义绑定名称，比如：RAD7.5 Client
Binding（见图 18），点击 OK。你会收到一个警告信息，忽略它。如果使用了 Client sample
缺省绑定，点击“确定”之后，回到图 19这个配置界面时，绑定配置是不可修改的。但是如果新建了自定义绑定，绑定配置则变成可配置的了，也就是说，需要用户配置自定义绑定。
图 18：在 RAD V7.5 中为 EchoService 服务客户机设置自定义策略集及绑定
图 19 中，选择 WS-Security，点击“配置(C)…”可以对客户端策略 WS-Security
的自定义绑定进行配置，包括认证、数字签名和加密（见图 20）。最后点击完成结束对策略集连接的设置。
图 19：自定义绑定的配置
图 20：绑定设置：认证、签名和加密
4. 展开 SampleClientSeiEAR-> META-INF，可以看到新建的自定义绑定
RAD7.5 Client Binding（见图 21），bindings.xml 中包含了图 19中关于认证、签名和加密的所有配置。同时
clientPolicyAttachments.xml 中也指定了该 Web Service 客户机所连接的策略集名称及绑定名称。
图 21：Web
Service 客户机的策略集及绑定配置
5. 导出 SampleClientSeiEAR.ear，这个应用包已经包含了策略集的设置，您可以将其部署到WAS
V7.0 上直接使用，不需要再做任何安全策略集配置。图 22 显示了部署后应用程序包内的策略集及绑定配置生效。
图
22：SampleClientSeiEAR.ear 的安全策略集及绑定
您也可以利用 launchClient 命令运行该 Client 应用程序，与 server1 上使用了相同策略集及对应绑定的
EchoService 进行交互。
注意：
1) 因为之前安装的 JaxWSServicesSamples 应用也包含了一个 SampleClientSei.war
应用，所以，需要先把该 war 应用从 server1 上删除，才能部署 SampleClientSeiEAR.ear。或者不需要改动
JaxWSServicesSamples 应用，而是把 SampleClientSeiEAR.ear 所包含的
SampleClientSei.war 部署到新应用服务器上以避免冲突。
2) 运行时，如果您在 SystemErr.log 里遇到 CWWSS5327E 的错误（见清单 2），是因为在RAD
V7.5 中配置自定义绑定时，没有为 token authentication（图 20中）创建时间戳标记的选项(注意：RAD
V7.5.1 里有这个选项，可以用来创建时间戳标记），但是 WAS V7.0的 Provider sample
绑定却要求验证用户名 token 的时间戳。
清单 2. SystemErr.log
日志记录
CWWSS6521E: 由于异常，登录失败: javax.security.auth.login.LoginException:
CWWSS5327E: 时间戳记的创建时间不允许为空值。Application Server 需要 wsu:Created 元素。 |
您可以通过以下方法解决这个问题：
从管理控制台，服务->策略集->常规提供程序策略集绑定->Provider sample->WS-Security->认证和保护->
con_unametoken->回调处理程序，把 verifyTimestamp 和 verifyNonce
的值从 true 改为 false（见图 23），保存并重启 server1 使之生效。
图 23：用户命令牌的定制属性 verifyTimestamp 和 verifyNonce
RAD 提供了一个察看 SOAP 消息的工具——TCP/IP 监视器。使用方法如下：
1. 在 RAD 中，选择 Window->显示视图->其他…，展开“调试”，选择“TCP/IP监视器”，点击确定，就会有一个
TCP/IP 监视器的窗口出现在 RAD 工作台的右下角，双击使其最大化。
2. 右键点击TCP/IP界面的空白处，选择“属性”，在弹出的界面上，点击“添加…”，在“新建监视器”的界面上，输入需要监控的应用服务器的主机名和端口号，及其监控端口号（见图
24）。点击确定。启动这个新建的 TCP/IP 监视器，点击确定。
图 24：新建 TCP/IP
监视器
3. 在浏览器中打开 http://<hostname>:<port>/wssamplesei/demo，选择“Synchronous
Echo”作为 Message Type，输入 Message String（此例中输入 test），然后点击“Send
Message”。需要特别注意的是：Service URI 这里需要指定 TCP/IP 监视器所在的主机名和监控端口，而不是
server1 的 HTTP 端口（见图 25）。
图
25：通过 TCP/IP 监视器访问 EchoService
4. TCP/IP 监视器可以监控 SOAP 的请求和响应信息，可以选择以 XML方式查看（见图 26）。可以看到，左下角是
SOAP 请求，右下角是 SOAP 响应，它们的头部及主体都包含了相关的安全信息。
图
26：通过 TCP/IP 监视器查看 SOAP 请求和 SOAP 响应
WAS V7.0 相对于 WAS V6.1 和 Web Services Feature Pack 来说，支持的
Web Services 安全机制更全面。同时，WAS V7.0 与 RAD V7.5 对 Web Services
标准的支持和扩展都是同步且紧密结合的，它们从各个方面提高了 Web Services 安全策略集的易用性。本文通过示例，向您展示了如何在
WAS V7.0 和 RAD V7.5 中配置安全策略集的各种途径和要领，希望能够对您有所帮助。
学习
获得产品和技术 | 
