Tag Archives: WSO2 ESB

Guest Blog: Speeding Delivery of Affordable E-Health With WSO2

The good news is that modern technology is helping us to live longer. According to the Ambient Assisted Living Joint Programme, some 25% of the population in the European Union will be over 65 by the year 2020, and the number of people aged 65 to 80 years will rise by 40% between 2010 and 2030.

The challenge before us is to ensure that as people age, we can enable them to live independently and experience the highest quality of life possible—and do so in a way that is affordable for individuals and governments. Addressing that demand has been a key priority here in the Active Independent Living (AIL) group within Barcelona Digital Technology Center (BDigital).

We have built eKauri, a non-invasive e-health and smart home platform that empowers seniors to gain autonomy, participate in modern society, and achieve independence through eKauri1solutions based on information and communications technologies (ICT). It includes a patient application that provides a range of services activated by the users—for example a home media center and video conferencing—plus sensors that monitor the patient’s activities and environment. A second care center module gives caregivers and managers tools for such activities as monitoring and managing patients and handling patient alarms, among many others.

The cloud-enabled eKauri platform takes advantage of credit-card sized Raspberry Pi computers and Z-Wave wireless home automation devices within patients’ homes. It also relies on four eKauri2products from the open source WSO2 Carbon enterprise middleware platform: WSO2 API Manager, WSO2 Identity Server, WSO2 Enterprise Service Bus and WSO2 Application Server. Together, these products enable eKauri to tie together data, applications and services across a range of applications, computers and Internet of Things (IoT) devices.

Notably, all WSO2 products extend from its Carbon base, so it created a seamless environment that allowed for our programmers to rapidly gain an understanding of the technology as well as accelerate our integration and product development.

Because our charter is to develop technology that commercial partners can then deliver as solutions to the market, we wanted to provide a minimally viable version that our commercial partners could start using by January 2015. By speeding our development with WSO2, we were able to complete the first minimally viable version of eKauri in October 2014, three months ahead of schedule, and we already have a built-in market and clients that want to pay for the product.

With a rapidly aging population worldwide, we need to move quickly to bring new solutions to market that enhance the health and quality of life for senior citizens. WSO2 has played an important role in helping us meet that demand with eKauri.

WSO2 recently published a case study about our use of its products with eKauri. You can read it here: http://wso2.com/casestudies/bdigital-delivers-e-health-and-smart-home-platform-using-the-wso2-carbon-platformJoan_Protasio

 

Joan Protasio, AIL Software Engineer, BDigital E-Health R&D Group

WSO2Con Insights – AlmavivA Adopts Lean Approach to Public Administration with WSO2

The Italian Ministry of Economy was looking for a complete transformation in data management by redefining and organizing its own data, so that information of millions of employees of the Italian Public Administration would be unique and certified.

The proposed system spelt the integration of two main IT systems in the Ministry; one that handles personal data, and a second that handles economic data, so that the system would have one single point of management, and serve applications regarding salaries and personal data as a self-service for the Italian public sector employees.

The Ministry approached AlmavivA Group, Italy’s number one Information and Communication Technology provider, for a solution. Guiseppe Bertone, Solution Architect at AlmavivA S.p.A. said during his session at WSO2Con 2014 EU, in Barcelona, Spain that AlmavivA designed and proposed an ad hoc master data management (MDM) solution for the Ministry, based on WSO2 products to manage the data of 2.6 million employees.

Picking the Best Product Solution

He said that there was a set criteria that AlmavivA and their client listed out prior to choosing the right products and platform for the project. Some of the critical features were interoperability with existing IT components, high modularity, optimized for performance, and most importantly, open source. Comparing pre-built product solutions available in the market, Bertone and his team made a decision to use WSO2 products for the entire solution.

“WSO2 products fit the requirement. You can enable only the components that you need, and leave the rest of it out, unlike in pre-built solutions,” he said.  almaviv1

He added that there were many redundant repositories within the Ministry IT systems; datasets needed to be optimized and integrated with external systems, and a migration workflow for the existing data had to be defined.

The reference architecture for the MDM solution included interface, events, security, and data quality components, as well as the repository layer, which consists of four databases; master data, meta data, historical data and reference data.  

The AlmavivA project ‘Anagrafca Unica’, roughly translating to ‘Unique Repository’, was initiated in March 2012.

