Automatically deactivating service level agreements in WebSphere Service Registry and Repository

Service Level Agreements (SLAs) in WebSphere Service Registry and Repository (WSRR) are agreements between service providers and consumers that can be enforced by ESBs at runtime when processing requests to ensure that the service consumer is authorised to invoke the target service. You can specify the dates between which an SLA is active, but WSRR does not automatically monitor SLAs in order to deactivate those SLAs whose termination dates have passed. This article shows you how to use a scheduled task in WSRR to monitor SLAs and automatically deactivate those that have expired.

Share:

Martin Smithson (msmiths@uk.ibm.com), Senior IT Specialist, IBM

Photo of Martin SmithsonMartin Smithson is a Product Architect on the WebSphere Service Registry and Repository Development team at the IBM Software Lab in Hursley, UK. He has 17 years of experience in the IT industry in software development and technical consultancy. His areas of expertise include WebSphere Application Server and the architecture, design, and development of J2EE applications. He has published several developerWorks articles and co-authored the following IBM Redbooks: WebSphere Application Server V6.1 System Management and Configuration, WebSphere Application Server V6 System Management and Configuration Handbook, WebSphere Service Registry and Repository Handbook, and CCF Connectors and Database Connections Using WebSphere Advanced Edition. Martin also developed the IBM Client Application Tool for JMS. You can contact Martin at msmiths@uk.ibm.com



25 September 2013

Introduction

When a service is offered for reuse within an organization, the provider of the service typically provides a number of artifacts that consumers of the service can use in order to implement client applications or services. These artifacts are usually include one or more WSDL or XML schema documents. While these artifacts provide the information required by the developers of a service consumer, they do not provide any information regarding the non-functional, or quality of service (QoS), characteristics that the service consumer can expect from the service.

The Governance Enablement Profile (GEP) provided with IBM® WebSphere® Service Registry and Repository (hereafter called WSRR) is a complete WSRR configuration profile that contains all of the business models, life cycles, ontologies, and governance policies, that you need in order to quickly get up and running with SOA governance. It enables a service provider to capture the QoS characteristics for a service using Service Level Definitions (SLDs). It also enables the agreements that exist between service providers and service consumers to be represented using Service Level Agreements (SLAs).

Importantly, SLAs are usually not open-ended agreements and are typically valid only for a limited time. While this information can be captured on an SLA in WSRR, it does not automatically monitor SLAs in order to deactivate those SLAs that are no longer valid. This article shows you how to implement a simple scheduled task in WSRR that you can use to monitor SLAs and automatically deactivate those that have expired.

Modeling service providers and service consumers

The business models contained within the GEP define all of the object types that you need in order to represent service providers, service consumers, and the agreements between them. The core types that are used to model service providers and service consumers are described in Table 1:

Table 1. Main object types in the Governance Enablement Profile (GEP)
Object TypeDescription
Organization iconOrganizationIn any governance process, there must be ownership. The organization object embodies this ownership. Every other object must be owned by an organization, either directly or indirectly.
Business Capability iconBusiness CapabilityA business capability object expresses a business view of a capability that is required within your enterprise. The object describes the business needs and concerns, but not the implementation. The capability can be viewed from a generalized business perspective. There are a number of types of business capability. For example, a capability might be used with other capabilities to build a wider capability. In this case, the capability is considered and represented as a business service. Business service, business application, and business process are specific types of business capability.
Capability Version iconCapability VersionA capability version is the realization of a business capability. The capability version indicates how the business capability is provided, for example, whether it is a web service, whether it requires messaging, and so on. Aspects of the implementation, such as web service definitions or SCA modules, are referenced from the capability version. In the same way that business capabilities have specific types, so do capability versions. For example, capabilities that are built from other capabilities, or are used to build other capabilities, can be considered as service versions. Service versions, application versions, and process versions are all specific types of capability version. One of the key aspects of capability version objects is that they have version numbers. There might be numerous versions of a capability version that realize the same business capability.
Service Level Definition iconService level DefinitionThe service level definition (SLD) describes non-functional, or quality-of-service, characteristics of a capability. These include characteristics such as how many hours a day the capability is available, or the types of security needed for interactions with the capability. Consider a capability version deployed onto a number of different servers, servicing different types of customer, or different geographies. Each server might not be able to provide the same qualities of service and require unique SLDs. However, each consumer interacts with the capability in the same way.
Service Level Agreement iconService Level AgreementIf a Capability version is offered for reuse in your enterprise, the SLA must be created to describe the details of the agreement between the capability consumer and provider. The SLA is usually a subset of the qualities of service offered by the SLD of the providing capability version. For example, the SLD might state that the service is available from Monday to Friday inclusive, but the SLA might define that the service is only required on Wednesday.
Service Endpoint iconService EndpointWhen a capability version is deployed on a runtime system, it has one or more network-addressable endpoints. These endpoints are represented by service endpoints. Service endpoint objects inform the user of the service where the service is available on the network.
Policy Attachment iconPolicy AttachmentPolicies specify the requirements that must be met so that a service can be consumed by a client. For example, a Web service may require that all messages are digitally signed and encrypted, or that it is only available at certain times; or that it can only handle a certain number of messages. The Policy Object includes the Policy Document, the Policy Expression, and the Policy Attachment.

