Telecom Web Services

Telecoms | Cloud

A cloud-based implementation of the GSMA's OneAPI.

Telecom Web Services

Instil was hired by a large telecoms software house to design and develop the core of their ‘Telecom Web Services’ platform, 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.

Initially hired to build a few of the API web services, Instil quickly became responsible for architecting, designing and developing the complete product.

More than just a collection of APIs, the platform includes a bunch of concepts now considered an essential part of any cloud deployment: monitoring, metrics, auditing, load balancing, reporting, auto-scaling, etc - all built from the ground up on a highly modular foundation of Java, OSGi and SpringDM.

And the 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 where 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.

TWS

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 services 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 it’s own process with it’s 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.

Technologies Used

Java, OSGi, Spring, Microservices, Web Services, Cloud, IoT, Telecoms

Have a Project Vision?

Give us a call and let's chat about your needs. You will be in safe hands.

Start Discussion