End of Support for WebSphere Service Registry and Repository

Your data is valuable and making it readily available for immediate continuity is indispensable. WebSphere Service Registry and Repository (WSRR) will soon be going out of service and we need to perform migration of legacy service descriptions out of WebSphere Service Registry and Repository to a new SOA Domain. Given the large number of services, we must automate the complete process.

Adopting Modern Software Delivery Methods with GitLab for WebSphere Service Registry and Repository

Challenges
  • The existing DataPower Gateway and SOA service deployment process must be made independent of WSRR which will soon be going out of service.
  • The appliances placed in the network must be modified to allow more bandwidth to the object services and to isolate management traffic from data.

Findings

Current System: We can represent the current system as,

  • The Developer will create, maintain and deploy to WSRR a service’s SLDs, WSDL and XSDs.
  • WSRR will publish as the subscribing DataPower demands the current services and policies, and on a service call DataPower will request the URL for a Client and Context ID from WSRR.
  • On a Client call, the DataPower appliance will collect URLs from WSRR, fetch WSDLs from the Provider and will pass the call to the Provider.

Revised System: The revised system after removing WSRR is,

The red path shows,

  • The migration of legacy services from WSRR to the DEV desk.
  • The DEV push of legacy or new services to the SOA Domain through an Admin Gateway.

The blue path is the legacy route skipping the paths which are now obsoleted.

To support these new flows we will need the following,

  • Programs or scripts at the DEV desk to extract metadata and construct service definitions for the appliance.
  • Admin Gateway on the appliance for managing service descriptions on the SOA Domain’s local: // directory.
  • SOA Gateway which will work from the on-board service descriptions to proxy SOAP requests identical to the existing legacy gateway.

Suggested Solution

The suggested solution includes 4 major activities

Extract Metadata

A standalone java application is created which will collect the fraction of WSRR information that DataPower will need to proxy the legacy services. The fetched information is packaged as a service description for follow on processing and uploaded to GitHub repository.

GitLab Automation

A shell script is created which will be executed by GitLab’s CI/CD runner configuration. This automation process will upload the service descriptions in GitHub under its respective Service names to DataPower’s local File Management.

Admin Gateway

A MPG created in DataPower which implements these operations,

  • POST /services//status/down: Rejects new service calls with an HTTP Response Code of 500.
  • POST /services//status/up: Marks the service up and the SOA Gateway will work as intended.
  • GET /services: Return the list of service names.
  • GET /services/: Return the list of WSDL, Config and XSD files.
  • DELETE /services/: Deletes the service folder.

SOA Gateway

A MPG created in DataPower which performs these operations,

  • Reads the config.xml to get the backend URL and WSDL location.
  • Checks the status of the service in the config.xml file. If Down, returns “Service marked as DOWN” response.
  • Uses the WSDL to perform Request and Response validation.
  • In addition to the above operations, performs the underlying policy rules from the legacy Web Service Proxy.

GIT-Based Collaboration Tool with Royal Cyber

To speed up your DevOps lifecycle with Royal Cyber sign up for a free demo. For more information of how we can do this migration, email us at info@royalcyber.com or visit www.royalcyber.com.

Leave a Reply