The various modules in the Module combo box represent Axis2 modules that implement various WS-*. Let’s say we’re interested in WS-Security. To enable this, we simply pick rampart from the list, as shown in Figure 9. Click the Engage button, and just like that WSAS will activate its WS-Security module for your service, as shown in Figure 10. Similarly, you can pick sandesha from the Module list and WSAS will enable WS-Reliable Messaging for your service. Let’s take a look at some of the security options we have available to us.

Security Configuration
Let’s go back to our Service listing (Figure 7) and this time click the Security Configuration link. This will bring up the interface shown in Figure 11. What is this list you see here? This list represents 11 different pre-set security configurations included with WSAS. These 11 configurations represent the most common scenarios for securing a Web Service. Whatever your security requirements are, it’s probably covered by one of them. Enabling any of them is trivial, just pick its radio button and continue. For example, let’s say we pick the “Sign and encrypt - TripleDES/RSA15 – DK” option then we’ll bring up the interface shown in Figure 12.

Notice that WSAS already has both a trusted certificate store and a keystore location provided to support encryption. The Management Console has a Keystore tab (on the left) that you can use to manage certificates and providers. Once you apply the security configuration, you can go back to the list of services and click on the Policy, as shown in Figure 13.

This will bring up the Policy, shown in Listing 3. The Policy is an extensible way to configure any/all of the WS-* technologies you have enabled for your service. Where did this Policy come from? It was generated by WSAS for you when you selected the Security Configuration. You can still manually edit this file either to tweak security or to configure your WS-Reliable Messaging policy.

Summary
In this article we’ve started with an Axis service, and very easily redeployed it to WSAS. All we needed was its WSDD deployment descriptor and a JAR of all its classes. We saw how WSAS made sure to maintain backwards compatibility with the original service, even though the original service used the deprecated RPC-encoding format. Once we brought our service into WSAS, we could easily enable WS-Security and WS-Reliable Messaging. Finally, WSAS made it especially easy to pick a powerful Security Configuration, automatically managing the Policy for us.

Resources

• Take a look at the WS-RM specification from the developerWorks library.
• Learn about the benefits of WS-Security in the developerWorks article Implementing WS-Security.
  
• WSAS enables WS-Addressing automatically. Learn how important this is in the developerWorks article The hidden impact of WS-Addressing on SOAP.
  
• Read about the Axis2 module system in the developerWorks article Web Services and Axis2 architecture.
  
• Explore the benefits of using a StAX processor in the developerWorks article StAX’ing up XML, Part 1: An introduction to Streaming API for XML.
  
• Keystores are integral part to your security. Learn all about them in the developerWorks article Unshackling key management in Java security.
• You’re going to want to download WSO2 WSAS.
• Read about the latest features in WSO2 WSAS 2.0.
  
• Learn from and interact with the WSO2 community on the WSAS Wiki.
  
• Learn about exposing your services as Web Services easily with Axis2.
  
• Learn how Axis2 can enable your SOA designs in the developerWorks article SOA with Axis2.