Category Archives: Customers

Eurecat: using iBeacons, WSO2 and IoT for a better shopping experience

Eurecat, based in Catalonia, Spain, is in the business of providing technology. A multinational team of researchers and technologists spread their efforts into technology services, consulting and R&D across sectors ranging from Agriculture to Textiles to the Aerospace industry. By default, this requires them to work in the space of Big Data, cloud services, mobile and the Internet of Things.

One of their projects happened to involve iBeacons in a store. In addition to transmitting messages, the low-energy, cross-platform Bluetooth BLE-based sensors can detect the distance between a potential user and themselves – and transmit this information as ‘frames’. Using this functionality, a customer walking outside the store would be detected and contacted via an automated message.

image00

Upon arriving at the entrance to the store, the customer would be detected by beacons at the front of the shop (near) and at the back of the shop (far). This event itself would be a trigger for the system – perhaps a notification for a store clerk to attend to the customer who just walked in. The possibilities aren’t limited to these use cases: with the combination of different positions and detection patterns, many other events can be triggered or messages pushed.

To implement this, Eurecat architected the system thusly.

image01

The process is set in motion by the iBeacon, which keeps broadcasting frames. These are picked up by the smartphone, which contacts the business services. Complex Event processing would occur here to sort through all these low-level events in real-time. The bus then funnels this data to where it needs to go – notification services, third parties, interfaces and databases.

The WSO2 Complex Event Processor (CEP) and the WSO2 Enterprise Service Bus (ESB) fit in readily, with the ESB collecting the events and passing them on to the processing layer.

image02

Jordi Roda of Eurecat, speaking at WSO2Con EU 2015, detailed why they choose to go with WSO2: the real-time processing capabilities of CEP, the array of protocols and data formats it can handle, and the Siddhi language, which enabled them to easily construct the queries that would sift through the events. The ESB, said Jordi, they selected because of its performance, security and connectivity it offered.

At the time of speaking, Eurecat had improvements pending: data analytics, a wifi-based location service, better security and scalability.

image03

At WSO2, we’re delighted to be a part of Eurecat’s success – and if your project leads you along similar paths, we’d like to hear from you. Contact us.[a] If you’d like to try us out before you talk to us, our products are 100% free and open source – click here to explore the WSO2 Enterprise Service Bus or here to visit the WSO2 Complex Event Processor.

Toon by Quby: Smarter Home Devices With WSO2 API Manager

Quby is hardly a household name. Nevertheless, many Dutch people would have come across a smart thermostat called the Toon, sold by Eneco, one of the largest suppliers of gas, electricity and heat in the Netherlands (there were about 120,000 of these devices installed in the Netherlands in 2015).

This thermostat is a Quby product: the Dutch startup designs the hardware, runs the software and basically does everything regarding this tablet-like device.

Eneco Toon from PlusOne on Vimeo.

The Toon is a little bit more than a thermostat: it also displays energy and gas usage. The device hooks into the home WiFi network and integrates with the central heating system, electricity meter and/or solar panel (so that you can check your yield). It also connects with Philips Smart LED lighting, Smart Plugs, and also exposes all of its functionality via mobile apps for phones and tablets. The apps let a user do everything from analyze a visual graph of energy usage to turn off your central heating from outside the home.  

Speaking for Quby, Michiel Fokke drilled down into the workings of these mobile apps. The app connected over a secure connection to the Mobile Backend – essentially, a reverse proxy; this in turn integrates with their asset management system to figure out the device login credentials, and once this is done the app is given a live connection to the display in your home

However, said Michiel at WSO2Con EU, they had a few problems with this architecture.

One, Quby had no information on alternative uses of that API they use for the connection. Someone made a Windows Mobile app for their platform, and someone else reverse-engineered the API to write a Python framework: they had no measurements on any of these uses. Thus, they could not account for capacity or predict it.

Two, there was a proprietary login involved, which means storing encrypted credentials on the device itself.

Three, their API was undocumented and unsupported, making it difficult for them to open up their platform to third parties even if they wanted to.

When they started looking for an off the shelf solution to fit their needs, they had a wishlist: it had to support OAuth2, it had to be open source with affordable support – because they wanted to look under the hood – and it had to be extensible enough that a small team like Quby’s could innovate with it. WSO2’s API Manager was an ideal fit for this.

