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.

Meet the WSO2 Enterprise Service Bus 5.0

The WSO2 Enterprise Service Bus is renowned as a lightweight, 100% open source ESB; it helps everything from big, digital-first companies (like eBay) to transnational governing bodies (like the Eurasian Union) achieve the kind of enterprise integration scenarios they need to work. We’ve now released version 5.0 of the WSO2 ESB – and here’s why you should take a look. 

As part of our new product strategy, the WSO2 ESB 5.0 release is composed of three key components – the runtime, tooling, and analytics. We’ve also added several new, major features:

  • Mediation Debugger for error detection in mediation flows
  • Data mapper to convert and transform data
  • Mediation statistics and tracing using ESB Analytics component
  • Support for JMS 2.0 and WebSocket transports

Interested? Let’s explore in more detail.

WSO2 ESB Tooling 5.0

The new WSO2 Developer Studio-based ESB tooling plug-in is built to work on top of Eclipse Mars2, the widely used IDE. It offers developers with improved usability and brings some new capabilities to the table:

Mediation debugging

At the operational level, a series of mediators called sequences determine the behavior of messages. Users were previously unable to figure out if these mediators -including their inputs, processing, and outputs – were operating as intended. The newly introduced Mediation Debugger allows users to debug this message mediation flow proactively, to identify any errors and rectify them in the development environment itself (figure 1).

image05Figure 1: Debugging mediation flow

Data conversion and transformation

 

WSO2 Data Mapper is one of the most awaited features by our customers. Having been built as a mediator that can be included in the mediation flow, it is capable of converting the data format of a message between JSON, XML or CSV (figure 2). It also comes with an operations palette that supports a number of operations to help users perform different functions in data mapping (figure 3). For instance, arithmetic functions enable users to add, subtract, multiply, divide or carry out other functions on data as a part of its transformation. Users can easily drag and drop operators into the mapping diagram and edit on the go.

The main categories of operations are listed below.

  • Common
  • Arithmetic
  • Conditional
  • Boolean
  • Type conversion
  • String

We’ve made it more appealing to developers by introducing a graphical mapping experience that also generates the execution files required to run on the Data Mapper Engine.

image09Figure 2: Data mapping

What’s special about WSO2 Data Mapper is that it can function independently of other WSO2 products or components.

image00Figure 3: Adding operations in data transformation

WSO2 ESB Analytics 5.0

The analytics component is a new addition to the ESB that lets users publish information on ESB processes. Previously, users had the ability to connect WSO2 DAS and define their own ESB dashboards. However, we’ve made the experience better by providing an analytics dashboard out of the box, with pre-defined statistics for ESB artifacts such as proxy services, APIs, sequences, endpoints and inbound endpoints. Users have the option here to choose which artifacts’ statistics and/or tracing should be published by enabling or disabling this through the runtime instance.

The dashboard displays a summarized view of the requests processed, their success/ failure rates, throughput, and message count over a specified time period, and top artifacts by request count (Figures 4, 4a, 4b, 4c respectively). For example, users can identify the top sequences, endpoints or the top APIs by request count in separate gadgets.

image04Figure 4: Statistics dashboard

image03Figure 4a: Overall transactions per second graph

image01

Figure 4b: Message count graph

image08

Figure 4c: Top endpoints by request count graph

The dashboard provides many features – from configurable timelines and detailed stats by artifact type to visual additions, such as theming and the customizability to portray your brand and explain statistics (figure 5).

image07

Figure 5: Dashboard with configurable timelines, theming buttons and navigation pane

Tracing mediation flows

Not only is it important to monitor statistics, but the ability to drill down into anomalies encountered in ESB processes is essential for DevOps teams, especially in production environments. Hence, we’ve introduced message tracing capabilities to provide more visibility into message mediation flows so developers can identify problems in live environments.

For a particular artifact type such as an API or proxy service, operational teams can dive into obtaining overall message count, latency and processing details of each message. Consider a scenario where messages pass through a REST API: the message gadget (figure 6) helps DevOps teams proactively identify which messages failed, as shown below.