The example shown in Figure 1 depicts a service provider. It illustrates how the WSRR objects described above relate to one another. A Credit Check business service is owned by the Common Services organization. This business service has a real implementation in the form of the Credit Check service version, which has been deployed into three geographical locations. Each geographical location hosts the service on a different server and so there is a different SLD for each installation. Each SLD can offer a distinct set of service endpoints for the service.

Figure 1. Modeling service providers
Modeling Service Providers

It will come as no surprise to learn that a service consumer is modeled in exactly the same way in WSRR as a service provider. This is due to the fact that, in a large number of cases, a service provider will also be a consumer of other services in your SOA. The object that links a service consumer to a service provider is the Service Level Agreement (SLA).

Service Level Agreements

When a service consumer wishes to consume a service, they must come to an agreement with the service provider regarding how much of the services overall capacity they are allowed to consume. When using WSRR, this information is encapsulated in a Service Level Agreement (SLA). SLAs are contracts that formally and quantifiably define the qualities of service agreed between the service provider and the service consumer.

In terms of the GEP core types that were described above, the SLA sits in between the consuming capability version and the SLD of the service provider, as shown below:

Figure 2. Service consumption
Service consumption

Once the details of the agreement between a service provider and a service consumer have been captured in an SLA this information can be used to aid the decision making process in your SOA, both at design time and runtime. An example of how this information can be used at design time is the Service Consumption Visualizer widget that is available in the Business Space user interface provided with WSRR. This widget lets you visualize:

  1. All of the consumers of a specific service.
  2. All of the services that a specific service is consuming.
  3. The agreements that exist between service providers and service consumers.

This information can be used at design time when you are planning to make changes to an existing service. It helps you to identify all of the other services that might be impacted by the planned changes. An example of how this information is displayed in the Service Consumption Visualizer widget is shown below:

Figure 3. Service Consumption Visualizer
Sevice Consumption Visualizer

An example of how this information can be used at runtime time is to actually configure the ESBs or Gateways in your SOA to enforce the SLAs defined in WSRR. The Resources section contains a link to an excellent article on how SLAs defined within WSRR can be enforced by the DataPower appliance.

SLA properties

The time interval for which an SLA is valid is defined by specifying suitable values for the Subscription Availability Date and Subscription Termination Date properties on the SLA. Table 2 describes these properties, along with the other properties that are defined on the SLA type:

Table 2. SLA properties
Display nameProperty nameDescriptionType
NamenameDescriptive name of the service level agreement.String
DescriptiondescriptionTextual description of the service level agreement.String
Context identifiergep63_contextIdentifierIf there are multiple SLAs between a service consumer and a service provider, these must be differentiated by use of the context identifier. An example of this scenario would be where a Trading Application has three SLAs with a Stock Quote Service. Each SLA has a unique context identifier: Gold, Silver and Bronze, and links to separate SLDs defined by the Stock Quote Service. Service requests from Gold customers are routed to an endpoint that returns the current stock prices. Requests from Silver customers are routed to an endpoint that returns stock prices that are 10 minutes old. Requests from Bronze customers are routed to an endpoint that returns stock prices that are 30 minutes old.String
Subscription availability dategep63_subscriptionAvailabilityDateThe date from which subscribed service providers will be available.Date
Subscription termination dategep63_subscriptionTerminationDateThe date after which subscribed service providers will no longer be available.Date
Version Match Criteriagep63_versionMatchCriteria
  • LatestCompatibleVersion
    The consumer may use the latest available version of the service that is compatible with the version to which it is subscribed.
  • ExactVersion
    The consumer must the version of the service to which it is subscribed.