According to Michiel, they went with WSO2 over MuleSoft – which was the other candidate considered – because of the open source nature of the product, the ease of using it – “You can download a zip file and unpack it and just run the start script; basically you’re ready to go!” – and also because of the clearly defined pricing model for support.

image00The new architecture has the WSO2 API Manager sitting between the connection, the Mobile Backend, the Asset Management system and the Authentication Service. The proprietary login has now been moved into the API Manager, so that both the device app and the backend can be standards-based. A couple of additions were needed – plugin to interface with Eneco’s authentication web service and JSON web tokens to pass user claims.

“We did a pilot implementation and organized a hackathon at the beginning of March: I have to say that was quite successful – over the weekend we had 14 working apps: we had complete Windows Mobile app; we had a working prototype of Apple Watch app; and a couple of students had figured out how to use a Smart Plug to measure the energy usage of a single individual. They had created a complete portal and a web app over the weekend.”

Quite a success, we’d say.

What’s next for Quby? Michiel, at WSO2COn EU 2015, outlined plans to migrate their own apps to the new API and start using WSO2 API Manager to provide internal APIs. The WSO2 API Manager, he said, is perfectly fit for that use case, too.

For more detail, watch Michiel’s talk at WSO2Con EU here.

At WSO2, we’re constantly working on improving our products – so to see what’s new with WSO2 API Manager, drop by here.  

WSO2 and MedVision360: Delivering Healthcare across Europe

Jan-Marc Verlinden is the founder and CEO of MedVision360. MedRecord, their flagship project, is an eHR (electronic Health Record) system: everything from patient data to digital health apps, devices, wearables, companies and hospital systems are wrapped together, providing a single platform on which healthcare providers can build medical applications and expose data and services via APIs. Currently, the MedVision platform is used in over 8 large EU projects, including hospitals from Hannover to Rome to Southampton.

At WSO2Con EU 2015, Jan-Marc took the stage to explain how MedVision360 achieved all this: using WSO2 products at the heart of their platform, with expertise from our partner, Yenlo.

Inside the medicine cabinet

MedRecord was born of a desire to do better. Europe, says Jan-Marc, is aging; by 2020, there will be 3 working people to every old person. In China, this problem is bound to be even more serious. This is a huge challenge for healthcare.

Given the severity of this situation, one would imagine this problem would have been tackled ages ago. Not so.

According to Jan-Marc, there are a few major problems in the way of change coming in with effective use of ICT; cost, concerns – or technical ignorance- about privacy and data security, a lack of communication between ICT systems, and the human capital it costs for data entry.

There’s also the lack of financial incentives to do better. There’s no real incentive for doctors to change the way they work and to reduce those long queues to something as simple as a mobile app, especially given the costs faced.

MedVision360 built two stacks: the first, which they subsequently open sourced, uses XML for storing data – and a second, enterprise version, with better performance using PostgreSQL. Both are based on the CEN/ISO EN 13606 standard, which requires the platform to use a dual-model architecture that maintains a clear separation between information and knowledge.

To convey the depth of modelling involved in this, Jan-Marc used the example of blood pressure, one of the many measurements involved in the process of treating a patient.

image01
This is the type of semantic model template developed by the NHS (the National Health Services, UK).  The idea is that this delivers both the data needed and the context that a medical specialist would need to frame the data in. As the system consumes these archetypes, it becomes instantly proficient.

image00
However, due to different workflows and standards, a doctor in a country other than the UK might require a different version of things, as seen above; not just a 1-1 translation of terms, either.

Working with Yenlo, MedVision360 utilized the open source WSO2 API Manager, WSO2 App Manager, and WSO2 Identity Server to solve this issue. WSO2 API Manager is a complete solution for designing and managing the API lifecycle after publishing. MedRecord’s architecture uses API manager to expose the data in the MedRecord platform from the PaaS layer, while managing access rights. WSO2 Identity Server enables login through third party identity providers (like Google and Netherland’s UZI-pass), handling role based access control and providing an audit trail.

image003
Everything else – applications, websites – is hosted on this layer. Swagger and JSON make it easier to build validated apps. Paired with a drag-and-drop HTML5 tooling interface, developers can easily build applications by accessing functionality from APIs with a few clicks. Hooks to portals like Drupal and Liferay allow better, device-independent presentation of content.

This opens up possibilities even for integration with Google Fit or Apple Health Kit. Google Fit, for example, collects data on the patient walking and so on; while that’s not relevant for a doctor, who’s more concerned with the patient not walking, parsing and analyzing the data would allow medical professionals to keep an eye on their customers’ health.