The WSO2 Advantage

The mapped reference architecture was a total solution platform based on a set of WSO2 products;   almaviv2

WSO2 Enterprise Service Bus (ESB) for interface services, the WSO2 Data Services Server (DSS) to access the repository layer and manage all life cycle services, WSO2 Identity Server (IS) as the security and identity component, WSO2 Message Broker (MB) for communication between applications, WSO2 Governance Registry (G-REG) to store configurations of all components, and the WSO2 Business Activity Monitor (BAM) to monitor services across the entire MDM solution. OracleDB is used as the repository layer.

With BAM being easily integrated to other WSO2 products, AlmavivA simply had to install only a specific BAM load inside each component, so that the statistics and real-time performance could be monitored. An additional console was added as an UI for the system’s custom procedures.

Another advantage of using WSO2 products was brought to light during the development stage; “Many aspects of WSO2 products can be simply configured from the web UI, or the developer studio for all WSO2 components. It’s really useful and easy to use,” explained Bertone.

In a covalent situation such as this, WSO2 deploys Carbon Apps. By creating a carbon app, a single file consisting of all components is created, so that once the file is deployed, the server knows which components to take, according to Bertone. “This is useful because once you have a system like this you can integrate it with an application cycle management solution already present in the customer environment, like we did,” he says. “We have now created a console where with a single click, the customer can pass from staging to production.”

AlmavivA is looking to expand Anagrafica Unica across the country to include all employees of the Italian Public Administration sector in the system, bringing the total user count to 3.5 million. Bertone and his team are also looking to serve data to external systems, such as the Ministry of Health, with more government institutions being added along the way.

For more information on AlmavivA’s development of the Master Data Management System, view the recording of Bertone’s WSO2Con EU presentation.

giuseppe-bertone-hover

WSO2Con Insights–Trimble Builds an Enterprise PaaS Framework with Open Source

A large part of the value of Trimble solutions is that they enable customers to build and manage their own positioning-centric solutions for employees in the field—a key requirement for customers in the agriculture, construction, and transportation sectors. Trimble also needs this capability in-house, since its various divisions are set up to be entrepreneurial and have the speed and agility to execute. As Prakash Iyer, Trimble’s vice president for software architecture and strategy, explained during his session at WSO2Con 2013 US, building an enterprise platform as a service (PaaS) framework with open source solutions helped Trimble meet these goals.

The Move to a Cloud Platform

When Trimble first considered building a flexible development platform, the question was whether to go with a traditional platform versus a product-driven platform, Iyer recalled. With a traditional platform, by the time the hard work is done, the technology is likely to have changed, he noted. The better solution, the Trimble team realized, was a product-driven platform where selection of the platform elements is driven by the product. Users can then build applications on the platform and deliver them efficiently.

PrakashIyer1The Trimble Platform as a Service, known as TPaaS, provides the core services needed to build any modern enterprise application, and also provides an architectural framework to build loosely coupled SOA applications, Iyer explained. Providing a foundation for TPaaS are four multi-tenant, cloud-enabled WSO2 Carbon products: WSO2 Enterprise Service Bus, WSO2 API Manager, WSO2 Application Server, and WSO2 Identity Server.

“Our first implementation of TPaaS had Identity Server, App Server, API Manager and ESB. We didn’t use the whole stack but then we incrementally added to it,” Iyer noted. “We’re able to then build an app on that platform and then deliver it to the team, and prove it can be done efficiently. And that creates momentum.”

TPaaS Supports Internal and External Users

Iyer explained that Trimble’s development platform includes deployment infrastructure and managed hosting services, all of which help reduce the cost, time, and complexity of application development.

A key advantage of TPaaS is that it is accessible to Trimble’s network of partners and dealers, who often need to use the system to exchange data and flow transactions through it, Iyer said. It can be offered as a service framework to these partners and dealers to host their applications. He noted that the platform also provides a cloud container that can host any Trimble service, and act as a gateway to share any Trimble service for wider reuse.

The Benefits of Open Source

While the cost savings of open source were attractive, Iyer stated that other aspects of an open source licensing model were important.

