Ws-policy
the problem solvedWe know that in the SOA architecture, the most important cornerstone is service, and the business of service constraints from the business contract contract, then how we implement the service implementation process to reflect the corresponding contract constraints. The standard for standardizing Web service in the SOA specification is ws-policy, while other specifications like ws-addressing,ws-rm,ws-security can be seen as a special case of ws-policy. In addition to the concept of new service governance in the SOA practice, service governance includes the management of policy. Policy management consists of two parts: one is to define the definition, exchange and enforcement of service policy at design and runtime, and the other is to have standards-based (such as WS-*) and organizational internal regulations. Then I can see the practical application of ws-policy in the SOA implementation process, or in the field of SOA control (governance). Ws-policy is a little more complicated than ws-addressing. In addition to the configuration of the work, if the developer to implement their own specific policy, also need to implement some Inteceptor interface to complete the specified operation.
Ws-policy
The important concept of
Assertion (Assertion
)It is the basic constituent unit of policy, and each assertion can be identified by their qualified name (QName). An assertion can be a simple string or a complex object with multiple child elements and attributes. Assertions are personalization requirements, capabilities, or other characteristics that represent the behavior of a service. For example, you can create an assertion that defines a security requirement that a SOAP message body must be signed with a trusted certificate of No.
Substitution (Alternative
)Substitution is only a representation of another form of assertion, or a combination of assertions.
Standardization (Normalization
)The goal of normalization is to simplify the strategy to a standard format for fusion (merge) and intersection (intersection) operations.
Fusion (Merge
)Convergence is the process of combining multiple sub-policies together to form a single policy.
Intersection (Intersection
)The intersection is the process of comparing the 2 Web service policies that are used for a public override. Only when the two sides agree on at least one policy substitution will the intersection occur.
Ws-policy
the application
WeblogicSupport for Ws-policy is also provided in WebLogic, which requires programmers to associate the files used by the Ws-policy using @policy claims at development time, and the administrator cannot associate Ws-policy files with the console configuration. However, you can associate other files that are related to Ws-policy. Documentation for WS-POLICY configuration in Weblogic 10: http://e-docs.bea.com/wls/docs100/ConsoleHelp/taskhelp/webservices/ Configurewspolicyfile.html
CXFWebLogic Ws-policy support for the CXF open source framework, is not complete and comprehensive. CXF's Ws-policy framework provides an enabling CXF users and developers to use Ws-policy application architectures and APIs. The version of the CXF support specification is 1.5. The framework is made up of a
Core Operating Environment (
Core
)and allow developers to insert their own defined assertions.
APIComposed of.
Core operational environments ( core
)Get polices information from a source file (WSDL, external document) the implementation of the policy (policy) of the service, endpoint, operation, and the calculation of the message object through the monitoring of the operational state of the policies implemented by the interceptor for a particular message support validation of an alternative implementation strategy The operations of the CXF, such as fusion (merge) and normalization, are done based on Apache Neethi.
APIContains two main types of interfaces: Assertionbuilder and Policyinterceptorprovider.
AssertionbuilderThe concept of Assertionbuilder is derived from the Neethi, in order to not rely on the Axis object model, it makes some simple changes and extends some support for specific comparison operations and intersection operations defined by the domain. The implementation of Assertionbuilder is dynamically loaded and automatically registered in the Asserionbuilderregistry registry, which is the extension of the bus. Currently, CXF supports the following Assertionbuilder and assertion implementations: {http://schemas.xmlsoap.org/ws/2005/02/rm/policy}rmassertion {/HTTP/ www.w3.org/2007/01/addressing/metadata}addressing {Http://www.w3.org/2007/01/addressing/metadata} anonymousresponses {http://www.w3.org/2007/01/addressing/metadata}nonanonymousresponses {http://cxf.apache.org/ transports/http/configuration}client {Http://cxf.apache.org/transports/http/configuration}server The above types are based on common assertion implementations (primitiveassertion, Nestedprimitiveassertion, Jaxbassertion), and developers can parameterize or expand their own assertion.
PolicyinterceptorproviderThis API is used to automatically enable interceptors to support domain-defined assertions as required in a running environment, thereby simplifying the configuration of interceptors.
Publicinterface Policyinterceptorprovider extends Interceptorprovider {
Return the schema types of the asssertions so can be supported
Collection<qname> Getassertiontypes ()
}
Currently, CXF supports Policyinterceptorprovider to implement the following types of assertions
{Http://schemas.xmlsoap.org/ws/2005/02/rm/policy} Rmassertion
{Http://www.w3.org/2007/01/addressing/metadata} Addressing
{Http://www.w3.org/2007/01/addressing/metadata} Anonymousresponses
{Http://www.w3.org/2007/01/addressing/metadata} Nonanonymousresponses
In addition, the CXF framework provides an improved domain expression in the policy attachment (XML elements that describes the policy topic within the scope of the strategy)
CXF
in
Ws-policy
Examples of After installing CXF, there is a samples/ws-policy directory under the CXF directory, which can be compiled and executed according to the Readme.txt instructions. CXF configuration Ws-policy is relatively simple, the following is the paragraph of the configuration file Design policy: ... <cxf:bus> <cxf:features> <p: policies/> </cxf:features> </cxf:bus> <p:externalattachment location= "Addr-external.xml"/> ... The following is defined in the PolicyAttachment file Addr-external.xml: <attachments xmlns:wsp= "Http://www.w3.org/ns/ws-policy" XMLNS:WSA = "Http://www.w3.org/2005/08/addressing" > <wsp:PolicyAttachment> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:address>http://localhost:9000/Soapcontext/soapport</wsa:address> < /wsa:endpointreference> </wsp:AppliesTo> <wsp:Policy> <wsam:addressing xmlns:wsam= "Http://www.w3.org/2007/02/addressing/metadata" > <wsp:Policy/> </wsam:Addressing> </wsp:Policy> </wsp:PolicyAttachment> </attachments> It is important to note that the CXF example does not provide an example of developing the Ws-policy API. This is one of the drawbacks of open source tools. In the interest of special research friends, you can also look at CXF source code study, deepen the understanding of ws-policy.
