- 浏览: 318570 次
- 性别:
- 来自: 长沙
文章分类
最新评论
-
完善自我:
支持一下!
揭秘IT人才特点:中美印日四国程序员比较 -
悲剧了:
好文,看玩thinking in java的提到的异常处理,看 ...
高效的Java异常处理框架(转) -
yin_bp:
开源框架bbossgroups页支持组件异步方法调用哦,详情请 ...
Spring 3中异步方法调用 -
flyjava:
sun的悲哀
Apache怒了,威胁说要离开JCP
WS-Security 以现有的密码学以及 XML 加密和签名行业标准为基础,为 Web 服务应用程序提供了一组全面的安全特性,您可以通过 WS-Policy 和 WS-SecurityPolicy 来指定特定应用程序可以使用哪些特性,从而允许服务客户机自行配置以访问服务。通过跨多个平台和 Web 服务框架对这些标准的广泛支持,可以实现出色的互操作性(并且会不断改善)。
尽管能带来这么多好处,但 WS-Security 也存在一些缺点。在本 系列 的前两篇文章中,您已经知道 WS-Security 的配置有时会非常复杂,并且有时会在交换的消息中添加许多块(bulk)。那么,WS-Security 带来的收益在什么情况下才物有所值呢?在本文中,我们将深入探讨 WS-Security 以及相关 WS-SecureConversation 的运行时成本(在处理开销和添加块方面),并引申到如何应用 WS-Security 才能让应用程序受益的话题。
为了测量应用程序在不同配置下的性能,本文将测定当客户机和服务器运行于同一系统中特定请求序列的执行时间。这种方法存在一些缺点 — 最显著的是,它将客户机和服务器处理开销结合在一起,因此不能单独测算它们 — 但它比在网络上运行测试能生成更加一致的结果。您还可以轻松地在自己的硬件和 JVM 上试运行这些测试,相关的实现代码请参见 下载 。
用于测试的应用程序是一个地震数据检索服务。它基于一个地震数据库,其中包含一段时间内世界各地发生的 93,000 多次地震的实际数据。对服务的请求将指定经度、纬度、日期或震级的范围,并且服务将按地区和时间顺序分组返回所有匹配的地震。整个数据库按索引保存在内存 中,以便于快速处理请求,因此每条请求几乎所有的处理时间都花在实际的 Web 服务处理代码上(包括将转换为 XML 或从 XML 转换而来的数据绑定代码)。
清单 1 展示了一个对服务的示例请求,以及随后的响应(为适应页面宽度重新调整了格式):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types"> <ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date> <ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date> <ns1:min-long>160.4685</ns1:min-long> <ns1:max-long>178.19693</ns1:max-long> <ns1:min-lat>-42.423557</ns1:min-lat> <ns1:max-lat>-30.44976</ns1:max-lat> </ns1:matchQuakes> </soapenv:Body> </soapenv:Envelope> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9"> <ns1:result-set> <ns1:area-name>New Zealand Region</ns1:area-name> <ns1:regions count="0"> <ns1:region ident="rgn159" index="159">NORTH ISLAND, NEW ZEALAND</ns1:region> <ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND, N.Z.</ns1:region> </ns1:regions> <ns1:quakes count="9"> <ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000" latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4" method="ML" region="rgn160"/> <ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0" latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5" method="ML" region="rgn160"/> <ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600" latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6" method="ML" region="rgn159"/> <ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000" latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3" method="MB" region="rgn159"/> <ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600" latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0" method="ML" region="rgn159"/> <ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700" latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0" method="ML" region="rgn159"/> <ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300" latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3" method="ML" region="rgn159"/> <ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900" latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5" method="ML" region="rgn159"/> <ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400" latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5" method="ML" region="rgn159"/> </ns1:quakes> </ns1:result-set> </ns1:results> </soapenv:Body> </soapenv:Envelope> |
在测试中,客户机将查询范围调整为整体地震数据集的一部分,并生成一系列伪随机请求。每次使用相同输入参数运行客户机所生成的请求序列都是相 同的,这允许我们测试不同的 Web 服务配置。通过更改客户机的输入参数(用于更改请求所使用的查询范围),可以轻松地测试不同的结果消息大小。
本文所示的测试结果基于两个请求序列。第一个序列使用 1,000 条请求,查询参数经过调整以便各查询只匹配整个地震数据库的一小部分(1,000 条请求仅返回 826 次匹配的地震)。第二个序列使用 100 条请求,同时调整以匹配更大的数据库部分(100 条请求返回 176,745 次匹配的地震)。每个请求序列都在不同的安全性配置下运行了多次,每种配置只取最好的测试结果。
运行测试的环境是 Mandriva 2009.1 64-bit Linux® 系统、Athlon X2 5400+ 处理器、4GB
内存和 Sun Java 1.6.0_13 32 位 JVM。服务器代码在 Tomcat 6.0.20 上运行,配置为使用 1,024MB
大小的堆,客户机代码使用 512MB 大小的堆。我们使用 1.5 版本的 Axis2,并使用最新版本的 Rampart
代码。(在本文测试时,还没有与 Axis2 1.5 代码相匹配的 Rampart 发行版可用。要运行完整的测试集,为 Tomcat 配置
1,024MB 大小的堆是非常必要的(为各安全性配置使用单独的 Web 服务应用程序);刚开始使用 256MB
大小的堆执行测试时,WS-Security 测试有时会因为各种奇怪的错误(举例来说,未提供 DTD 时出现的 “SOAP message
MUST NOT contain a Document Type Declaration(DTD)” 错误)或者 java.lang.OutOfMemoryError
而失败。
我们使用以下安全性配置运行各测试:
- plain :无安全性
- ssl :使用 HTTPS 连接到服务器
-
username
:请求中使用 WS-Security 纯文本
UsernameToken
- sign :WS-Security 主体和报头签名,使用时间戳
- encr :WS-Security 主体加密
- signencr :WS-Security 主体和报头签名,使用时间戳和主体加密
实际测试时间从 plain 配置的 4 秒到 signencr 配置的 55 秒。图 1 显示了相对测试时间,为便于比较使用了相对 plain 配置时间的倍数:
从 图 1
中可以看出,Secure Sockets Layer (SSL) — 从技术上说,现在应该称作 Transport Layer
Security (TLS),但本文仍然使用为人所熟知的旧表示方法 —
加密所提供的性能接近无保护措施时的性能水平(但其处理大消息比处理小消息的性能要好,处理小消息所花的时间要长 80%,处理大消息所花的时间要长
20%)。另一方面,使用 WS-Security 会造成性能显著降低。仅在请求消息上添加简单的 UsernameToken
报头会造成性能降低到 SSL 处理小消息时的性能水平,但比使用 SLL 处理大消息时的性能慢
几倍。在签名与加密相结合的情况下,测试时间比无保护措施下要长 2,100%。
从一定程序上说,WS-Security 带来的这种性能上的影响归因于 Rampart 处理程序实现的缺陷,这会造成每次有
Rampart 参与时都将各请求和响应消息转换成 Document Object Model (DOM)
格式(即使未对消息执行任何安全性处理)。应该在 Rampart 1.5 发行版中修复此问题以便它可以兼容 Axis2
1.5。根据修复的实现方式,它可以显著改善 UsernameToken
测试的运行时间。但是,即使修复了此问题可能也不会影响其他的 WS-Security 运行时间。
与 WS-Security 相结合的 XML Signature 和 XML Encryption 的运行方式,以及 WS-Security 和这些 XML 标准的实现所使用的库也是影响性能的因素之一。还记得 “Java Web 服务:Axis2 WS-Security 签名和加密
” 这篇文章说过,签名 XML 消息需要一个叫做规范化
的步骤,用于在捕获签名值之前将 XML 转换为特定的规范格式。标准需要这一步骤是因为已经确定即使在解析器分解 XML
并重新生成它之后也需要保留签名。虽然这毫无疑问是 XML Signature
的一个实用的特性,但它为处理增加了大量的开销。在一定程度上,由于使用 DOM 模型是实现规范化最简单的一种方法,因此 XML
安全性库都被设计为操作 XML 的 DOM 表示。(这是为何 Rampart 处理程序即使在参与服务或客户机任务时也要生成 DOM
的原因,但前提是 DOM 有必要的作用)。仅将数据转换成 DOM 表示的步骤就会造成大量的 WS-Security 开销,这可以从 UsernameToken
时间看出。在大响应消息的情况中,这种开销看上去与实际的签名或加密处理相当(如 图 1
所示,比较 username 测试的红柱 — 其中,唯一的主要开销是 DOM 的创建 — 与 sign 和 encr 测试的红柱,其中,实际的加密处理是在创建 DOM 之后完成的)。
除了 DOM 问题之外,大部分 WS-Security 开销都是计算紧密型的生成摘要和加密数据的任务。这一部分的工作是必需的,而与所使用的实现方法无关,因此 WS-Security 处理时间的改善是有限的。本系列的后续文章将比较其他一些使用 Axis2/Rampart 的 WS-Security 实现的性能 — 但是,它们大多数都使用相同底层库,因此不要指望能看到巨大的差异。
WS-SecureConversation 是在 WS-Security 和 WS-Trust 标准之上构建的一种标准,用于支持涉及多个消息的安全交换。由于它所使用的上下文针对运行中的消息交换,因此 WS-SecureConversation 更有可能比 WS-Security 实现更高的效率。Rampart 发行版包括一个单独的 rahas 模块,它支持发起 WS-SecureConversation 所需的安全令牌。它还包括一个使用 WS-SecureConversation 的策略配置示例(samples/policy/sample04),用于作为性能测试应用程序所使用的策略基础。
WS-SecureConversation 策略(未包含在此处,请参见 下载
中的 secureconversation-policy-client.xml)包括一个 <sp:SecureConversationToken>
元素,用于描述消息交换将使用的安全令牌,以及提供应用于 token-exchange 消息的安全性选项。这些 token-exchange
消息使用由 rahas 模块实现的操作为客户机和服务之间的消息交换提供支持 — 因此在使用 WS-SecureConversation
时,您偶尔会看到 request-response 消息对在客户机和服务器之间传递,如 清单 2
所示。要区分添加的这些 token-exchange 消息与应用程序消息,可以根据它们所使用的不同的安全性选项(由策略定义),以及它们所使用的特殊的 http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT
请求和 http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT
响应操作代码(两者都由 WS-SecureConversation 定义)。
<?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"> ... </wsse:Security> <wsa:To >http://localhost:8800/axis2/services/seismic-secureconversation</wsa:To> <wsa:ReplyTo> <wsa:Address >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address> </wsa:ReplyTo> <wsa:MessageID>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:MessageID> <wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action> </soapenv:Header> <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-30222347"> <xenc:EncryptedData ...> ... </xenc:EncryptedData> </soapenv:Body> </soapenv:Envelope> <?xml version='1.0' encoding='UTF-8'?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"> <wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1"> ... </wsse:Security> <wsa:To >http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To> <wsa:MessageID>urn:uuid:1BCDE6BE423F5FDE791246409571325</wsa:MessageID> <wsa:Action >http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</wsa:Action> <wsa:RelatesTo>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:RelatesTo> </soapenv:Header> <soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd" wsu:Id="Id-5148380"> <xenc:EncryptedData ...> ... </xenc:EncryptedData> </soapenv:Body> </soapenv:Envelope> |
为了与普通的使用证书的 WS-Security 的性能相比较,WS-SecureConversation 配置被设置为仅在加密消息主体时使用会话令牌。图 2 展示了最终测试时间与 plain 及 encr 测试配置之间的比较,为便于比较使用了相对 plain 配置时间的倍数:
图 2. WS-SecureConversation 时间比较
如 图 2 所示,WS-SecureConversation 加密确实相对 WS-Security 提供显著的性能改善。这对于较小的消息尤为明显,其 WS-SecureConversation 配置的运行速度几乎是使用证书的 WS-Security 加密的两倍。而对于较大的消息来说,性能优势则逊色许多,但 WS-SecureConversation 仍然提供了 18% 的速度提升。
从系列的前一篇文章中看到,WS-Security 可以会向 SOAP 消息报头添加大量块(bulk)。当数据通过网络在客户机与服务器之间传递时,这些添加的块会对性能造成显著影响(而在本文中,客户机和服务器是在相同的 系统上运行的)。客户机与服务之间的网络连接的质量将决定这些增加的块会对性能造成多大的影响,但毫无疑问的是,消息越大,交换速度就越慢。
图 3 显示了不同测试用例中的典型消息的实际大小,为便于比较使用了相对 plain 配置时间的倍数:
与预期相符,username 配置仅增加了请求消息的大小,因为 UsernameToken
仅出现在请求消息中。其他安全性配置则同时增加了请求和响应消息的大小。WS-Security
添加的块对于较小的请求和响应消息来说更加明显。对于各配置来说,WS-Security
报头基本上是恒定不变的,因此当原始消息大小较小时,相同大小的增加会带来更加显著的影响。在使用加密时,加密数据所使用的 base64
编码中出现了单独的填充(padding)效果。
您已经了解了 WS-Security 对处理时间和消息大小的影响。您可能想知道这些代价何时才是值得的。简单的回答是:当较简单的 SSL 替代方案没有作用时。在本节的其余部分,我们将提供一些指导方针来帮助您确定 SSL 是否能满足您的需求,或者是否需要全功能的 WS-Security 解决方案,并且还将指导您在选择 使用 WS-Security 后最大限度降低与之相关的开销。
保护机密信息是安全性最重要的一个方面。WS-Security 使用 XML Encryption 保护消息内容不被非目标接收者获取,其方法通常是使用封装在数字证书中的公共密匙。加密可以应用于整个消息或所选部分,并且您甚至可以使用多层加密来控制 哪些信息可以由涉及多个系统的消息交换中的参与者访问。
WS-Security 的一个示例用例是一个在线购物系统,其中,客户机连接到商业系统下订单,但付款(比如说,通过信用卡)需要在处理订单前由某银行系统确认。如果商业系统能 够以未加密的形式访问信息卡信息,则会带来基于浏览器的购物网站所特有的安全性风险:信用卡最终经常会存储在安全性较差、易于受到黑客攻击的数据库中。使 用 WS-Security,信用卡信息可以以加密的格式传递,并且仅能由发出付款确认的银行系统解密。
但是,对于许多应用程序来说,在保护机密信息方面,WS-Security 和 XML Encryption 的功能有点过于强大。如果您的服务需要客户直接与之联系(而不是间接通过其他服务器)并且直接执行所有必要的处理,那么您可以仅使用 SSL (HTTPS) 连接来实现访问功能,这样能以比 WS-Security 更低的成本提供出色的机密信息保障功能。不过,这种方法仅适用于直接客户机连接。否则,如果服务需要将信息传递给其他服务,那么您又遇到了与在线购物网站 易受攻击的情况:您使用安全的连接向购物网站传递信用卡信息,但是却无法保证信息将安全地保存在站点服务器上。
数据完整性是与机密性相类似的一个问题。WS-Security 使用 XML Signature 确保数据不会在传输中被篡改,因为任何窜改都会导致签名失效。与 XML Encryption 相同,签名可以应用于整个消息或者所选部分,并且您可以使用多层签名来保证涉及多个系统的消息交换中的参与者所处理的数据的完整性。
虚构的在线购物系统还提供了很好的数据完整性的例子。使用 WS-Security,客户对发送给银行系统的付款指令进行签名,从而防止中间的商业系统随意修改指定的付款额。由于付款额经过客户签名,因此不需要对 它进行加密,以便商业系统在向银行系统提交事务之前确定付款额正确无误。
此处,如果您的服务需要客户直接与之连接并且在内部执行所需必需的处理,则 WS-Security 和 XML Signature 又显得有些过于强大了。SLL 连接不仅能保证数据的机密性,它们还能防止数据在传输过程中被修改 — 但仅限于在在单一的客户机与服务器之间。如果服务器将数据传递给其他系统,则这些系统无法保证数据不被服务器修改。
在真实性方面,WS-Security 所提供的特性是 SLL 所无法匹及的,即使针对客户机与服务器之间的直接连接。使用 WS-Security 和 XML Signature 对消息进行签名,不仅允许您的文档在接收和处理时进行真实性验证,还可以为用于审计的文档提供可靠的真实性保障。
SSL 在这方面做的出色的地方就是在客户机与服务器之间建立连接时要求客户机证书作为身份证明。但是,它所提供的真实性保障要比消息数字签名弱很多。您不能轻易 地将客户机与服务器之间交换的整个数据流保存为 SSL 连接的一部分,因此,即使您在建立该连接时验证了客户机证书,也无法在稍后返回并证明此步骤已得到正确处理。
再次回到在线购物系统示例,付款指令上的客户机签名将允许该指令由银行系统保存,并在以后就该事务出现任何争辩时提供该签名。这样,银行系统便可以证明 付款已经得到了客户的授权,从而让自己免除任何责任。
除了基本的机密性、完整性和真实性之外,WS-Security 还针对特定的安全性需求提供了许多其他特性。举例来说,UsernameToken
就是一个简单的特性,它提供了与服务传递基本用户授权的标准方法。其他 WS-Security 特性还允许 Security Assertion
Markup Language (SAML) 授权令牌和其他形式的与安全性相关的信息,用于添加到 SOAP 消息交换中。如果需要在 Web
服务中使用此类型的安全性信息,可以使用 WS-Security
支持来传递信息,因为它定义了一些标准的格式和过程,可能会比您自己实现的功能更加可靠。
如果您要使用 WS-Security,可以从本文的测试结果中看出性能是一个问题。但是,在顾虑其开销之前,请考虑一下您服务的数据量。使用 WS-Security 进行加密和签名之后,服务的性能会大打折扣 — 但是,如果您的服务每小时只交换少量消息,则硬件需求方面的差异是可以忽略不计的。
对于性能无法折衷的场景,您可以通过合理地安全性选项来帮助最大限度地减小性能影响。某些 Web 服务框架倾向于生成 “所有上述” 安全性配置,它们使用 WS-Security 实现全面的消息签名和加密,并 通过 SSL 连接发送它们。如果您确实希望提供最高级别的保护,而对性能毫不关心,那么这种方式没有问题。但是,在大多数情况下,更有意义的方法是使用 SSL(如果只关心为在客户机和单一服务器之间传输的信息提供保护)或者 WS-Security 加密(如果需要跨多个服务器传递数据,同时在它们经过中间系统时保护机密信息的安全。
对于客户机和服务器之间需要长时间交换消息的情况工(甚至通过中间系统访问其一),您还可以使用 WS-SecureConversation 提供相对于使用证书的 WS-Security 更好的性能。WS-SecureConversation 特别适合相对较小的消息之间的交换,其中,证书和非对称加密方面增加的开销与消息主体的实际(对称)加密相比是相当可观的。
降低 WS-Security 性能成本的另一种方法是将安全性处理转嫁给专门的硬件来完成。一些 XML 网关工具提供了对 WS-Security 加密和签名的加速处理。您可以使用这些工具来处理大开销的 WS-Security,同时处理应用程序中的纯 SOAP。显然,您需要确保在向服务器添加工具时不会打开任何潜在的安全性漏洞。并且,您应该在购买之前测试工具所带来的性能提升。但是,至少从理论上来 说,这种模式确实能实现一些性能提升。
WS-Security 的性能成本是可观的,并且简单的 SSL 点对点加密有时是更好的解决方案。但是,对许多应用程序而言,SSL 是远远不够的。在这些情况中,就必须使用 WS-Security(或者它的后代 WS-SecureConversation),而且性能成本也成为必要的开销。在本文中,您已经了解了 WS-Security 的成本,并学习了一些可帮助您确定 WS-Security 是否适用于自己应用程序的指导方针。
在本系列的下一篇文章中,我们将从另一个视角来解读 WS-Security,将演示如何使用 WS-SecurityPolicy 实现对 Web 服务中各操作所使用的 WS-Security 特性的粒度化控制。在操作层面控制 WS-Security 也是一个能够(至少可能)降低 WS-Security 开销的技巧,因此,在转向其他话题之前,这是对本文的最好的沿续。
j-jws6.zip | 1.6MB | HTTP |
原文:http://www.ibm.com/developerworks/cn/java/j-jws6/
发表评论
-
WS-I闭关,这对WS-*意味着什么?
2010-11-15 21:19 958观点 :Web Services互操作组织(WS-I) 刚 ... -
EDA 和 SOA 的融合以及实践
2010-11-08 09:55 1047EDA 和 SOA SOA 简介 ... -
REST vs. SOAP
2010-11-04 17:08 1795看起来在web API协议之争(如果曾经有过)中,潮流正稳步的 ... -
SOA分析和设计中的错误处理要点
2010-10-24 23:51 1106在SOA分析和设计阶段进行全面的错误处理需求分析对于正确完成设 ... -
WebSphere Message Broker 开发和部署最佳实践
2010-10-23 18:24 2335简介: 本文以多个客户企业的经验为基础,给出了使用 Web ... -
带附件的 SOAP 消息
2010-09-30 15:16 1328简介: 本 文介绍了一种在 MIME Multipa ... -
利用 Geronimo 2.2 创建安全的 Web Service 应用
2010-09-30 14:49 1033简介: 随着 Web Service ... -
大学内的云计算解决方案
2010-09-29 14:16 1749本文通过使用一个 Virtual Computing Lab ... -
整合 WebSphere ILOG JRules 与 IBM Content Manager Enterprise Edition
2010-09-28 10:30 2219简介: 自动决策在内 ... -
评估企业是否适合开发复合业务服务
2010-09-27 17:01 1069本文介绍如何评估一个 ... -
集成 IBM 元数据存储库,第 2 部分: 在 WebSphere Service Registry and Repository 中治理元数据生命周期
2010-09-27 16:55 1103通过将您的应用程序与 IBM® Rational® Asset ... -
集成 IBM 元数据存储库,第 1 部: APIs for accessing Rational Asset Manager
2010-09-27 16:52 973通过将您的应用程序与 IBM® Rational® Asset ... -
不使用客户端证书的 WS-Security
2010-09-27 15:42 1352许多 WS-Security 配置要 ... -
CXF 性能比较
2010-09-27 15:15 1703Apache CXF Web 服务栈建立在与本系列早期文章讨论 ... -
通过 CXF 使用 WS-Security
2010-09-27 15:11 2799与 本系列 前面的文章 ... -
CXF 简介
2010-09-27 15:07 4367Apache CXF Web 服务堆栈是来自 Apache ... -
比较 Metro 与 Axis2 性能
2010-09-27 15:04 1147Metro Web 服务堆栈是基于 ... -
Metro 服务下的 WS-Security
2010-09-27 15:00 1333本文展示如何通过 Metro 来使用和配置 WS-Securi ... -
Metro 简介
2010-09-27 14:52 1995Metro Web 服务栈是由 Sun M ... -
Axis2 中的 JAXB 和 JAX-WS
2010-09-27 10:38 1726早期的 Apache Axis 建立在第一个面向 Web 服务 ...
相关推荐
传统的WS-Security处理器通常基于DOM(Document Object Model),虽然这种实现方式便于编程,但DOM解析XML文档时需要将整个文档加载到内存中,这会导致较大的时间和空间开销。为了克服这些问题,本文介绍了一种基于...
WS-SecureConversation**: 这个规范建立了一种机制,允许在多个请求之间保持一个安全会话,减少了每次请求都需要重新协商安全凭据的开销。WSE3.0通过实现WS-SecureConversation,提供了高效的会话安全。 **4. WS-...
4. **模块化设计**:CXF由多个模块组成,包括Bus(核心组件)、JAX-WS、JAX-RS、DataBinding、Addressing等,这种模块化设计使得开发者可以根据项目需求选择合适的组件,避免了不必要的资源开销。 5. **工具支持**...
Rampart是一个在Apache Axis2框架下开发的安全模块,它主要负责实现Web服务安全标准,如WS-Security、WS-SecureConversation和WS-Trust。这个发布包包含了Rampart的源代码,允许开发者深入理解其内部工作原理,并...
4. **WS-*兼容性**:CXF实现了众多Web服务标准,如WS-Security、WS-Addressing、WS-RM(Reliable Messaging)等,确保了与其它WS-*兼容的服务进行交互。 5. **拦截器和端点**:CXF允许通过拦截器来扩展和定制服务...
- **Rampart**:提供Web服务安全功能,如WS-Security、WS-Trust和WS-SecureConversation。 - **Neethi**:用于处理WS-Policy,定义服务的安全、可靠性和事务策略。 - **WSDL工具**:用于生成和处理WSDL文档,这是...
- **WS-Security**:一种用于保护Web服务安全的标准,gSOAP支持WS-Security规范,提供身份验证、消息完整性与机密性等安全特性。 2. **gSOAP的功能** - **代码生成**:gSOAP提供了一个名为`wsdl2h`的工具,可以从...
2412FASA5540Cisco4507RAP1242GInternet景兴新办公大楼网络拓扑 总机房 WS-C2900-24 1F WS-C2900-48 3F WS-C2900-24 WS-C2900-24 7F WS-C2900-24 2F WS-C2900-24 4F WS-C2900-48 5F WS-C2900-24 WS-C2900-24 6F WS-...
7. **模块化设计**:Apache CXF由多个模块组成,如核心服务、WS-Security、数据绑定等,这种模块化设计使得可以根据项目需求选择必要的组件,避免不必要的性能开销。 在解压"apache-cxf-2.6.0-src.tar.gz"后,你会...
4. **WS-Security和安全认证**:gSOAP支持WS-Security标准,允许添加安全令牌、数字签名和加密,确保Web服务的安全通信。 5. **MTOM/XOP优化**:Message Transmission Optimization Mechanism (MTOM) 和 XML In-...
在实际开发中,这些组件的集成涉及到大量的配置工作,例如Spring MVC的拦截器配置、CXF的WS-Security设置、Spring Security的角色权限配置、MyBatis的Mapper配置以及Proxool的连接池参数设定等。通过这个项目,...
2. **安全性**:通过一系列相关的WS-*规范如WS-Security等,SOAP提供了高级别的安全机制,确保数据传输的安全性。 3. **事务支持**:WS-AtomicTransaction 和 WS-Coordination 等规范支持原子性事务处理,这对于金融...
5. **安全与策略**:深入研究 CXF 如何处理安全性(如 WS-Security)和策略(如 WS-Policy)。 6. **调试与测试**:了解 CXF 提供的调试工具和测试框架,确保服务的正确性。 通过阅读官方文档、参考示例代码和实践...
- **WS-Security**:通过数字签名和加密技术确保消息的完整性和机密性,增强Web服务的安全性。 - **BouncyCastle JCE provider**:提供了强大的加密算法支持,适用于JDK1.4环境下的安全通信需求。 #### WS-...
SOAP 1.1和SOAP 1.2是其两个主要版本,1.1是较早的版本,而1.2在设计上更现代,支持更多的WS-*规范,比如WS-Security、WS-ReliableMessaging等。 HTTP协议的核心特点包括: 1. 简单:HTTP协议的语法简单,易于实现...
2. **WS-STAR规范**:Web Services的核心规范包括WS-I(Web Services Interoperability)、WS-Security、WS-Reliability等,它们确保了不同厂商实现的Web Services可以相互通信。 二、Web Services开发工具与技术 ...
例如,WSDL(Web Services Description Language)用于定义服务接口,UDDI(Universal Description, Discovery, and Integration)用于服务发现,WS-Security提供了安全机制。这些规范增强了Web服务的功能,但同时也...
8. **SOAP与REST的比较**: SOAP提供了一套完整的框架,适合复杂的事务处理和安全性需求,但其消息格式复杂,开销较大。而REST则更轻量级,易于理解和实现,适合简单的数据获取和更新操作。 9. **SOAP消息实例**: 一...
1. **集成性**:CXF支持多种服务规范,如SOAP、JAX-RS(Java API for RESTful Web Services)、WS-*(如WS-Security、WS-ReliableMessaging等),这使得它能够轻松地与其他系统集成。 2. **高性能**:CXF采用了高效...
4. **WS-*系列**:包括WS-Security、WS-Reliability、WS-ReliableMessaging、WS-Addressing和WS-Transaction等,提供了Web Service的扩展功能,如安全性、可靠性、消息传递和事务处理。 在实际开发中,了解并掌握...