Skip to main content

skip to main content

developerWorks  >  WebSphere | SOA and Web services  >

SOA run-time governance with WebSphere Service Registry and Repository and AmberPoint

developerWorks
Document options

Document options requiring JavaScript are not displayed

Sample code


Rate this page

Help us improve this content


Level: Introductory

Laura Olson (menkell@us.ibm.com), Certified Consulting IT Specialist, IBM
Nicholas Frank (nfrank@amberpoint.com), Senior Systems Engineer, AmberPoint

30 Jan 2008

Learn how to use WebSphere® Service Registry and Repository and AmberPoint™ to create a robust SOA run-time governance solution.

Introduction

SOA holds the promise of business agility and resilience through loose coupling, flexibility and interoperability. In order to realize the benefits this promise, you need to be able to do the following:

  • Effectively govern your SOA from all perspectives, from design-time to run-time.
  • Manage a service and its related artifacts throughout the service's life cycle, from inception to retirement.
  • Locate the artifacts based on classifications or other criteria and understand how the artifacts are related to each other.
  • Manage and enforce policies during design, change, and run-times.
  • Monitor and manage what is actually going on in your run-time environment.

These capabilities enable you to quickly and easily make decisions that affect your business. An effective run-time governance solution can help you answer the following:

  • What is the state of a service?
  • Do you have rogue services?
  • Who is using a service and what are its dependencies?
  • How effective is a service?
  • What is a service's performance?

A run-time governance solution can help ensure the health and well-being of a complex SOA environment and remedy unexpected conditions before they can impact system performance.

WebSphere Service Registry and Repository (Service Registry), IBM® Tivoli® Composite Application Manager for SOA (ITCAM for SOA), and an IBM ESB, such as WebSphere DataPower, are IBM's run-time governance solution. However, in today's SOA environments, IBM recognizes that its products must be built using standards that enable them to be easily plug- and playable in any environment.

Using Service Registry with AmberPoint SOA Management System (SMS) is an example of a complete SOA governance solution. In this article, we'll introduce an SOA run-time governance solution consisting of Service Registry and AmberPoint. We'll then configure the "out-of-box" integration between Service Registry and AmberPoint.



Back to top


What's needed in SOA run-time governance

An SOA run-time governance solution typically consists of a registry and repository, a run-time, and a management system. The registry and repository are where the service and policy artifacts, as well as metadata about those artifacts are stored. It provides full governance life cycle support for the artifacts. The run-time is where the work of governance is performed. For example, AmberPoint SOA Management System (SMS) might delegate management policies to its run-time agents, which execute those policies on the application components comprising the SOA system. The run-time provides message transformation, routing and security. The management system is the glue that holds everything together, from aggregating information from the various components of the run-time environment, to enforcing performance and availability thresholds. The management system also provides alerts when performance thresholds have been violated.

Figure 1 shows the components of an SOA run-time governance solution


Figure 1. Components of an SOA run-time governance solution
Figure 1. Components of an SOA run-time governance solution

Service Registry and and the SOA run-time governance solution

Service Registry is a robust, integrated registry and repository, where all the SOA artifacts and the metadata about those artifacts is stored and governed. It serves as the authoritative source for SOA artifacts throughout the life cycle from model to assemble, deploy, manage, and eventually retirement. Service Registry is optimized for the run-time environment to enable dynamic endpoint selection, retrieve policies and ensure the proper contracts are in place to invoke a service.

Service Registry provides governance of the SOA artifacts using a customizable state machine-driven life cycle, which is enforced by a validation framework. Different SOA artifacts require different life cycles. For example, a service's life cycle is different from that of a service contract. Figure 2 shows an example of a service life cycle.


Figure 2. Life cycle for a service
Figure 2. Life cycle for a service

Figure 3 shows an example of a contract life cycle.


Figure 3. Life cycle for a contract
Figure 3. Life cycle for a contract

Service Registry has a flexible data model that allows you to easily create custom entities to reflect your SOA artifact needs, such as modeling a service contract and the relationships with other entities in your Service Registry. Figure 4 shows a graph produced by Service Registry that shows the relationships for a contract called MySampleContract.


Figure 4. Sample Service Registry graph showing relationships
Figure 4. Sample Service Registry graph showing relationships

