Using Validator for WS-Policy in Eclipse with IBM WebSphere Application Server

Validator for WS-Policy in Eclipse is a plugin that helps troubleshoot WS-Policy issues. Learn how to use it to debug a problem with some WS-Policy used by IBM WebSphere Application Server. Also find out how to create your own schemas to use the validator with other WS-Policy assertions.

Matthew Wilson (matthew.wilson@uk.ibm.com), Software Engineer, CICS TS Development, IBM

Matthew WilsonMatthew Wilson is a software engineer at IBM Hursley. He works in the Architecture Enhancements development team for CICS Transaction Server. He joined IBM in 2008 after graduating from the University of Southampton with a Master of Engineering degree in Computer Science with Distributed Systems and Networks. He developed Validator for WS-Policy in Eclipse as a Hursley Blue Opportunity project.



Katherine Sanders (katherine_sanders@uk.ibm.com), IBM Software Services for WebSphere, IBM

Katherine Sanders Katherine Sanders is a consultant working in IBM Software Group's EMEA Laboratory Services in Hursley, UK. She previously developed and tested Web services functionality in WebSphere Application Server, with a particular focus on WS-Addressing, WS-ReliableMessaging and WS-Notification. She holds a Bachelor of Science degree in Computer Science from the University of Nottingham. She developed Validator for WS-Policy in Eclipse as a Hursley Blue Opportunity project.



02 September 2011

Also available in Chinese Japanese

Using the Validator for WS-Policy in Eclipse

This section of the article will illustrate how the Validator for WS-Policy in Eclipse can be used to debug errors caused by invalid WS-Policy. It uses the sample application included with the article. It also uses IBM® Rational® Application Developer 8.0.2 and IBM WebSphere® Application Server 7.0.0.17.


Setting up IBM WebSphere Application Server and IBM Rational Application Developer

A server must be created in IBM Rational Application Developer to identify the runtime environment that will be used when testing project resources. This creates a pointer from the workbench to an existing installation of an application server or server profile. In this article, the IBM WebSphere Application Server 7.0.0.17 installation will be used as the application server for the sample application. However, before the server can be created, a suitable Server Runtime Environment and IBM WebSphere Application Profile must also be created if they do not already exist. Finally, the Server must be started so it is ready to install and start the application.

  1. Launch IBM Rational Application Developer 8.0.2 with a new workspace
  2. Close the Welcome page. You should now be in the Java™ EE perspective.
  3. Create a Server Runtime Environment by selecting Window > Preferences
  4. Server / Runtime Environments > Add
Figure 1. Add a Server Runtime Environment
Add a Server Runtime Environment
  1. Select "WebSphere Application Server v7.0" > Next
Figure 2. Select the type of Runtime Environment
Select the type of Runtime Environment
  1. Name = "WebSphere Application Server v7.0.0.17", Installation directory = <WAS_HOME> (e.g. C:\Program Files\IBM\WebSphere\AppServer) > Finish
Figure 3. Specify the IBM WebSphere Application Server installation directory
Specify the IBM WebSphere Application Server installation directory
  1. Create an IBM WebSphere Application Server Profile by selecting Window > Preferences
  2. Server / WebSphere Application Server > Run Profile Management Tool
Figure 4. Run Profile Management Tool
Run Profile Management Tool
  1. Once the Profile Management Tool has opened, click Launch Profile Management Tool
Figure 5. Launch Profile Management Tool
Launch Profile Management Tool
  1. Click Create...
Figure 6. Create a new profile
Create a new profile
  1. Ensure "Application Server" is selected > Next
Figure 7. Specify the type of environment to create
Specify the type of environment to create
  1. Ensure "Typical profile creation" is selected > Next
Figure 8. Choose the typical profile creation process
Choose the typical profile creation process
  1. Deselect the "Enable administrative security" checkbox > Next
Figure 9. Disable administrative security
Disable administrative security
  1. Review the profile details > Next
Figure 10. Review the profile creation summary
Review the profile creation summary
  1. Once the profile has been created, deselect the "Launch the First steps console." checkbox > Finish
