‘Telecom Web Services’ platform is a cloud-based implementation of the GSMA’s OneAPI specification - a set of REST/SOAP APIs built over telecom capabilities such as SMS, MMS, Terminal Location (TLX), etc.
Instil was initially hired back in 2006 to build out a few API services, but our team quickly became responsible for architecting, designing and developing the entire platform.
More than just a collection of cloud-based APIs, the platform was designed around a core set of services that are now considered an essential part of any cloud infrastructure: monitoring, metrics, auditing, load balancing, reporting, auto-scaling, etc - all built from the ground up using a highly modular architecture of Java, OSGi and SpringDM. This modularity extended all the way down to the APIs which were designed as microservices (long before microservices became a thing).
Developed over 3 years, backed by 10000+ automated unit tests, the system is capable of handling thousands of concurrent users and processing many more thousands of transactions per second.
Challenge
When Instil first got involved in this project, the existing code was packaged as a single project and built into a single Enterprise Archive file (EAR). Deployed to JBoss, the project surfaced a bunch of web services that basically interacted with the underlying gateways through a C++ bridge. As such:
- The software was prototypical but already becoming monolithic and therefore needed to be completely overhauled so that it could be onward developed sustainably.
- The software was not designed for extensibility. For example, it was not possible for the professional service team to make vendor-specific modifications without changing the core product.
- Web services could not be scaled independently from other services.
- The software was missing many of the features that would make it a viable product: monitoring, reporting, provisioning, etc.
- The majority of the encumbent team were new to Java having mostly worked in C++. The team needed to be mentored and guided on how to write and test robust enterprise scale systems.
Approach
The new platform was designed around a core runtime of Java and OSGi. Web services became OSGi bundles - essentially independent projects that could be reasoned about in isolation from other web services - and dependencies were specified and glued together using Spring DM.
The live system made extensive use of OSGi services to provide pluggable cross-cutting capabilities to each web service e.g. normalising supplied telephone numbers in E164 format so that black-listed numbers could be rejected. OSGi services were also used to plug alternative vendor specific behaviour into the system (without having to change the core product code).
The system was designed as a collection of distributed processes that could be scaled independently from each other. In effect each web service was deployed in its own process with its own database table(s), which meant each service could be scaled and monitored independently from other services.
Not quite finally (as we affected a lot more change than this), but the Instil team also introduced a culture of clean code and rigourous unit testing across the entire client organisation, Belfast and Sri Lanka, as well as providing training on OSGi, Java and engineering discipline.
