Part 1 of this series on the IBM WebSphere Application Server V7 Feature Pack for SCA, provided an introduction to open Service Component Architecture (SCA) concepts, and described objectives of the technology along with some of the key integration points that provide great value to WebSphere Application Server V7 users. This article introduces you to Web services policy sets, and explains how to configure SCA components to use them. These policy sets can be used to realize SCA quality of service assertions (intents) when Web services bindings are being used. Web services policy sets provide concrete policies that can be configured to guarantee these assertions.
An overview of policy sets
When using SCA components that are bound with Web services bindings, you can simplify the configuration of the Web services by grouping security and other Web services settings into policy sets. Policy sets are reusable units that you can create, copy, and share with other WebSphere Application Server components.
WebSphere Application Server V7 provides preconfigured policy sets made up of commonly used policies. The Feature Pack for SCA supports configuring these policy sets with SCA services using Web services bindings.
SCA services using Web services bindings can take advantage of a number of preconfigured policy sets that are part of WebSphere Application Server. Policy sets provide reusable quality of service configurations, which can be associated with the SCA Web services bindings defined in a composition unit. Policy sets can also be shared with other Web services deployed in the same cell.
The WebSphere Application Server administrative console supports attaching these policy sets to SCA services and references. The policy sets can be configured for a service provider, its endpoints, or operations. Likewise, you can also attach a policy set to a service reference, its endpoints, or operations. You can also simply attach policy sets to all services or references in an SCA composite.
An instance of a policy set consists of a collection of policies. For example, the WS-I RSP default policy set consists of instances of the WS-Security, WS-Addressing, and WS-ReliableMessaging policy types. A policy set is identified by a name that is unique across the cell.
These preconfigured policy sets can be used as a starting point and can be customized to your particular requirements. You can further customize the attached policy set by using bindings that are specific to your composition unit (application-specific bindings) or you can simply use general bindings. General bindings are global to the security domain and can be shared across applications and composition units.
For more information, see the Web services policy sets topic in the WebSphere Application Server Information Center.
Configure HelloWorld with a policy set
As an example, consider a preconfigured policy set that is configured with the Async HelloWorld Web Service Sample that is delivered with Feature Pack for SCA. Configure the sample as described in its associated readme file and then use a browser to verify that the sample works before continuing.
In the steps below, you will import the "WSSecurity default" policy set from the WebSphere Application Server default repository. This policy set provides message integrity through digital signature and message confidentiality through encryption. You will then attach the WSSecurity default policy set to the service providers and service references in the two composition units of the HelloWorld sample: helloworldws and helloworldwsclient.
From the WebSphere Application Server admin console, navigate to Services => Policy Sets => Application policy sets. Click on Import, and select From Default Repository... (Figure 1).
Figure 1. Application policy sets
Scroll down and check the box for the Username WSSecurity default policy set (Figure 2), then click OK at the bottom of the panel.
Figure 2. Import from default repository
Navigate to the myhelloWorld business-level application and go to the helloworld composition unit (Figure 3). Select Service provider policy sets and bindings from the Additional Properties list on the right.
Figure 3. helloworld composition unit
Select the HelloWorldService checkbox and click the Attach button. From the pull-down menu that displays (Figure 4), click the WSSecurity default policy set.
Figure 4. Service provider policy sets and bindings
Return to the composition unit panel (Figure 3) and repeat the same steps to configure the reference. Click on References policy sets and bindings from the Additional Properties list on the right. Select the HelloWorldCallbackService checkbox (Figure 5), then click Attach. From the pull down menu that displays, select the WSSecurity default policy set.
Figure 5. References policy sets and bindings
You have now attached the WSSecurity default policy set to the Web service reference and provider in the helloworldws composition unit.
Navigate to the second composition unit, helloworldclient (Figure 6).
Figure 6. helloworldclient composition unit
Use the Service provider policy sets and bindings and References policy sets and bindings links to attach the WSSecurity default policy set, just as you did for the helloworld composition unit. When these steps are complete, both the HelloWorldCallbackService service provider and the HelloWorldCallbackService reference should have the WSSecurity default policy set attached.
If you were to select the first resource in the table, helloworldws, you would be attaching the policy set to all of the service references in this composition unit. This would be a more interesting option had the helloworldws been configured with a number of service references.
Use the console’s Save option to write the changes to your configuration.
Navigate to the business-level applications collection, then stop and restart both myhelloWorld and myhelloWorldClient business-level applications (Figure 7).
Figure 7. Business-level applications
You can now run the HelloWorld sample, as described in its associated readme file.
By configuring a policy set for the services and references in the sample, you were able to change the security behavior of the services without making any changes to the business logic.
Before the policy set was configured, the messages flowing between the HelloWorldCallbackService and HelloWorldService services were not protected in any way. Now they are protected by the policies defined by the WSSecurity default policy set. The messages are signed and time-stamped, assuring that data is consistent and correct. The messages are also encrypted, assuring confidentiality. Of course, there are more policy set configuration capabilities that are not covered here. One of interest is the policy set replace operation. Navigate to Application policy sets => WSSecurity default => Attached deployed assets to see learn how it works.
- More in this series
- Managing policy sets using the administrative console
- Defining and managing policy set bindings
- Web services policy sets
- Defining and managing service client or provider bindings
- WebSphere Application Server V7 Information Center
- IBM developerWorks WebSphere
- Wikipedia: Service component architecture definition
- WebSphere Application Server V7.0 Feature Pack for Service Component Architecture product information
- Roadmap for WebSphere Application Server V7.0 Feature Pack for Service Component Architecture V1.0
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.