Governing an existing service

This tutorial shows you how to use the service management profile to govern an existing service, and control its visibility and use across the organization.

What you should be able to do

At the end of this tutorial, you should be able to:

Register an existing service and endpoint in WSRR.
Identify and define the business capability that the service provides.
Provide planning information to support this version of the service.
Provide a complete specification of this service version, including the service level definition that can be consumed by other services.
Complete the service lifecycle, to ensure that the service endpoints are visible and enabled in the various environments.

Each lesson in this tutorial assumes that you use the WSRR dashboard.

Note: Before you begin this tutorial, you must complete the steps described in Setting up the tutorials, Starting the WSRR dashboard, and Creating an organizational structure.

Introduction

The SOA governance process can start in either of the following ways:

The IT department discovers and catalogs the services that it is using, and thereby introduces governance and control over existing services. (This is demonstrated in this tutorial.)
The business plans the services it needs according to a top-down service lifecycle.

In this tutorial, a single existing Eligibility service (named Account eligibility), which verifies that a customer satisfies the commercial credentials to be an account holder, is currently deployed in the production environment, and is used by development, test/staging, and other lines of business. The Eligibility service is defined by a monolithic WSDL (EligibilityService.wsdl) that defines the service, endpoint, binding, portType, and message types. This WSDL might have been obtained from the deployed service, using a ?WSDL command on the endpoint, or it might have been loaded automatically into WSRR using service discovery.

If you have security enabled, you can add more realism to this tutorial by creating a separate user ID for each role (SOAGovernance, Development, and Operations), and assigning each user ID to its role by using WSRR security. Then, at each stage of the tutorials where you change perspective because the actions are performed by a different role, log out of the WSRR dashboard and log in with the appropriate user ID. You can assign users to roles by using the web UI; for details, see Add and remove principals for a role.

The roles participating in this tutorial are:

: The SOA Governance role creates the representation of the business service in the dashboard, registers the WSDL service, provides the scoping and planning information for the service, and approves the service level definitions (SLDs) designed by the Development and Operations roles, and the Eligibility service designed by the Development role.
: The Development role creates the SLD and Eligibility service specification for the service, proposes the SLD that has been customized by the Operations role for approval, and completes the service lifecycle.
: The Operations role adds the service endpoint to the SLD, declares endpoints for staging and production environments, and finally moves the service to the operational governance state.

The tasks that make up this tutorial are divided into a number of sections that form a sequence. If you want to carry out all the tasks, complete the sections strictly in the order shown; however, you can also examine a specific section for reference purposes.