Healthcare is a very serious business, and at WSO2, we’re glad that providers like MedVision360 – and their clients- have chosen to trust our platform with the lives of others. To examine the full video of Jan-Marc Verlinden’s talk, click here.

At WSO2, we’re committed to making our platform better. To check out the components that MedVision used so successfully, visit the WSO2 API Manager, Identity Server and App Manager pages.

Capgemini, WSO2 and the new UN ecosystem

Ibrahim Khalili is a system integration analyst at Capgemini, a multinational that’s one of the world’s foremost providers of management consulting, technology and outsourcing. Headquartered in Paris, Capgemini has been running since 1967, and now makes over 11 billion EUR in revenue.

ibrahim

Capgemini and WSO2 have a history of working together. One of Capgemini’s recent projects was for the United Nations – to build a new reference architecture for UN agencies to function across a connected technology platform. Khalili, speaking at WSO2Con Asia 2016 in Colombo, Sri Lanka, outlined the three major goals of the new platform.

Whatever they designed had to allow beneficiaries, donors, citizens and the UN’s increasingly mobile workforce to access the functionality and information of agencies regardless at “anywhere, anytime, on any device”; it had to handle information, people and devices in a much smarter and more cost-efficient way that the UN was doing already. It also had to break out the data and bring the UN’s agencies into the world of an API ecosystem.

To put this into finer context, we’re talking about a system that can handle assets, finances, information and humans across a diverse array of agencies – including the nitty-gritty of fundraising, running initiatives, and reporting that are key to most UN operations. What they required was what Khalili calls a “platform enabled agency” – more or less a complete update to operational infrastructure, with APIs exposing services, information, and functionality across the board.

Their solution starts with an integration layer that connects to all legacy systems, providing a view of all the data that can be managed. On top of that goes the process layer, which contains the functionality, and on top an API layer exposing the platform’s services and data.

capgemini-abstract

Once the logical framework was done, Capgemini started filling it in. At the very bottom go IaaS services like VMWare. On top of that comes an ERP universe of sorts – functionality from SugarCRM, Talend, WSO2 Application Server, WSO2 Complex Event Processor, and others, connected by the WSO2 ESB. WSO2 Enterprise Mobility Manager, WSO2 API Manager, and WSO2 User Engagement Server face outwards, allowing this functionality to be used. WSO2 Identity Server wraps around the entire platform, handling ID and authentication.

That gives Capgemini – and the UN – not only a cleaner, layered architecture, but one that brings in better scalability as well as a Devops approach. But above all, the chief advantage, says Khalili, is that it’s also open source. With WSO2 products, Capgemini has complete freedom to customize, take apart or rebuild whatever’s required to make a better platform. There’s no stopping innovation.

Capgemini’s not the only one who can leverage our technology. All WSO2 products are free and open source.

Go to http://wso2.com/products/ to download and use any part of our middleware platform. For more information on Capgemini’s solution for the UN, watch Ibrahim Khalili’s full presentation at WSO2Con here.  

Trimble, WSO2, and The Internet of Dirty Things

“It’s probably a simplification to say that you have to have muddy work boots to be a Trimble customer, but if you have muddy work boots, you know who we are.”

– Gregory Best, Senior Technologist, Trimble, speaking at WSO2Con US 2015

Trimble, founded in 1978, is a company where the Internet of Things is not just a catchphrase. For some reason, Trimble’s Wikipedia page doesn’t do it justice; ‘makes GPS positioning devices, laser rangefinders and UAVs’ barely scratches the surface of what Trimble does.

Consider: In 1990, a climber named Wally Berg led an expedition up Mount Everest. He carried with him a Trimble GPS device, which he planted on Everest at roughly the cruising altitude of a Boeing 747. The purpose was to try and figure out the real height of the tallest mountain in the world.

Take Disneyland.

Sleeping_Beauty_Castle_DLR

Disneyland has some 100 million dollars’ worth of extravagant and complex costumes. Tracking all of those was once a 180 person-hour job – 15 to 20 people, says Gregory, would work 8 to 10 hours a day to go through and hand-count everything. One Trimble division changed all that: by attaching lowly RFID tags to every costume, they managed to set up a system where one person pushes a cart up and down the aisle and all the costumes check in – a device role-call done via radio.

That’s 180 person-hours cut down to 2.

