What is SOA Governance

SOA Governance is a set of policies, standards, and processes that organizations put in place to manage and maintain the quality and integrity of their Service-Oriented Architecture (SOA) over time. This can include things like setting standards for how services should be designed and implemented, establishing procedures for testing and deploying new services, and creating mechanisms for monitoring and managing the performance and availability of existing services. The goal of SOA Governance is to ensure that services are designed and implemented in a way that is consistent, reliable, and secure, and that they continue to meet the needs of the organization as it evolves over time.


One of the key components of SOA Governance is establishing clear guidelines and policies for service design and development. This might include things like defining standards for how services should be named, organized, and exposed, or specifying which security or compliance requirements services must meet. By establishing these guidelines, organizations can ensure that services are developed in a consistent way that aligns with the overall architecture and goals of the organization.


Another important aspect of SOA Governance is creating and maintaining a registry of services that are available for use within the organization. This registry is typically used to document the capabilities of each service, including information on how it can be accessed, what data it requires, and what output it returns. This information can be used to help other teams or developers understand how to interact with the service, and can help ensure that services are being used correctly and effectively. Additionally, monitoring and managing of the services availability can be done to ensure that the services are always available to the client applications which are dependent on them.

Hacking in to webpack build process

With API Manager, we have a requirement to allow users to keep a separate source folder for each web application. To describe the requirement a bit more, we have a folder structure as follows.

We are sending updates to the source folder after releasing the product. If a developer customized the content in the source folder, it will be rewritten by the new updates. So for them to maintain the code separately we wanted to implement a file overriding mechanism. Our goal was to allow users to copy the file into a different folder on the same level as the source folder and do the customization logic there. Example.

The files in the overrides folder should take president over the files in the source folder. To achieve this we use a Webpack loader. A Webpack loader can be used to tap into the Webpack build process. 

 { 

   test: /\.(js|jsx)$/, 

   exclude: /node_modules/, 

   use: [ 

    { 

      loader: path.resolve('loader.js'), 

    }, 

   ], 

},  

https://github.com/wso2/apim-apps/blob/v9.0.389/portals/publisher/src/main/webapp/webpack.config.js#L139

Now, all we need to do is create a new file at the same level as weback.config.js and add our logic. We get the list of files and the source content as input params. 

  module.exports = function (source, map) 

{ 

 ..... 

 // Do your magic 

 this.callback(null, newSource, map); 

} 

Loader source https://github.com/wso2/apim-apps/blob/v9.0.389/portals/publisher/src/main/webapp/loader.js

APIM 3.0 add multiple apis - bash script

Created a bash script to create, tag and publish multiple APIs. This is useful to populate data for the landing page.

#!/bin/bash

# get the URL of the current Astronomy Picture of the Day (APOD)
clientId=$(curl -k -X POST -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -d @payload.json https://localhost:9443/client-registration/v0.14/register | jq -r '.clientId')
clientSecret=$(curl -k -X POST -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -d @payload.json https://localhost:9443/client-registration/v0.14/register | jq -r '.clientSecret')
# get just the image name from the URL
echo $clientId
echo $clientSecret

encoded=$(echo -ne $clientId:$clientSecret | base64)
echo $encoded

# get access token
accessToken=$(curl -k -d "grant_type=password&username=admin&password=admin&scope=apim:api_view,apim:api_create" -H "Authorization: Basic $encoded" https://localhost:9443/oauth2/token | jq -r '.access_token')

echo "======= access token =========="
echo $accessToken

declare -a tags=("weather" "finance" )
for tag in "${tags[@]}"
do
    for i in {6..50}
    do
        echo $tag
        apiId=$(curl -k -H "Authorization: Bearer $accessToken" -H "Content-Type: application/json" -X POST --data-binary '{"name":"'$tag'API'$i'","version":"1.0.0","context":"'$tag'API'$i'","tags":["'$tag'"],"isDefaultVersion":false,"gatewayEnvironments":["Production and Sandbox"],"transport":["http","https"],"visibility":"PUBLIC","endpointConfig":{"endpoint_type":"http","sandbox_endpoints":{"url":"http://apiendpoint"},"production_endpoints":{"url":"http://apiendpoint"}},"policies":["Unlimited"]}' https://localhost:9443/api/am/publisher/v1.0/apis  | jq -r '.id')
        echo "==============================================================="
        echo $apiId


        ## publishing
        echo "===========================publishing===================================="
        publishState=$(curl -k -H "Authorization: Bearer $accessToken" -H "Content-Type: application/json" -X POST "https://localhost:9443/api/am/publisher/v1.0/apis/change-lifecycle?action=Publish&apiId=$apiId" -H "accept: application/json")
    done
done

Microservices governance vs SOA

whether you enforce contracts is independent of if you connect through the service bus or directly. You could build your microservices to use SOAP and WSDL. The industry as a whole seems to be moving away from this.

The team responsible for deploying the microservice needs to treat all external parties like customers. This means when changes occur, they need to keep backwards compatibility and then undergo a change management process in other teams to have them upgrade before decommissioning the old version. We avoid breaking changes as much as possible, and use semantic versioning otherwise. Automated tests help keep all this possible.

In terms of governance, I would set ground-rules around the following:

• what is (and is not) considered a breaking change, and how this is to be handled in the versioning system
• how/where documentation for services is to be published and updated
• how clients are to authenticate themselves
• security recommendations such as TLS and authentication mechanisms

While you may not have a canonical data model covering all services, it could be wise to introduce some smaller conventions suitable to your domain. In my domain, this means always using 3-character ISO standard currency codes alongside monetary amounts. We never assume the currency or use a different representation.

Source: StackOverflow

Microservices and SOA

Microservices is one of the buzzwords that generate a lot of hype in these days.So we thought about discussing SOA(Service-oriented architecture) and Microservices.

(SOA): an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.

Microservices: a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs

When looking at Microservices and SOA based service, I can see a lot of similarities between them. However, Microservices is a special approach of breaking a monolithic SOA service into small parts. So finally one service can be divided into many smaller services that talk to each other. Ideally, each SOA service operation should be implemented as a Microservice.

A Service which is implemented based on Service-oriented architecture has a broader scope than a one Microservice. The primary driving force of a Microservices architectural solution is the scalability. When demand is increasing for one or two services, we can easily scale them with fewer resource constraints. However, if we have a monolithic service, scaling will bring up many unwanted resources as well. So, instead of deploying the entire application only once everyone is done, developers can deploy their respective services. Also, testing, issue isolation are manageable easily in microservices.

When considering disadvantages of microservices, implementing distributed systems can be complex. There will be multiple small-small services which complicates the deployment. Also when implementing a complex service, we need to think about database connectivity and transaction handling as well.