Service Registry provides visibility to the assets within the SOA artifacts, such as WSDL, XSD, WS-Policy, and SCA. It parses these artifacts into their logical constructs, such as services, port types, ports, operations, messages for WSDL documents, and complex type, simple type, element and attributes for XSD documents. This enables you to easily locate and reuse assets without knowing their physical file location.

We've just touched on a small subset of the capabilities that Service Registry provides an SOA run-time governance solution. For more information on Service Registry, see Resources.

AmberPoint run-time governance

AmberPoint provides run-time governance through a combination of SOA visibility and active policy enforcement.

Today's SOA composite applications are made up of many different protocols and a technologies. AmberPoint provides visibility and transaction tracking in these heterogeneous environments, including Java® and .NET®; SOAP, XML, JMS, REST, EJB and JDBC; application servers such as WebSphere Application Server; ESBs and hardware devices, such as WebSphere DataPower.

AmberPoint automatically discovers the SOA-based services, as well as the performance metrics associated those services. This helps your company prevent rogue services, which are services put into production outside of a design-time governance process. These services are often insecure and expose a company to significant risk.

The performance and service-level agreement metrics AmberPoint provides can be used to determine if the services are meeting business needs.

Transactions within a SOA-based application can disappear without a trace because of delays, failures and errors. With AmberPoint, you get end-to-end transaction tracking of your composite applications. This visibility reduces your problem resolution time when errors or faults do occur.

AmberPoint has an active policy enforcement engine that implements standards such as WS-Security and WS-Policy. AmberPoint policies can be used to secure and protect services and their valuable data. For example, you can protect endpoints with a policy for authentication against an LDAP, ActiveDirectory or identity management system, such as Tivoli Access Manager. AmberPoint contains a rich collection of security policies to reduce the burden on the SOA service developer and enable uniform distribution of security standards to your services.

Service Registry and AmberPoint working together

Service Registry and AmberPoint work together to give you complete run-time governance of your SOA. To do this, Service Registry provides the governance of the services, policies and contracts. It then socializes the services and policies associated with the service to AmberPoint. AmberPoint can then manage those services and enforce policies on the services. Once the service is managed by AmberPoint, AmberPoint collects metrics from the run-time environment and publishes those metrics back to Service Registry. These Service Registry metrics can be used by integration developers to make service selections, by business analysts when deciding on funding for services, or by a run-time environment to choose the service that is performing best at a given time.

AmberPoint can also discover rogue services and publish them to Service Registry. Service Registry can then decide what to do with the rogue services. For example, it can accept the rogue service as valid and place it under governance, or reject it and start the appropriate processes to remove the service from the environment.

Both Service Registry and AmberPoint come with a robust set of APIs to help you quickly and easily create custom solutions. For example, in less then a week, the authors built Service Registry policy forms that updated the AmberPoint run-time via the Service Registry custom notification APIs and AmberPoint WS-Policy importer APIs. At the same time, we implemented contract enforcement between a service consumer and a service provider using the Service Registry Web services APIs, which were invoked by the AmberPoint agent.

Service Registry and AmberPoint integrate through standard UDDI Version 3.02 APIs that are supported by both products.

In the following sections, we'll walk through the necessary steps for configuring Service Registry and AmberPoint. We'll publish an OrderService WSDL (provided for download with this article) to Service Registry, which will then publish the OrderService to the IBM UDDI registry. AmberPoint will discover the governed service in the UDDI registry and manage the service. The metrics AmberPoint gathers on the service will then be reflected back in Service Registry.



Back to top


Configure Service Registry UDDI synchronization

There are three ways you can configure the UDDI synchronization:

  • Modify the properties text file and load the properties with jacl scripts.
  • Use the Service Registry UDDI configuration wizard.
  • Edit the UDDI configuration using the Service Registry Web user interface's configuration perspective.

We'll use the configuration wizard to configure the UDDI properties. Then we'll use the Service Registry configuration perspective to configure the notification and validation properties required for the UDDI synchronization.

Step 1: Configure UDDI properties

For this sample configuration of the Service Registry and AmberPoint , we'll use IBM UDDI Registry, which is a part of WebSphere Application Server Network Deployment V6.1. We'll also leverage the AmberPoint tutorial applications, Bookmart and OrderService, which are included with AmberPoint SMS 6.0. You can find the EAR files, bookmart.ear and bookmartClient.earl, in the AmberPoint SMS installation file and directory: SMSJava.zip:\samples\applications\websphere. For more information about the AmberPoint sample tutorials, refer to the AmberPoint documentation. Note: An Amberpoint user ID and password are required to access the documentation.

To configure the UDDI synchronization using the UDDI configuration wizard complete the following steps:

  1. To run the UDDI synchronization configuration tool, enter the following command:
    <WSRR_INSTALL_ROOT>\admin\configureUDDI.bat
  2. Enter the host name and the SOAP port of your Service Registry, as shown in Figure 5, and click Continue.

    Figure 5. Enter the Service Registry host name and port


  3. In the next screen, as shown in Figure 6, do the following:
    • For UDDI synchronization, select Enabled.
    • The Scheduled interval time (in minutes) field specifies how often you want UDDI synchronization to occur. For this example, specify 10.
    • Leave the Publishing format set to the default of Technical Note 2.0.2.
    • The Overview URL specifies the location of the artifact you want to publish to UDDI. You can publish the document's original location, which is probably on an HTTP server somewhere, or you can publish the Service Registry URL for the artifact. We recommend publishing the Service Registry URL for the artifact, because a file living on a file system can easily be changed or moved without your knowledge. For this example, we'll use the Service Registry URL.
      • Select Use WSRR.
      • Select HTTP.
      • Specify the Host name.
      • Specify the Port.


      Figure 6. Specify UDDI synchronization details


  4. Service Registry can synchronize with multiple UDDI registries. We've configured a default UDDI registry for this example. To modify this configuration, do the following:
    1. Select the default UDDI node and click Edit.
    2. On the General Properties tab, shown in Figure 7, specify a UDDI inquiry URL and UDDI publishing URL.
    3. Check WSRR can write to UDDI.


    Figure 7. Enter the UDDI inquiry and publishing URLs


  5. Select the Security tab, shown in Figure 8, and do the following:
    • Select Auth Token, and enter aSecurity API URL.
    • Check Publish API secured.
    • If you enabled security on your registry, specify the Trust and Key store locations, and the Key file.
    • In the User information section, click Add.
    • Enter the username and password for publishing to your UDDI registry, and click OK.

      Note: If security is disabled, make sure that the Default user name for the UDDI node is the same as the username you enter here. To set the default user name for the UDDI node, do the following:

      • Log in to the WebSphere administrative console at http://yourhost:port/ibm/console.
      • Select UDDI => UDDI Nodes => Your UDDI NODE .
      • In the Default user name field, enter the user name you specified in the Service Registry UDDI configuration wizard. In our example, we used wasadmin. Then click OK, as shown in Figure 8.


      Figure 8. Default user name for the UDDI node


  6. Back on the Security tab, select the user ID you just created for the User ID for publishing to UDDI field, then click Test UDDI Connection..
  7. Click OK.

    Figure 9. Configure UDDI security


  8. Next you need to select the entities you want to move between Service Registry and the UDDI registry, as shown in Figure 10. For this example, you only need to move the WSDL documents.
    1. In the WSRR entity selection criteria section, click Add.
    2. Enter the following XPath expression: /WSRR/WSDLDocument
    3. Click OK.
    4. Click Apply this Configuration to WSRR.


    Figure 10. Select entities


You've now completed the UDDI properties configuration. Next you'll configure the notification properties.

Step 2: Configure notification properties

The UDDI notifier notifies the UDDI synchronization module when any create, update, delete, or any governance operation takes place in Service Registry. You need to register the UDDI notification class with Service Registry. We'll use Service Registry's configuration perspective to register the notifier.

  1. Open a browser to your Service Registry console. For example, http://yourhost:port/ServiceRegistry.
  2. From the perspective drop-down menu, select Configuration and click Go, as shown in Figure 11.

    Figure 11. Select Configuration


  3. In the left navigation, expand Plug-ins and select Notification Properties.
  4. Click on Notification properties plug-in (NotificationProperties).
  5. Comment out the line: notifiers=com.ibm.sr.api.ServiceRegistryNotiferJMS
  6. Uncomment the line: notifiers=com.ibm.sr.api.ServiceRegistryNotiferJMS, com.ibm.sr.uddi.notifier.WSRRNotifier
  7. Click Apply, and then Okay.

Step 3: Configure validation properties

The UDDI validator is needed to prevent accidental deletion of objects in Service Registry that store details of the mappings between Service Registry and UDDI entities. You need to register the UDDI validation class with Service Registry. We'll use Service Registry's configuration perspective to register the validator.

  1. Open a browser to the Service Registry console. For example, http://yourhost:port/ServiceRegistry.
  2. From the perspective drop-down menu, select Configuration and click Go.
  3. In the left navigation, expand Plug-ins and select Validation Properties.
  4. Append ,com.ibm.sr.uddi.validator.UDDIImgValidator to the validator property as shown below: 
    validators=com.ibm.sr.api.SRTemplateValidator,com.ibm.sr.api.SRBusinessModelValidator,
com.ibm.sr.governance.validator.GovernancePolicyValidator,
com.ibm.sr.uddi.validator.UDDIImgValidator

  5. Click Apply, and then Okay.

Step 4: Verify Service Registry and UDDI synchronization

Now that you've configured the UDDI notification and validation properties, you can verify the synchronization between Service Registry and the UDDI registry. To do that, complete the following steps:

  1. Log on to Service Registry console by point your browser to http://yourhost:port/ServiceRegistry.
  2. In the Load Documents dialog, as shown in Figure 12, do the following:
    • Select Local file system.
    • Click Browse and select OrderService.wsdl.
    • Select WSDL for the Document type.
    • Optionally, specify a document description and document version.
    • Click OK.

      Figure 12. Load OrderService.wsdl


  3. On the next screen, click Finish.

Since you set the synchronization interval to ten minutes, you may have to wait the full ten minutes to see the OrderService.wsdl appear in the UDDI registry. All documents published from Service Registry to UDDI will belong to the WSRRBusinessEntity business. Figure 13 shows the OrderService.wsdl in the IBM UDDI registry.


Figure 13. The OrderService published to the IBM UDDI registry

Next we'll add a general_keywords categorization to the OrderService service in the IBM UDDI registry and see it synchronized to Service Registry. To add a property to the OrderService service, follow these steps:

  1. From the Publish tab of the IBM UDDI Registry console, select Show owned entities.
  2. Select Show services to find the OrderService on the WSRRBusinessEntity.
  3. Select Edit for the OrderService.
  4. In the Categorization section, select categorization:general_keywords from the drop-down menu.
  5. Enter FROMUDDI in the Key Name Field, as shown in Figure 14.
  6. Enter Verification Test in the Key Value Field
  7. Click Add Categorization.

    Figure 14. Add a general_keywords categorization


  8. Click Update Service.

Again you may have to wait the full ten minutes to see the property appear on the OrderService service in the ServiceRegistry. Navigate to the OrderService service entity in Service Registry by selecting Service Metadata => WSDL => Services => OrderService => properties.

As you can see in Figure 15, the categorization FROMUDDI that we added to the OrderServer service in the IBM UDDI registry has now been synchronizated to the ServiceRegistry's OrderService service properties.


Figure 15. Verification that the property added in UDDI appears in Service Registry

We tested integration between Service Registry and the UDDI registry by publishing the OrderService.wsdl to Service Registry, which synchronized it to the UDDI registry. We then tested that the changes made in the UDDI are reflected in Service Registry. Next we'll configure the AmberPoint integration to the UDDI registry to allow AmberPoint to discover and manage the governed OrderService.wsdl.



Back to top


Configure AmberPoint

Once you have finished setting up the AmberPoint management server, you can register a UDDI registry. We'll use the username "wsadmin" for for publishing. We'll assume that the wasadmin user name is entitled to publish business entities to the UDDI registry.

Step 1: Set up UDDI business entity and capture business entity key

If you have already setup a UDDI business entity for publication you can skip the creation step and capture the business entity key later.

  1. Log in to the WebSphere UDDI UI at http://localhost:9080/uddigui/.
  2. Click on the Publish tab. You'll be prompted for an ID, such as "wasadmin". That ID is used by AmberPoint when registering the UDDI registry.
  3. Enter the name of the new business entity APBiz in Name field, as shown in Figure 16. Click Add Name and then click Publish Business.

    Figure 16. Set up business entity


  4. Record the business entity key for later and note the owner of the business entity (wasadmin), as shown in Figure 17.

    Figure 17. Review and record the business entity key


Step 2: Register the UDDI registry in AmberPoint

  1. Log in to the AmberPoint SOA Management System (SMS) console.
  2. Click the Network tab, then the Infrastructure tab and select Register => UDDI Service, as shown in Figure 18.

    Figure 18. Register UDDI registry within AmberPoint


  3. In the Service WSDL URL field, enter the appropriate URL for the UDDI inquiry port's WSDL for your environment. For example:
    http://nfrank-laptop:9080/uddiv3soap/services/UDDI_Inquiry_Port?wsdl
    Then click Next.

    Figure 19. Register UDDI using Inquiry Port WSDL


  4. On the next screen, specify an optional service version or change the inquiry service name, then click Next.
  5. When the UDDI_Inquiry_Service port is completely set up, click Edit Synchronization to configure AmberPoint's synchronization with the registry.
  6. In the Set up Synchronization dialog, shown in Figure 20, do the following. (For more information on these settings, refer to the AmberPoint product help.)
    • Check Discover from UDDI to register services from the registry with AmberPoint.
    • Check Publish to UDDI to publish services, performance metrics and policies to the registry from AmberPoint.
    • The Synchronization Interval specifies the number of seconds between UDDI synchronizations. Leave the default of 86400, which is the number of seconds in a day.
    • In the Business Entity Key (for Publish) field, enter the business entity key for APBiz. For example:
      (uddi:nfrank-laptopcell01:nfrank-laptopnode01:sms:keyspace_id:94bb4694-7d4e-4ed8-87b8-e92631e9b847)
    • Enter wsadmin for the UDDI Username, which is the ID that owns the business entity used for publication.
    • Enter the password for wsadmin for UDDI Password.


    Figure 20. Set up UDDI Synchronization


Step 3: Verify that AmberPoint is synchronizing with Service Registry

After you've configured the UDDI registry, you'll see the UDDI Inquiry Service dialog, as shown in Figure 21. Here you can see the discovery details and force a discovery or publication. If nothing is discovered or published, it may mean you have no services registered or under management in AmberPoint or the UDDI registry.


Figure 21. UDDI inquiry status

  1. You can view the services in the IBM UDDI Registry, as shown in Figure 22, by doing the following:
    1. Point your browser to http://localhost:9080/uddigui/.
    2. Click on the Publish tab.
    3. Select Show owned entities.
    4. Find APBiz under Registered Businesses and select Show services.


    Figure 22. UDDI services under APBiz and WSRRBusinessEntity link


  2. Now drill down and find Policies and Metrics for the services by clicking OrderService, as shown in Figure 23.

    Figure 23. AmberPoint Logging policy applied to the OrderService


    Figure 24 shows the performance metrics that AmberPoint has captured for the OrderService and published to the Service Registry through UDDI. In the next section. we'll verify these metrics in the Service Registry.



    Figure 24. Performance Metrics on the OrderService




Back to top


Verify the integration between Service Registry and Amberpoint

To verify that the metrics gathered from AmberPoint appear on the OrderService in Service Registry, navigate to the OrderService service entity in Service Registry by selecting Service Metadata => WSDL => Services => OrderService => properties.

Figure 25 show the performance metrics that AmberPoint has captured for the OrderService and published to the Service Registry.


Figure 25. Performance metrics for the OrderService service in Service Registry

These metrics in Service Registry are now available for use by integration developers in making service selections, by business analysts when deciding on funding for services, or by run-time environments to choose the service that is performing best at a given time.

In this view, you can also verify that the rogue services discovered by AmberPoint are in now in Service Registry and ready to be governed.



Back to top


Summary

In this article, we introduced the concept of SOA run-time governance, and described a solution for SOA run-time governance that includes WebSphere Service Registry and Repository and AmberPoint. You learned the steps for configuring integration between Service Registry and AmberPoint.

Once you've configured your SOA run-time governance solution, you can quickly and easily make business decisions. You can locate SOA artifacts and understand how these artifacts are related to each other, you can manage and enforce policies throughout the services life cycle, and you can monitor and manage what is actually going on in your run-time environment. You now have the tools to answer these questions, among others: What is the state of a service? Are there any rogue services? Who is using a service and what are the service dependencies? How effective is a service? What is the service's performance?




Back to top


Download

DescriptionNameSizeDownload method
WSDLOrderService.zip2KBHTTP
Information about download methods


Resources



About the authors

Laura Olson

Laura Olson is a Certified Consulting IT Specialist at IBM in Rochester, Minnesota. She specializes in SOA governance. You can reach Laura at menkell@us.ibm.com.


Nicholas Frank photo

Nicholas Frank is a Senior Systems Engineer at AmberPoint in Atlanta, Georgia. He specializes in SOA runtime governance and system integration and middleware technologies. You can reach Nicholas at nfrank@amberpoint.com.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful		Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top