As Gregory says, if you can do it in one place, you can do it in another. If you can tag clothes, you can tag other things. Trimble, working with Ford and DeWalt, created a system where tagged tools are networked to a computer sitting in a dashboard. When the contractor has a specific job, the system is able to highlight what he needs. When he’s done, the system is able to check whether he’s returned everything and is free to go.

Sleeping_Beauty_Castle_DLR

“And if you can do that inside the truck, you can do that outside: so we can put tags on equipment and materials out on a storage yard, but the RFID tags on the outside of the truck can now add a GPS receiver. As the truck goes through the yard it can inventory everything and associate that with their GPS positions; now I know where everything I need to know is.”

This is IoT. Stripped to actual moving parts, IoT becomes a buzzword wrapped around transmitters, receivers, sensors and clever software.

The buck doesn’t stop here. Trimble’s applications of this technology take us into fleet management – where every truck is not just a vehicle, but a rolling mass of information on wheels, spewing out numbers for everything from speed to engine faults to fuel consumption; that veers into routing, where it’s never the shortest distance, but the most fuel-efficient journey that matters, with driving regulations that change from state to state. Where you’re able to tell if a truck is going too fast, and if its weight is causing it to handle different at those speeds.

Screen Shot 2016-06-27 at 2

That leads up to being able to collect data from all sorts of different sources, analyze it and be able to tell truckers that gas is cheaper here than in the next state, and to be able to use all of these things to figure out the best possible route for any truck to take.

“But we can do better than that,” says Gregory, who seems to have made this his catchphrase. While Google has been building self-driving cars, Trimble’s been gunning for the big game: they’ve used Trimble positioning to automate massive CAT haul trucks. They pick up loads in very specific points, drop them off in very specific points, stop when they wants to refuel, and doing it in a very efficient, very safe way.

Screen Shot 2016-06-27 at 2

A robot driving something this large is almost scary, when you think about it. And Trimble hasn’t stopped: they’re extending this to farming vehicles, and pairing that with survey data to control how much water, fertilizer and effluence is laid down on the field. Everything is optimized for the best harvest.

All of this inevitably demands some incredibly powerful software, and that’s what Trimble Connect is: a robust Platform-as-a-Service that provides the core components for any application and lets Trimble’s rather diversified businesses maintain a set of services on top of it. It’s accessible to Trimble’s network of partners and dealers and also provides a cloud container than can host any Trimble service. It’s built using four multi-tenant, cloud-enabled WSO2 middleware  products: WSO2 Enterprise Service Bus, WSO2 API Manager, WSO2 Application Server, and WSO2 Identity Server.

Screen Shot 2016-06-27 at 2

This is crucial, because, as Gregory  explains, Trimble’s businesses are run separately and there’s not a lot of coordination between all of them; after all, it’s a huge leap from measuring the tops of mountains to automating giant machines that look like they came out of Mad Max. But because of this platform, Trimble is able to share technology and capability across all of these – if agriculture wants a geofencing capability and construction has one, they can just go take that capability. Thanks to WSO2 and a lot of hard work, Trimble can keep climbing those mountains and stalking giant fleets of IoT-enabled trucks. 

For more insight into Trimble and how they do things, watch Gregory Best’s talk at WSO2Con here. For more information on WSO2 and how our platform works, visit wso2.com/products.

Zeomega: Building on WSO2 for a Comprehensive Healthcare Solution

The typical health management platform is a complex mechanism. This is, after all, an industry with zero tolerance for faults: even the slightest mistake could mean a life in danger.

Building healthcare solutions is what Zeomega specializes in. The Texas-based firm delivers integrated informatics and business process management solutions. Zeomega’s clients collectively service more than 30 million individuals across the United States.

image00

WSO2 is a part of their success: key to Zeomega is Jiva, Zeomega’s population health management platform. Delivering analytics, workflow, content and patient engagement capabilities, Jiva uses key WSO2 products and provides a deployable PHM infrastructure that both healthcare providers and clients can use. A strong track record of integration and acquisitions keep both Zeomega and Jiva on top of what they do.

Attending WSO2Con Asia 2016 to explain all of this were Praveen Doddamani and Harshavardhan Gadham Mohanraj, Technical Leads at Zeomega. Their speech, titled Building on WSO2 for a Comprehensive Healthcare Solution, detailed how Jiva works and why. Let’s dig in.

The State of the Art

