Tag Archives: WSO2 API Manager

Accessibility Requirements in WSO2 API Management

Accessibility standards in the world of web and internet are quite important as it allows people to access web resources without any difficulty, irrespective of their disabilities. There are many standards put forward to help developers implement accessibility into web-based resources. Some of these are:

  • Section 508 of the Rehabilitation Act of 1973
  • W3C Web Content Accessibility Guidelines (WCAG) 2.0 level A
  • W3C Web Content Accessibility Guidelines (WCAG) 1.0
  • W3C Authoring Tools Accessibility Guidelines (ATAG 1.0)

As a middleware vendor we’ve often been asked by Government customers and Federal Agencies in the United States, Europe and other parts of the world, if we are compliant with Section 508, WCAG 1.0/2.0, and ATAG 1.0 to enable a wider audience to use our software. These standards describe the desired accessibility required from information technology based services and products to make them accessible to differently-abled people.

A small explanation for those who can’t relate directly; sometimes you may ask if our software doesn’t touch end users, then why bother? Our software is predominantly catered towards developers and architects and they are the people who engage with our software on a technical level. So for instance, if you’re catering to a colorblind developer, having software complying to Section 508 ensures their disability is addressed.

What Do These Standards Say?

Section 508 states that it “requires Federal Agencies to make their ‘electronic and information technology’ accessible to people with disabilities”. However, this not only applies to Federal Agencies, but also impacts any company that conducts business with a Federal Agency like private contractors, and financial, healthcare, and legal organizations among others.

Section 508 was made part of the Rehabilitation Act of 1973 in 1998. It was revised in 2017 to include requirements for information and communication technology (ICT) in the federal sector. The guidelines were also updated to extend to the telecommunications sector, hence Section 508 was reorganized (along with Section 255) to better align with and reflect recent communication technology innovations.

Similarly, WCAG 1.0/ 2.0 documentation defines how to make ‘web content’ more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Web “content” generally refers to the information on a web page or web application, including:

  • Natural information such as text, images, and sounds
  • Code or markup that defines structure and presentation

It is primarily intended for web content developers (page authors, site designers, etc.), web authoring tool developers, web accessibility evaluation tool developers and others who want or need a standard for web accessibility, including for mobile accessibility.

The WCAG 1.0 is organized around guidelines that have checkpoints while 2.0 is organized around four design principles of web accessibility. The basis of determining conformance of the former are the checkpoints and the latter are the success criteria.

Overall, these different accessibility standards apply in different circumstances but are designed to complement each other. Often, these standards improve over time which is why you come across different versions.

In the open source community, we are as open to individual differences as we are to heterogeneous technologies. WSO2 API Manager, being one of the key products of the WSO2 Integration Agile Platform, has widespread deployments and has also been adopted by Governments and federal organizations. Hence, we designed WSO2 API Manager to be compliant with Section 508 so that it is accessible to all sorts of intended users regardless of their differences. The following section presents how each of the guidelines has been achieved in the product.

Section 508 Compliance in WSO2 API Manager

I have presented the basic guidelines from Section 508 and indicated how WSO2 API Manager has been designed to achieve this particular requirement. In this guideline, only the applicable parts have been discussed.

Addressing the requirements of Subpart B:

Section 508 Technical Standard WSO2 API Manager Achievement (with a few examples)
Software applications and operating systems
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. WSO2 API Manager can be started up and executed using the command line (Windows)/ terminal (Mac), where the keyboard is the primary tool used to operate the application. Once started up, the API manager functions can be performed using the keyboard. For instance, the API design and implementation can be executed using the keyboard where you use the tab to move to each field where you want to specify API metadata. This is demonstrated in the sample API provided at the first-time launch of the product.
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. WSO2 API Manager is a web-based application. It does not interfere, disable or disrupt the operation of other applications or operating system on which it is running and vice versa.
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

Yes, on the startup screen, a walk-through to create an API is presented for first-time users. This shows the current focus and guides the user to the next item after completion of each step.

For experienced users, the tab key can be used to identify the current focus and navigate through the interfaces. When a text field is focused, it shows the cursor in the particular textbox and the textbox is outlined in blue. For dropdowns, the list of options is expanded and shown to the user.

