Tag Archives: API Management

Guest Blog: Ensuring Your API Quality

Let’s face it – in this API economy, there are a lot of solutions out there for managing, testing, deploying, tracking, and monitoring your APIs. It’s a booming industry and you can see evidence of it all over: large enterprise companies reinventing their message around the concept of microservices and APIs, and the rise of startups whose sole focus is APIs.

It’s noisy out there. And you’ve got a business that depends on the quality of your API. So how do you wade through the noise and find the right solution for you? Let’s look at some considerations:

  • End-to-end capabilities One important factor to consider is how comprehensive the solution is. You know that you need to do the basics – test, manage, track, monitor. You can find and implement tools that each do one of those functions and tie them together procedurally. Or you can find a solution that provides all of those capabilities with minimal overhead.
  • Try Before Buy If you’ve been around software development long enough, you’ve seen it happen more than once – a tool sounds great on the website… and the demo was really slick. But when you actually try to use it with your team and your processes, it falls short. Having a free trial period where you can actually use the tool with your own API and your own staff lets you validate that this is the right tool for you.

Even better is having access to open source products, where there’s never a cost involved and you have the ability to contribute to the code base and make it even more applicable to your work environment.

  • Affordability – If you can find an open source tool that has the support and features you need, that’s great. Even better is when you find an open source tool that is integrated with the rest of your tool set to provide you with that end-to-end solution we talked about. But if the tool that fits you best is not open source, you should consider how well it fits within your budget. Having affordable options means you can provide licenses for your whole team rather than compromising on how widely you distribute the tools.

Introducing the WSO2 plugin for Ready! API

If you can find a way to put all of this together, you’ve got a very powerful story around your API quality. Now with our new plugin that integrates the open source WSO2 API Manager platform with the affordable Ready! API platform, you can take your API from inception to deployment, knowing that you have fully tested, secured, and managed that important asset. At SmartBear, we are very proud of our partnership with WSO2, a fellow open source vendor and API quality advocate. For more information about the new plugin and how it works, check out the github readme. The plugin can be downloaded and installed from within Ready! API’s Plugin Manager.

Lorinda Brandon,  Technical Evangelist, API Products, SmartBear

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 solutions 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 products 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.

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.

The 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 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.

API Registry and Service Registry

[Based on a post originally appearing at http://asanka.abeysinghe.org/2014/07/api-registry-and-service-registry.html.]

Registry acts as a core component in Service Oriented Architecture (SOA). Early SOA reference architecture named the registry as a service broker for service providers to publish service definitions, allowing service consumers to look up and directly consume the services.

Figure 1: SOA triangle

With the evolution of SOA, Registry started to provide more value, such as lifecycle management, discovery, dependency management, and impact analysis. The Registry became the main management, control and governance point in such architecture. It also became a vital component within the SOA Governance layer of the overall architecture. As a product, the Registry started providing three distinct functionalities – repository, registry and governance framework.

Repository functions to store content such as service artifacts, configuration, and policies, the Registry to advertise them for the consumers to access, governance to build management control and policy-based access over the stored artifacts and to connect people, policies and data.

Changing Role of Registry

With changes and challenges taking place in businesses as well as the technical architecture of the enterprise, the role of the registry has changed. Even while the technical definition of a service is based a standard (e.g. WSDL, WADL), the business definition of a service can vary from organization to organization. Therefore, a customizable definition for a registry artifact became a requirement. For example WSO2 Governance Registry contains RXT (Registry ExTensions) to define services. RXT provides a customizable service definition as well as sets the behavior of an artifact when an artifact is imported and operated in the governance runtime.

When it comes to governance, registry became the core design-time governance controller in the enterprise. Features such as Discovery and UDDi compatibility became nicer to have features than the practical use of them. Having said that, runtime wiring based on environment metadata has emerged as a practical replacement for discovery.

In the modern architecture, Services implement business functionalities of an organization, APIs are interfaces for services that allow consumers to consume business capabilities.

During the last decade, services were developed using various service development standards, programming languages, and frameworks. Services were designed and developed – and funded – in silos in each business/organization unit. This led to duplicate services in the same organization which violates the core SOA concept of reusable shared services. Services are more technically driven, designed and implemented by enterprise developers. If we look at a service catalog, more than 80% of the services perform some kind of a CRUD (Create/Read/Update/Delete) operation. Data Services is another common industry term used to describe the CRUD services. The remaining services implement business logic with the help of business rules and CRUD services. A small remaining portion of utility services exists to provide functionalities such as computations and validations.

Figure 2: Service types

The technically driven nature of the services lead to unhappy consumers. As a result, new service implementations were introduced to the market by duplicating as well as avoiding reusability. Some enterprises started implementing wrapper services in front of the actual services and added an additional burden of maintaining a new service layer.

Emerence of APIs

Complex, rapidly changing business requirements for consumer apps have changed the expectations of the services. Consumers increasingly look at APIs to be:

  • RESTful
  • JSON based
  • Secured with OAuth
  • Follow WEB API design

Unfortunately, most of the existing services are not compliant with these expectations leaving a huge gap between the implementation and demand. In a consumer-driven market, APIs that do not meet the demand will not have value and will not survive for long. To meet the demand, technical teams started to write wrapper services in front of the actual services. But this created a huge maintenance issue as well as slowing down the time to go-to-market.

Using APIs as the service interfaces for consumers to invoke service functionality, resolves the issues we identified above, mainly converting technical driven services into business-friendly APIs as well as implementing the common reusable services for the enterprise and meet the demand/expectation of the service consumers. There is much more value proposition from APIs to the enterprise. Lets now look at them in detail.

Figure 3: Service and APIs

A pure API layer might be not enough to cater the demand. A mediation layer might be required based on the gap between the services and API. As I explained earlier APIs are light-weight interfaces that do not represent any implementations. Traditional Facade patterns came to the API architecture as API Facades, providing a solution to this problem. Introducing a mediation layer with the API Facade will take care of protocol switching (transports/message formats) as well as security bridging. In addition, it helps to convert the traditional backend services into modern web-api designs by using techniques such as service chaining (light-weight orchestration). More information can be found in this blog. Having said that, API-ready backend services can be directly exposed through the API management layer as an API without going through any additional mediation layer.

There are two main usages of APIs, internal and external. External APIs create an eco system for a business to expose their functionality to their customers and partners in a consumer friendly, secured and governed manner. Internal APIs again help to resolve the broken SOA pattern and provide reusable common functionalities across business units. This allows business units to promote and “sell” their services across the enterprise and maintain and manage by the business unit itself.

Design-time Implications on the Registry

I hope the information provided above is insightful and has helped you identify the usage of the registry and a clear differentiation between services and APIs. Lets now look at the key discussion points of the service registry/API registry. Looking at a reference architecture will be more helpful to identify the concept.

Figure 4: Service and API registry reference architecture

Service definitions will be defined in the service registry, the service registry will maintain the additional metadata about the services and catalog detailed technical definition of the services. Usually service definitions is defined automatically when services are deployed to the service containers, but in some enterprises this happen as a manual process by importing the service definition from various catalogues or service containers. Once the services are defined the registry will create the dependencies, associations and versions of these services and metadata.

We spoke about having a mediation layer to bring non-API ready services into API ready, proxy services defined in the mediation layer. This will also go as service definition in the service registry.

While technical definitions of the services and proxy services are defined in the service registry, consumers of the APIs require a place to lookup the services. This is where the API registry will come into the picture as the consumer-facing API catalog.

The target audience of the APIs are application developers, hence an API registry requires and supports publishers to cater to their expectations such as social features and the ability to subscribe and get an access token.

From an API governance point of view, API publishers should be able to secure the APIs by providing access control to the APIs and resources inside the APIs. Some APIs might require additional control with entitlement and workflow support to get approval for subscriptions before providing an access token.

Runtime Implications

We already discussed the functional requirements of the two registries, lets now look at the runtime view. The deployment will depend on the nature of the APIs. There are three categories.

  • Internal only APIs
  • External only APIs
  • Internal and external APIs

To facilitate the first category deployment can combine the service registry and API registry to run in the secured network (LAN). But this will provide two different views for the API consumer and the Service developer. External only APIs require the API Registry to expose externally (in DMZ) and service registry to run in the secured network. Internal and external APIs require an external (public) API registry as well as an internal (private) API registry. The internal API registry can combined with the service registry.

Figure 5: Deployment patterns

Conclusion

I hope the information described above helps you identify the difference between services and APIs as well as the benefits of separately architecting a service registry and a API registry. Having two registries helps fulfill the requirements of the API consumer as well as service developers, in addition, this allows you to decouple services and APIs by having an individual life cycle and versions for each of them.

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

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.

According 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, 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 facades 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 composite services.

“The goal is to make this a cohesive API,” Brown explained. “We’re finding that we have a lot of services that had to be handwritten, which involves talking with our 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 Insights – West Interactive Solves Multichannel Communications Challenge With Cloud Solution Powered by WSO2 Carbon Middleware

As the leading provider of technology-driven communication services, West Interactive has developed and managed large-scale, mission-critical transactions for clients’ communications needs for more than 25 years. However, Pranav Patel, West Interactive vice president of systems development, explained in a presentation at WSO2Con US 2013, past solutions deployed by the company weren’t flexible enough to support today’s dynamic business needs.

For West Interactive, the solution was to create West Connect, a cloud solution powered by WSO2 Carbon middleware that enables organizations to provide an improved, personalized experience for their customers.

The Multichannel Challenge

The primary business of West Interactive is to provide contact center solutions, which include cloud-based interactive voice recognition (IVR) and speech automation, mobile applications for customer care, and a hosted contact center—all based on carrier grade, scalable and reliable platform. The company now handles some 4 billion minutes of customer engagement annually.

“Today’s challenge is that there are multiple channels available,” Patel observed. “It’s no longer just a phone call or an IVR that people use to get in touch with your enterprise or customer care.  You have mobile apps, text messages, social media, email, the Web—and enterprises have to manage those and provide customer care solutions across all these channels.”

Patel then explained that, because today’s consumers demand anytime and anywhere access to data and services, across more channels of communication than ever before, it is not enough to simply provide the channels.

“These channels have to be wholly integrated,” Patel said. “The systems that provide these should be very intelligent—that’s the business challenge at hand.”

In seeking to address these business demands, West Interactive realized that the solution would rely, not on extending its existing legacy systems, but by taking advantage of a service-oriented architecture (SOA) based on modern middleware technologies.

West Connect for Modern Communications Demands

The resulting solution was West Connect, a cloud-enabled middleware platform based on a SOA, which is equipped with a set of technologies and core services that are open and flexible. It sits between the top layer of the architecture where there are applications across different channels, and the West Manage API services below, which is where the company can expose services or APIs for customers to use.

Describing West Connect, Patel noted, “The vision here is to build several services on top, as it provides for multichannel communication, multi-tenancy and services like identity management, context awareness, analytics, notifications, rules engine, and more.”

West Connect is based on several products within the cloud-enabled, fully multi-tenant and 100% open source WSO2 Carbon enterprise middleware platform. These include WSO2 Application Server, WSO2 Data Services Server, WSO2 Enterprise Service Bus (ESB), WSO2 API Manager, WSO2 Identity Server, WSO2 Governance Registry, and WSO2 Business Activity Monitor (BAM)

In describing the roles of the products, Patel explained that, “The API will need WSO2 API Manager and Identity Server for exposing the APIs out. West Connect is essentially WSO2 ESB, Governance, and BAM. A lot of the services reside on the Application Server, and when you talk to databases you use the WSO2 Data Services Server.”

The WSO2 Advantage

Patel recounted the factors behind West Interactive’s decision to work with WSO2; “We wanted something we could do a POC with, that would start out quickly and wanted a low cost of entry. The flexible, pluggable architecture made it even much better; we can choose and pick only the products we want. And a low infrastructure footprint—we can run several of these products on a VM.”

WSO2 API Manager was also a major selling point for Patel. “API Manager really gives our business the ability to go outside, not just internally, cataloging the APIs and providing the APIs with documentation as part of the API store.”

Looking ahead, West Interactive is evaluating how other WSO2 products can contribute to expanded capabilities within West Connect.

According to Patel, “We still continue to evaluate all the WSO2 products out there and we can easily see some fitting right here, business rules, complex event processing, and also how to use things like App Factory. The work continues.”

For more information about how West Interactive uses WSO2 products to power West Connect, view Patel’s WSO2Con 2013 presentation.

WSO2Con Insights – How APIs are Driving StubHub’s Business

Transforming a business to an API-centric architecture is a major undertaking, but it’s one that yields many benefits, most notably the ability to grow the business by extending processes to partners. In his keynote presentation at WSO2Con US 2013, Sastry Malladi, chief architect for StubHub, explained how the company has implemented an API-centric architecture to capitalize on this opportunity.

According to Malladi, adopting an API-centric architecture was driven by two factors. First, the company wants to expand from an online marketplace for tickets to become an end-to-destination for fans, including sharing their event experiences and getting information about things to do in event locales. Second, StubHub, which currently has a presence in three countries, plans to expand worldwide.

He observed that to achieve this goal, StubHub needed to build a developer community and enable partners to bring their content and services to the StubHub audience.

For example, Malladi noted, “If you’re at a hotel, and say you want to do something this evening to a concierge—how do we integrate those? You need to go to places where people are instead of expecting them to come to your site.”

Reusable Components Are Key to API Architecture

Before StubHub could extend APIs to partners, Malladi told attendees, the company first had to break down StubHub’s monolithic, hardwired application into shared, usable components, or services. This was necessary, he explained, because an API is an externally exposed “service,” which includes a developer program and typically has a “functional” contact as well as a “non-functional” contract, such as a service-level agreement (SLA). Moreover, the API potentially maybe orchestrated across multiple services, he said.

As part of this effort, Malladi explained, StubHub has established a domain meta model in which each domain is separate and independent and has one or more functions; each of these functions can have one or more APIs, but there is a one-to-one relationship between an API and an endpoint. Additionally, he said, the StubHub team does dependency modeling, so when someone is developing a function or API, the dependency is understood. Finally, he explained that domains are done in such a way that the entities belonging to a domain are owned by that domain, and the only way to access those entities is by going through the domain.

“Bottom line,” Malladi noted, “These APIs are giving us the business agility that we need and the operational excellence.”

API Architecture Opportunities Vs. Challenges

Malladi observed that an API-centric architecture offers several benefits for StubHub in addition to business agility:

  • Sellers have the flexibility to build their own customized solutions, and systems scale well to inventory and traffic.
  • Buyer experiences are enhanced, since it allows the developer community to extend the StubHub fan experience.
  • API brands serve to drive revenue and increase visibility.
  • Developers are encouraged to explore the APIs and see what they can accomplish with them.

However, becoming an API-centric organization presents challenges as well.

Malladi noted that while a new business could start from scratch, an established company, such as StubHub needed to balance the re-architecture with meeting other commitments to the business and customers.

A second challenge according to Malladi is that consumption patterns are not fully “baked” at the time of building an API; you won’t know fully who is going to consume them and what their patterns will be. Similarly, chargeback models and SLAs will not be clearly baked at first.

That is why it is important to build the API in such a way that it is flexible and can adapt to changes, he said. Moreover, exposing APIs to a lot of partners is not free, so architects and developers need to incorporate capacity planning and accountability into their models, he added.

At the same time, fraudsters are looking to make money off of Internet business sites. For this reason, companies need to be able to detect and prevent them from leveraging the API, and impersonating and collecting confidential data, Malladi advised.

The Role of WSO2 API Manager

For its own API architecture, StubHub is using the Store and Publisher in WSO2 API Manager, API Gateway based on WSO2 Enterprise Service Bus, and WSO2 Identity Server, Malladi said. The Publisher is where internal team members publish their APIs and manage the lifecycle of the APIs, he explained.

The Store is where an API is exposed both to the external and internal consumers, so they can create their applications. Malladi noted that the Store works the same way both internally and externally on both the website and mobile apps. He also invited attendees to visit StubHub’s implementation of the Store, the Developer Portal, at https://developer.StubHub.com.

WSO2 Identity Server manages user authentication, key management, JSON Web Token (JWT) assertion, Malladi said. Meanwhile, the WSO2 ESB-based API Gateway routes all incoming requests and works with WSO2 Identity Server to authenticate them.

Malladi noted that the combination of WSO2 API Manager and WSO2 ESB has enabled StubHub to address the need to manage APIs across Web and mobile domains. This is an important feature, since mobile is where StubHub sees the biggest growth, he explained.

Big Data Insights into APIs

To support StubHub and its expanded business model, the company is creating a big data platform to answer key questions, Malladi said. For example: How does the API manage social data and business analytics? How do StubHub APIs use these data sources, process the data, and bring it back in real time?

“It’s not just about creating an API but how it works on the backend,” Malladi observed. ““It’s so important to understand who your customer is and what they are doing.”

As Malladi then closed his session, he noted that building an API-centric architecture is a key driver for business growth, but as with any initiative there are challenges as well.

“The good news is you aren’t alone,” Malladi said. “And there are solutions.”

For more information about StubHub’s process for creating APIs, you can view Malladi’s WSO2Con US 2013 keynote address.

 

New WSO2 API Manager Introduces 2 Industry Firsts

I’m excited to announce the newest release of the WSO2 API Manager as it introduces two industry firsts. Featuring full native multi-tenancy, The WSO2 API Manager is:

  • The first API management product that can run on servers, in a private cloud, public cloud or hybrid cloud environment—all from the same software.
  • The first API management product that enables federated access to APIs across multiple entities, enabling new models for organizations to collaborate and monetize APIs.

The 100% open source WSO2 API Manager offers an API Store, for IT organizations to set up their own Apple or Google Marketplace-like store where developers can easily subscribe to and consume APIs. And also provides API publishers with complete API lifecycle governance—from creating to publishing, deprecating and retiring APIs—as well as analytics and metrics to support decision-making and enforce service-level agreement (SLA) policies. Do download the latest version and let us know what you think.

You can also join Chris Haddad from WSO2 and guest presenter, API Evangelist Kin Lane, in a webinar next week as they talk about API branding strategies. They will discuss

  • Why you should create an API brand
  • What actions and presence influences API brand success
  • How to efficiently promote APIs through multiple branded API portals

I’m sure you would not want to miss out on this one!

– Sumedha Rubasinghe is a Senior Architect at WSO2 and leads the WSO2 API Manager team. He blogs at http://sumedha.blogspot.com

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.

Facades 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 of 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.

nike-harajuku-store-opening-1

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
  5. 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 a 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