Jiva has the capability to integrate with various data repositories and management systems. During the initial days of integration, they built an ETL tool and a framework – using Python – to integrate data into Jiva, generally in the form of a CSV. It could also export data.

As their customer base expanded, this integration challenge became even more integral; their requirements changed to needing to load millions of records. To pull this off, Zeomega used the pyramid framework to build a RESTful web service that would do the job. They ended up building a SOAP system as well to better interface with their clients, and using these three tools, they could address batch integrations effectively.

When it comes to a deployment, however, with multiple servers, having these multiple systems turned out to be a burden, especially when clients needed a single API to be able to manipulate data; multiple systems with different tech stacks became roadblocks to both support and development.

The Fix

“We don’t want to rewrite our existing logic; we want to leverage the existing business logic and provide a healthcare solution to external applications and well as third-party vendors,” said Harshavardhan Mohanraj, who was co-presenting with Doddamani.

At this point, they started evaluating WSO2 for a solution to this problem. WSO2 Enterprise Service Bus and WSO2 API Manager are built for this purpose. The WSO2 ESB would allow them to retain their legacy business platform and still connect whatever they needed to. WSO2 API Manager would handle the complete API management lifecycle, allowing them to push out secure APIs for their real-time web services.

To do this, said Mohanraj, they created a Jiva API framework. The core Jiva platform is exposed through RabbitMQ. Data is sent and received to this core platform through a module with the WSO2 ESB; this handles the integration, data transformation, turning flat files (CSV/XML)  or anything else into the JSON actually processed by Jiva.

image01This functionality is exposed via WSO2 API Manager, which enables Zeomega to publish, deploy and manage the necessary SOAP and REST APIs.

In the future, said Mohanraj, they intend to shift Jiva from a monolithic structure to a less tightly coupled SOA model, with reusable components and better standards support. And to do this, they intend to use WSO2 – not just WSO2 ESB and WSO2 API Manager, but also WSO2 Identity Server and WSO2 Governance Registry.

“WSO2 products provide us with high performance, high availability, and better configurability,” said Mohanraj. “We want SOA governance, DevOps and flexibility. As a whole, we’re able to achieve a robust solution by integrating WSO2 products. We’re now moving away from spending more of our efforts on business infrastructure and we’re able to speed up agility by creating healthcare solutions.”

To learn more about Jiva and the WSO2 collaboration, watch the Zeomega talk at WSO2Con Asia 2016 here.

 

WSO2Con Insights: How NYU used WSO2 to become a more agile organization

New York University is one of the largest private American non-profits for higher education; it’s long since expanded beyond New York, and now spans more than twenty schools, colleges, and institutes – including 12 major branches across the world. They’ve produced thirty-six Nobel Prize Winners and the most Oscar winners of any university in existence. It’s safe to say that’s it’s a pretty big organization.

NYC_-_Washington_Square_Park_-_Arch

Washington Square Park in Greenwich Village – the original home of NYU

Underneath all of the education and the alumni achievements lies a deeper, more technical problem. This level of largesse means enormous amounts of data and rather complex services required to keep everything together. Peter Morales, PhD, leads NYU’s Educational Technology Innovation efforts. Speaking at WSO2Con USA 2015, he described his task: to find out how to move away from their New York-centric data center model.

The solution? WSO2’s Enterprise Service Bus.

Swapping out the engines

NYU has a lot of existing processes. The key word there is existing. To innovate, they would have to avoid touching everything else and breaking it.

This wasn’t just code, but people. Bringing in an ESB wasn’t simply bringing in technology. “You have lots of layers and lots of roles and people who are going to be affected, and you really have to be mindful about that, or the whole strategy unwinds,” explains Peter, who likens this to changing the engines of an airplane while the airplane is in flight.”

The task of implementing the ESB wasn’t simply a technological addition: it was a way of bringing in organizational change. Peter outlined several ‘Agility Accelerators’: agile processes, lean investments, cloud services, unified architecture – things that make it easier for NYU to move forward.

WSO2 comes in on a technical level. NYU uses WSO2 to decouple services at three levels – at the UI level, at the middleware level and at the data level. “If you don’t decouple it at those three layers, you’re always going to end up with some degree of coupling that’s going to impede your ability to change,” said Peter.

Screen Shot 2016-04-19 at 11

The decoupling gives them the ability to build a model where existing systems can interoperate with newer services. This, in turn, solves the original problem: they can now add and extend functionality without disrupting the old code, rolling out incremental improvements in a way they simply could not do before.

