WebSphere Service Registry and Repository (hereafter called
Service Registry) governance profile as an example, this article describes
lifecycle definition and governance policies, and their usage in service
governance. It also introduces an integration metadata solution called
Service Registry Advanced Lifecycle Edition (Service Registry ALE) through
the design-time and runtime lifecycle.
Service Registry configuration profiles
Service Registry V6.0.2 introduces a concept called a configuration profile, which contains a complete set of Service Registry configuration files. Its functionality extends gradually in later versions, and in Service Registry V6.2 you can customize a set of configuration files, including access control, business model systems, classification systems, lifecycles, Web user interfaces, user-defined validators, modifiers and notifiers. Service Registry V6.2 provides a default profile, as well as a governance profile suitable for real application environment. Both of these profiles are loaded at installation. To see the configuration profiles and their status, as shown in Figure 1, switch to the Configuration perspective in the Service Registry Web console, and select Manage Configuration Profiles => Configuration Profiles. You can load as many profiles as you like into Service Registry, but only one can be Active at a given time. All others will be Archived. To make a different profile active, select the profile and click Make Active. In the navigation tree, expand Active Configuration Profile, you can see all items defined in the active profile, as shown in Figure 1.
Figure 1. Configuration profiles
Overview of the Service Registry governance profile
The Service Registry V6.2 governance profile is a set of Service Registry configuration artifacts, including business models, classification systems, lifecycles and governance policies that support basic SOA governance. This profile is intended as a starting point for Service Registry SOA governance. You can modify the business model, lifecycles and policies to meet your requirments.
This section introduces the lifecycle and governance policies of the governance profile, which provide the promotion of service through their lifecycle as an important governance function. Then next section will explain in detail how to use them.
Composite state machine
A lifecycle model for governed metadata uses a business state machine to describe the lifecycle states and the transition between them. Using the visual editor in WebSphere Integration Developer (Integration Developer),
In the default profile, only one SOA lifecycle is supported. However, in a real-world application, it's unlikely that all metadata of various types in Service Registry would follow this lifecycle. Therefore, the governance profile provides a composite state machine, in which metadata of different types can follow different sub-state machines.
Using the Life Cycle Configuration view, shown in Figure 2, you can view and update the content of
the lifecycle definition, and also import the file into Integration
Developer to see it in a graph view, as shown in Figure
3. The initial state is Create, and the terminate
state is Completed. There are four composite states:
Each composite state includes a sub-state machine.
Figure 2. Lifecycle definition in the governance profile
Figure 3. Lifecycle definition in Integration Developer graph view
After viewing the above business state machine, you may have a couple of questions:
- Which type or types of entities is a certain sub-state machine suitable for?
- When executing a transition from one state to another, are there requisite conditions for the metadata?
The answers to both of these are defined in governance policies. You can view and customize these settings from the Service Registry Web console Configuration perspective by selecting Active Configuration Profile => Plug-ins => Governance Policies, as shown in Figure 4.
Figure 4. Governance policies
Each composite state must have a policy that defines which types it is
suitable for. For example, the
governance policy describes the requisite conditions applicable for the
ServiceInterfaceLifecycle. Listing 1
shows part of the
ServiceInterfaceLifecycle - InitiatePolicy
Listing 1. Part of ServiceInterfaceLifecycle - InitiatePolicy governance policy
1 <wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy" … > 2 <wsrrgp:ValidatorPolicy wsrrgp:name="ServiceInterfaceLifecycle 3 - Initiate Policy 4 … 5 <wsrrgp:WSRROperationFilter> 6 7 <wsrrgp:WSRROperation>MAKE_GOVERNABLE</wsrrgp:WSRROperation> 8 <wsrrgp:WSRROperation>TRANSITION</wsrrgp:WSRROperation> 9 </wsrrgp:WSRROperationFilter> 10 <wsrrgp:TransitionOperationFilter> 11 <wsrrgp:TransitionOperation> 12 http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileLifecycle 13 #InitiateInterfaceLifecycle 14 </wsrrgp:TransitionOperation> 15 </wsrrgp:TransitionOperationFilter> 16 <wsrrgp:EntityAssertionPolicy> 17 <wsp:Policy wsrr:policyClass="EntityAssertionClass" 18 wsrr:policyClassDomain="http://www.ibm.com.policy/GovernancePolicyDomain"> 19 <wsrrgp:AnyOfAssertion 20 wsrrgp:name="GovernanceProfileLifecycleInitializationPolicy. 21 ServiceInterfaceLifecycleEntityAssertion"> 22 <wsrrgp:EntityAssertion 23 wsrrgp:name="GovernanceProfileLifecycleInitializationPolicy. 24 ServiceInterfaceLifecycleEntityAssertion" 25 wsrrgp:entityType="XSDDocument" /> 26 <wsrrgp:EntityAssertion 27 wsrrgp:name="GovernanceProfileLifecycleInitializationPolicy. 28 ServiceInterfaceLifecycleEntityAssertion" 29 wsrrgp:primaryType="http://www.ibm.com/xmlns/prod/serviceregistry 30 /6/1/TechnicalModel#ServiceInterface" /> 31 <wsrrgp:EntityAssertion 32 wsrrgp:name="GovernanceProfileLifecycleInitializationPolicy. 33 ServiceInterfaceLifecycleEntityAssertion" 34 wsrrgp:primaryType="http://www.ibm.com/xmlns/prod/serviceregistry 35 /6/1/TechnicalModel#ServiceBinding" /> 36 <wsrrgp:EntityAssertion 37 wsrrgp:name="GovernanceProfileLifecycleInitializationPolicy. 38 ServiceInterfaceLifecycleEntityAssertion" 39 wsrrgp:primaryType="http://www.ibm.com/xmlns/prod/serviceregistry 40 /6/1/TechnicalModel#MessageSchema" /> 41 </wsrrgp:AnyOfAssertion> 42 </wsp:Policy> 43 </wsrrgp:EntityAssertionPolicy> 44 … 45 </wsrrgp:ValidatorPolicy> 46 </wsp:Policy>
- Lines 5-9 define
WSRROperationFilterand specify that only the
TRANSITIONoperations are applicable for the policy.
MAKE_GOVERNABLEmakes an ungoverned metadata governed, and
TRANSITIONtransitions the state of a governed metadata.
- Lines 10-14 indicate the policy is suitable for the
InitiateInterfaceLifecycletransition, which enters into the
InterfaceLifecyclesub-state machine (see in Figure 2).
specifies the appropriate transition classification URL.
- Lines16-43 describe the
ServiceInterfaceLifecyclelimits to metadata of the following types:
For each metadata type compatible with a composite state, every transition
in the sub-state machine has a policy for restriction. For instance, the
ServiceInterfaceLifecycle - ServiceInterface - ApproveInterfacePolicy
governance policy describes the requisite conditions when executing the
ApproveInterface transition for metadata of
Service Interface type. Listing 2
shows part of the
ServiceInterfaceLifecycle - ServiceInterface
Listing 2. Part of ServiceInterfaceLifecycle - ServiceInterface - ApproveInterfacePolicy governance policy
1 <wsp:Policy xmlns:wsp="http://www.w3.org/ns/ws-policy" ... > 2 <wsrrgp:ValidatorPolicy wsrrgp:name="ServiceInterface Lifecycle 3 - ServiceInterface - ApproveInterface Policy"> 4 <wsp:Policy … wsp:Name="urn:ServiceInterfaceLifecycle_ServiceInterface_ 5 ApproveInterfacePolicy"> 6 … 7 <wsrrgp:TransitionOperationFilter> 8 <wsrrgp:TransitionOperation> 9 http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileLifecycle 10 #ApproveInterface 11 </wsrrgp:TransitionOperation> 12 </wsrrgp:TransitionOperationFilter> 13 <wsrrgp:EntityAssertionPolicy> 14 <wsp:Policy …> 15 <wsrrgp:RelationshipAssertion 16 wsrrgp:relationshipName="wsrrtm_authoritativeWSDLs" 17 wsrrgp:minCardinality="1" wsrrgp:maxCardinality="1" 18 wsrrgp:name="ServiceInterfaceLifecyclePolicy. 19 ExactlyOneAuthoritativeInterfaceWSDLAssertion"> 20 <wsrrgp:EntityAssertion wsrrgp:entityType="WSDLDocument" 21 wsrrgp:name="ServiceInterfaceLifecyclePolicy. 22 ExactlyOneAuthoritativeInterfaceWSDLAssertion" /> 23 </wsrrgp:RelationshipAssertion> 24 </wsp:Policy> 25 </wsrrgp:EntityAssertionPolicy> 26 </wsp:Policy> 27 </wsrrgp:ValidatorPolicy> 28 </wsp:Policy>
Lines 15-23 define a condition that the metadata of
Service Interface type must satisfy or the transition will
fail to execute. In addition, the metadata should have a
wsrrtm_authoritativeWSDLs relationship to one and only one
Using the Service Registry governance profile
Service Registry can be used across all phases of the SOA lifecycle. Let’s
look at a scenario to illustrate how to use a composite state machine and
governance policies for metadata governance. Several types of lifecycles
defined in the governance profile are involved in this scenario, including
The governance profile can be easily customized to meet user requirements,
such as modifying the lifecycle or changing governance policies. In this
example, we'll modify the
ServiceLifecycle - BusinessService -
governance policy, as shown in Listing 3. Sections
in bold are added to loosen the restriction, the condition of Business
Service with both classifications under
wsrrgp:ClassificationAssertion relaxes to either one of them.
Listing 3. Customize ServiceLifecycle – BusinessService - ApproveForDeploymentPolicy
<wsrrgp:RelationshipAssertion wsrrgp:relationshipName="wsrrgp_realizingServices" wsrrgp:minCardinality="1" wsrrgp:name="ServiceLifecyclePolicy.DeployedServiceVersionAvailableAssertion"> <wsrrgp:EntityAssertion wsrrgp:entityType="GenericObject" wsrrgp:name="ServiceLifecyclePolicy.DeployedServiceVersionAvailableAssertion"> <wsrrgp:ClassificationAssertion wsrrgp:combinationCode="Any"> <wsrrgp:Classification> http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileLifecycle #ServiceVersionDeploy </wsrrgp:Classification> <wsrrgp:Classification> http://www.ibm.com/xmlns/prod/serviceregistry/6/1/GovernanceProfileLifecycle #ServiceVersionManage </wsrrgp:Classification> </wsrrgp:ClassificationAssertion> </wsrrgp:EntityAssertion> </wsrrgp:RelationshipAssertion>
Service description entities are a category of metadata in the information model maintained by Service Registry that includes physical documents, logical derivations and generic objects. To see these, switch to the GP Administrator perspective in the Service Registry Web console.
- Physical documents: Actual documents that describe a service, such as a WSDL document. To see physical document types, expand Service Documents in the navigation tree.
- Logical derivations: Service Registry automatically parses physical
documents to generate derived objects to represent constructs within
the document, such as a
portTypedefinition derived from a WSDL. To see logical derivation types, expand Service Metadata in the navigation tree.
- Generic objects: Generic objects represent anything in the information model that does not have a physical document in Service Registry. To see generic objects, select Business Metadata => Concepts.
In our scenario, three types of generic objects are used: Business Service, Service Interface and Service Version. Figure 5, gives you an overview of the relationship among them and their respective lifecycles.
Figure 5. Several types of lifecycle and state transition preconditions
More details are in the following scenario description steps. We'll take the math service as an example. This service is a simple math calculation service, providing addition and subtraction operations.
Model the service
Complete the following steps to model the service. Refer to Service
Registry configuration profiles to activate
WSRR_GOVERNANCE_PROFILE in the Service Registry Web
- Select Business Metadata => Business Service View =>
Organizations and create an organization with the name
Sample. Click Sample in Governance dialog, then click Govern to make it governable.
- To create a generic object called
MathServicerepresenting the math service, switch to the GP Administrator perspective, and select Business Metadata => Business Service View => Business Services. Create a business service called
MathService. In the Details dialog, click Edit Relationships, add Sample to
MathService’s Owning Organization relationship, and click Finish.
- Click Edit Classification and select Governance Profile Taxonomy => Business Domain => Finance, and add it to MathService.wsdl, indicating the math service applies in the finance industry.
- Next, you need to develop the math service interface,
MathInterface.wsdl. MathInterface.wsdl defines the WSDL
portType(see in SampleWSDLs.zip). Two operations,
subtract_X_from_Y, stand for addition and subtraction in math.
- Publish the MathInterface.wsdl by selecting Sevice Documents
=> WSDL Documents to load MathInterface.wsdl. Math
Math(PT)) as a
PortTypeof a logical derivation and Math (hereafter called
Math(SI)) as a
Service Interfaceof a generic object are automatically created; Math(SI) has an
Authoritative WSDLSrelationship to MathInterface.wsdl and an
Interface Declarationsrelationship to Math(PT).
Select Business Metadata => Governance Service View => Service Interfaces, and click Math(SI) to see the dependencies in the Details view of the metadata.
- Now you need to make the
Service Interfacegovernable and set the state to model phase. Switch to the Governance tab of the Math(SI), and select
Initiate Interface Life Cyclefrom the Initial state transitions list, and click Govern. The governance state of the Math(SI) changes to the
Specifystate. Based on the analysis of the governance policy in Listing 1, we know that the lifecycle of Math(SI) is authorized to follow the
InterfaceLifecyclesub-state machine. Based on the governance policy in Listing 2, the Math(SI) satisfies the precondition of the
ApproveInterfacetransition, so you can click Transition to change the governance state to
Published, as shown in Figure 6. The governance state of MathInterface.wsdl is also
Publishedbecause it is in the same governance group with Math(SI).
Figure 6. Set the state of the service interface to Published
Assemble the service
Complete the following steps to assemble the service:
- Develop the binding of the math service, MathBinding.wsdl. MathBinding.wsdl defines the WSDL binding, which imports MathInterface.wsdl (see in SampleWSDLs.zip).
- Publish MathBinding.wsdl into Service Registry as step 5 above. Since
MathInterface.wsdl already exists in Service Registry, the import
relationship satisfies and publishing MathBinding.wsdl will be
MathSoapBinding(B)) as a Binding of a logical derivation and
MathSoapBinding(SB)) as a Service Binding of a generic object are created automatically;
Authoritative WSDLSrelationship to MathBinding.wsdl, a
Binding Declarationsrelationship to
Associated Interfacerelationship to
Select Business Metadata => Governance Service View => Service Bindings, and click MathSoapBinding(SB) to see the dependencies in Details view of the metadata.
- The lifecycle of
Service Bindingis also authorized to follow the
InterfaceLifecyclesub-state machine. Make
MathSoapBinding(SB)governable and transition the governance state to
Publishedas in step 6 above.
Governed Service Interfacerelationship. The lifecycle of
Business Serviceis authorized to follow the
ServiceLifecyclesub-state machine, which you could see in the governance policy. (Refer to the samples in Overview of the Service Registry governance profile.) Make
MathServicegovernable and transition the governance state to Assemble, as shown in Figure 7, to indicate that the service is completely assembled.
Figure 7. Set the state of the business service to assemble
Deploy the service
Complete the following steps to deploy the service:
- Develop the endpoint of the math service. MathService.wsdl defines the WSDL endpoint that is the SOAP address to access the math service. MathService.wsdl imports MathBinding.wsdl (see in SampleWSDLs.zip). You can use the sample WSDLs provided for download, or refer to Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language for more information on writing WSDLs.
- Publish and classify MathService.wsdl. Publish MathService.wsdl into
Service Registry as before.
MathServiceas a Service of a logical derivation and
MathService(SV)) as a Service Version of a generic object are created automatically. Add a Test classification to
MathService.wsdlas shown in Figure 8, indicating that the math service is deployed in a test environment application server.
Figure 8. Add a Test classification to the WSDL
- The lifecycle of Service Version is authorized to follow the
ServiceVersionLifecyclesub-state machine based on the governance policies. Make
MathService(SV)governable (see Figure 9) and transition the governance state to Service Version Deploy (see Figure 10) to indicate that the math service has been deployed.
Figure 9. Service Version follows ServiceVersionLifecycle
Figure 10. Set state of service version to Service Version Deploy
If MathService.wsdl is not classified as Test, when executing the transition from the
Service Version Assembleto the
Service Version Deploygovernance state of
MathService(SV), you'll see the error shown in Figure 11. Because the
MathService(SV)should have at least one related endpoint WSDL with a Test classification. You could get this related endpoint WSDL from the
ServiceVersionLifecycle - ServiceVersion - ApproveForDeploymentPolicygovernance policy.
Figure 11. State transition error
Realizing Governed Servicesrelationship. Then, transition the governance state of
Manage the service
Complete the following steps to manage the service:
- Classify MathService.wsdl. Once the math service is running well in
the test environment, you can deploy it in a production environment
for real use. Remove the
Testclassification and add the
Productionclassification for MathService.wsdl.
- Govern the Service Version and Business Service. Transition the
governance state of
Service Version Manageand
Manage, meaning that the math service has been used in practice and is entering management phase.
- When the math service is uninstalled, transition the governance state
Service Version Retired. Notice that the transition of
MathServicemust be done first. If the sequence reverses, you'll get an error when executing the transition of
MathService(SV)(Figure 12). Governance policies have a restriction that means that the transition of
MathService(SV)can only be executed when its related
Service Retiredgovernance state.
Figure 12. State transition errors
Using Service Registry ALE for lifecycle governance
Service Registry can integrate with some other IBM products to govern metadata throughout their lifecycles, from design-time to runtime. Service Registry ALE V6.2 consists of Service Registry V6.2 and IBM Rational® Asset Manager V7.1, which work together to govern the service lifecycle from creation to consumption. In this section we'll describe how to use Service Registry ALE, especially how to configure synchronization and the integration between Service Registry and Rational Asset Manager in order to implement metadata governance through complete lifecycles.
Synchronization configuration is done in Rational Asset Manager. Choose a Community, such as WSRR ALE, and create a new connection to a Service Registry server, as shown in Figure 13. Use the following information to create the connection:
- URL: Service Registry server URL.
- Login and Password: Necessary for Service Registry with security.
- Type: Publish allows synchronization from RAM to Service Registry; Synchronize is the reverse synchronization direction (Service Registry to RAM); Publish and Synchronize supports both directions.
After configuration, click Test Connection to ensure that the changes have taken effect.
Figure 13. New a connection to a Service Registry server in Rational Asset Manager
Using Service Registry ALE at design time
Rational Asset Manager manages information for reusable assets, especially at design time. Complete the following steps to implement ALE solution at design time.
- As an example, develop an
AddressBookservice that is used to store and find addresses. In the Rational Asset Manager Web console, submit the asset
AddressBookwith an artifact service WSDL called AddressBook.wsdl (see SampleWSDLs.zip). For more information about the concepts of assets and artifacts, refer to Part 1 of this series. The asset has all the relevant details about the
AddressBookservice, indicating that the service has been developed completely.
- Click Publish to service registry for the
AddressBookasset to synchronize the asset from Rational Asset Manager to Service Registry, as shown in Figure 14. Notice that only assets in the WSRR ALE community configured for synchronization can be published to Service Registry. Moreover, synchronization is executed for one asset manually, rather than automatically or for multiple assets at a time. Because Service Registry is a runtime metadata repository, the metadata should be managed strictly and carefully.
Figure 14. Synchronization an asset from RAM to Service Registry
- Select the artifacts to be published, check the destination, and add
classifications in the Categorize page, search and
select metadata in Service Registry in the Associate
page, and then publish AddressBook.wsdl. Rational Asset Manager has a
local copy of the classification systems after the first
synchronization from Service Registry, so you can now add
classifications. The governance profile lifecycle is a classification
system in Service Registry. Select and add State/Interface
Life Cycle/Published, as shown in Figure 15.
Figure 15. Add classifications when publishing the asset from Rational Asset Manager to Service Registry
- After the synchronization successfully completes, open the Service
Registry Web console to see the new metadata that were created: a
RationalAssetManagerAsset(hereafter called AddressBook(RAMA)) represents the
AddressBookasset in Rational Asset Manager; a WSDL document AddressBook.wsdl corresponds to the artifact AddressBook.wsdl selected in Rational Asset Manager; other generic objects such as
AddressBookServiceare generated automatically when the WSDL document is published. Figure 16 shows the details of
Figure 16. AddressBook(RAMA) details
Following are some general tips for synchronization from Rational Asset Manager to Service Registry at design time:
- Use Service Registry V6.2 classification systems during synchronization of an asset.
- Provide the function of searching metadata in Service Registry and adding relationships to the asset.
- After synchronization, the asset corresponds to a generic object, artifacts correspond to documents, and the relationship of asset and artifacts maps to the relationship added on the generic object.
Using Service Registry ALE at runtime
Service Registry manages metadata information, especially at runtime, such
as the service dynamic lookup or service governance. At runtime, the
service goes through test, production, and eventually retire phases. In
Service Registry, the Service Version continues to be governed through
Service Version Deploy,
Service Version Manage
Service Version Retired correspondingly.
Synchronization from Service Registry to Rational Asset Manager can be implemented either manually or automatically at a scheduled time. To implement the synchronization manually, open the Rational Asset Manager Web console and click Synchronize for a configured Service Registry server. You'll see the synchronization results as shown in Figure 17.
Figure 17. Synchronization from Service Registry to RAM
To implement the synchronization automatically at a scheduled time, you'd need to set the time using the Synchronization schedule during configuration (see Figure 13).
After synchronization from Service Registry to Rational Asset Manager, the
AddressBook asset is created in the WSRR ALE community
of Rational Asset Manager. On the General Details page,
shown in Figure 18, BsrURI
represents the unique ID in Service Registry; Link
directs to the corresponding metadata
the Service Registry Web console; and Publish by relates
AddressBook asset submitted in design-time. Using this
method, you not only integrate metadata in Rational Asset Manager and
Service Registry, but also relate them at design and runtime.
Figure 18. AddressBook details from Service Registry to Rational Asset Manager
In addition, other metadata that doesn't exist in Rational Asset Manager
could be synchronized at this time. For example, MathInterface.wsdl,
MathBinding.wsdl and MathService.wsdl in Service Registry are published to
Rational Asset Manager as three assets. On the General
Details page of an asset, (such as the MathBinding.wsdl asset
show in Figure 19)
Governance Profile Life Cycle
and relationships are all achieved, as well as a link connecting to the
original metadata in Service Registry Web console. In this way, metadata
managed in Service Registry can be reused in the Rational Asset Manager
Figure 19. MathBinding.wsdl details from Service Registry to Rational Asset Manager
In conclusion, synchronization from Service Registry to Rational Asset Manager at runtime includes the following:
- A WSDL document in Service Registry corresponds to an asset in Rational Asset Manager;
- The asset previously synchronized from Rational Asset Manager to Service Registry is republished to Rational Asset Manager, and the republished asset establishes a Publish by relationship to the original asset in Rational Asset Manager;
- A document relationship in Service Registry maps to an asset relationship;
- A governance lifecycle can be synchronized to Rational Asset Manager;
- If you delete a document in Service Registry, the corresponding asset in Rational Asset Manager is also deleted at next synchronization.
This article introduced the lifecycle and governance policies defined in the Service Registry governance profile, provided a scenario showing you how to use them, and provided an introduction to Service Registry ALE for integrated metadata management in both design and runtime lifecycles between Service Registry and Rational Asset Manager.
|Sample WSDL files||SampleWSDLs.zip||3KB|
- Asset lifecycle management for service-oriented architectures, Grant Larsen and Jack Wilber (developerWorks, 2005): This article examines the use of asset lifecycle management practices, tools, and standards in the development of service-oriented architecture (SOA) solutions. Effective lifecycle management of services enables organizations to apply tools and methods for governing, administrating, applying, and reusing these assets to augment the advantages of SOA development.
- WebSphere Service Registry and Repository Version 6.2 information center: Get complete product documentation.
- Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language: The WSDL specification.
- IBM WebSphere Service Registry and Repository Advanced Lifecycle Edition, V6.2: Get product information.
- developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.