String enumeration list

SLA life cycle

Thee SLA lifecycle in the GEP, shown in Figure 4 below, is used to govern an SLA from its initial identification, through to being activated, and, eventually, terminated when it is no longer required. There is an active/inactive cycle, which allows it to be turned on or off as required. By making it active or inactive, a run time can determine whether a particular consumer is allowed to invoke a particular endpoint by checking whether the relevant SLA is in the correct state:

Figure 4. SLA life cycle
SLA life cycle

For the purposes of our discussion, we do not want to terminate the SLA once the termination date has passed since this would not allow the service consumer to agree an extension to the SLA with the service provider. For this reason, the scheduled task that we will implement will use the Deactivate SLA transition to move the SLA back to the SLA Inactive state. This state, along with the other states that are defined on the SLA lifecycle, is described in Table 3:

Table 3. SLA life cycle
TransitionTarget stateDescription
(Initial state)SLA identifiedThis state is entered as soon as a consumer, represented by a capability version, requests a dependency on a service version or other capability version that offers the service level definition (SLD) that they require.
Request SLASLA requestedThe agreed endpoints relationship target has been selected together with details of the required SLA properties and policies. The provider of the selected SLD must approve the request, reject it or ask for it to be revised.
Approve SLA requestSLA inactiveThe development team that want to consume the service can continue their development based on the consumption of this specific SLA, but they do not yet have authorization to access any endpoints.
Revise SLA requestSLA identifiedAs part of the negotiation of an SLA, the service provider requests a rework of the details of the SLA by the service consumer. This is done by moving the SLA back into the identified state, ready for a resubmission.
Activate SLASLA active All the approved endpoints associated with the SLD, that are online, can be invoked using the terms of the SLA. There might be situations where the SLA is deactivated, in which case the SLA enters the SLA inactive state and any further interactions are blocked until it is reactivated.
Deactivate SLASLA inactive For operational issues, the SLA is temporarily suspended by moving it back to the inactive state. Once the operational issues have been removed, the SLA can be reactivated.
Terminate SLASLA terminatedNo interactions from this SLA are permitted.

Scheduler framework

The scheduler framework within WSRR provides a framework in which operations can be scheduled to execute on a regular basis. WSRR defines a number of interfaces that allow you to implement classes that can be configured to execute within the scheduler framework. Classes written to these interfaces are referred to as scheduled tasks. Various components in WSRR make use of scheduled tasks in order to perform tasks on a regular basis. Examples of this are:

  • The Enhanced Search component, which makes use of a scheduled task to periodically update the internal index that is used when performing full text searches.
  • The Service Discovery component, which makes use of a number of scheduled tasks in order to execute discovery tasks against each of the configured target environments.

There are currently two types of scheduled tasks that can be implemented and configured in WSRR:

  • Timed
    A timed task is a simple task that is executed at a specified interval. Timed tasks must implement the ServiceRegistryTimedTask interface.
  • Message
    A message task creates a durable subscription to the specified JMS topic. The task is executed at a specified interval and then processes any messages that have been published to the JMS topic while it was inactive. Message tasks must implement the ServiceRegistryMessageTask interface.
    The message processing can be performed in a single transaction, or each message can be processed in its own transaction.

For our purposes, we need to implement a timed task. When this task is executed it needs to query all of the active SLAs in WSRR, inspecting the Subscription Termination Date property for each to determine if the SLA has expired. For those SLAs that have expired, the scheduled task needs to perform the Deactivate SLA transition to move the SLA back to the SLA Inactive state.

Scheduled task configuration

A scheduled task is configured in a similar manner to other WSRR plug-ins. An XML configuration file is used to specify:

  • The type of the scheduled task.
  • The type of the calendar that should be used to define the frequency with which the scheduled task will run.
  • The actual definition of the frequency.
  • The class name of the scheduled task implementation.
  • The transactionality for the scheduled task.

Scheduled task granularity

While seconds can be specified, the Scheduler Framework is not designed to be accurate to the second. For this reasons it is recommended that intervals should be specified that are at least one minute apart. We therefore recommend the seconds term is always 0. For more information on the format of the CRON frequency string, please follow the CRON Calendar Format link within the Resources section.