The bus in the cloud

At the heart of this implementation lies what Peter calls an “ESB in the cloud”: an architecture that runs on Amazon web servers and allows them to build applications. These applications function as cohesive units, but are actually comprised of lots of swappable services running in the background – services that range from anything from identity to ones that detect and write captions for videos. Various WSO2 ESB clusters host these services, which are then delivered through Amazon CloudFront.

This, as it turns out, is a powerful combination that allows them to run everything at low latencies. It also gives them some interesting capabilities: the ability to orchestrate functionality, and the ability to roll forward services and roll them back in real time.

One of the biggest hurdles they encountered, says Peter, was adding a process for innovating – especially when it comes to introducing new technologies. There were a lot of misconceptions about what was needed.

“A lot of us, coming out of the financial services world,  had been involved in enterprise service bus implementations which traditionally were kinda heavy – the TIBCOs, the Jbosses – this is where WSO2 is very different,” he says. “And the other argument we heard was ‘why not to microservices, without an ESB’? And the big one is ‘Is this services bus going to become another point of failure?’ We have a lot of software that needs to run 100% uptime, all the time.”

It’s safe to say that WSO2’s lightweight, high performance ESB overcame all those concerns, because NYU now runs the WSO2 ESB without a hitch. And now, says Peter, they’re looking at building an enterprise service fabric – multiple instances of an ESB on the background, synchronizing data in such a way that you get the same data regardless of where you are in the world or what your latency is supposed to be.

That’s a lot of boundaries to push – organizational, technical, you name it. But whatever NYU does, we’re proud to be there, pushing those boundaries with them.

For more information on how NYU jump-started middleware services, watch Peter’s presentation at WSO2con US 2015.

WSO2Con Insights: Why West Interactive built an app-based cloud platform with WSO2

West Corporation is a spider in a web. Andrew Bird, Senior Vice President at West, speaking at WSO2Con USA 2015, described it as a 2.5-billion dollar giant situated right at the heart of America’s telecommunications. Close to a third of the world’s conference calls run through the West network. To give you some perspective, Google+ and Cisco run calls on West networks – as does the 911 call system.

Screen Shot 2016-04-18 at 10

According to Andrew (who runs product management, development and innovation there) depending on where you are in America, 60% of the time, any call you place would go through the West network.

However, networks aren’t all that West does. West has a division called West Interactive Services which builds IVR systems for customers that need complex customer interaction networks. Here’s what Andrew had to say about how West Interactive used integrated, modular WSO2 middleware to drastically speed the delivery of service and enhance these systems – for both the customers and for themselves.

The challenge: customer interaction

Screen Shot 2016-04-18 at 9
IVR systems involve providing customer interaction platforms, application design services, multi-channel communication systems, and often goes beyond building solutions for Fortune 100 companies. The services involved are often complex –  context identification, notifications, chat, call, data collection, routing, message delivery, provisioning, identity – and the ability to communicate across Web, IVR, mobile and social platforms.

To represent its work, Andrew played a demo where a customer dials into a call center from an iPhone. The automated system on the other end recognized the customer, recognizes that fact that he is on a mobile device and addresses him by name. It then proceeds to interact with the customer via text and speech – all of this without needing an app.

Context is key here: Andrew Bird – and West – believes that customers should not have to repeatedly tell systems who they are. They should not have to waste time identifying themselves, their devices and the context in which they’re calling. Systems should be able to figure out that Mr Smith is calling from such and such a location and that’s probably because of this reason. West’s systems are designed to understand this kind of context, and they’re very good at it.

The solution: a middleware platform for West

But of course, building is not enough: scaling these kinds of systems is the challenge.

At some point, West apparently realized that while they were the best at scale, running “a couple of complex event processing engines, a couple of business rules managing engines, a couple of databases” – was neither sustainable nor particularly supportable. For one customer, for instance, they were managing 43 APIs, all of which were completely different. They needed everything on common standards, able to work with each other instead of in little silos of their own.

West’s solution was to build cloud-enabled middleware platform that sits between West’s proprietary services and the applications running across different channels. West’s managed services are exposed through the platform via APIs.

This is where WSO2 came in. The WSO2 ESB serves as the SOA backbone, providing mediation and transformation between West’s different applications; WSO2 Governance Registry provides run-time SOA governance, and WSO2 Analytics platform monitors SOA metrics.

