Integrating IBM metadata repositories, Part 2: Governing the metadata lifecycle in WebSphere Service Registry and Repository

Learn how to enable asset-based development by integrating your applications with IBM® Rational® Asset Manager. In Part 2, you'll learn how to use WebSphere® Service Registry and Repository for defining and governing the metadata lifecyle.

Share:

Bei Bei Wang (wangbeib@cn.ibm.com), Software Engineer, IBM

Bei Bei Wang photoBei Bei Wang is a Software Engineer at the SOA Design Center in the China Development Lab. She focuses on SOA governance related topics, and is currently a developer working on the SOA Federated Metadata Management (FMDM) incubation project.



Tian Tan (tantbj@cn.ibm.com), Software Engineer, IBM

Tian Tan photoTian Tan joined the SOA Design Center of the China Development Lab as a software engineer in 2007. In the past two years, he worked on the FMDM incubation project, focusing on Rational Asset Manager integration, metadata management, ontology, and the semantic web. He has extensive experience in Java, J2EE, Eclipse RCP and Web 2.0 related techniques. Tan Tian is an IBM Certified SOA Solution Designer.



Zhe Yan (yanzhe@cn.ibm.com), Software Engineer, IBM

Zhe Yan photoZhe Yan is a staff software engineer working at the SOA Design Center in the China Development Lab. He concentrates on SOA governance -elated topics, especially metadata federation. He is currently doing design and development related to the integration of WBG and WebSphere Services Registry and Repository.



Xiao Xing Liang, Software Engineer, IBM

Xiao Xing Liang photoXiao Xing Liang is a software engineer working at the SOA Design Center in the China Development Lab. He is an IBM Certified WebSphere Enterprise Developer and an IBM Certified SOA Solution Designer. His current focus is on SOA governance and related topics including WebSphere Service Registry and Repository, Rational Asset Manager, Tivoli Application Dependency Discovery Manager, and Tivoli Change and Configuration Management Database.



Yu Chen Zhou (zhouyuc@cn.ibm.com), Architect, IBM

Yu Chen Zhou photoYu Chen Zhou is a Staff Software Engineer at the IBM China Software Development Lab. His work focuses on pervasive and portal solutions. He can be reached at zhouyuc@cn.ibm.com.



Chuan Feng Li (lichuanf@au1.ibm.com), Software Engineer, IBM

Chuan Feng Li photoChuan Feng Li is a Software Engineer working at the SOA Design Center in IBM's China Software Development Lab. He has several years of work experience in the IT industry, and is strongly interested in software development and application. Currently, he is engaged in development work relevant to ESB and SCA.



03 February 2010

Also available in Chinese Spanish

Introduction

Using the 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
Configuration profile

(See a larger version of Figure 1.)


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: InterfaceLifecycle, PolicyLifecycle, ServiceVersionLifecycle and ServiceLifecycle. Each composite state includes a sub-state machine.

Figure 2. Lifecycle definition in the governance profile
Lifecycle definition in the governance profile
Figure 3. Lifecycle definition in Integration Developer graph view
Lifecycle definition in graph view in WebSphere Integration Developer

(See a larger version of Figure 3.)

Governance policies

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
Governance policies

Each composite state must have a policy that defines which types it is suitable for. For example, the ServiceInterfaceLifecycle - InitiatePolicy governance policy describes the requisite conditions applicable for the ServiceInterfaceLifecycle. Listing 1 shows part of the ServiceInterfaceLifecycle - InitiatePolicy governance policy.

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 WSRROperationFilter and specify that only the MAKE_GOVERNABLE and TRANSITION operations are applicable for the policy. MAKE_GOVERNABLE makes an ungoverned metadata governed, and TRANSITION transitions the state of a governed metadata.
  • Lines 10-14 indicate the policy is suitable for the InitiateInterfaceLifecycle transition, which enters into the InterfaceLifecycle sub-state machine (see in Figure 2).
    http://www.ibm.com/xmlns/prod/serviceregistry/6/1/ GovernanceProfileLifecycle#InitiateInterfaceLifecycle
    specifies the appropriate transition classification URL.
  • Lines16-43 describe the ServiceInterfaceLifecycle limits to metadata of the following types: XSDDocument, ServiceInterface, ServiceBinding and MessageSchema.

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 - ApproveInterfacePolicy governance policy.

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 WSDL document.


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 InterfaceLifecycle, ServiceVersionLifecycle and ServiceLifecycle.

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 - ApproveForDeploymentPolicy 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 portType definition 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
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 console.

  1. 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.
  2. To create a generic object called MathService representing 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.
  3. 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.
  4. Next, you need to develop the math service interface, MathInterface.wsdl. MathInterface.wsdl defines the WSDL portType (see in SampleWSDLs.zip). Two operations, add_X_to_Y and subtract_X_from_Y, stand for addition and subtraction in math.
  5. Publish the MathInterface.wsdl by selecting Sevice Documents => WSDL Documents to load MathInterface.wsdl. Math (hereafter called Math(PT)) as a PortType of a logical derivation and Math (hereafter called Math(SI)) as a Service Interface of a generic object are automatically created; Math(SI) has an Authoritative WSDLS relationship to MathInterface.wsdl and an Interface Declarations relationship 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.

  6. Now you need to make the Service Interface governable and set the state to model phase. Switch to the Governance tab of the Math(SI), and select Initiate Interface Life Cycle from the Initial state transitions list, and click Govern. The governance state of the Math(SI) changes to the Specify state. Based on the analysis of the governance policy in Listing 1, we know that the lifecycle of Math(SI) is authorized to follow the InterfaceLifecycle sub-state machine. Based on the governance policy in Listing 2, the Math(SI) satisfies the precondition of the ApproveInterface transition, 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 Published because it is in the same governance group with Math(SI).
    Figure 6. Set the state of the service interface to Published
    Set state of service interface to Published