As mentioned previously, we need to implement a timed task. Since the Subscription Termination Date on an SLA does not allow you to specify a value more fine grained than a date, we can configure our scheduled task to run once a day during periods of low system usage. In order to achieve this we need to specify a calendar type of CRON and a frequency that indicates that the scheduled task should execute at 2 a.m. every morning. The format for the frequency element in the configuration file is:

second minute hourOfDay DayOfMonth Month DayOfWeek

The value for the frequency element that we need to specify in order to configure the scheduled task to execute at 2 a.m. every morning is as follows:

0 0 2 ? * *

Scheduled task implementation

Logging and error checking

The sample code described in this article contains a limited amount of logging and error checking. Ensuring that errors are caught and handled appropriately is left as an exercise for the reader.

The sections that follow describe various aspects of the implementation of the scheduled task. The ServiceRegistryTimedTask interface is very simple, defining a single execute method.

Basic class definition

The code in Listing 1 below defines the SLAMonitorTask class. This class implements the ServiceRegistryTimedTask interface. It defines a number of member variables that are used to query WSRR and process the results. These can be broadly categorized as follows:

  • The WSRR delegate objects are used to simplify the process of accessing WSRR. They are business delegates that provide a wrapper around the WSRR local EJB interfaces and they hide the details of using the EJB API from the client. Because these delegates access the WSRR EJB API using the local interfaces they can only be used from within plugin code.
  • Since the bulk of the processing that this plugin will be performing is querying WSRR and processing the results, we define a number of string constants to hold the OWL URIs of the required types, states and transitions that we are used.
  • The XPATH_QUERY_ACTIVE_SLAS string constant defines the XPath expression that will be used to query all of the active SLAs that are currently defined within WSRR.
Listing 1. Class definition
public class SLAMonitorTask implements ServiceRegistryTimedTask {

    // Logger
    private static final Logger logger
        = Logger.getLogger("com.ibm.serviceregistry.sample");
    private static final String CLASS_NAME = SLAMonitorTask.class.getName();

    // The WSRR delegate objects
    private RepositoryDelegate repositoryDelegate = null;
    private GovernanceDelegate governanceDelegate = null;

    // Business Model, Classification and Transition URIs
    private static final String OWL_URI_SLA =
        "http://www.ibm.com/xmlns/prod/serviceregistry/profile/v6r3/
         GovernanceEnablementModel#ServiceLevelAgreement"; 
    private static final String OWL_URI_SLA_ACTIVE =
        "http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
         LifecycleDefinition#SLAActive";
    private static final String TRANSITION_DEACTIVATE_SLA =
        "http://www.ibm.com/xmlns/prod/serviceregistry/lifecycle/v6r3/
         LifecycleDefinition#DeactivateSLA";
    
    // WSRR XPath Queries
    private static final String XPATH_QUERY_ACTIVE_SLAS
        = "/WSRR/GenericObject[classifiedByAnyOf(.,'"
        + OWL_URI_SLA
        + "') and classifiedByAnyOf(.,'"
        + OWL_URI_SLA_ACTIVE
        + "')]";

    // Misc. String and Character Constants
    private static final String PROPERTY_AVAILABILITY_DATE
        = "gep63_subscriptionAvailabilityDate";
    private static final String PROPERTY_TERMINATION_DATE
        = "gep63_subscriptionTerminationDate";
    private static final String DATE_FORMAT = "yyyy-MM-dd";

}

Execute method

The code in Listing 2 below defines the execute method for the scheduled task. This method will be invoked by the scheduler framework whenever the scheduled task fires, based on the configuration in WSRR. The execute method:

  1. Creates the delegate objects that are used to access WSRR.

    classifiedByAnyOf

    Because the XPath expression used makes use of the classifiedByAnyOf custom function it will also return any instances of sub-classes of the SLA type.

  2. Uses the RepositoryDelegate to perform a PropertyQuery in order to retrieve all of the active SLAs that are currently defined in WSRR. We use a PropertyQuery because we do not need to retrieve the entire SLA object in order to check whether it has expired. We simply specify the set of properties that we wish to retrieve for each object in order to perform the required checks. As a general rule of thumb, you should try to use a PropertyQuery in preference to a GraphQuery whenever possible for performance reasons.
  3. Iterates over the results of the PropertyQuery, checking whether the termination date has passed.
  4. If the termination date for a given SLA has passed the execute method uses the GovernanceDelegate to perform a "Deactive SLA" transition on the SLA, returning the SLA in question to the inactive state.