Screen Shot 2016-04-18 at 9
Other, more specific functionality is provided by the likes of WSO2 Complex Event Processor, Application Server, Data Services Server and Machine Learner. The multi-channel access services  – those that face the world – rely on WSO2 Identity Server and WSO2 API Manager, providing a way to expose APIs to internal or external applications that may integrate with the platform.

Context is everything

For West to rely on WSO2 for the backbone of their middleware platform is, for us, an indicator of the amount of faith they have in our products. West, after all, is a company that supports some of the biggest organizations in the world. They cannot afford to fail.

But perhaps the best statement was Andrew’s recollection of how much their customers trust WSO2. “I was once meeting with a customer, talking about our vision,” he says, “and they were like ‘so what are you using for an ESB?’ I said, “WSO2”. No more questions. Done. They were using the same thing as well. I needed something like that – something where if I go talk to a customer who I’m trying to take care of, I don’t need to spend my time justifying myself.”

If you’re interested in knowing more, check out Andrew’s complete keynote talk at WSO2Con USA here. For more details on the deployment, read our case study on West Interactive here.

 

WSO2Con Insights: How WSO2’s Open Source API Management Platform is Enabling BNY Mellon’s Digital Transformation

Let’s talk numbers. Bank of New York Mellon (BNY Mellon) runs a set of systems that track up to USD 30 trillion worth of wealth globally through investment management, investment services and wealth management. That’s about a quarter of all the world’s wealth of private assets, assets under management and assets under custody and/or administration.

When it comes to technology numbers, BNY Mellon operates a private cloud out of their own data centers, and has about 900 projects going on at any moment in time, run and managed smoothly by a 13,000 strong team.

Front_of_BNY_Mellon_Center_(3583589876)
Image courtesy of WikiMedia Commons.

During his talk at WSO2Con USA 2015, Michael Gardner, managing director and Head of the BNY Mellon Innovation Center explained how these numbers converged into creating the NEXEN digital ecosystem powered by WSO2’s API management platform, to transform the financial services industry.

The path of the open source code

Software driven disruption is impacting every company in every industry, Gardner noted, and the only way to survive is to keep moving in the same velocity, ability and agility as technology itself. Companies have evolved from mere ecommerce-related online retailers to managing entire customer relationships, to complete supply chain management and today, to digitized business operations. Such a company, according research firm Gartner, is defined as a ‘digital enterprise’.

Gardner noted that it’s critical for BNY Mellon to be a digital enterprise, to have the ability to accept new technologies and adapt, pushing very hard on it’s digital transformation and doing so by converging various technologies. He then went on to express why open source is now the center of their focus in this transformation.

“Open Source is very very important to us,” Gardner said. “We believe that open source is the future of enterprise collaboration. It’s not because it’s free. That’s great… but it (open source) becomes the basis for enterprises to collaborate together to evolve software mutually in ways that they need.”

The NEXEN digital ecosystem

BNY Mellon is bringing a collection of progressive software projects and technologies together, with an API program that enables the digital transformation of the organization to occur as an ecosystem.

Screen Shot 2016-03-25 at 12

“This transformation takes technology, it takes process and people, all these things working together,” Gardner comments. “It’s not easy to do this. If you are not driving that people part of it and the business process part of it, you are not going to accomplish the digital transformation.”

This convergence, Gardner said, was what finally lead BNY Mellon to create what is called the digital ecosystem of NEXEN. It involves BNY Mellon employees, covering both technology and business areas, customers as well as partner collaborators, including WSO2.

APIs – the critical link within the ecosystem

WSO2’s API management solution was chosen for the NEXEN ecosystem’s API program. “We selected WSO2 not just for the reason that it was open source. It gave us the chance to be able to actually work with the code, and understand the behavior of the system.”

How important are APIs for this digital transformation?

To keep the BNY Mellon cloud as modern as possible, the team constantly refactors backend systems. For this, smaller teams need to be empowered to carry out a given functionality.

“So APIs become really critical in being able to implement the most modern microservices based platform and architecture that we can,” Gardner noted. His team needs to ensure that whatever generation of technology a service is architected upon, that there is a modern REST API that’s available not only to interact with software systems, but to also allow people to consume these services.

“The microservices and architecture end up being the enabler of the digital transformation,” Gardner said. “If you’re going to be able to have the business move quickly, and adapt to new technology – you have to have APIs as the enabling lifeblood of it.”

