Tag Archives: API Management

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

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

Re-invigorate Your SOA Initiative with Internal API Service Adoption

You’ve heard the benefits of managed APIs when enterprises extend their data, processes and services out to customers and partners via APIs. Consumer self-service, automated key management, and monetization opportunities are just a few of them.

But have your considered API management as a strategic component within your SOA initiatives?

Ten years after the rise of SOA, many enterprises have identified and published services as shared assets, however teams and partners often continue to invest considerable time and resources when building new solutions.  Many teams experience rapid portfolio proliferation and sprawl, but not enhanced portfolio efficiency or business agility.  Achieving business agility requires the growth of development partnerships and interactions, which should span both internal and external teams.

The WSO2 API Manager enables your internal development teams to extend data, processes and services across projects, departments, or divisions. Using WSO2 API Manager, your teams will be able to:

  • Establish their own API marketplace and promote APIs
  • Manage the API across lifecycle phases and enforce API Governance best practices
  • Use the API Store and OAuth 2.0 key model to self-subscribe applications, authorize subscribed applications, and provide a self-service key management and revocation environment.
  • Deploy a composable and componentized platform architecture enabling extreme scalability, flexible deployment configuration, and feature expansion.

To learn more about  internal API services adoption download the recently published white paper –  “Promoting service reuse within your enterprise and maximizing SOA success”

If you still need help to get going, consider our special APIStart package.

– Chris Haddad, WSO2 Technology Evangelist

API Management: The Missing Link for SOA Success