Listing 2. Execute method
@Override
public void execute() {
    // Log entry to the method
    final String METHOD_NAME = "execute";
    if (logger.isLoggable(Level.FINER)) {
        logger.entering(CLASS_NAME, METHOD_NAME);
    }

    try {
        repositoryDelegate = DelegateFactory.createRepositoryDelegate();
        governanceDelegate = DelegateFactory.createGovernanceDelegate();
            
        /**
         * Query all active SLAs (including any sub-classes).  Retrieve the bsrURI, name,
         * availability date and termination date properties. 
         */
        PropertyQuery query
            = (PropertyQuery)DataFactory.INSTANCE.create( TypeConstants.SR_URI
                , TypeConstants.TYPE_PROPERTYQUERY);
        query.setQueryExpression(XPATH_QUERY_ACTIVE_SLAS);
        BSRSDOHelper sdoHelper = BSRHelperProvider.INSTANCE.getBSRSDOHelper();
        sdoHelper.addProperty(query, "p1", PropertyConstants.BSR_URI);
        sdoHelper.addProperty(query, "p2", PropertyConstants.NAME);
        sdoHelper.addProperty(query, "p3", PROPERTY_AVAILABILITY_DATE);
        sdoHelper.addProperty(query, "p4", PROPERTY_TERMINATION_DATE);
        List<PropertyQueryResult> results = repositoryDelegate.executeQuery(query);
            
        // Log the number of results.
        if (logger.isLoggable(Level.FINEST)) {
            logger.logp( Level.FINEST, CLASS_NAME, METHOD_NAME
            , "# of query results:" + results.size()
            );
        }
            
        /**
         * Now iterate over each of the active SLAs and check to see if we are beyond
         * the termination date.  If we are, perform the DeactivateSLA transition to
         * deactivate the SLA. 
         */
        SimpleDateFormat DATEFORMAT = new SimpleDateFormat(DATE_FORMAT);
        Date now = new Date();
        for (PropertyQueryResult result : results) {
            String slaBsrUri = sdoHelper.getPropertyQueryResultValue(result,
                PropertyConstants.BSR_URI);
            String name = sdoHelper.getPropertyQueryResultValue(result,
                PropertyConstants.NAME);
            String availabilityDateStr = sdoHelper.getPropertyQueryResultValue(result,
                PROPERTY_AVAILABILITY_DATE);
            String terminationDateStr = sdoHelper.getPropertyQueryResultValue(result,
                PROPERTY_TERMINATION_DATE);

            // Log the details of the SLA that we are processing
            if (logger.isLoggable(Level.FINEST)) {
                logger.logp( Level.FINEST, CLASS_NAME, METHOD_NAME
                           , name + "(" + slaBsrUri + "): " + availabilityDateStr
                           + " -> " + terminationDateStr);
            }

            if (terminationDateStr != null && !terminationDateStr.isEmpty()) {
                Date terminationDate = DATEFORMAT.parse(terminationDateStr);
                if (now.after(terminationDate)) {
                    if (logger.isLoggable(Level.FINEST)) {
                        logger.logp( Level.FINEST, CLASS_NAME, METHOD_NAME
                                   , name + "(" + slaBsrUri
                                   + ") has expired.  Deactivating this SLA."
                                   );
                    }
                    governanceDelegate.transition(slaBsrUri, TRANSITION_DEACTIVATE_SLA);
                }
            } // IF - terminationDateStr != null, etc.
        } // FOR
    } catch (ParseException e) {
        e.printStackTrace();
    } catch (ServiceRegistryException e) {
        e.printStackTrace();
    }

    // Log exit from the method
    if (logger.isLoggable(Level.FINER)) {
        logger.exiting(CLASS_NAME, METHOD_NAME);
    }
}

Compiling the scheduled task in WSRR Studio

In order to test the scheduled task, you need to compile the source code, package the generated class file into a JAR file and load the JAR file into WSRR. Fortunately, WSRR Studio performs most of the heavy lifting for you. The sections that follow describe how to perform these tasks.

Creating the WSRR Configuration project