Developer productivity too, according to Gardner was fundamental in achieving digital transformation. With 13000 people in technology at BNY Mellon, he explained how important it was to enable them to move at the same velocity as the technology itself, with modern API capabilities.

“At the end of the day what we are doing via the NEXEN program and the API Program is we are building a digital ecosystem that allows collaborations, and allows us to operate as a digital enterprise where every aspect of our business is digital.”

For more detailed information on BNY Mellon’s NEXEN API program, view Gardner’s WSO2Con USA 2015 presentation.

To understand more about BNY Mellon, check out ‘A History of BNY Mellon’ on Youtube.

WSO2 Insights: iJET builds an end-to-end microservice architecture with WSO2 middleware

For the past 10 years, iJET International has delivered intelligence-driven integrated risk management solutions by assessing an organization’s exposure to risk and threat. To empower these multinational organizations, iJET collects intelligence on a global scale, about health, natural disasters, geopolitical and civil unrest, capturing data in a manner that is machine processable to deliver response solutions.

During his session at WSO2Con USA 2015, David Clark, director of IT architecture at iJET labs, the innovation center at iJET International,  explained how the organization moved from a rigid legacy system to a microservice architecture, with an identity management solution powered by WSO2 middleware.

Satiating the demand for sensitive data security

The biggest challenge Clark was faced with when he joined iJET in 2015 was identity management. With many of iJET’s customers already having identity management solutions in place, Clark recalled the increased demand for federated Single Sign-on (SSO) across the board. Customers had a need for more security protocol options, specifically SAML 2.0 and OAuth 2.0. There was also a need to provide them with user self-provisioning through the secure use of third party systems, as well as multifactor authentication, he noted.

An additional challenge was iJET’s legacy architecture. It was not agile, not scalable, and had limited revenue opportunities. What possibly began as a clean three-tier application had over the years snowballed into a mammoth, rigid system that could not pivot with the business anymore. “What this means is we really couldn’t monetize our main asset, which is our intelligence”, Clark said. It was time to move on to a more Service Oriented approach.

Open source, open standards

WSO2 middleware was the best fit for iJET’s Service Oriented Architecture (SOA). “Being open source aligns with iJET’s values”, Clark noted. “We wanted to take ownership of the products and deploy it the way we wanted to, and WSO2 allows us to do that. Being open source, it’s extensible.”

iJET also utilized WSO2’s Quick Start Program (QSP) from the initial stages of the project. DavidClark01 “The QSP ensures that you get off on the right foot,” Clark observed. “Their engineers come in, understand what your business problem is, and ensure that you get the right architecture, and start in the right direction.”

Clark explained the implementation of the WSO2 products to the audience, starting off with federated SSO using WSO2 Identity Server. The product supported configurable authenticators for federation, and just-in-time user provisioning was added, where the incoming claims could be mapped to local schema. This worked in conjunction with the iJET customer user store manager, Clark explained, which was implemented as an OSGI bundle.

Integration of the legacy applications followed. With the iJET applications already configured to use another SSO, Clark explained the use of Apache Mellon to bridge the SAML negotiation and provide a façade between the old and new systems, generating session cookies with the same key value peers the old system was using.

Optimizing iJET’s microservices

The integration of WSO2 API Manager with WSO2 Identity Aerver, Clark continued, was carried out via an OAuth key manager and Java Web token. The core focus then shifted to optimizing iJET’s microservices. WSO2 API Manager is used to prototype, version and publish APIs provided by microservices. But most importantly, Clark observed, API Manager was used to govern the access and provide security to APIs.

A hexagonal architecture was used for the microservices, with business logic at the core.   Inbound controllers and adapters surrounding the core helped expose the REST API that the user applications would access through the API Manager. The outbound repositories helped the service to communicate with the database.

IJet-MS-Arch

Clark also explained that iJET follows a template driven development process to create microservices. Not yet at the point of using Docker containers, Clark stated that each microservice gets deployed on an Amazon EC2 instance.

Six months to successful deployment

“Six months later, we have our federated SSO working”, Clark noted. “We were able to deploy a new application built entirely on REST APIs and these are now available for our customers to consume as well.” The legacy applications too are able to authenticate with third party identity providers, with extremely satisfied iJET customers using their own solutions.

For more information on iJET’s microservice architecture use case, view Clark’s WSO2Con USA 2015 presentation.

Open Conversations on the New Business of Enterprise Software

WSO2