Figure 11. Finish the profile creation wizard
Finish the profile creation wizard
  1. Close the Profile Management Tool
  2. Observe that the new profile is now listed in the bottom panel. Click OK to close the Preferences Window.

Create a Server and start it

  1. Servers tab > right click > New > Server
Figure 12. Create a new Server
Create a new Server
  1. Select "WebSphere Application Server v7.0" > Next
Figure 13. Select the server type
Select the server type
  1. Ensure the name of the profile you just created is selected > Finish
Figure 14. IBM WebSphere Application Server settings
IBM WebSphere Application Server settings
  1. Servers tab > right click "WebSphere Application Server v7.0.0.17 at localhost" > Start
Figure 15. Start the server
Start the server

Importing and running the sample application

The sample application uses a Policy Set that is not installed in IBM WebSphere Application Server and IBM Rational Application Developer by default, so it must be imported into both of them first. Then the sample application EAR file can be imported into the IBM Rational Application Developer workspace and started on the Server that was created in the previous section. Once the application is running, it can be used to send a synchronous web service request. However, an exception will occur instead of a successful response message because the WS-Policy in the sample application is invalid.

  1. Import the provider policy set required by the sample application into IBM WebSphere Application Server by selecting Servers tab > right click "WebSphere Application Server v7.0.0.17 at localhost" > Administration > Run Administrative Console...
Figure 16. Run the Administrative Console
Run the Administrative Console
  1. Administrative Console > Services / Policy Sets / Application Policy Sets > Import... > From default repository...
Figure 17. Import a Policy Set
Import a Policy Set
  1. Scroll to the bottom of the page and click the arrow to move to page 2
  2. Check the box next to "WS-Security default" > OK > Save
Figure 18. Select the WS-Security default Policy Set
Select the WS-Security default Policy Set
  1. Logout and close the Administrative Console
  2. Import the provider policy set required by the sample application into IBM Rational Application Developer and download the WSSecurity default.zip file included with this article
  3. Right click in the Enterprise Explorer view > Import > Import...
Figure 19. Open the import wizard
Open the import wizard
  1. Web services / WebSphere Policy Sets > Next
Figure 20. Import a Policy Set
Import a Policy Set
  1. Browse for the file you downloaded > Finish
Figure 21. Import the downloaded Policy Set
Import the downloaded Policy Set
  1. Import the broken sample application and download the InvalidPolicy.ear file included with this article
  2. Right click in the Enterprise Explorer > Import > EAR File
Figure 22. Import an EAR file
Import an EAR file
  1. Browse for the file you downloaded, confirm the target runtime = "WebSphere Application Server v7.0.0.17" > Finish
Figure 23. Import the downloaded EAR file
Import the downloaded EAR file
  1. Note that the sample application compiles without errors using the default plugins that come with IBM Rational Application Developer
Figure 24. Imported sample application compiles without errors
Imported sample application compiles without errors
  1. Run the broken sample application and select Servers tab > right click "WebSphere Application Server v7.0.0.17 at localhost" > Add and Remove...
Figure 25. Open the Add and Remove wizard
Open the Add and Remove wizard
  1. Select InvalidPolicy in the Available column > Add > Finish
Figure 26. Add the broken sample application
Add the broken sample application
  1. Once the application has successfully published, observe that the server status has changed to [Started, Synchronized]
Figure 27. Check the server status
Check the server status
  1. Open a web browser and navigate to http://<WAS_HOST>:<WAS_PORT>/wssamplesei/demo e.g. http://localhost:9080/wssamplesei/demo
  2. Select Message Type = Synchronous Echo, Message String = hello > Send Message. An exception will occur.
Figure 28. Invoke the broke sample application Web service
Invoke the broke sample application Web service

Analyzing the errors and locating the invalid WS-Policy

When an error occurs in the Server Runtime Environment, the error logs are displayed in the console view in IBM Rational Application Developer. In this case there will be an error indicating a problem in the WS-Security configuration on the client, and it will be determined that the client is configured using the WS-Policy in the provider WSDL document.

  1. Look at the console in IBM Rational Application Developer and observe the following messages:
Listing 1. Errors after running the broken sample application
[23/05/11 14:40:12:906 BST] 0000001f SystemOut     O >> CLIENT: ERROR: SEI Echo EXCEPTION.
[23/05/11 14:40:12:906 BST] 0000001f SystemErr     R javax.xml.ws.WebServiceException:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS5400E: algorithm attribute is
required but found:
com.ibm.ws.wssecurity.confimpl.PrivateCommonConfig$AlgorithmConfImpl(algorithm=[null],
type=[null], properties=[{}]).
  1. Observe that the errors are occurring on the client side while generating the policy set configuration:
Listing 2. Errors stack trace
[23/05/11 14:40:12:921 BST] 0000001f SystemErr     R 	at
com.ibm.ws.wspolicy.runtime.handler.ClientWSPolicyHandlerImpl.
generatePolicySetConfigurations(ClientWSPolicyHandlerImpl.java:282)
  1. Observe that the Web services client is configured to use the provider policy
  2. Select Services view > JAX-WS/Clients/SampleClientSei: {http://com/ibm/was/wssample/sei/echo/}EchoService > Manage Policy Set Attachment...
Figure 29. Manage client Policy Set attachments
Manage client Policy Set attachments
  1. Observe that all services are set to "Acquire Provider Policy"
Figure 30. View the policy acquisition for each service
View the policy acquisition for each service
  1. Click "Use Provider Policy..." and observe that the policy is acquired using HTTP GET from the default WSDL URL
  2. Cancel both windows
Figure 31. View the provider policy WSDL URL
View the provider policy WSDL URL
  1. Locate the provider WSDL file containing the provider policy and navigate to http://<WAS_HOST>:<WAS_PORT>/WSSampleSei/EchoService?wsdl e.g. http://localhost:9080/WSSampleSei/EchoService?wsdl
  2. Note that the URL redirects to http://<WAS_HOST>:<WAS_PORT>/WSSampleSei/EchoService/WEB-INF/wsdl/Echo.wsdl because the WSDL being used is the one packaged in the provider WAR (InvalidPolicy/SampleServicesSei/WebContent/WEB-INF/wsdl/Echo.wsdl)
Figure 32. Locate the Echo.wsdl file
Locate the Echo.wsdl file

Installing the Validator for WS-Policy in Eclipse plug-in

Since it has been established that there is a problem with the WS-Policy in the provider WSDL document, and none of the existing validators in Eclipse have found the cause, the Validator for WS-Policy in Eclipse plug-in will be installed. This will be done using the standard update mechanism used by other Eclipse plug-ins.

  1. Download VWPE.zip, the Zip file containing Validator for WS-Policy in Eclipse 1.0, from alphaWorks
  2. Expand VWPE.zip to a local directory to create a local update site in the specified directory
  3. Help > Install New Software...
  4. Click Add...
Figure 33. Add a new repository
Add a new repository
  1. Click Local... and choose the VWPE directory that was extracted earlier
Figure 34. Choose the VWPE directory
Choose the VWPE directory
  1. Enter the Name VWPE and click OK.
  2. Select the Validator for WS-Policy in Eclipse plug-in and click Next
Figure 35. Select the plug-in to install
Select the plug-in to install
  1. Review the install details and click Next
Figure 36. Review the items to be installed
Review the items to be installed
  1. Review the license, accept it and click Finish
Figure 37. Review the license
Review the license
  1. Click OK to ignore the security warning
Figure 38. Ignore the security warning
Ignore the security warning
  1. Once the install has finished, click Restart Now to restart IBM Rational Application Developer with the new plug-in.
Figure 39. Restart IBM Rational Application Developer
Restart IBM Rational Application Developer

Configuring the Validator for WS-Policy in Eclipse

To verify that the plug-in has been installed correctly, the configuration should be reviewed to ensure that the validator is enabled and that it will run on WSDL documents.

  1. Once IBM Rational Application Developer has restarted go to Window > Preferences
  2. Validation > Ensure that WS-Policy validator is enabled (has a check in both the "Manual" and "Build" checkboxes)
Figure 40. Ensure that the WS-Policy validator is enabled
Ensure that the WS-Policy validator is enabled
  1. Click the "..." button next to "WS-Policy validator" to open the Settings
  2. Observe that WS-Policy Validator will run on all files with wsdl and xml extensions. Click Cancel.
Figure 41. File types used by the validator
File types used by the validator
  1. Validation / WS Policy Validator. Observe that this sub-page allows custom schema files to be used. By default, the schema directory is empty so the schemas supplied with the plug-in are used. There are more details about this in the "Test the schema" section below.
Figure 42. WS Policy Validator schema directory
WS Policy Validator schema directory

Validating the invalid WS-Policy from the broken sample application

All the files in the project will be validated and a single WS-Policy error will occur in the provider WSDL document that was identified as the source of the client configuration error earlier. A marker will identify the specific WS-Policy assertion that is invalid, and the error message will make it clear that an assertion is missing. The error will be resolved by adding the missing assertion, using the specification and provider configuration for guidance.

Figure 43. Validate the WS-Policy
Validate the WS-Policy
  1. Click OK to close the Validation Results dialog when the Validation finishes
Figure 44. Validation results
Validation results
  1. Observe that a new Invalid WS-Policy error has appeared in the Markers tab. The error says that the AlgorithmSuite assertion must occur at least 1 time.
Figure 45. Invalid WS-Policy error in the Markers tab
Invalid WS-Policy error in the Markers tab
  1. Double click on the error and the InvalidPolicy/SampleServicesSei/WebContent/WEB-INF/wsdl/Echo.wsdl file will open with the relevant line highlighted. Note that this is the same file we identified above. It contains the WS-Policy published by the Web services provider and the client is using the provider policy to configure itself.
  2. Observe that the error is inside an AsymmetricBinding assertion
Figure 46. Invalid AsymmetricBinding assertion
Invalid AsymmetricBinding assertion
  1. Observe the syntax for the AsymmetricBinding assertion in the WS-Security Policy 1.2 specification. As the error indicates, the AlgorithmSuite is mandatory and it is missing:
Listing 3. AsymmetricBinding assertion syntax
<sp:AsymmetricBinding xmlns:sp="..." ... >
 <wsp:Policy xmlns:wsp="...">
 (
 <sp:InitiatorToken>
 <wsp:Policy> ... </wsp:Policy>
</sp:InitiatorToken>
    ) | (
     <sp:InitiatorSignatureToken>
       <wsp:Policy> ... </wsp:Policy>
     </sp:InitiatorSignatureToken>
     <sp:InitiatorEncryptionToken>
       <wsp:Policy> ... </wsp:Policy>
     </sp:InitiatorEncryptionToken>
    )
    (
     <sp:RecipientToken>
       <wsp:Policy> ... </wsp:Policy>
     </sp:RecipientToken>
    ) | (
     <sp:RecipientSignatureToken>
       <wsp:Policy> ... </wsp:Policy>
     </sp:RecipientSignatureToken>
     <sp:RecipientEncryptionToken>
       <wsp:Policy> ... </wsp:Policy>
     </sp:RecipientEncryptionToken>
    )
    <sp:AlgorithmSuite ... => ... </sp:AlgorithmSuite>
    <sp:Layout ... => ... </sp:Layout> ?
    <sp:IncludeTimestamp ... /> ?
    <sp:EncryptBeforeSigning ... /> ?
    <sp:EncryptSignature ... /> ?
    <sp:ProtectTokens ... /> ?
    <sp:OnlySignEntireHeadersAndBody ... /> ?
    ...
  </wsp:Policy>
  ...
</sp:AsymmetricBinding>
  1. Observe the syntax for the AlgorithmSuite Assertion:
Listing 4. AlgorithmSuite Assertion syntax
<sp:AlgorithmSuite xmlns:sp="..." ... >
 <wsp:Policy xmlns:wsp="...">
 (<sp:Basic256 ... /> |
 <sp:Basic192 ... /> |
 <sp:Basic128 ... /> |
 <sp:TripleDes ... /> |
 <sp:Basic256Rsa15 ... /> |
 <sp:Basic192Rsa15 ... /> |
 <sp:Basic128Rsa15 ... /> |
 <sp:TripleDesRsa15 ... /> |
 <sp:Basic256Sha256 ... /> |
 <sp:Basic192Sha256 ... /> |
 <sp:Basic128Sha256 ... /> |
 <sp:TripleDesSha256 ... /> |
 <sp:Basic256Sha256Rsa15 ... /> |
 <sp:Basic192Sha256Rsa15 ... /> |
 <sp:Basic128Sha256Rsa15 ... /> |
 <sp:TripleDesSha256Rsa15 ... /> |
 ...)
 <sp:InclusiveC14N ... /> ?
 <sp:SOAPNormalization10 ... /> ?
 <sp:STRTransform10 ... /> ?
 (<sp:XPath10 ... /> |
 <sp:XPathFilter20 ... /> |
 <sp:AbsXPath ... /> |
 ...)?
 ...
</wsp:Policy>
 ...
</sp:AlgorithmSuite>
  1. Servers tab > right click "WebSphere Application Server v7.0.0.17 at localhost" > Administration > Run Administrative Console...
  2. Services / Policy sets / Application policy sets > WS-Security default
Figure 47. WS-Security default policies
WS-Security default policies
  1. Click WS-Security
Figure 48. WS-Security policy
WS-Security policy
  1. Click Main Policy
Figure 49. Main policy
Main policy
  1. Click Algorithms for asymmetric tokens. Observe that the provider is using Basic128Rsa15.
Figure 50. Algorithms
Algorithms
  1. Log out and close the Administrative Console
  2. Add the following WS-Policy assertion to Echo.wsdl to use the Basic128Rsa15 algorithm (inside the AsymmetricBinding/Policy assertion above the Layout assertion):
Listing 5. Algorithm Suite policy for the sample application
<ns2:AlgorithmSuite>
 <wsp:Policy>
 <ns2:Basic128Rsa15 />
 </wsp:Policy>
</ns2:AlgorithmSuite>
  1. Save the changes and observe that the Invalid WS-Policy error disappears.

Rerun the modified sample application

The Server must be restarted for the WS-Policy changes to take effect on the client configuration. Once the application is running again, another synchronous Web service request will be sent, and this time a successful response message will be received. The WS-Security configuration error will no longer occur in the console logs.

  1. Servers tab > right click "WebSphere Application Server v7.0.0.17 at localhost" > Restart. This ensures that the client policy set configuration is recreated instead of using a cached copy of the previous invalid configuration.
Figure 51. Restart the server
Restart the server
  1. Navigate to http://<WAS_HOST>:<WAS_PORT>/WSSampleSei/EchoService?wsdl e.g. http://localhost:9080/WSSampleSei/EchoService?wsdl and ensure that the WSDL has refreshed and the AlgorithmSuite assertion is present
  2. Navigate to http://<WAS_HOST>:<WAS_PORT>/wssamplesei/demo e.g. http://localhost:9080/wssamplesei/demo
  3. Select Message Type = Synchronous Echo, Message String = hello > Send Message
  4. The response returns successfully and the string hello is returned
Figure 52. Invoke the modified sample application Web service
Invoke the modified sample application Web service
  1. Observe that the error no longer occurs in the console logs

Summary

The sample application contains invalid WS-Policy in the provider WSDL document. Since the client was configured to read the WS-Policy and use it to configure the client's WS-Security settings, the Web service invoke failed.

To debug this failure, the logs in the console were inspected for errors. An error was present that indicated the problem was in the client policy set configuration. The client was configured to use the provider policy from the WSDL document which meant the WS-Policy was potentially invalid.

The Validator for WS-Policy in Eclipse plug-in was installed and all the files in the project were validated. The only error was in the provider's WSDL file, and it indicated there was a missing AlgorithmSuite assertion. When the file was opened, the error marker also indicated the AlgorithmSuite assertion was missing from inside the Assymmetric binding assertion.

The error was fixed by adding the AlgortithmSuite assertion that corresponded with the provider's configuration. There is also documentation supplied with the plug-in that has examples of more WS-Policy validation errors and how to fix them.

The WS-Policy in the provider's WSDL document is over 100 lines long and none of the standard Eclipse validators were able to identify any errors in it. Also WS-Security Policy is very complex, so it would take a long time to validate ever assertion manually, and manual validation is error prone. Clearly, without the Validator for WS-Policy in Eclipse, this trivial error would have taken far more effort to resolve.


Creating your own schema

The Validator for WS-Policy in Eclipse is supplied with ready-made schemas for all WS-Policy assertions supported for IBM WebSphere Application Server 7.0. However, it can be extended with user-defined schemas for other specifications. For example, you may wish to include WS-Policy assertions in your WSDL for consumption by an endpoint on another platform. This section of the article will demonstrate how to construct a schema for use with Validator for WS-Policy in Eclipse for the WS-Eventing specification.

WS-Eventing describes a means for a Web service to register interest in events that occur in another Web service or application. It describes subscription managers that allow a service to manage its subscriptions about events. In order to indicate support for WS-Eventing, two WS-Policy assertions are specified. The presence of the EventSource assertion indicates that a service accepts requests to create subscriptions, while the SubscriptionManager assertion indicates that the service supports managing subscriptions on behalf of other services. Both assertions are relatively simple in their structure and therefore provide a convenient example to demonstrate how to create a schema. The format of schema files for the validator was designed so that it is a simple task to create from a formal specification. Therefore the format is largely based on the syntax conventions used in OASIS specifications such as WS-Security Policy. However, the validator does require some additional metadata to be added to the syntax information and imposes some restrictions in its structure. The schema file is divided into sections which begin with a heading in square brackets.

The first two of these sections concern the XML namespaces associated with the specification. The first is the [Namespaces] section. It lists the namespace prefixes to be used in the schema with the corresponding qualified namespaces, similar to the xmlns attribute in a basic XML document. Note that unlike xmlns, every namespace used must be declared and referred to by its prefix throughout the rest of the schema; use of fully-qualified assertions not supported. In the case of WS-Eventing, there is only one namespace we are concerned with, the WS-Eventing namespace, given in section 3.5 of the specification, for which we will use the wse prefix. We code the section as shown below.

Listing 6. The namespace section of the schema
[Namespaces]
<
	wse = "http://www.w3.org/2011/03/ws-evt"
>

We must also specify the versions of the WS-Policy specification supported by the specification in the [PolicyNamespaces] section. This allows the validator to verify that any WS-Policy embedded within assertions uses the correct version of the specification, and apply the correct validation to attributes of WS-Policy assertions (which differs between WS-Policy 1.2 and 1.5). The WS-Eventing specification only mentions WS-Policy 1.5, so we code the sections as follows.

Listing 7. The PolicyNamespace section of the schema
[PolicyNamespaces]
<
   "http://www.w3.org/ns/ws-policy"
>

The remainder of the schema concerns the assertions themselves. Each top-level assertion should be described in a separate [Syntax] section. The syntax for these sections is very similar to that used in Web services specifications, and can generally be easily adapted from those sections. For specifications where fragments of assertions are repeated within several top-levels assertions, such fragments can be included in [Referenced] sections. However, this is not necessary in the case of the WS-Eventing specification.

To create the [Syntax] section for the EventSource assertion we will first copy the syntax as shown in section 9.1 of the specification, reproduced below.

Listing 8. The syntax of the EventSource assertion as given in the specification
<wse:EventSource ...>
  <wse:FilterDialect URI="xs:anyURI" ...>
    xs:any*
  </wse:FilterDialect> * 
  <wse:FormatName URI="xs:anyURI" ...>
    
    xs:any*
  </wse:FormatName> * 
  <wse:DateTimeSupported .../> ?
  <wse:Expires min="xs:duration"? max="xs:duration"?.../> ? 
  <wse:EndToSupported .../> ?
  <wse:NotificationPolicy ...>
    xs:any
  </wse:NotificationPolicy> ?
  
  xs:any*
</wse:EventSource>

We then need to perform the following modifications for it to conform to the schema format supported by the validator:

  • Add the cardinality indicator ? after the <wse:EventSource ...> to say that the top-level assertion is not required in a policy. If we do not do this, the validator will expect to find this assertion in every policy it validates.
  • Move cardinality indicators so that they appear after opening tags rather than closing tags for <wse:FilterDialect>, <wse:FormatName> and <wse:NotificationPolicy>
  • Remove xs:any* from the body of the tags. By reading the description given in the specification we can see that they are intended to indicate element extensibility, so we replace them with ellipses...
  • Replace the xs:duration type given for the attributes of the Expires assertion as this is not supported by the validator. xs:unsignedLong would be an appropriate substitute.

This gives us the following.

Listing 9. The revised syntax of the EventSource assertion for inclusion in the schema
[Syntax]
<wse:EventSource ...>?
  <wse:FilterDialect URI="xs:anyURI" ...>*
  ...
  </wse:FilterDialect>  
  <wse:FormatName URI="xs:anyURI" ...>*
  ...
  </wse:FormatName>  
  <wse:DateTimeSupported .../> ?
  <wse:Expires min="xs:unsignedLong"? max="xs:unsignedLong"?.../> ? 
  <wse:EndToSupported .../> ?
  <wse:NotificationPolicy ...> ?
  ...
  </wse:NotificationPolicy> 
  ...
</wse:EventSource>

A [Syntax] section must also be created for the SubscriptionManager assertion, which is done by applying exactly the same rules as above. These rules are also generally applicable to schemas providing syntax details in this form. This completes our schema; the complete file is provided as a download with this article.

Testing the schema

Having crafted our schema for WS-Eventing, we'll now use IBM Rational Application Developer with Validator for WS-Policy in Eclipse installed to test it. The validator will by default use schema files distributed within the Eclipse plugin jar. In order to use your own schema files, you must configure the validator to point to a directory to read them from as follows:

  1. Window > Preferences
  2. Select WS-Policy Validator from the list.
  3. Click the browse button on the preference page to select a directory. Once selected, the validator will read all files with a .schema extension in the selected directory. Deleting the contents of the field will cause the validator to use the default location again.
  4. If you wish to add your own schema to those already provided with the validator, copy the .schema files distributed with the validator to the directory you configure. These can be extracted from schema folder in the plugin jar file.
  5. Restart IBM Rational Application Developer for the change to take affect.
Figure 53. Configuring the schema directory used by the validator
Configuring the schema directory used by the validator

Now we will create some WS-Policy to validate as follows:

  1. Switch to the Resource perspective.
  2. File > New... > Project
  3. Select General > Project in the New Project dialog. Click Next.
  4. Enter a project name and click Finish.
  5. File > New > File
  6. Select your project and enter a suitable file name e.g. policy.xml
  7. Add some policy to your file. The following should be sufficient:
Listing 10. Basic policy to test out the schema
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
xmlns:wse="http://www.w3.org/2011/03/ws-evt"
xmlns:test="http://www.ibm.com/websphere/policy/blueop/testing">
<wse:EventSource ...>
<wse:FormatName URI="...">
 <mex:Location
Type="wsdl:definitions"
 URI="http://example.com/Notif_WSDL_Metadata" />
</wse:FormatName>
</wse:EventSource>
</wsp:Policy>

If the schema is correct, no validation errors should occur. You will see a warning on the mex:Location element as this not part of the schema.

Figure 54. Correct validation of the WS-Eventing assertions
Correct validation of the WS-Eventing assertions

To ensure the validation is working, we can make our policy invalid by inserting two DateTimeSupported elements, which should give an error on one of them.

Figure 55. Validation error due to duplication DateTimeSupported assertion
Validation error due to duplication DateTimeSupported assertion

Troubleshooting

If validation results are not as expected, view the Eclipse error log (Window > Show View > General > Error Log). The schema parser will generate exceptions which should help you troubleshoot the problem. For example, if we had forgotten to change the xs:Duration attribute type we would see the following exception:

com.ibm.alphaworks.wspolicy.validator.SchemaParsingException: Unrecognised attribute key: duration

Figure 56. An exception generated by the schema parser
An exception generated by the schema parser

Downloads

DescriptionNameSize
Sample Policy SetWSSecurity_default.zip2KB
Sample ApplicationInvalidPolicy.ear598KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=753169
ArticleTitle=Using Validator for WS-Policy in Eclipse with IBM WebSphere Application Server
publish-date=09022011