image06Figure 6: Messages and their status

We’ve also made it possible to further scrutinize into the message flow (figure 7), and dive into a mediator and view its properties in relation to a payload, transport properties and context properties (figure 8), both before and after the mediator. It provides a mechanism by which operational teams can verify if message flows operate as they are intended, and fix any errors.

image02Figure 7: Message flow detailed view

image10Figure 8: Mediator properties

These features also are useful in testing environments to evaluate changes done to artifacts (sequences, APIs, endpoints etc ) or message mediation flows, as a feedback mechanism prior to moving into production.

Support for JMS 2.0 and Websocket

Last but not least, we’ve also added two transports – JMS 2.0 and WebSocket – to be able to support more integration use cases.

With JMS 2.0, the WSO2 ESB supports new messaging features – shared topic subscription, getting the JMSX delivery count and specifying message delivery delays. A typical scenario would be using the JMS endpoint to act as a shared topic listener so that it can connect to shared topic subscribers and help share the workload. We’ve also introduced WebSocket as a transport and inbound protocol to support bidirectional message mediation mostly advantageous in near-real-time communication for IoT, web, and mobile scenarios.

We’ve bumped the product quite a bit in this release and we’d love to hear what you think about the all new WSO2 ESB 5.0.

Go ahead and try it yourself – it’s free to download and use!

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.  

Managing Identity Across the Internet of Things

 

network-782707_960_720 (1)

It’s estimated that at least 50 billion devices will be connected to the Internet by end-2020. That’s more than six times the entire population of the world! With this rapid increase of the Internet of Things (IoT), the concept of identity management has extended to the Identity of Things (IDoT).

WSO2 Director of Security Architecture Prabath Siriwardena wrote a white paper that explores the benefits, risks and challenges of implementing an IDoT solution based on the concept of “connected identity”.

He explains that through IDoT, organizations can assign unique identifiers with associated metadata to devices, enabling them to connect and communicate securely and effectively with other entities over the Internet. Your ultimate goal is to reach out to as many customers, partners, distributors, and suppliers as possible that would result in more business interactions and revenue growth. This would greatly increase the number of external digital identities that interact with your enterprise. An external identity provider can be treated as an identity silo that shares its identity data or IDoT via APIs. You first need to trust the identity provider in order to accept the given user identity. Beyond this, you need to speak the same language to transport the identity data. If not, you need to either fix the identity provider’s end to speak the same language or do the same for your own enterprise.

This is not a scalable approach, and will eventually end up in a spaghetti identity anti-pattern. To avoid this, you should build a protocol-agnostic security model. With the identity bus or identity broker pattern, your enterprise isn’t coupled to a specific identity provider or a given federation protocol. The broker maintains the trust relationships between each entity as well as identity tokens between multiple heterogeneous security protocols. This creates a common, connected identity platform that enforces controlling, auditing and monitoring of identities.

Some benefits of this pattern include

  • Frictionless approach to introducing new service and identity providers and removing existing ones.
  • Easy enforcement of new authentication protocols.
  • Ability to perform claim transformations, role mapping, and just-in-time provisioning.
  • Centralized monitoring, auditing and access control.
  • Easy introduction of a new federation protocol.

When implementing an identity broker you need to follow certain fundamentals. It needs to be federation protocol, transport protocol, and authentication protocol agnostic. Additionally, it should provide the ability to perform claim transformations, home realm discovery, and multi-option and multi-step authentication, among others.

WSO2 helps you solve identity management needs across your enterprise applications, services, and APIs by utilizing the full breadth of the WSO2 platform. By combining WSO2 Identity Server’s comprehensive security model based on OAuth 2.0 with WSO2 API Manager, you can easily build an end-to-end API security ecosystem for your enterprise. Avoid vendor lock-in and enable integration across systems with WSO2’s open source model, which acts as a fully functional enterprise identity bus.

To learn more, download Prabath’s white paper 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.