“We can take WSO2 and customize it. If we don’t find everything we need, we can PrakashIyer3 customize it. We don’t have to take everything, just the part needed for us,” Iyer observed. “The other advantage is portability and ownership. I want to take my PaaS across multiple infrastructures and services; some divisions may want to deploy in Rackspace, some in Amazon, or even internally.”

Additionally, since technology changes so quickly, using WSO2 open source products allows  Trimble to avoid costly investments in solutions that will become out of date, or can’t be customized. Finally, there was the issue of focus. Iyer recalled that Trimble needed to build a solution, and using open source would allow the team to focus on those areas where Trimble could differentiate.

“My goal was always to eventually have everything from writing the code to deployment; things we could assemble and put together our own platform, and then we can focus on the applications,” Iyer said. “That was the strategic alignment part we shared with WSO2.”

For more information about Trimble’s development of an enterprise PaaS framework, view Iyer’s WSO2Con 2013 presentation.

WSO2Con-US-2013--Building-an-Enterprise-PaaS-framework-using-Open-Source-Components

WSO2Con Insights – BarclaycardUS Optimizes Backend Services and Performance Across 10 Distinct Environments with WSO2 ESB

As one of the world’s largest and most respected financial services companies, with partnerships that include over 60 best-in-class companies and brands, BarclaycardUS is dedicated to making the purchasing experience simple and rewarding for its customer community. A key part of serving those customers is working with backend service providers using multiple protocols at very high volumes, explained Alex Brown, BarclaycardUS group lead, in his presentation at WSO2Con 2013 US.

For BarclaycardUS, the solution has been to integrate to integrate WSO2 Enterprise Service Bus (WSO2 ESB) with its existing service-oriented architecture (SOA), and leverage REST APIs with the ESB to boost performance and monitoring across 10 distinct environments.

Different Partners with Different Domains

BarclaycardUS’ partnerships involve handling credit cards for large companies such as Apple and LL Bean, and specializing in the backend services for these types of businesses. Additionally, BarclaycardUS works with different vendors to conduct its credit checks, rewards and fulfillment.

“This creates an interesting perspective, since we have to integrate with a lot of different partners with unique and different needs,” Brown said.

AlexBrown-Barclaycard1According to Brown, the company has to accommodate applications and services relying on SOAP, REST, Android and Apple iOS mobile operating systems, Voice XML, and OFX, along with many different APIs. In the wake of increased cross-domain orchestration, BarclaycardUS realized the need for an ESB to serve as a common backbone for connecting these different services.

After exploring various offerings on the market, BarclaycardUS decided on WSO2 due to its ease-of-use and comprehensive middleware stack, which represented endless possibilities for growth.

“The other open source platforms we looked at during the time didn’t have that, and WSO2 was very complete and robust and supported all the modern protocols, which was a big advantage for us,” Brown explained.

Strengthening Services with WSO2 ESB

Today, Brown noted, “We’re leveraging the ESB and different parts of it, and we have a lot of different use cases.” At WSO2Con he reviewed three of those use cases to highlight how WSO2 ESB is enabling BarclaycardUS to optimize business services.

Prepaid Platform is a new service the company has rolled out, which works as a mobile application available on iPhone and Android application stores. It supports balance inquiry and mobile application and origination, Brown noted. The mobile bill payment platform also is leveraging external prepaid vendors.

“To do that, we had a mobile app that was talking in REST to the ESB, and behind the scenes AlexBrown-Barclaycard2 we had to orchestrate to many different systems,” Brown explained.

Core Domain Services: are hosted in many locations and pull data from data sources and different vendors. As a result, company wants to gain control over what is happening and have a cohesive view of service APIs in the organization, Brown explained. The company’s goal is to have customers, accounts, devices and some of these core domain services facade with each other. Working with the ESB, the company has an effective intermediary to do this.

“In the ESB, behind the scenes, it’s talking to many different things like partners, existing services we have, and different vendors—this is what we’re heading towards and is in production now,” Brown said.

Account Aggregators is a new service that is currently in development and will go live soon, Brown noted. It will address the challenge of screen scraping, programmatic collection of visual data, which can often be a heavy process that requires aggregators to login, pretend to be a customer, go through and load Web resources. BarclaycardUS didn’t want these aggregators to take valuable processing away from its regular customers. With the WSO2 ESB, BarclaycardUS can have its aggregators support the OFX standard used by banks and boost performance.

“In the ESB, the aggregators are coming in and are authenticating themselves, and I’m loading all of this data at exactly the same time. So the aggregators were able to get the info off of our website, scraping it in a minute or two—this takes less than a second, around 900 milliseconds—we’ve loaded 100% of that customer’s information and given it to the aggregator,” Brown said.

He added, “We’re also using the throttle, so if they’ve indicated they won’t go above a certain threshold but there are multiple aggregators, we need to make it so they don’t accidentally go above that threshold.”

Investing in the Future

In addition to WSO2 ESB, BarclaycardUS takes advantage of WSO2 Governance Registry and WSO2 Business Activity Monitor. Looking ahead, Brown noted, the company plans to further enhance existing services and the use of coesb-logo-h42mposite services.

“The goal is to make this a cohesive API,” Brown greg-logo-h42explained. “We’re finding that we have a lot of services that had to be handwritten, which involves talking with bam-logo-h42our backend service providers and developers, and taking the time to test and deploy.”

BarclaycardUS plans to integrate the WSO2 Identity Server into its system to implement OAuth for RESTful services, which will be important for mobile applications. Additionally, the company is looking at the potential to leverage the WSO2 Complex Event Processor to help manage business operations and events streams and the WSO2 API Manager to gain insight into metering and monitoring of different service consumers.

“It sounds like we’re going to get exactly what we need with WSO2 in 2014, it’s a very cool product we’re going to be playing with more.”

For more information about how BarclaycardUS works with different backend service providers across 10 distinct environments using the WSO2 Carbon enterprise middleware platform, see Brown’s WSO2Con 2013 full presentation.

WSO2Con-US-2013-Powering-an-enterprise-with-messaging-and-APIs

WSO2Con Insights – Accenture Solves IT Integration Challenges Using the Cloud-Enabled WSO2 ESB to Support the Accenture Cloud Platform

As the world’s largest independent technology and outsourcing services provider for nearly 25 years, Accenture has extensive experience in helping global clients navigate through the
complex cloud choices in the market. Igor Mameshin, a manager within the Accenture Cloud Platform (ACP), explained in a presentation at WSO2Con US 2013, how the company is using WSO2 technology to help address today’s cloud demands.

Mameshin explained that, as companies use hybrid cloud integration—combining private computing resources and public services with integration touch points between the two environments—new and more complex risks arise.

For Accenture, the solution was to build a cloud-based infrastructure that accelerates the successful adoption and integration of cloud services, without compromising quality, standards or security. The Accenture Cloud Platform, powered by WSO2’s enterprise middleware platform, Mameshin explained, provides a rich portfolio of application adapters that simplify the connectivity to external systems such as ERP applications like SAP, Salesforce.com, social platforms and other integration endpoints.

The Service Integration Challenge

“Governance was a challenge in the past, but the cloud introduces new and even more complex risks. Service interoperability is a critical problem to solve,” Mameshin observed. Without consistency to this solution, IT users take over the issues, and a company loses control over defining any IT infrastructure within its organization. Multiple business units in the enterprise go to multiple public providers. “Thus, you never know what goes on within the enterprise,” he said.

IgorMameshin-AccentureTo address integration challenges around connectivity, system configuration issues, application customizations, non-functional requirements, reliability, scalability, and security, Accenture realized that the solution could not rely on existing on-premises integration tools. The resulting solution was the Accenture Cloud Platform, a cloud-enabled middleware platform based on a SOA, to better implement the interoperability between the cloud and on-premises environments for its customers.

By acting as both a governance entity and a cloud broker, the Accenture Cloud Platform allows an enterprise to provision services in public cloud providers. Accenture currently works with Amazon Web Services, Azure, NTT Communications, and Terremark. A proof of concept was developed to explain the integration between Salesforce.com and SAP ERP using a cloud-based implementation of WSO2 Enterprise Service Bus.

Integration Approach Overview

Accenture has employed WSO2’s Enterprise Service Bus as a cloud-based integration backbone to pass messages from system to system, Mameshin explained. This has provided agility and flexibility to adapt to future change and growth. Moreover, it provides location transparency, transformation, routing, and protocol conversion, and it has helped with security issues, reliable messaging, and monitoring and management.

The platform has a management portal that provides a self-service interface where customers can engage with the service catalogue and pre-integrated multiple services, and order cloud services through this front-end. WSO2 ESB is installed on one of the virtual machines that Accenture has provisioned in the entity public cloud. IgorMameshin-Accenture2

Within WSO2 Enterprise Service Bus is WSO2’s Salesforce.com Certified Force.com Developer (SFDC) mediation library, which contains a set of ESB templates and offers operations that simplify a customer’s interactions with Salesforce.com. Supported operations include log in, log out, create, update, Query and QueryMore. On the Salesforce.com side, Accenture used SOAP API, REST API, and the WSO2 Salesforce.com Connector to work with these APIs. A new feature of the WSO2 Developer Studio integrated development environment (IDE) allows for developing integration flows when integrating via the Salesforce.com connector.

Mameshin noted that an advantage of WSO2’s application-level integration approach, which uses real-time integration based on the native application’s integration frameworks and APIs, is that it preserves the application’s data integrity. It also allows for real-time integration between Salesforce.com and SAP, he said, and provides application-level security and an audit trail.

In implementing WSO2 Enterprise Service Bus to create Accenture’s cloud platform, Mameshin concluded, “We established that WSO2 ESB is a powerful and stable product—it did the job quickly and correctly. It has been working for three months without needing to re-boot to fix any issues.”

For more information about how Accenture uses WSO2 products to power the Accenture Cloud Platform, see Mameshin’s WSO2Con 2013 full presentation.

WSO2Con-US-2013-Using-WSO2-ESB-to-integrate-Salesforce-com-and-SAP-ERP-Accenture (1)

WSO2Con Insights – Algar Telecom Delivers Innovation Through Next-Gen Server-Side JavaScript Framework

As telecommunications continue to compete on service, they  look at new ways to enrich the customer experience. For Algar Telecom, one of those ways is enabling customers to create their own Web applications using the popular JavaScript language.
At WSO2Con US 2013, Cesar William Alvarenga, front end engineer at Algar Telecom, described how the company  is taking advantage of Jaggery, WSO2’s server-side JavaScript framework for composing Web applications.

Building on Initial Success

Before describing the company’s use of Jaggery, Alvarenga began by talking about the company’s first project using WSO2 software: Algar Telecom OCS (online charging system). OCS is used to charge customers in real-time, based on their service usage, and all mobile and fixed line traffic will run through this platform. The traffic is passed through WSO2 Enterprise Service Bus (ESB), transforming the data and integrating with legacy services.

“Today we are processing over 200,000 transactions per day and this number will increase every day,” Alvarenga said. “The performance of the ESB is agreeable and it supports our telecommunication requirements.”

CesarWilliams2Algar Telecom also uses WSO2 products to support its Coreo platform, which is used to deliver a range of applications. For example, Alvarenga noted, an application could let a user send in the airport and flight number and receive the flight information—all using SMS.

Currently Algar Telecom deploys WSO2 ESB and WSO2 Business Activity Monitor (BAM) across the Coreo platform, Alvarenga explained. WSO2 ESB is used to create an interface between all the Coreo modules and transform the data, while the company uses WSO2 BAM to collect and present all of the platform’s data. The company is now testing Jaggery to facilitate Web app development.

The Jaggery Advantage

“Web developers love JavaScript, but typically must alternate between two languages when they want to build applications on the server side,” Alvarenga said. “Using Jaggery allows our developers to work strictly with JavaScript to build Web applications across the Coreo platform.”

With Jaggery, users can generate HTML and they can exchange messages with JSON, CesarWilliamsAlvarenga observed; “Another benefit is you can reduce the number of layers in your solution. You can access directly the ESB or database for example, and this helps the developer to build a small solution, accessing directly the main services.”

Working in JavaScript using Jaggery also supports Algar Telecom’s vision of a mobile platform that inherently supports Web-native applications.

“I think the future evolution shows that the mobile platform will support these Web  applications,” Alvarenga said, “Today we have some operating systems that support only this type of application, like Ubuntu phone, HP WebOS. Tizen from Linux, and Firefox OS from Mozilla. Using Jaggery, you have a lot of functionality, so if you know JavaScript, for the server-side application, you don’t have to do much. It’s very easy.

Alvarenga wrapped up by providing a detailed explanation of how Jaggery is used with the Coreo platform—using the Jaggery template to generate HTML for the user, granting access to the user with Jaggery and an OAuth module, executing the application using the WS-Request module, and using the ActiveMQ module to get the result back to the user.

For more information about how Algar Telecom is using Jaggery and other WSO2 solutions to develop web and mobile applications, view Alvarenga’s WSO2Con 2013 presentation here.

WSO2Con-US-2013-Using-Jaggery-in-Telecom-Web-and-Mobile-Applications

WSO2Con Insights – How WSO2 Middleware Powers Deutsche Telekom’s Connected Car Platform

Like many telecommunications companies, Deutsche Telekom is seeking new ways to drive revenue and business growth. One of those initiatives, the “connected car” program, is being driven by the company’s T-Systems unit, which delivers information and communication technology (ICT) solutions.

As Thomas Wieger, solutions architect for T-Systems International GmbH, explained to WSO2Con US 2013 attendees, connected car is a modular, service-oriented architecture (SOA) based platform that integrates vehicles with the Internet and enterprise processes. For instance, trucks can be connected with a back-end infrastructure, or fleet management software can be used to monitor vehicle maintenance and driver efficiency. Electric vehicles, which are also growing in popularity, also require technology such as mobile applications that provide monitoring and control of energy usage.

“The great thing about connected car in the activities here is that it leverages all capabilities of Deutsche Telekom,” Wieger observed. “So we can provide connectivity, especially mobile Internet; we can provide worldwide operations in our data centers; provide platform development with T-Systems system integration; and application management with T-Systems. All these capabilities are already in place and we want to put these together to do new and exciting things.”

Seeking a Single Platform

T-Systems has several types of clients for its connected car business, and several use cases—for example, big car manufacturers want to provide mobility service to their fleets, and auto dealers want to improve customer satisfaction by remotely diagnosing car problems.

Thomas-Wieger-at-WSO2ConUs-2013However, Wieger told attendees, “If we do everything like a solitary project, we would get a lot of different software with different components. We would be reinventing the wheel, re-developing the same component over and over again.”

Instead, Wieger explained, T-Systems recognized early on the need for a single platform to enable solution development and services across all of its customers and services, using common components as well as a modular, SOA.

Open source middleware at the core of the platform was a requirement, Wieger observed, since T-Systems was building a platform to serve millions of cars and customers and wanted to avoid the burden of licensing costs. In addition, the company wanted the ability to troubleshoot and fix solutions on its own if the vendor was not addressing the issue.

Working with WSO2

T-Systems first decided to work with WSO2 in 2011 after evaluating WSO2 Enterprise Service Bus (ESB) and choosing the software for its scalability and cost-effectiveness. Today, everything in the connected car platform is connected to WSO2 ESB, Wieger said.

“One ESB is used as a device gateway or vehicle gateway for data from the car; all that is exchanged between the embedded side and the backend side goes through the device gateway,” Wieger explained. “We are also using the ESB for integrating all services in our platform, so all end user services and platform services are using the ESB to work together, and we also use the ESB for integration of third-party content end services.”

T-systems-WSO2-Backend-platformIn addition to WSO2 ESB, T-Systems also uses WSO2 Identity Server for access management—since security is a high concern for many customers, WSO2 Application Server to host services in the connected car platform, WSO2 Business Activity Monitor (BAM) for monitoring and control, and WSO2 Governance Registry.

With an eye to the future T-Systems is currently evaluating WSO2 Complex Event Processor (CEP), Wieger said; “It’s very interesting to have fast reactions on events from devices—to get continuous streams of data in the backend—so we can react on data.”

Using the WSO2 middleware with components that we have enhanced for the domain of connected car, we have an operating system for connected car solutions,” Wieger concluded. “We have the first cornerstones of our platform already in action and running, and are enhancing it continuously to implement the vision”

For more information about T-Systems development of its middleware platform, view Wieger’s WSO2Con 2013 presentation.

WSO2Con-US-2013-How-WSO2-Middleware-powers-Deutsche-Telekoms-connected-car-platform-architecture

Implementing an API Façade with the WSO2 API Management Platform

[Based on a post originally appearing at http://asanka.abeysinghe.org.]

In my previous post I described about the reference architecture of API Façade. This post gives implementation details using the WSO2 API Management Platform and the WSO2 ESB.

Business scenario: A backend service with SOAP binding required to expose as a RESTful service and secured using OAuth. Consumers require responses in either XML or JSON using the same API.

Technical requirements: SOAP to REST protocol switching, content negotiation, XML to JSON conversion.

Reference architecture

Based on the recommended API Façade Pattern in my previous blog, the architecture looks like following diagram:

APIFacade-blog-refarc1

The API Gateway (Gateway is one of the roles in API Management Platform) will expose the RESTful API. The Mediation layer will do the protocol bridging and connect to a backend service with the SOAP binding.

Lets look at the implementation with WSO2 middleware products:

APIFacade-blog-refarc2

WSO2 API Manager and WSO2 ESB will be the primary middleware components used to build this Façade pattern.

Mediation logic (using standard EIP notations) looks like below.

APIFacade-blog-mediation

API definition in API Manager (Gateway)

Screen Shot 2013-05-04 at 7.29.12 AM

Mediation in ESB

Screen Shot 2013-05-04 at 7.23.19 AM

Commands to Invoke the API

XML response :
curl -v -H "Authorization: Bearer zBAIbMiXR4AJjvWuyrCgGYgK2Osa" -X GET
http://localhost:8280/ordersoap/1.0.0/view/JBLU
Screen Shot 2013-05-04 at 9.55.31 AM

 

JSON response:
curl -v -H "Authorization: Bearer zBAIbMiXR4AJjvWuyrCgGYgK2Osa" -X GET
http://localhost:8280/ordersoap/1.0.0/view/JBLU -H "Accept: application/json"

Screen Shot 2013-05-04 at 9.57.38 AM

To view the JSON message properly in CMD

curl -v -H "Authorization: Bearer zBAIbMiXR4AJjvWuyrCgGYgK2Osa" -X GET
http://localhost:8280/ordersoap/1.0.0/view/JBLU -H "Accept: application/json" | python -mjson.tool

In the above sample WSO2 API Manager running with default offset (0) and WSO2 ESB running with offset 3.

Note: If you want to use the anti-pattern of doing both Facade and mediation in the same layer, you can copy the ESB configuration to API Gateway configuration and get the same functional result.

Asanka Abeysinghe
Vice President of Solutions Architecture
Blog: http://asanka.abeysinghe.org

A Pragmatic Approach to the API Façade Pattern

[Based on a post originally appearing at http://asanka.abeysinghe.org/2013/04/pragmatic-approach-to-api-facade-pattern.html.]

Business APIs expose business functionality for access by external and internal consumers.  In technical terms APIs provide an abstract layer for the internal business services to cater to consumer demand.

Most service platforms are not ready-made to safely and cleanly expose internal services to consumers, posing a common challenge for API providers.  Providing a pragmatic approach to the well-known API Façade pattern is the motivation of writing this post.

Fanike-harajuku-store-opening-1cades hide the complexity of internal implementations and provide simple interfaces.  This is a common pattern in computer science but we can even find it in real world too. Lets look at a real world example first: if you walk to a shoe store you find samples displayed in a manner making them easy to pick and select, but if you walk to the back oUntitled 2f the store you will find a massive warehouse with millions of shoes that will not provide an easy way find the correct shoe for you. What does the showroom do?  It provides a facade that displays the shoes in a way that helps buyers select and buy the shoes they want, thereby reducing the complexity and enhancing the buying experience.

Similarly, facades used in computer systems hide complexity and provide a better experience for the consumers (demand).

FacadeDesignPattern

Lets look at how Façade pattern applies for API Management. There is a clear gap between the consumer demand for APIs and the internal services available in each enterprise. As an example, consumers look for Web APIs that can access using REST principles, deliver content using JSON and secured by OAuth addition to that the APIs can be externally accessible and discover. This may map to an authenticated XML/SOAP based service within the enterprise.

API Façade patterns mainly contains four functional layers:

1. Backend services
2. Mediation
3. Façade
4. External format / Demand Slide08

Most commercial API Management solutions treat the Mediation, Façade and Demand as a single functional, architecture as well as deployment layer.

Slide09

If we look at the gap between backend services and the Demand, can a lightweight mediation layer with limited service bindings such as HTTP/s, JMS can build a business API? Are you willing to add the resulting additional wrapper service layer and maintain it?

WSO2 recommends more pragmatic approach by recommending dividing the Façade layer and Mediation layer into clear functional, architecture and deployment layers.

Slide13

This architecture can facilitate heavy mediation including service chaining/orchestration to provide a business friendly API for the consumers. This also allows one to do a clean deployment by inheriting the infrastructure policies appropriate for each layer, as well as scale each architecture layer separately.

Slide15

Implementation of WSO2 API Façade is facilitated by using the WSO2 API Manager to build the Demand and Façade layers, the WSO2 ESB to build the Mediation layer (also add in products like the WSO2 Business Process Server if required) and connect to the existing services. If you are planning to write new set of backend services using standards such as JAX-WS, JAX-RS you can use the WSO2 Application Server as a runtime. In addition to that if there are any other business/technical requirements to build new business APIs you can add them with or after the mediation layer by leveraging the 17+ products in the WSO2 Middleware Platform.

This pragmatic and architecturally rich approach of WSO2 API Façade pattern results many benefits for the API management solutions:

  • Clean architecture by separating the concerns
  • Have a clear separation of internal and external processing of an API call
  • Ability to scale based on the actual usage of each layer
  • Avoid implementing new services or building wrapper service layers
  • Leverage SOA principles with the new Web API architecture
  • Utilize the middleware and go to market quickly

Having said that if you are planning to have a single layer to facilitate all three layers of API Façade, there are no technical limitations in WSO2 API Management Platform to doing that. You can build the mediation by configuring the pre-configured ESB running as the internal dispatching engine of API Gateway.  However for a real-world deployment we recommend that you consider using the flexible, componentized nature of the WSO2 platform to build a clean, scalable, manageable WSO2 API Façade. In my next post I’ll talk more about how to implement this pattern using WSO2 technologies.

Asanka Abeysinghe
Vice President of Solutions Architecture
Blog: http://asanka.abeysinghe.org

WSO2 product’s; summer release round-up

Couple of weeks ago, CTO Paul Fremantle and Tech Evangelist Chris Haddad, conducted a webinar on the innovative advancements of the WSO2 Carbon middleware and WSO2 Stratos cloud platforms. Here are some highlights from their presentation

  • WSO2 Carbon core 4.0 released with many improvement and new features
    • Enhanced Deployment Synchronizer
    • Deployment performance improvements
    • Managements and worker node separation
    • JDK 1.7 support
    • Better integration with Tomcat 7
    • Upgrading Equinox SDK (OSGI Runtime) to v3.7
    • P2 Repository: Features grouped by product
    • Multi Tenancy in Carbon
“The Carbon platform is your reconfigurable modular middleware. Recently we’ve seen lots more customers actually wanting to de-couple different parts of a product to vertically scale while at the same time horizontally scaling. This capability is proving to be a major benefit of the Carbon platform.”
– Paul Fremantle  
“We are rapidly evolving all of our products simultaneously on top of single cohesive code base. This is unparalleled in the industry to have such coordinated releases on a single platform.”
– Chris Haddad
  • WSO2 Stratos 2.0 Platform as a Service will include
    • Support for multiple languages and runtimes
    • Support for more IaaS providers (vmWare, EC2, OpenStack, CloudStack, Rackspace etc.) via Jcloud
    • Enhanced manageability
“We are embracing a heterogeneous environment were you can run PHP in the cloud environment and take advantage of the rich set of PaaS foundation services that Stratos offers. Also you can plug-in any application server or asynchronous  server and cloud-ify  the application environment by having an mechanism that ties back into the pass foundation and Startos controller services.”
– Chris Haddad
“The key differentiator for Startos is its inherent multi-tenancy. There are other PaaS offering that have the polyglot language support but what they don’t have is the concept and modeling of multi-tenancy. That plus the richness of the set of Stratos services that the cartridges have available to you make us really stand out.”
– Paul Fremantle

You can watch the full recording of the webinar here: http://wso2.org/library/webinars/2012/09/wso2-carbon-wso2-stratos-summer-release-roundup

 – Hasmin AbdulCader, Director, Communications

Open Conversations on the New Business of Enterprise Software

WSO2