Summary:
Websphere Service Registry & Repository (WSRR) is useful to register reusable Business Services and serves as a centralized repository to capture all metadata related to Service Lifecycle, Configuration and Deployment.
Purpose
This document aims to shed light on some of the WSRR migration issues from version 6.x to v7 and v7.5. WSRR v7 offers major improvements compared to previous versions in different areas such as performance, enhanced governance lifecycle, ontology support etc. To quote an example, we have seen significant improvements related to import and export of documents from Web UI after migrating to WSRR v7. So there are a handful of very good reasons to migrate to the newer version.
Migration Path & Best Practices:
A medium-size or large enterprise typically will have separate environments for Development, Testing and Production activities. The challenge is to accomplish migration of all environments minimizing the repetition of same tasks for each environment, thereby reducing the overall time to complete migration.
We have also taken into account future needs of the WSRR, as the Enterprise’s SOA Adoption Strategy evolves. The chosen migration path should be reusable for any enhancements to be done in future on WSRR dataset.
Upgrade In-place vs. New Install & Copy Dataset
Given both options for a typical migration project, I would prefer new install & copy of dataset. This is lesser error-prone, risk-free approach and would allow leveraging all new features available with the newer version after migration. To eliminate the confusion, IBM does not offer a solution to upgrade “In-place” in the case of WSRR. Instead, recommends a 2-step process for a successful migration.
Migration Tasks
Profile Migration:
• Capture profile in source repository using WSRR Web UI. Choose Configuration perspective, profile export option.
• Load the exported profile into target WSRR.
Note: If errors are encountered during the import, modify the profile using WSRR v7 Studio. Import the updated profile into WSRR v7.
Ontology Migration:
For this, ‘upgradetool.sh’ should be used. It involves the following 2 tasks.
i) Export the dataset. This will create a cloudscape database dump file.
ii) Import the dataset.
For a dataset with 200 documents and around 100 concepts, export took almost 40 hours. There were errors at the end of the long wait. We have to manually fix these errors using WSRR utility code developed in-house.
Why Cloudscape database is needed?
It might be useful if the database type of target WSRR v7 is different from source WSRR v6.x such as from SQL Server to Oracle or vice-versa. However, for most of the ESB Environments, it is unlikely to change the database type from one to another and breaks 80-20 rule. It adds unnecessary complexity to the overall migration process.
The following 2 approaches were considered for Migration.
Option A (Repeat Migration Tasks for each Environment):
• Migration of WSRR v6.x DEV to WSRRv7 DEV.
• Repeat this for 2 times to complete migration for QA and Production environments.
Option B (Migrate only once; leverage WSRR API features):
• Migration of WSRR v6.x DEV to WSRR v7 DEV.
• Reconcile dataset from QA and Production to WSRR v7 DEV using the WSRR client API. This will provide a good baseline dataset to setup Governance Repository in future.
• Develop WSRR client code to modify / migrate metadata using WSRR API. It is fairly simple and should not take longer time to develop.
• Build datasets for QA and Production from WSRR v7 DEV dataset using export utility available in WSRR v7 after classifying the dataset as DEV / QA / Production.
• Import dataset into QA.
• Import dataset into Production.
Decision Taken: We have used Option B for migration instead of Option A and successfully completed the Migration ahead of time.
Websphere Service Registry & Repository (WSRR) is useful to register reusable Business Services and serves as a centralized repository to capture all metadata related to Service Lifecycle, Configuration and Deployment.
Purpose
This document aims to shed light on some of the WSRR migration issues from version 6.x to v7 and v7.5. WSRR v7 offers major improvements compared to previous versions in different areas such as performance, enhanced governance lifecycle, ontology support etc. To quote an example, we have seen significant improvements related to import and export of documents from Web UI after migrating to WSRR v7. So there are a handful of very good reasons to migrate to the newer version.
Migration Path & Best Practices:
A medium-size or large enterprise typically will have separate environments for Development, Testing and Production activities. The challenge is to accomplish migration of all environments minimizing the repetition of same tasks for each environment, thereby reducing the overall time to complete migration.
We have also taken into account future needs of the WSRR, as the Enterprise’s SOA Adoption Strategy evolves. The chosen migration path should be reusable for any enhancements to be done in future on WSRR dataset.
Upgrade In-place vs. New Install & Copy Dataset
Given both options for a typical migration project, I would prefer new install & copy of dataset. This is lesser error-prone, risk-free approach and would allow leveraging all new features available with the newer version after migration. To eliminate the confusion, IBM does not offer a solution to upgrade “In-place” in the case of WSRR. Instead, recommends a 2-step process for a successful migration.
Migration Tasks
Profile Migration:
• Capture profile in source repository using WSRR Web UI. Choose Configuration perspective, profile export option.
• Load the exported profile into target WSRR.
Note: If errors are encountered during the import, modify the profile using WSRR v7 Studio. Import the updated profile into WSRR v7.
Ontology Migration:
For this, ‘upgradetool.sh’ should be used. It involves the following 2 tasks.
i) Export the dataset. This will create a cloudscape database dump file.
ii) Import the dataset.
For a dataset with 200 documents and around 100 concepts, export took almost 40 hours. There were errors at the end of the long wait. We have to manually fix these errors using WSRR utility code developed in-house.
Why Cloudscape database is needed?
It might be useful if the database type of target WSRR v7 is different from source WSRR v6.x such as from SQL Server to Oracle or vice-versa. However, for most of the ESB Environments, it is unlikely to change the database type from one to another and breaks 80-20 rule. It adds unnecessary complexity to the overall migration process.
The following 2 approaches were considered for Migration.
Option A (Repeat Migration Tasks for each Environment):
• Migration of WSRR v6.x DEV to WSRRv7 DEV.
• Repeat this for 2 times to complete migration for QA and Production environments.
Option B (Migrate only once; leverage WSRR API features):
• Migration of WSRR v6.x DEV to WSRR v7 DEV.
• Reconcile dataset from QA and Production to WSRR v7 DEV using the WSRR client API. This will provide a good baseline dataset to setup Governance Repository in future.
• Develop WSRR client code to modify / migrate metadata using WSRR API. It is fairly simple and should not take longer time to develop.
• Build datasets for QA and Production from WSRR v7 DEV dataset using export utility available in WSRR v7 after classifying the dataset as DEV / QA / Production.
• Import dataset into QA.
• Import dataset into Production.
Decision Taken: We have used Option B for migration instead of Option A and successfully completed the Migration ahead of time.
No comments:
Post a Comment