11.2 Web Service Registry Management

Service registries are typically accompanied by their own management application. This management application may be JMX based, or it may provide JMX MBeans that expose the registries' management information and operations. If it does not provide a JMX interface but does provide programmatic access to its management functionality, you may be able to develop your own registry management application by developing your own MBeans that invoke those APIs.

11.2.1 Registry Owner

There are two levels of registry ownership: (1) owning the registry implementation code and (2) owning and controlling a registry application. In the second case you have purchased the application, like UDDI, from a vendor and are executing it within your environment.

When you own the registry implementation code, you can instrument the registry directly for manageability. What should you instrument it with? You should expose

• Identification information:

  - Product name

  - Version

  - Install date

  - Maintenance level

• Configuration information:

  - IP addresses

  - URLs

  - Current status

• Metrics that will help operators gauge its responsiveness and usage:

  - Number of entries in the registry

  - Number of get requests

  - Number of search requests

  - Rate of access

  - Average response time for a get

  - Average response time for a search

  - High and low watermarks for get response times

  - High and low watermarks for search response times

• Notifications to warn operators that the registry

  - Is degraded

  - Is running out of space

  - Is about to fail

  - Has failed

  - Has experienced security access failures

• Operations to

  - Start the registry

  - Stop the registry

  - Run a backup operation to save the current registry data to a backup database or file

You may also expose additional metrics, configuration, notifications, and operations that are specifically useful for your registry implementation.

Here is a sample UDDI registry MBean interface that could be exposed by the UDDI registry itself:

  public   interface  UDDIRegistryManagerMBean {         // identity        String getName();  void  setName(String name);        String getVersion();        // configuration        String getURL();  void  setURL(String url);        String[] getURLs();  void  setURLs(String[] secureURLs);        String getStatus();        // metrics  int  getNumberOfEntries();  int  getNumberOfGets();  int  getNumberOfSearchs();  int  getAverageSearchTime();  int  getAverageGetTime();  int  getHighSearchTime();  int  getHighGetTime();  int  getLowSearchTime();  int  getLowGetTime();        // operations  int  start();  int  stop();  int  backUpRegistryData(); } 

A simple implementation of this interface is available from the download Web site for this book (http://www.awprofessional.com/titles/0672324083). Because this example relies on the UDDI registry exposing management interfaces, the examples rely on UDDIRegistryData and UDDIRegistryController classes to be implemented by the UDDI registry. Therefore the examples don't actually interact with a UDDI registry. All of these examples use the UDDI4J ^[22] UDDI client implementation available from IBM's open -source projects on the developerWorks Web site (http://www-124.ibm.com/developerworks/projects/uddi4j) and IBM's Web Services Tool Kit available on IBM's alphaWorks Web site (http://www.alphaworks.ibm.com/tech/webservicestoolkit).

If you are in control of the executing registry application, what should you be managing? You should start by monitoring the network availability and operational availability. If the registry is instrumented with JMX, you can use monitor MBeans along with the registry's MBean to monitor performance. You should register for failure notifications as well.

If the registry does not support JMX, you will have to write your own MBean to interact with the registry to get performance data. You should try to monitor performance characteristics, like the number of entries in the registry, the rate of access, average response time for a get, and average response time for a search. Armed with this information, you can tune your registry implementation to be sure your registry responds quickly and accurately. For example, if it is backed by a database, you can expand the database if the number of entries is getting very high. If the registry is itself accessed as a Web service, you can get some of these performance numbers from the Web service execution environment as you would for any business service. We'll see more on this in Section 11.3.

There may also be other operations and performance information exposed to you by the registry that you might want to consider adding to your registry MBean. These will vary pretty widely depending on the registry type and implementation.

Here is a sample UDDI registry MBean interface that could be exposed for a third-party UDDI registry that you are executing:

  public   interface  UDDIRegistryRuntimeManagerMBean {         // identity        String getName();  void  setName(String name);        String getVersion();        // configuration        String getURL();  void  setURL(String url);        String[] getURLs();        String getStatus();  void  setStatus(String avail);        // metrics  int  getNumberOfEntries();  int  getNumberOfGets();  int  getNumberOfSearchs();  int  getAverageSearchTime();  int  getAverageGetTime();  int  getHighSearchTime();  int  getHighGetTime();  int  getLowSearchTime();  int  getLowGetTime();        // operations  long  checkAvailability(String businessName);  long  checkNetworkAvailability();  int  start();  int  stop();  int  backUpRegistryData(); } 

A simple implementation of this MBean is provided on the download Web site for this book (http://www.awprofessional.com/titles/0672324083). Once again, this example relies on the UDDIRegistryData and UDDIRegistryController classes to be implemented by the UDDI registry and therefore doesn't actually interact with a real UDDI registry.

11.2.2 Registry User

If you are a user of the registry, as either a publisher of services or a discoverer of services, and you do not own the registry, what can you do? You will still want to know if the registry is available and performing well enough for your application to use. You can develop your own JMX MBeans to manage your connection to the registry. You should develop an MBean to represent the registry and monitor it using monitor MBeans.

At the very least, any registries you are dependent on, inside or outside of your enterprise, should be monitored for availability. Because these registries are available through a network (and if they are not redirected by the hosting company), an old-fashioned ping can be used to check on the registry's network availability. Beyond connectivity you should monitor for functional availability ”that is, whether the registry can perform the functions you need when you need them. To check for functional availability you should send an actual operation to the registry, like a logon or a fetch of one of your service entries, to ensure that the registry is functional and returning information that is important to your application or enterprise. In this case your registry MBean should have a status attribute, and checkNetworkAvailability() and checkAvailability() operations. The checkNetworkAvailability() method would do a ping and return the number of milliseconds it took for the ping to return. If the ping failed to return, the method would return “ 1 . It is convenient to use checkNetworkAvailability() on the MBean instead of a direct ping because your management application will always call the same method, even if the implementation of the method is more sophisticated than a ping and could change depending on the type of network through which the service is accessed. The checkAvailability() method would do a get of one of your service entries, returning the number of milliseconds it took to get the entry back, or returning “ 1 for failures. Status would be calculated from the combination of response times to ping and checkAvailability() , and evaluation of notifications from the registry.

Let's look at an example of an MBean for monitoring the availability of a UDDI registry. For UDDI registries, you can use UDDI4J, which is a Java UDDI client API, to interact with the registry. The getStatus() method for the status attribute should execute both of these methods . If they are both successful, then the status is available . If either fails, the status is unavailable . Now you can create a JMX String monitor to monitor the status attribute for a change to unavailable . Such a change will trigger a notification to your management system.

You can also set up custom monitors that check network availability more often by just executing the checkNetworkAvailability() method. If you have service entries that you have published that are critical to your business, you can monitor that they are returned to you with the checkAvailability() operation. If those entries are not available, you can automatically republish. Automatic republishing is not always the correct correctional response, so you should be sure that it has no ill effects on the registry or your entry before you set up automatic publishing. UDDIRegistryClientManagerMBean is an example of an MBean interface we have been discussing:

  public   interface  UDDIRegistryClientManagerMBean {         String getName();  void  setName(String name);        String getURL();  void  setURL(String url);        String getStatus();  void  setStatus(String avail);        Long checkAvailability(String businessName);        Long checkNetworkAvailability(); } 

The constructor for this MBean would need to accept the name and IP address of the registry. These would be retrievable as MBean attributes. If you are going to invoke a UDDI operation in the checkAvailability() operation, then you will also need to pass the UDDI logon name and password into the constructor. For security reasons, these will not be retrievable as MBean attributes.

A full implementation of the UDDIRegistryClientManagerMBean class is listed at the end of this chapter and is available on the book's Web site (http://www.awprofessional.com/titles/0672324083). Because the scenario is that we are managing a UDDI registry we do not own, we do not rely on the UDDI registry to implement or expose any management classes. We do rely on the UDDIRegistryClient implementation to interact with the UDDI registry.