We will assume that you are starting with empty workspace in WSRR Studio. If you already have WSRR Configuration Project created within your WSRR Studio workspace you can ignore the steps in this section. If not, follow the steps show below to create a WSRR Configuration Project:

  1. Open WSRR Studio.
  2. Change to the WSRR Configuration perspective.
  3. Select File -> New -> WSRR Configuration Project.
  4. The Create a WSRR Configuration Project dialog will be displayed. Enter a value of GEP_V80 in the Configuration Project name entry field and select Governance Enablement Profile - WSRR v8.0 from the list of Configuration Profile templates. The dialog should look like this:
    Figure 5. Creating the WSRR Configuration project
    Creating the WSRR Configuration Project
  5. Click Finish.
  6. The new WSRR Configuration Project is created and is visible in the WSRR Configuration Project Explorer view.

Importing the scheduled task source code

Now we need to import the source code for the scheduled task into the WSRR Configuration project that we have just created. In order to do this we need perform the following steps:

  1. In the WSRR Configuration Project Explorer view, expand GEP_V80 and right click on the src folder.
  2. In the context menu that is displayed, select New -> Package.
  3. The New Java Package dialog will be displayed. Enter a value of com.ibm.serviceregistry.sample in the name entry field:
    Figure 6. New Java package dialog
    New Java package dialog
  4. Click Finish.
  5. The com.ibm.serviceregistry.sample java package is created and is displayed under the src folder within the WSRR Configuration Project Explorer view.
  6. Right click on the com.ibm.serviceregistry.sample package.
  7. In the context menu that is displayed, select Import....
  8. The Import dialog will be displayed. Select File System as the import source and Click Next >.
  9. Click the Browse... button.
  10. The Import from directory dialog will be displayed. Navigate to, and select, the directory that contains the java source file for the scheduled task.
  11. Click OK.
  12. Back in the Import dialog, select the SLAMonitorTask.java file:
    Figure 7. Specifying the file to import
    Specifying the file to import
  13. Click Finish.
  14. The SLAMonitorTask.java file is imported into the com.ibm.serviceregistry.sample java package.

Importing the scheduled task configuration

The SLAMonitorTask class now compiles successfully. We now need to modify the configuration of WSRR in order to specify how frequently the scheduled task should be invoked. In order to do this we will import the configuration file that was provided with this article.

  1. In the WSRR Configuration Project Explorer view, expand GEP_V80 -> Configuration Profile Files and right click on the Scheduler folder.
  2. In the context menu that is displayed, select Import....
  3. The Import Scheduler dialog opens. Navigate to the directory that contains the SLAMonitorScheduler.properties file and select it:
    Figure 8. Specifying the file to import
    Specifying the file to import
  4. Click OK.
  5. The SLAMonitorScheduler.properties file is imported into the Scheduler folder. For reference, the content of the SLAMonitorScheduler.properties file is shown in Listing 3:
        <?xml version="1.0" encoding="UTF-8"?>
    <scheduler-configuration
        xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/1/SchedulerProperties">
    
        <scheduler-task name="SLAMonitor">
            <type>Timed</type>
            <calendarType>CRON</calendarType>
            <frequency>0 0 2 ? * *</frequency>
            <class>com.ibm.serviceregistry.sample.SLAMonitorTask</class>
            <enabled>true</enabled>
            <transactionality>Single</transactionality>
        </scheduler-task>
    </scheduler-configuration>

Generating the WSRR artifacts

The real power in WSRR Studio is its ability to translate the artifacts defined in the workspace into the various configuration artifacts that can be loaded into WSRR. For example, for each business model that is defined in a WSRR Configuration Profile project, a corresponding OWL file is generated that contains an OWL representation of each of the types defined within the business model. It is this OWL file that is published into WSRR.

In the context of our scheduled task, WSRR Studio will package the resources contained within the src folder into a JAR file and place the JAR file within the Configuration Profile Files -> Plug-in JARs folder. It is worth noting that, by default, this will include a number of properties files that contain the translations of error messages that are used by the Governance Policies that are defined within the WSRR Configuration Profile project.