[This post first appeared on my blog at http://sanjiva.weerawarana.org/2012/08/api-management-missing-link-for-soa.html.]

Nearly 2 years ago I tweeted:

Well, unfortunately, I had it a bit wrong.

APIs and service do have a very direct and 1-1 relationship: an API is the interface of a service. However, what is different is that one’s about the implementation and is focused on the provider, and the other is about using the functionality and is focused on the consumer. The service of course is what matters to the provider and API is what matters to the consumer.

So its clearly more than just a new name.

Services: If you build it will they come?

One of the most common anti-patterns of SOA is the one service – one client pattern. That’s when the developer who wrote the service also wrote its only client. In that case there’s no sharing, no common data, no common authentication and no reuse of any kind. The number one reason for SOA (improving productivity by reusing functionality as services) is gone. Its simply client-server at the cost of having to use interoperable formats like XML, JSON, XML Schema, WSDL and SOAP.

There are two primary reasons for this pattern being so prevalent: first is due to a management failure whereby everyone is required to create services for whatever they do because that’s the new “blessed way”. There’s no architectural vision driving proper factoring. Instead its each person or at least each team for themselves. The resulting services are only really usable for that one scenario – so no wonder no one else uses them!

Writing services that can service many users requires careful design and thinking and willingness to invest in the common good. That’s against human intuition and something that will happen only if its properly guided and incentivized. The cost of writing common services must be paid by someone and will not happen by itself.

That’s in effect the second reason why this anti-pattern exists: the infrastructure in place for SOA does not support or encourage reuse. Even if you had a service that is reusable how do you find out how well it works? How do you know how many people are using it? Do you know what time of day they use it most? Do you know which operations of your service get hit the hardest? Next, how do others even find out you wrote a service and it may do what they need?

SOA Governance (for which WSO2 has an excellent product: WSO2 Governance Registry) is not focused on encouraging service reuse but rather on governing the creation and management of services. The SOA world has lacked a solution for making it easy to help people discover available services and to manage and monitor their consumption.

API Management

What’s an API? Its the interface to a service. Simple. In other words, if you don’t have any services, you have no APIs to expose and manage.

API Management is about managing the entire lifecycle of APIs. This involves someone who publishes the interface of a service into a store of some kind. Next it involves developers who browse the store to find APIs they care about and get access to them (typically by acquiring an access token of some sort) and then the developers using those keys to program accesses to the service via its interface.

Why is this important? In my opinion, API Management is to SOA what Amazon EC2 is to Virtualization. Of course virtualization has been around for a long time, but EC2 changed the game by making it trivially simple for someone to get a VM. It brought self service, serendipitous consumption, and elasticity to virtualization. Similarly, API Management brings self service & serendipitous consumption by allowing developers to discover, try and use services without requiring any type of “management approval”. It allows consumers to not have to worry about scaling – they just indicate the desired SLA (typically in the form of a subscription plan) and its up to the provider to make it work right.

API Management & SOA are married at the hip

If you have an SOA strategy in your organization but don’t have an API Management plan then you are doomed to failure. Notice that I didn’t even talk about externally exposing APIs- even internal service consumption should be managed through an API Management system so that everyone has clear visibility into who’s using what service and how much is used when. Its patently obvious why external exposition of services requires API Management.

Chris Haddad, WSO2’s VP of Technology Evangelism, recently wrote a superb whitepaper that discusses and explain the connection between SOA and API Management. Check out Promoting service reuse within your enterprise and maximizing SOA success and I can guarantee you will leave enlightened.

In May this year, a blog on highscalability.com talked about how “Startups Are Creating A New System Of The World For IT”. In that the author talked about open source as the foundation of this new system and SOA as the load bearing walls of the new IT landscape. I will take it to the next level and say that API Management is the roof of the new IT house.

WSO2 API Manager

We recently introduced an API Management product: WSO2 API Manager. This product comes with an application for API Providers to create and manage APIs, a store application for API Developers to discover and consume APIs and a gateway to route API traffic through. Of course all parts of the product can be scaled horizontally to deal with massive loads. The WSO2 API Manager can be deployed either for internal consumption, external consumption or both. As with any other WSO2 product, this too is 100% open source. After you read Chris’ whitepaper download this product and sit it next to your SOA infrastructure (whether its from us or not) and see what happens!

Sanjiva Weerawarana, WSO2 co-founder and CEO
Sanjiva’s blog: http://sanjiva.weerawarana.org

WSO2 API Manager Beta Program Launched

Chris Haddad, Vice President of Technical Evangelism for WSO2, has introduced the new WSO2 API Management beta program in his blog.  At the end of the post he reveals that…

WSO2 has begun recruiting beta customers for the new WSO2 API Manager product scheduled to launch this summer.  Ideal candidates for the WSO2 API Manager beta program are enterprise IT professionals who are planning or evaluating infrastructure to offer APIs to third parties—whether externally or within the organization. WSO2 requests participant commitment to provide use cases and feedback. For more information please visit the product Web site at http://wso2.com/products/apimanager and contact us at mailto:bizdev@wso2.com to join the beta program.

WSO2 API Manager will enable enterprises to extend their data, processes and services out to customers, partners and other business units via APIs while providing the ability to secure, protect and monitor API resource interactions. WSO2 API Manager also will enable developers to rapidly find, subscribe to, and evaluate the APIs that enterprises make available.  Using WSO2 API Manager, enterprises will be able to:

  • Offer APIs to their customers and partners, as well as other internal users.
  • Display and promote APIs in an API store
  • Enable developers to sign up and subscribe to APIs.
  • Collect usage, performance, and quality of service metrics to analyze and understand how APIs are being used.
  • Use a policy-based approach to securing APIs, managing access, and throttling usage.

Re-invent your software delivery and re-invigorate your SOA initiative by adding WSO2 API Manager and encouraging API adoption.

Read the full post, explaining the importance of API management to SOA adoption, “WSO2 API Management Platform Re-invents Software Delivery” at http://blog.cobia.net/cobiacomm/2012/03/22/wso2-api-management-platform-re-invents-software-delivery/.

The related news release is at http://wso2.com/about/news/wso2-begins-recruiting-beta-customers-for-new-wso2-api-manager-product.

Jonathan Marsh, VP Business Development and Product Design
Jonathan’s blog: http://jonathanmarsh.net/blog

WSO2 Platform for API Management

One of the niceties of mainframes was the simplicity of a single API for the users.  After years of evolution towards a decentralized model we still find this pattern appearing, even among SOA implementations that span many subsystems and service platforms.

I discussed the need for unified APIs in my previous blog posts [1],[2], and explained how you can build using the WSO2 middleware platform.

Presenting entire subsystems, which may include legacy systems, databases, and internal and external services as a single unified API makes integration easier for a partner (further decoupling detailed knowledge of the subsystems), and is increasingly used for internal users such as business processes, business rules and mashups. A unified API hides a variety of transports and systems behind a single, consistent, API.

With the introduction of unified API, API management and monitoring becomes an important factor.  Different formats and protocols like SOAP/HTTP, JSON, XML/HTTP, JMS can be exposed across the range of services. A centralized configuration change at the ESB layer enables different protocols or enables QoS features across the API.  Features such as usability, the security, governance can be managed in a single location, as can enterprise features like scalability and high-availability. Monitoring provides a single point for assessing the usage and health of the system.

As I described in my previous posts, the WSO2 Enterprise Service Bus (ESB) provides the a simple yet powerful and highly performant system upon which to implement a unified API and select the various QoS characteristics. WSO2 ESB supports all the popular security standards required for integration and leverages WSO2 Carbon clustering features for scalability and high-availability out of the box.

The WSO2 Governance Registry builds the required governance framework for the unified API by providing a repository for policies and API metadata – even for API documentation – and adds the ability to share, version, analyze dependencies and policy conformance, and manage lifecycles of this metadata.  The WSO2 Governance Registry helps you define the and manage the QoS of your API, and works in conjunction with the ESB to assess and enforce the defined policies.

Monitoring – a key part of runtime governance – is accomplished by deploying the WSO2 Business Activity Monitor (BAM) to collect, summarize, and report on the API usage.  Or you can use the JMX support in the WSO2 ESB and other WSO2 Carbon products to tie into third-party monitoring tools.

Certain services need to go beyond simple monitoring. When we looked at the business requirements of our API management customers, billing and metering, isolated runtimes for specific consumers/consumer groups, as well as customization or overriding of the API for specific consumers emerged. We have found multi-tenancy to be a powerful answer for those requirements, and is available in the WSO2 cloud platform, WSO2 Stratos. With WSO2 Stratos you can easily expose your API in the cloud or as part of the SaaS offerings you provide.

In summary, both essential and extended features for API implementation and management are provided by WSO2 middleware platform, making it a great choice for meeting both your business and technical requirements.

Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/