Introduction

With the advent of service-oriented architecture (SOA), services are more and more being considered a key enterprise asset. This transition to a service-centric view of both business and IT has created the need for a comprehensive solution to manage and promote service-related information and metadata across an organization's ecosystem comprised of multiple actors, processes and systems.

As part of SOA governance, you need to define, manage and enforce a service life cycle that allows a holistic view of an enterprise's services and related concepts. In this article, you'll learn about the capabilities provided by WebSphere Service Registry and Repository (hereafter called Service Registry) to enable a service life cycle. Specifically, the article show you step-by-step how to define a custom service life cycle and how to implement separate life cycles to govern different types of entities or different aspects of a given entity than the default life cycle provided in Service Registry.

When you install Service Registry, two life cycles are provided, a default life cycle and a more complex sample called SampleLifecycleDefinition. The default life cycle is very simple, as shown in Figure 1:

SampleLifecycleDefinition contains ten states, one of which is a composite state containing five further states, as shown in Figure 2:

The intent of this article is not to explain these default life cycles, but rather to describe how to build a new one from scratch.

Back to top

Designing a service life cycle

There is no one-size-fits-all solution to creating a service life cycle. Before you start, you need to understand what states and transitions are needed, how many roles exist, and how and when users will interact with Service Registry to go through the different states of the life cycle. Your life cycle definition may also vary depending on the environment in which it applies. You need to have a clear definition of what activities need to happen before being able to move to the next stage. To help you with the SOA governance life cycle, Service Registry provides a framework to validate data and metadata, and also to notify other components.

In any organization, even where SOA is not a primary focus, there are very well-established roles to take defining responsibilities for business analysis, architecture, design, development, deployment, management, and so on. When growing the IT governance to include SOA governance, you may need to add some additional roles that did not previously exist, but the main point is that you must clearly know and clearly define all roles and the set of responsibilities attached to them. For a detailed description of how different roles in the business interact with WebSphere Service Registry and Repository in an SOA governance life cycle, see Introducing IBM WebSphere Service Registry and Repository, Part 1: A day in the life of WebSphere Service Registry and Repository in the SOA life cycle.

Let's look at the definition of a state in the UML terminology in more detail. A state is a stage in the behavior pattern of an entity. States are represented by the values of the attributes of an entity. From this definition, you can see that you need to define the set of attributes that represents the entities that you want to govern. You do this when you define the information model, at which point you can modify attributes, or custom properties, relationships, classifications, and even change the content of an entity, if you're dealing specifically with a document that will drive the need for different states.

You also need to define transitions between states. In a UML context, a transition is a progression from one state to another, which will be triggered by an event that is either internal or external to the entity being modeled. A transition is typically the result of an invocation that causes an important change in state. However, not all invocations will result in transitions. This may be because there are many significant changes related to the governance model for an entity (for example a service as a concept) or a group of entities (when we consider all the dependencies of that entity) that we need another state; hence, a transition.

You may have other reasons to create additional states and transitions; for example, when you want to implement some of the processes defined in the governance model that don't imply a change of data or metadata of the governed entity. An example might be when you want to enforce compliance or vitality checks to ensure that a guideline to design the service have been properly followed. In that case, an administrator or quality manager would validate whether the guideline was properly followed for the specific entity and then would invoke the transition to the next state. You could create this transition manually using the the Service Registry administrative console, or automatically, using one of the Service Registry interfaces, such as the Web services or scripting interfaces.

Once you've determined the set of metadata and the physical documents (you may have one or the other or both), you can start to ask yourself the following questions to begin designing a life cycle. These questions are based on the authors' experience, rather than any specific recommendation provided by Service Registry.

• Who is the owner for the specific metadata? For example, who owns and manages the service endpoint information? Who owns and manages the quality of service information that you decided to use in the service information model?
• Is the metadata specific to an environment? If some service endpoint information is included in the Service Information Model, it's likely that the metadata will be specific to each environment.
• Is there any obvious grouping or classification for the metadata, or are they independent of each other?
• Are there any validation or notification rules when the values are changing?
• Do the values of the metadata change during the life cycle? If so, why?

This set of questions should help you link the different values of the metadata, or the content of the document, to the different states of the life cycle.

Back to top

Creating a custom service life cycle

For the purposes of this article, we'll assume that you've already designed the life cycle. Now we'll see how to build it with WebSphere Integration Developer (hereafter referred to as Integration Developer). The reason we'll use Integration Developer is that it contains a state diagram editor that you can use to create the required SACL file. SACL stands for State Adaptive Choreography Language and is the standard used to represent the state diagram as a file.