Assemble the service

Complete the following steps to assemble the service:

  1. Develop the binding of the math service, MathBinding.wsdl. MathBinding.wsdl defines the WSDL binding, which imports MathInterface.wsdl (see in SampleWSDLs.zip).
  2. 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 successful. MathSoapBinding (hereafter called MathSoapBinding(B)) as a Binding of a logical derivation and MathSoapBinding (hereafter called MathSoapBinding(SB)) as a Service Binding of a generic object are created automatically; MathSoapBinding(SB) has a Authoritative WSDLS relationship to MathBinding.wsdl, a Binding Declarations relationship to MathSoapBinding(B) and a Associated Interface relationship to Math(SI).

    Select Business Metadata => Governance Service View => Service Bindings, and click MathSoapBinding(SB) to see the dependencies in Details view of the metadata.

  3. The lifecycle of Service Binding is also authorized to follow the InterfaceLifecycle sub-state machine. Make MathSoapBinding(SB) governable and transition the governance state to Published as in step 6 above.
  4. Add Math(SI) to MathService’s Governed Service Interface relationship. The lifecycle of Business Service is authorized to follow the ServiceLifecycle sub-state machine, which you could see in the governance policy. (Refer to the samples in Overview of the Service Registry governance profile.) Make MathService governable 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
    Set the state of the business service to Assemble

Deploy the service

Complete the following steps to deploy the service:

  1. 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.
  2. Publish and classify MathService.wsdl. Publish MathService.wsdl into Service Registry as before. MathService as a Service of a logical derivation and MathService (hereafter called MathService(SV)) as a Service Version of a generic object are created automatically. Add a Test classification to MathService.wsdl as 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
    Add a Test classification to the WSDL
  3. The lifecycle of Service Version is authorized to follow the ServiceVersionLifecycle sub-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
    Service Version follows ServiceVersionLifecycle
    Figure 10. Set state of service version to Service Version Deploy
    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 Assemble to the Service Version Deploy governance 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 - ApproveForDeploymentPolicy governance policy.

    Figure 11. State transition error
    State transition error
  4. Add MathService(SV) to MathService’s Realizing Governed Services relationship. Then, transition the governance state of MathService to Deploy.

Manage the service

Complete the following steps to manage the service:

  1. 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 Test classification and add the Production classification for MathService.wsdl.
  2. Govern the Service Version and Business Service. Transition the governance state of MathService(SV) to Service Version Manage and MathService to Manage, meaning that the math service has been used in practice and is entering management phase.
  3. When the math service is uninstalled, transition the governance state of MathService to Service Retired and MathService(SV) to Service Version Retired. Notice that the transition of MathService must 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 Business Service, MathService is in Service Retired governance state.
    Figure 12. State transition errors
    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.

Configure syncrhonization

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
New a connection to a Service Registry server in RAM

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.

  1. As an example, develop an AddressBook service that is used to store and find addresses. In the Rational Asset Manager Web console, submit the asset AddressBook with 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 AddressBook service, indicating that the service has been developed completely.
  2. Click Publish to service registry for the AddressBook asset 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
    Synchronization an asset from RAM to Service Registry

    (See a larger version of Figure 14.)

  3. 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
    Add classifications when publishing the asset from RAM to Service Registry
  4. After the synchronization successfully completes, open the Service Registry Web console to see the new metadata that were created: a generic object AddressBook as a RationalAssetManagerAsset (hereafter called AddressBook(RAMA)) represents the AddressBook asset 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 AddressBook, AddressBookBinding, AddressBookPort and AddressBookService are generated automatically when the WSDL document is published. Figure 16 shows the details of AddressBook(RAMA).
    Figure 16. AddressBook(RAMA) details AddressBook(RAMA) details
    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 and 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
Synchronization from Service Registry to RAM

(See a larger version of Figure 17.)

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 other 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 AddressBook(RAMA) in the Service Registry Web console; and Publish by relates to the 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
AddressBook Asset details from Service Registry to RAM

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) BsrURI, Governance State, 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 design-time repository.

Figure 19. MathBinding.wsdl details from Service Registry to Rational Asset Manager
MathBinding.wsdl details from Service Registry to RAM

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.

Summary

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.


Download

DescriptionNameSize
Sample WSDL filesSampleWSDLs.zip3KB

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, Rational
ArticleID=466039
ArticleTitle=Integrating IBM metadata repositories, Part 2: Governing the metadata lifecycle in WebSphere Service Registry and Repository
publish-date=02032010