The name of the generated JAR file matches the name of the WSRR Configuration Profile project. In our example, therefore, the name of the generated JAR file is GEP_V80.jar. In order to generate the WSRR artifacts you need to perform the following steps:

  1. Right click on the GEP_V80 project and select Generate All WSRR Artifacts.
  2. The progress of the generation process is displayed in the Progress Information dialog.
  3. Generation errors

    If an error occurs while generating the WSRR artifacts, details of the errors can be found in the Problems view.

    Once the artifact generation process is complete, the outcome is displayed in the WSRR Configuration Artifacts Generation dialog:
    Figure 9. WSRR configuration artifacts generation dialog
    WSRR configuration artifacts generation dialog
  4. Click OK.

Synchronizing the changes with WSRR

Configuring WSRR locations

For the purposes of this article we assume that you already have at least one WSRR location configured within your WSRR Studio workspace. For more information on configuring WSRR locations, see Configuring WSRR Studio.

Another powerful feature of WSRR Studio that was introduced in WSRR V7.5 is the ability to synchronize a WSRR configuration profile project in your workspace with an actual instance of WSRR running in your environment. This capability extends the Team Synchronizing perspective in Eclipse to allow WSRR Studio to retrieve configuration files from the active profile within the specified WSRR instance and compare them with the files in the workspace. Files that have been modified in the workspace are then displayed in the Synchronize view and individual files can be pushed into WSRR. This process is called partial publish since it does not require you to publish an entire WSRR configuration profile ZIP file to WSRR. In order to synchronize the relevant artifacts with WSRR, perform the following steps:

  1. Right-click on the GEP_V80 project and select Synchronize Profile with WSRR.
  2. The Synchronize dialog is displayed. A single WSRR Studio workspace can contain multiple WSRR Configuration Profile projects and multiple WSRR Location definitions. This dialog allows you to specify the WSRR configuration project and the WSRR instance to compare, that is, the source and target configuration profiles to compare. Ensure that GEP_V80 is selected in the Configuration Project drop down and that you have specified the correct target WSRR instance in the Target WSRR Server dropdown:
    Figure 10. Specifying synchronization source and target
    Specifying synchronization source and target
  3. Click Finish.
  4. The progress of the synchronization process is displayed in the Progress Information dialog.
  5. Once WSRR Studio has finished comparing the profiles the Synchronize view will be updated to list all of the configuration files in the workspace that are different to those loaded in the target WSRR instance. We are interested in pushing the GEP_V80.jar and SLAMonitorScheduler.properties files to the target WSRR instance. In the Synchronize view, expand GEP_V80 and then expand both the Configuration Profile Files/PLUGIN_JAR and Configuration Profile Files/SCHEDULER_PROPERTIES folders.
  6. Using the Ctrl key, select both the GEP_V80.jar and SLAMonitorScheduler.properties.
  7. Right click on one of the selected files.
  8. In the context menu that is displayed, select Commit to Server.
  9. The Commit to Server dialog is displayed. This dialog lists the configuration files that have been selected for publishing to the specified WSRR instance and the action that will be performed on the target server. The dialog should look like this:
    Figure 11. Performing the commit
    Performing the commit
  10. Click Finish.

Importing the test data

Before testing the scheduled task, you need an active SLA with a Subscription Termination Date in the past. For simplicity, you can import into the WSRR instance a set of test data that includes a representation of a service provider and a service consumer, as well as the expired SLA that connects the two. Figure 12 shows the test data that will be imported:

Figure 12. Test data
Test data

If you would like to use your own test data, you will need to create the relevant objects manually. The steps to create an SLA and move it through its life cycle are described in the Tutorials for the Governance Enablement Profile in the WSRR Information Center. See Creating a Service Level Agreement for more information on how to create an SLA and the related objects within the core GEP model discussed in the sections Modeling service providers and consumers and Service Level Agreements above. To import the test data into WSRR, perform the following steps:

  1. Open a command window.
  2. Navigate to the <WAS_INSTALL_ROOT>/WSRR/admin/scripts_cell directory.
  3. If your WSRR instance is running on a WebSphere Application Server cluster execute the following command:
    <WAS_INSTALL_ROOT>/bin/wsadmin.sh -f importMetadata.jacl 
        -user <USER_ID>
        -password <PASSWORD>
        -cluster <CLUSTER_NAME>
        -filepath <FILE_PATH>
        -filename export.zip

    If your WSRR instance is not running on a WebSphere Application Server cluster execute the following command:
    <WAS_INSTALL_ROOT>/bin/wsadmin.sh -f importMetadata.jacl 
        -user <USER_ID>
        -password <PASSWORD>
        -cell <CELL_NAME>
        -node <NODE_NAME>
        -server <SERVER_NAME>
        -filepath <FILE_PATH>
        -filename export.zip

    Where:
    • <USER_ID> is the id of a WSRR administrator.
    • <PASSWORD> is the password for this user.
    • <CLUSTER_NAME> is the name of the WAS cluster.
    • <CELL_NAME> is the name of the WAS cell.
    • <NODE_NAME> is the name of the WAS node.
    • <SERVER_NAME> is the name of the WAS server.
    • <FILE_PATH> is the path to the export.zip file.
  4. The test data will be imported into the target WSRR instance. You should the following messages at the end of the console output in your command window:
    The entities with the following URIs were imported:
    [09f51409-cf00-4057.a487.f4b3c4f48707, e0bd7fe0-7704-444f.9b39.aa1366aa3978]
    > ServiceRegistryRepository#importMetaData imported URIs:
    >> 09f51409-cf00-4057.a487.f4b3c4f48707
    >> e0bd7fe0-7704-444f.9b39.aa1366aa3978

