Optimizing Service Platforms with SOA Governance
Barclays currently uses following two WSO2 products extensively-
- ESB (4.7.0)
- Governance Registry
We plan to use following two products in the near future –
- BAM & CEP
- API Manager
When we started with ESB (version 4.5.0) around 3 years back and now when are using ESB 4.7.0 we see a lot of differences/upscaling in the features provided in the currenty used version. I still remember when we had to implement a REST API in of our
projects (a serious concern for us) we had numerous discussions with the WSO2 support team over this and finally broke the jinx by getting the right configuration/QA-ed patch to get this working.
Aggregators, one of our major project using the WSO2 ESB platform has been a great win for us in the recent past. We succesfully on-boarded Yodlee in December last year and plan to on-board another one – Intuit this year. The kind of ease and useful configurations provided using WSO2 ESB is just phenomenal. These aggregators continously had to screen-scrape our Customer Website and the website had to manage a heavy load during peak/off hours.
We provided a completely different API to them where ESB does the magic for us that includes –
- Iteration over the request set, containing request for current transactions and historical statements.
- Cloning of 10 independent and parallel request to hit the backend within the same time frame
- Aggregate the data in a useful format.
- Applying XSLT over the aggregated data to return the required response to the aggregators in a specific format – OFX.
Another project where we successfully used the similar ESB workflow/setup was providing a Bulk Account Load for the customer website. Wherein all the sequential calls (~ 25) from the website were converted into a single Proxy and ESB did the complete cloning, and aggregation
for us.
The only thing we need to make sure/continuously monitor here is the kind of load that our ESB servers manage, it is a big volume!
Governance Server is the place where all our schemas and contracts reside.It offers complete SOA governance, configuration and life cycle management.
Governance has been a key issue for SOA. Governance is fundamentally classified into –
- Design Time
- Change Time
- Run Time
WSO2 Governance Registry helps resolve this. It comprises of the following components –
- Service Registry /Repository
Governance Registry stores service information in a service registry. This includes WSDLs, XML Schemas, and WS-Policy policies. When registering a service, you can do so in one of two ways. You can either add a new service or add a new WSDL. The easier way to do so is to add a new WSDL.
- Service Manager
Each resource stored inside the registry can have a lifecycle attached to it. A lifecycle essentially acts as a state machine. The service management tool manages the state transitions of a service. For example, a service can be in a “modeled”, “assembled”, “deployed”, or “retired” state.
- Policy Server
In the recent past, we have moved away from using the worker/manager setup of ESB to manager only setup. Yes, so we have moved
away from using the SVN based Deployment Synchronizer. Deployment Synchronizer allows you to synchronize these deployment artifacts
across the nodes of a product cluster.
We had been experiencing numerous SVN Client Exceptions during our daily lower environment deployments (car -file deployment).
Deployment Synchronizer performs following functions :
Maintaining an up-to-date backup of the artifact repository.
Sharing a single artifact repository among multiple servers in a cluster.
Enforcing artifact updates to be deployed on a server at runtime. (this was where we had been experiencing issues)
We finally decided to move away from this and now we just have nodes configured on our individual servers where there is no deployment
synchronization happening with SVN auto-commits.
We are working over implementing Activity Monitoring in our environments for achieving a detailed metrics of our services alongwith the service response times. This would obviously include our message header data (including the context id, application name, etc.) asynch flowing into the BAM servers for
providing us a detailed metrics of the complete call flow. We also plan to incorporate the Complex Event Processor. WSO2 CEP is part of WSO2 Big Data Analytics Platform where it provides the Realtime Analytics pipeline. The WSO2 CEP provides enterprise level management, statistics, debugging and tracing support for the whole event flow, enabling highly scalable and high availability deployments.
We also are looking at options as to how we can leverage WSO2 Cloud Services Gateway within the private cloud of Barclaycard US where we are currently migrating
our services.
Systems Analyst,
Barclaycard US