法，可以实例化工具包中的类并添加这些对象到本身表示的标记对象中。当然，如果需要，客户可以自由的直接操作工具包中的对象。 　　 　　需要提到的是，并不是所有对象都是立即可得的。它们会随着工具包实现阶段的不断展开，在后续的文章中被依次介绍并添加到工具包中来(参见第一部分的结论部分) 　　 　　如下，图1显示了工具包框架中各种对象以及客户间的关系。 　　　 　　图1. 工具包的操作 　　 　　为了更好的理解图1，需要对工具包操作的几个重点概念进行进一步的解释： 　　 　　·不是所有的标记元素都可以从现有XML元素生成。例如，重用现有时间戳元素(wsse.Toolkit.Tokens.Wss.TsToken标记)来构建新的标记，没有什么实际意义——实际上,需要时应该从头构建并相应添加新标记 　　 　　·可从现有XML元素创建的标记类，具有唯一参数类型为org.w3c.dom.Element的构造函数，此构造函数会对输入的XML数据进行浅层次的数据有效性验证。所有情况下，必须正确地维护用于构建新标记XML元素的org.w3c.dom.Document对象，不合适的文档对象会在添加元素时产生错误。标记类基类WsToken类、WsConpositeToken类以及帮助类WsTokenHelper具有处理XML文档的功能。 　　 　　·虽然标记引用类型也都是从基类wsse.Toolkit.Tokens.WsToken派生的，但是大多数引用类型的作用是引用现存的XML元素，不是作为本身可以被添加的元素。不过，在下面的WSSE映射部分会提到一些特殊的标记引用类型，除具有引用元素功能外，本身也可以作为被添加的元素。 　　 　　·标记引用类型可以引用不同的安全信息头部中的标记元素——此功能有助于在新的WSSE头部中添加现有标记元素的功能的实现。标记引用类型甚至可以引用在安全处理过程的初期添加的当前不存在的元素, 比如前面代码示例中加密签名元素构成的元素。 　　 　　·标记帮助类的责任是实例化标记类型对象和标记处理器对象，并将二者联系起来处理，当然这需要适当的配置信息以及初始化工作。标记处理器类型的责任是操作标记帮助类的处理结果，比如在安全头部中添加一个新产生的数字签名元素。处理器接口的要约是仅对引用标记进行适当的处理，并不对此处理过程中产生的新标记进行任何操作。 　　 　　·处理操作可以连接起来构成处理操作链。这样，可以对多个安全头部的入口签名，然后对签名加密, 如上面客户处代码示例。 　　 　　工具包提供了轻量的对象层次，处理每次客户调用时，会实例化一些具有仅于自己上下文环境关联的对象， 因此不必担心并发问题。工具包中大多数类没有提供同步化锁，只有wsse.Toolkit.Utils.Xml.XmlFactory 类和 wsse.Toolkit.Utils.Config.ConfigHelper类除外，这两个类提供了一些可以被多个线程共享的功能。对于配置的目录服务和SAML服务实现提供者来说，由于工具包的所有运行客户都访问相同的提供者，它们的实现必须是线程安全的。 　　 　　WSSE映射 　　 　　现在，将要讨论工具包内的组件是如何与WSSE规范规定的主要构建块的映射关系。注意：WSSE 规范的第5部分对<wsse:Security>头部块是这样定义的，“<wsse:Security>头部块以SOAP行动者或角色的形式存在，提供在在SOAP信息中添加针对特定接收者的安全相关信息的机制”， 这意味着， WSSE安全头部是可以扩展的， 同时在所有可能使用此技术的应用中试图使用它是不合适的。 因此，工具包框架仅对规范中规定的标记类型及其关系进行映射，同时可以在以后添加新的标记类型及其处理器。 　　　 上一页  [1] [2]