There are other ways to build the SACL file. Creating customized classification systems with WebSphere Service Registry and Repository V6.0.0.1: A step-by-step guide for administrators to create new classification systems and life cycles for WebSphere Service Registry and Repository, by Ian Shore, describes an alternative method that uses a text file to represent the state diagram. You can also create a simplified UML representation of the state diagram, and then use the transformation framework in Rational™ Software Architect to create the SACL file.

In the following sections, you'll learn how to create a state diagram associated with a life cycle, and then load the resulting SACL and associated Web Ontology Language (OWL) file into Service Registry using Integration Developer. For this example, we used Service Registry V6.0.2 and Integration Developer V6.0.2.

You can use Integration Developer to generate SACL documents that are usable by Service Registry. For our example, we'll generate a state diagram called using WebSphere Integration Developer. We'll use a very simple life cycle so that you can easily see the different steps required in Integration Developer. Notice that we used adjectives for the states and verbs for the transitions, which is considered good practice. Figure 3 shows the contents of the SACL and the interfaces:

Create the SACL file

To create the SACL file, do the following:

1. Start Integration Developer.
2. Select File => New => Module to create a new module.
3. Enter WSRRLifeCycle as the name of the module.
4. In the Business Integration window, expand WSRRLifeCycle => Business Logic => State Machines, then right-click New Business State Machine to open the New Business State Machine wizard.
5. In the New Business State Machine dialog, specify the following, as shown in Figure 4:
   • Module: Specify the name of the module; in our case, WSRRLifeCycle.
   • Namespace: Uncheck Default to allow a namespace to be entered, then specify the namespace you want to use for the life cycle and the classification system that will be used to represent it. In our example, we use http://www.mycompany.com/xmlns/lifecycle/CustomLifeCycle.
   • Folder: Specify the location where you want the SACL files to be placed. In our example, we use lifecycle.
   • Name: Specify the name of the life cycle you want to create. In our example, we use CustomLifeCycleStateMachine.
     
     Figure 4. New Business State Machine dialog
     
     
     
6. Click Finish to open the business state machine editor, as shown in Figure 5:
   
   Figure 5. Business state machine editor
   
   
   

Create the interface

Next, we'll create the interface associated with the state diagram. The interface will include the operations that are used to define the transitions in the state diagram.

1. Select File => New => Interface.
2. Select the WSRRLifeCycle module.
3. Uncheck Default to allow a namespace to be entered, then enter a namespace. In our case, we'll use http://www.mycompany.com/xmlns/lifecycle/interface/CustomLifeCycle.
4. Specify lifecycle for Folder.
5. Specify CustomLifeCycleInterface for the Name.
6. Click Finish to open the interface editor for the new interface, as shown in Figure 6:
   
   Figure 6. Interface editor
   
   
   

Define the transitions

Next we need to add the various operations to the interface to define the transitions.

1. In the interface editor, click the Add One Way Operation icon as shown in Figure 7:
   
   Figure 7. Click Add One Way Operation icon
   
   
   
2. Change the name of the operation from operation1 to create.
3. Change the name of the Input to bsrURI.
4. Leave the Type as string.
   
   Figure 8. Specify create operation
   
   
   