(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. Yes, this is made available where necessary.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance. Yes, the images used for APIs and their meanings are often consistent. The first letter of the API name is reflected in the image if it is not uploaded separately.
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. Yes, textual information is provided through operating system functions. As a minimum, we provide:

  • Short text labels
  • Sample text that reflects the type of input required
  • Text input location identified using the cursor
  • Simple and consistent text attributes for titles, labels, validations, and descriptions across all WSO2 API Manager components
(g) Applications shall not override user selected contrast and color selections and other individual display attributes. WSO2 API Manager shows the default screens, however only affected by the contrast and color selections of the user’s screen/ monitor’s configuration.
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. Not applicable as animations are not part of WSO2 API Manager.
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Information is conveyed in different means, such as text, color, images and other items. For instance, the action to start creating an API (on the Publisher) is indicated as a rectangular button with text that says ‘Start Creating’.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided. Not applicable as adjusting color and contrast settings are not part of WSO2 API Manager.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. Not applicable as flashing and blinking text, objects or other elements are not used in WSO2 API Manager.
(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. Screen magnification is available as the interface can be zoomed in and out as preferred. Assistive technology is not built into the WSO2 API Manager however, it can work with such tools available with the OS/browser to enhance such capabilities.

The above table is based on WSO2 API Manager v2.6.0. If you do have any feedback, please email us at bizdev@wso2.com

AI-Powered Cyber-Attack Protection for APIs with WSO2 and PingIntelligence

The exponential increase in API adoption has made it a prime target for hackers who are hijacking tokens, cookies and keys, as well as targeting weaknesses in individual APIs. Because of the complexity of these attacks and the different access patterns and users of an API, static security controls alone cannot prevent a breach. That’s why we partnered with Ping Identity to protect APIs against cyber-attacks by combining the artificial intelligence (AI) powered API cybersecurity of PingIntelligence for APIs with the robust policy-based controls in the open source WSO2 API Manager.

WSO2 API Manager is a unique open source approach to addressing the full API lifecycle. It offers various static policy-based options for security and access control. These include:

  • OAuth 2.0 authentication and authorization for API access
  • Request and response validation against the most common request based attacks such as SQL injection, parsing attacks, and schema poisoning
  • API policy creation and enforcement based on specific parser properties and regular expressions
  • Support for many types of rate limiting capabilities including rate limits by request counts and network bandwidth usage
  • The ability to assign quotas to users, applications, IP addresses, devices, and regions among other things

PingIntelligence for APIs is the leading solution for AI-powered API cybersecurity. They help enterprises augment their static controls and extend their security capabilities with continuous, proactive API threat monitoring and detecting that automatically discovers anomalous API traffic behavior. Because bad actors are well versed in circumventing static security policies, PingIntelligence for APIs was purpose-built to recognize and respond to attacks which fly under the radar of foundational API security measures, and target API vulnerabilities—without policies, rules or code. These include:

  • Credential stuffing and brute-force attacks on login systems
  • Layer 7 DDoS attacks that scrape data and disrupt API services
  • Taking over accounts using stolen cookies, tokens or API keys
  • Rogue insiders exfiltrating data in small amounts over extended periods of time

WSO2 has developed an open source extension to communicate with the PingIntelligence API Security Enforcer (ASE), which can be deployed in the WSO2 API Gateway. This means that WSO2 API Manager users can apply AI-based security analysis for their APIs along with static policy-based security controls. Meanwhile, PingIntelligence users can utilize AI-based analytics when they externally expose their services as APIs.

To learn more about how the extension works and what attacks it can detect, read WSO2 Associate Director and Architect Sanjeewa Malalgoda’s article or register for our webinar. Download the extension for WSO2 API Manager here.

WSO2 API Manager Multi-Data Center Deployment Architecture

This has been a hot topic at WSO2 as many of our users and customers often ask how they can deploy WSO2 API Manager in a multi-datacenter setup. This blog post is an effort to elaborate the technical details and internals of the multi data center (m-dc) deployment architecture.

Caching, clustering, deployment synchronization, worker-manager separation, API subscription/metadata sharing and traffic routing are some of the important areas engineers and devops have to focus on at the deployment stage. Each of these aspects will be explained in detail to provide more clarity.

Caching  and clustering

The WSO2 platform uses Hazelcast as the clustering framework/engine, which is also a JSR-107 (JCache) provider. The platform has support for L1 and L2 cache, and the L2 cache is implemented as a distributed cache that adds and removes values from a Hazelcast distributed map. More information about WSO2 caching implementation can be found here: http://blog.afkham.org/2013/11/wso2-multi-tenant-cache-jsr-107-jcache.html

When it comes to a multi-dc deployment, WSO2’s recomendation is to set up the cluster local to a data center. This is done mainly to avoid environmental stability issues (such as the cache not getting synced instantaneously) due to network latencies across geographic locations.

Worker-manager separation

This is the traditional setup where we will carry out the worker-manager deployment per data center. Each data center will have its own manager node managing the local cluster.

Deployment synchronization

Deployment synchronization in a multi-dc deployment is two-fold: the local synchronization between nodes and across data center artifact synchronization.

In this step, among the data centers, a master needs to be selected. Even though there are multiple manager nodes within each data center, only one manager is configured to check-in artifacts (<AutoCommit>true</AutoCommit>) other managers will not commit anything. The data center with the privileged manager node will be the master data center.

We also have to setup SVN repositories at each data center and only the master will have a read/write repository whereas others will be read-only. There needs to be some mechanism (there are plenty of tools for this task) to synchronize these SVN repositories in a unidirectional manner.

Once new APIs are added from the master data center’s manager, it will take some time to synchronize across data centers because there won’t be a cluster message broadcasted across DCs to get an update; therefore, the nodes in slave data centers will eventually be consistent (artifacts will be polled periodically from the SVN). This can be expedited if required by reducing the polling interval and the SVN sync delay.

API publishing

API publishing will only happen from the master data center, hence publisher application will only be deployed at the master.

API subscription and metadata sharing

When an API is published there are associated metadata like tags, throttling information, scope information, comments, and ratings. An API also has subscriptions coming in from both data centers; this means OAuth tokens, keys, and secrets. All this information is stored in the WSO2 registry database schema and API manager database schema. These schemas need to be replicated across the data centers. Traditionally, tools like Oracle Goldengate are used for this task and if it’s in EC2, the RDS replication can be used.

API traffic routing

Since the data centers will be eventually consistent, enabling session affinity (sticky sessions*) at the load balancer is the best option to avoid intermittent resource errors that are not found. This will also avoid any throttling inconsistencies that can occur in a multi-dc setup.

Complete deployment architecture

* Also Refer http://nginx.org/en/docs/http/load_balancing.html#nginx_load_balancing_with_ip_hash

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

 

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

Forrester Places WSO2 in Top 2 for API Management

A few weeks ago, Forrester Research released The Forrester Wave: API Management Platforms, Q1 2013 report. The report’s findings were based on a 15-criteria evaluation of commercial and open source vendors that deliver products for the emerging API management platforms market, including API consumer experience, integration capabilities with various back-end and third-party systems, analytics and monitoring features.

We were thrilled that Forrester cited us as a leader in this report.  We believe that it validates our commitment to democratizing API management by making it affordable to acquire the software, easy to control APIs and manage the API lifecycle, and simple to find and subscribe to APIs. We have expanded on that commitment with significant enhancements in WSO2 API Manager 1.3 and in our continued evolution in enhancing the customer experience. (version 1.4 coming soon too!)

The WSO2 API Manager enables you to securely and confidently extend data, processes, and services out to customers, partners, and business units.  The enterprise-ready product transforms your cloud service or web service delivery by offering on-demand self-service API subscription, API lifecycle governance, key management, access provisioning, and API usage monitoring.
You can download the full report by visiting http://wso2.com/resources/analyst-reports/forrester-api-management-wave-2013/

Sumedha Rubasinghe,
Software architect and Data Technologies MC Chairperson
http://sumedha.blogspot.com