Testing the scheduled task

We are now ready to test the scheduled task. Obviously, we do not want to wait until 2am in order for the scheduled task to execute. Fortunately, WSRR provides a script that can be used to manually invoke the scheduled task immediately. In order to do this, and verify that the state of the SLA is correctly modified, we need to perform the following steps:

  1. In a web browser, log on to the Business Space user interface and change to the Service Registry for SOA Governance space. You may need to create a new space based on the Service Registry for SOA Governance template if one does not already exist.
  2. On the Overview tab find the Service Registry Collection widget and click on the SLA - Test Service Consumer 1.0 to Test Service Provider 1.0 object in the table:
    Figure 13. Locating the test SLA
    Locating the test SLA
    If the SLA - Test Service Consumer 1.0 to Test Service Provider 1.0 object is not visible then you might need to page through the list of using the controls at the bottom of the widget. Alternatively, you could select Watch List: Service Level Agreements in the widgets View drop down in order to display just SLAs.
  3. On selecting the SLA - Test Service Consumer 1.0 to Test Service Provider 1.0 object, you will be taken to the Browse tab and the various widgets will be populated to display the details of the test SLA. Notice that the Governance State in the Service Registry Detail widget is SLA Active and that the Subscription Termination Date is in the past:
    Figure 14. Before executing the scheduled task
    Before executing the scheduled task
  4. Open a command window.
  5. Navigate to the <WAS_INSTALL_ROOT>/WSRR/admin/scripts_cell directory.
  6. If your WSRR instance is running on a WebSphere Application Server cluster execute the following command:
    <WAS_INSTALL_ROOT>/bin/wsadmin.sh -f executeSchedulerTaskImmediate.jacl 
        -user <USER_ID>
        -password <PASSWORD>
        -cluster <CLUSTER_NAME>
        -taskname SLAMonitor

    If your WSRR instance is not running on a WebSphere Application Server cluster execute the following command:

    <WAS_INSTALL_ROOT>/bin/wsadmin.sh -f executeSchedulerTaskImmediate.jacl 
        -user <USER_ID>
        -password <PASSWORD>
        -cell <CELL_NAME>
        -node <NODE_NAME>
        -server <SERVER_NAME>
        -taskname SLAMonitor
  7. The scheduled task will in invoked. You should see the following messages at the end of the console output in your command window:

    > ServiceRegistryRepository#executeSchedulerTaskImmediate invoke...
    > ServiceRegistryRepository#executeSchedulerTaskImmediate SLAMonitor task completed.
  8. Back in the Web Browser, click on the twisty in the title bar of the Service Registry Detail widget and select Refresh:
    Figure 15. Refreshing the Detail widget
    Refreshing the Detail widget
  9. The details for the SLA -- Test Service Consumer 1.0 to Test Service Provider 1.0 object will be updated. Notice that the Governance State has changed to SLA Inactive.

Conclusion

This article provided an example implementation of a scheduled task that monitors active SLAs and deactivates them when they have expired. It also demonstrated the behaviour of this scheduled task within the product.

Acknowledgements

The author would like to thank David Seager and Tim Baldwin of IBM for helping to review this article.


Download

DescriptionNameSize
Code sampleDownload.zip18 KB

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=946337
ArticleTitle=Automatically deactivating service level agreements in WebSphere Service Registry and Repository
publish-date=09252013