5. Repeat the same operation to create three additional one-way operations, with the following names: develop, deploy, deprecate. You can specify the same inputs (bsrURI with a type of string for each of them, as shown in Figure 9:
   
   Figure 9. Added operations
   
   
   
6. Click Ctrl + S to save your changes, and close the interface editor.
7. Next, you need to complete the state diagram. In the Business State Machine editor, create the following states: Created, Specified, Provisioned, Operational, Deprecated. To do this, first rename State1 to Created.
8. For the remaining states, select the state icon from the palette, and click the freeform surface. Rename each state as listed above. The result should look something like Figure 10:
   
   Figure 10. Created states
   
   
   
9. Now that you've finished specifying the states, you need to define the transitions. To create the transitions, click and hold on a state, then click on the state with which you want to create a transition. Repeat this action between each of the states (Created and Specified, Specified and Provisioned, and so on). The result should look like Figure 11:
   
   Figure 11. Transitions defined
   
   
   
10. Delete the transition between the Created state and the FinalState1 by right-clicking on it and selecting Delete.
11. Link the interface definition to the transitions by clicking the + icon beside Interfaces on the righthand side of the window, as shown in Figure 12:
    
    Figure 12. Link the interface definition to the transitions
    
    
    
12. Select CustomLifeCycleInterface and click OK.
13. Next you need to associate the operations with the transitions. In the Properties view, select the operation1 transition, ensure that CustomLifeCycleInterface is selected for Interfaces, then select the create operation. You should see something like Figure 13:
    
    Figure 13. Associate create operation with operation1
    
    
    
14. Repeat this for each of the other transitions. That is, select the transition in the property view, click the appropriate operation button, and select the appropriate interface and operation. Alternatively, you drag and drop the Interface panel to the transition itself. Alternatively, you can drag and drop the operation definitions from the Interfaces panel (on the right of the screen) of the CustomLifeCycleInterface. The results should look like Figure 14:
    
    Figure 14. Associated operations and transitions
    
    
    

Add correlation properties

1. Finally, you need to add the correlation properties. A correlation set defines properties that are used to distinguish one instance of a state machine from another within a runtime environment. For each operation, or event, that the state machine responds to, a property alias locates the input that corresponds to each defined correlation property. Click the + icon next to Correlation properties on the righthand side of the window, enter bsrURI for the Name, select string for the Type, and click OK.
2. Select the bsrURI correlation property, and in the property view for each operation, click and select bsrURI, as shown in Figure 15:
   
   Figure 15. Add correlation properties
   
   
   
3. Save the state diagram.
4. Check the Problem window to see if there are any errors. You should have only one warning, as shown in Figure 16:
   
   Figure 16. Problem window
   
   
   

Export the SACL

Now you're ready to export the SACL to the file system.

1. Select WSRRLifecycle => Business Logic => State Machines => CustomLifeCycleStateMachine in the Business Integration view, then right-click and select Export to open the Export window.
2. Select File system and click Next.
3. Select a directory to export the file to, such as C:\article\, click Finish, as shown in Figure 17. (We assume that the directory already exists. If not, you'll be prompted to create it.)
   
   Figure 17. Export file
   
   
   
4. The SACL file that is going to be loaded into Service Registry and Repository needs a corresponding OWL file. To create this file, use the XSLT file that is included in your WebSphere Service Registry and Repository installation.

   From a command prompt, enter the following command to generate an OWL file associated with the SACL:

   <was_home>\java\bin\java.exe -cp <was_home>\java\jre\lib\xml.jar org.apache.xalan.xslt.Process -in C:\article\CustomLifeCycleStateMachine.sacl -v -xsl <wsrr_home>\admin\scripts\GenerateLifecycleOntology.xsl -out C:\article\CustomLifecycleDefinition.owl

   
   
5. Now you need to remove the default life cycle that was already loaded in Service Registry. Select Classification Systems => Classification systems, then select DefaultLifecycle and click Delete.
6. Delete the SACL file from Service Registry. Enter the following from a command prompt:

   <wsrr_home>\CLI\WSRRCLI.bat deleteConfig.py -a myserver -c \wsrr\CLI\config\wsrrcli.conf -n LifecycleDefinition -t SACL

   
   

   Hint: The following command provides you with a list of all the configuration files loaded in Service Registry, the file type is SACL:

   <was_home>\profiles\wsrr2\bin\wsadmin -wsadmin_classpath <wsrr_home>\ServiceRegistryClient.jar -username wasadmin -password wasadmin -f <wsrr_home>\admin\scripts\ reportAllConfigurations.jacl /temp wsrr_report.txt

   
   
7. Import the new SACL file into the Service Registry by entering the following from a command prompt, assuming the name of the WebSphere Application Server profile is wsrr2:

   <was_home>\profiles\wsrr2\bin\wsadmin -wsadmin_classpath <wsrr_home>\ServiceRegistryClient.jar -username wasadmin -password wasadmin -f <wsrr_home>\admin\scripts\loadConfiguration.jacl /article CustomLifeCycleStateMachine.sacl LifecycleDefinition SACL true

   
   

   Note: The name LifecycleDefinition is mandatory. If you cannot specify something else, it will not fail, but it won't work.

Load the OWL file

Now load the associated OWL file using the Web interface.

1. Select Classification Systems => Load classification system, then click Browse.
2. Specify C:\article\CustomLifecycleDefinition.owl for the path, then click OK, as shown in Figure 18:
   
   Figure 18. Load the OWL file
   
   
   
3. Restart Service Registry.

Using the life cycle

You can now start to use the new life cycle. Let's work on a simple WSDL document. Any entity will do, but for this example, let's assume that you have the famous TemperatureConverter service WSDL file loaded in Service Registry.

1. Select TemperatureConverter.wsdl.
2. Click the Governance tab, then click Make Governable, as shown in Figure 19:
   
   Figure 19. Make an entity governable
   
   
   
3. Select InitialState1 as the Governance State.
4. There is only one transition to get to the next state, the create transition. This sample is very simple, so since we are using a WSDL file, we can assume that the work has been done to create the service. For example, we can assume that a service specification document (not stored in Service Registry) has been created, and is associated with this WSDL. Having checked that the documentation is accurate and that the WSDL is also correct, the service owner would decide to go to the create state.
   
   Figure 20. TemperatureConverter create state
   
   
   

   The TemperatureConverter service goes into the Create state. As time goes on, we will transition to the different states that represent the development and deployment of this service.

Clean up and restore

Complete the steps in this section if you want to remove the changes you've made in Service Registry while working through this article

1. Remove the LifecycleStateMachine classification from the user interface. From the navigation panel, expand Classification Systems, then select Classification Systems. Select CustomLifeCycleStateMachine and click Delete.
2. Remove the SACL configuration file by entering the following from a command prompt:

   <wsrr_home>\CLI\WSRRCLI.bat deleteConfig.py -a myserver -c \wsrr\CLI\config\wsrrcli.conf -n LifecycleDefinition -t SACL

   
   
3. Load the default lifecycle into <wsrr_home>\install\config\DefaultLifecycle.sacl by entering the following from a command prompt:

   <was_home>\profiles\wsrr2\bin\wsadmin -wsadmin_classpath <wsrr_home>\ServiceRegistryClient.jar -username wasadmin -password wasadmin -f lt;wsrr_home>\admin\scripts\loadConfiguration.jacl <wsrr_home>/install/config/DefaultLifecycle.sacl LifecycleDefinition SACL true

   
   
4. Load the associated OWL file under <wsrr_home>\install\config\DefaultLifecycle.owl
5. Restart Service Registry.

Back to top

Conclusion

In this article, we provided guidelines for designing a custom life cycle, which emphasized the need to spend adequate time to get the most accurate SOA governance life cycle, and highlighted the importance of a good governance model design. Then we demonstrated how to build a custom life cycle in Integration Developer and export it to Service Registry.

Resources

• Introducing IBM WebSphere Service Registry and Repository, Part 1: A day in the life of WebSphere Service Registry and Repository in the SOA life cycle: This article introduces the main concepts and capabilities of IBM WebSphere Service Registry and Repository. It explains the role of Service Registry and Repository throughout the service-oriented architecture (SOA) life cycle and provides resources to help you learn more about it.
  
  
• Introducing IBM WebSphere Service Registry and Repository, Part 2: Architecture, APIs, and content: This article provides an architectural overview of WebSphere Service Registry and Repository and its capabilities. It describes how WebSphere Service Registry and Repository components work together to advertise, find, retrieve, manage, and govern service metadata.
  
  
• Creating customized classification systems with WebSphere Service Registry and Repository V6.0.0.1: A step-by-step guide for administrators to create new classification systems and lifecycles for WebSphere Service Registry and Repository: This article describes how to create, load, update and use new classification systems and lifecycles within WebSphere Service Registry and Repository quickly without having to use any special tooling.
  
  
• WebSphere Service Registry and Repository Information Center: Provides complete product documentation.
  
  
• developerWorks WebSphere business process management zone: Provides a host of technical resources, such as articles, tutorials, and downloads, on WebSphere BPM solutions, including WebSphere Service Registry and Repository.
  
  
• developerWorks WebSphere SOA zone: Provides a host of technical resources, such as articles, tutorials, and downloads, on WebSphere SOA solutions.
  
  
• WebSphere Service Registry and Repository product information: Provides WebSphere Service Registry and Repository product information, including requirements and how to purchase.
  
  
• WebSphere Integration Developer product information: Provides WebSphere Integration Developer product information, including requirements and how to purchase.
  
  

About the authors

Arnauld Desprets is an IT architect with IBM Software Services for WebSphere in the United Kingdom. Arnauld has over 10 years of consulting with companies all over Europe. He has over eight years of experience with WebSphere Application Server, and now specializes in SOA and Web services, especially in WS-Security. His latest interest is on the role of governance and the registry, including the WebSphere Services Registry and Repository in an SOA. You can reach Arnauld at arnauld_desprets@fr.ibm.com.

Laurent Rieu is an IT Architect working for the Worldwide SOA Advanced Technology team (formerly known as Enterprise Integration Solutions) within IBM Software Group. As part of this worldwide team, Laurent acts as a Europe/ Middle East/Asia (EMEA) Lead Solution Architect and helps drive and enhance IBM software strategy around SOA through customer engagements, field-based development, asset harvesting, and thought leadership. Laurent has more than eight years of experience in the IT industry and has been working at IBM for seven years in various industries across Europe. He received his MS from Ecole Supérieure d’Electricité (Supélec) in 1998. You can reach Laurent at Laurent.Rieu@fr.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Designing a service life cycle
• Creating a custom service life cycle
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: WebSphere Integration Developer (in the SOA Sandbox: Connect)
• Demo: Process automation, adoption pattern
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Integration Developer (in the SOA Sandbox: Connect)

Dig deeper into WebSphere on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers