Suva Uses WSO2 Enterprise Service Bus to Manage 250-Plus Web Services Internally and Across
Customers, Government Agencies, and Other Third Parties
As Switzerland's leading provider of federal insurance for companies and their employees, Suva
manages more than 2 million policyholders. Each year, the company
handles some 466,000 cases of illness or accident, covering costs for each person’s medical care,
as well as any compensation for time out of work. Efficiently managing these cases requires Suva
to integrate processes and information with the broad range of disparate systems used internally
and by the federal agencies and companies the insurer supports.
Today, Suva relies on WSO2 Enterprise Service Bus (WSO2 ESB now extended as WSO2 Enterprise Integrator) to serve as the central integration
platform for enabling Web services across the various platforms involved in providing holistic
care for policyholders.
Proprietary Approach Leads to Integration Complexity
For years, Suva has used a number of SAP business management software products to manage its processes, so when the company decided to implement a solution for process integration in 2008, SAP NetWeaver Process Integration (SAP PI) was a natural choice.
At the same time, like many organizations, Suva takes advantage of other platforms, including the Oracle WebLogic Java application server, the Microsoft .NET framework, and other legacy applications.
At first, it was relatively easy to interconnect one to three systems with one or two Web services.
However, by 2010, Web services started to be used frequently for interconnecting platforms. All the web services would have to go through SAP PI even if they had nothing to do with the SAP platform. Additionally, Suva needed to monitor the web services, but the integrations only provided visibility at the platform-level.
"It was time consuming to manage the integrations, and the complexity was growing," recalled
Igor Berchtold, lead of IT Framework and Integration at Suva. "The systems would call each other, and no one would
know because we didn't have the visibility. We realized we needed a solution that would enable
business functionality integration across heterogeneous platforms—including commercial software
and our own home-grown applications."
Evaluating SOA Alternatives
Suva recognized that there were two key factors in streamlining its systems integration. First was
adopting a service-oriented architecture (SOA), which would de-couple Web services from the
service providers and consumers, supporting protocols, security, and data mapping. The second was finding a new integration product to serve as the backbone for this SOA.
The company evaluated major players, such as SAP, Oracle, IBM and JBoss, along with traditional integration products that had been rebranded as being “SOA-enabled.” Suva also evaluated newer products designed specifically to support web services, including WSO2 and Apigee.
"It was a short evaluation. We didn't want to use one of the older proprietary solutions because they would create the same problems as SAP PI," Mr. Berchtold
said. "When we looked at WSO2, we saw that it would just fit our needs. The technology was quite mature and really looked good, and even before we became customers, we got very good answers from the WSO2 support team.”
WSO2 Quick Start Helps Speed Deployment
Prior to committing to an implementation around WSO2 ESB, Suva
first engaged WSO2 for a QuickStart consulting program. WSO2
sent three engineers to work onsite at Suva for one week. In just
five days, the engineers had designed the architecture and helped Suva to build prototypes of the use cases. Following the onsite
engagement, the QuickStart program also included 20 hours of
support as Suva continued working with the prototypes and testing
"The technology was
quite mature, extensible
to fit to our needs, and
really looked good, and
even before we became
customers, we got very
good answers from the
WSO2 support team."
"WSO2 had a solution for each of our requirements, and after one week, we got a very good
impression of the product and the people," Mr. Berchtold noted. "When we started to use the
support, it was very quick, very responsive. The support team knew what type of solutions we
needed, and we've been very happy with their work."
Having completed the prototypes, Suva started deploying WSO2 ESB in June 2011. By early
October 2011, the company had the first five Web services in production handling 200,000 calls
per month. And as of June 2017, Suva has more than 250 services in production managing some 35 million calls per month.
"Even as we have scaled, WSO2 has proven to be a very stable platform," Mr. Berchtold says.
"We cannot afford to experience a failure in supporting our customers, and WSO2 meets this
Several aspects of the highly configurable, modular and 100% open source WSO2 ESB architecture
have helped to facilitate the implementation process.
"WSO2 ESB is much lighter and quicker than other ESB products," Mr. Berchtold observes. "It's
very easy to install and set up. It's also open, and a lot of the integrations can simply be configured
with WSO2 ESB, which reduces the need for programming."
In addition to the technology, WSO2 support also has played an important role in enabling this
quick scaling of the deployment.
"Whenever we have questions about the functionality or when there are bugs or problems, we get
a very quick response and the support we need,” Mr. Berchtold explains. "It's really incredible. No
other company in the IT arena that I have worked with is able to catch up with WSO2 in the area of
WSO2 ESB Provides Central Integration Hub
Today, WSO2 ESB is used as a central proxy into which all
the platforms call. They know where the implementation of the
service is, routing it from one system to another. The service
consumer does not have to know what software is running in the
"No other company in the
IT arena that I have worked
with is able to catch up
with WSO2 in the area of
"WSO2 ESB provides a layer of abstraction in the middle, so we can hide some of the
complexity and platform-specific things," Mr. Berchtold explains. "If things change on one platform,
we can tweak the ESB, so the consumer is not affected by that change."
Significantly, this centralized approach now provides Suva the visibility to understand what is happening
with each of the 250-plus Web services it has implemented.
"We can go to the central ESB to look at what types of services are being consumed and how
often," Mr. Berchtold notes. "We measure the time it takes for a service, and we can see if there is
an error, so that we can quickly address any issues."
To implement the various integrations, Suva developers use the WSO2 Developer Studio
integrated development environment (IDE) in combination with WSO2 ESB and the Apache Maven
build manager to create ESB artifacts, such as proxy mediation sequences. These artifacts are
packaged as WSO2 Carbon Application aRchive (CAR) files, which are then deployed to different
ESB instances, which are always synchronous so that each instance has the same deployment at
Suva's internally developed Carbonara tool completes the deployment by then taking a CAR file
or set of CAR files, and allowing developers to say which stage they want to deploy, what the
configuration is, and what kind of services are available at each stage. Carbonara then checks to
ensure that all of these details are included in the deployment node.
Transport ESB Artifacts with Carbonara
Implementing Security Mediation with WSO2 ESB
Because Suva handles highly confidential information about policyholders, the company uses
WSO2 ESB to support the different layers of security it has in place.
Notably, the WSO2 ESB used for Suva’s intranet is complemented by a second WSO2 ESB
that connects to other companies and government agencies via the Internet. These third-party
organizations use an entry server that goes into the WSO2 ESB implemented within the demilitarized
zone (DMZ), which then connects to the WSO2 ESB on Suva’s intranet residing behind the
"The separation of our intranet and extranet using the WSO2 ESB servers helps enforce our
security and supports scalability," Mr. Berchtold says. "It works very well."
WSO2 ESB also provides security mediation through the Security Assertion Markup Language
(SAML). When a service consumer uses SAML to talk to Suva’s back-end system, and it doesn’t
understand the company's homemade SOA token, WSO2 ESB transforms SAML into a token that
enables secure communications to proceed. Other security technologies Suva employs are the
open WS-Security protocols and SAML Sender Voucher Assertion for SAP.
System Architecture Diagram: Integration of external and internal systems using WSO2 ESB
Enhancing the Customer Experience
Responsiveness is an important aspect of the customer service that Suva provides its policyholders
and their employers. Today, even as Suva handles some 300 business functions, managed
through 250-plus Web service proxies, across a multitude of platforms, WSO2 ESB ensures with its
small footprint an excellent average response of 200 milliseconds (one-fifth of a second).
Additionally, Suva customers—big companies with their own IT systems—want to interact directly
with the insurer's systems. Meeting these requests has been straightforward using WSO2 ESB.
"Our customers connect to WSO2 ESB through Web services," Mr. Berchtold explains. "The complexity
we have is hidden behind the ESB, which makes it a lot easier for customers to work with
Flexibility to Meet Future Demands
Not only does Suva connect with customers, the
company also integrates with laboratories via WSO2 ESB.
As the insurer continues to expand its systems, the company
expects that the total number of Web service calls will double
to roughly 4 million per month by mid-2013. By 2017, it had grown to about 35 million calls per month.
"The fact that all WSO2
middleware products run
on the WSO2 Carbon
Framework means each
product looks like the other
and is easily integrated."
Suva also has upgrading from WSO2 ESB 4.8.1 to the latest release in order to take advantage
of the new ESB tooling and analytics as well as the better performance. Additionally, while the company is only using
WSO2 ESB and WSO2 Developer Studio today, the development team is looking at how to take
advantage of other products in the WSO2 Carbon enterprise middleware platform.
"The fact that all WSO2 middleware products run on the WSO2 Carbon Framework means each
product looks like the other and is easily integrated," Mr. Berchtold says. "This makes the WSO2
Carbon platform very attractive to us as we think about adding new capabilities."
Mr. Berchtold adds, "The engineers have created such a great product with WSO2 ESB . It is
playing a key role in our success and we expect for many years to come."