Tag Archives: API Management

Cashing in on APIs – Leveraging Technology to Boost Your Business

Even if you’re not an excessively tech-savvy individual, you most likely would have used a mobile application in your mobile device via an internet connection, used a Gmail client, Twitter, Facebook, or mobile apps, or purchased something online. In a tech world, you’re already reaping the benefits of application programming interfaces (APIs). The use of APIs is becoming even more popular today as service providers are scrambling to embrace the Internet of Things. With the availability of new tracking devices, smart homes, smart vehicles, mobile phones and tablets, consumers now have more options on how they consume applications.

Let’s take a step back and try to understand what this all means. An API is a term that’s used to denote a well-defined interface to access certain resources – in other words a service available to an end-user. If you haven’t worked with web APIs before, you may think it’s a type of service exposed over the Internet to perform certain operations. APIs are the foundation of today’s software engineering industry and enterprises are jumping on the bandwagon to reap the benefits of using them to integrate and automate to make their online services more appealing and user-friendly to end-users. Well-designed APIs will enable your business to expose content or services to internal and external audiences in a versatile manner. Today, most organizations use APIs to build their solutions internally and expose these services to the world at large. APIs will immensely benefit both service development teams as well as service consumers.

A good, yet simple example that illustrates this well is a weather update application that’s available on your mobile device. This application that typically runs on a device will not be able to provide weather forecasts of a specific area without connecting to an external service. However, it can call a GPS device on your mobile device or request the user to retrieve location coordinates of a specific area for which you want a forecast. Once you’ve defined your geographical location, the mobile application can simply call a weather service API and request the required information. What’s important to note here is that you don’t need to perform any complicated tasks, do calculations, or run an analysis on the mobile device. You can simply push relevant parameters to an API and obtain the results you want.

If you view this same example from one level up, you’d see that there’s a client application and a service and both of these are connected by an API. That’s essentially what an API does; it can integrate your services, data, content, and processes with external parties in a very effective and efficient manner. So, what’s the difference between services and APIs? Essentially, the functions of both are the same, but a slight differentiator would be that an API would generally have a well-defined interface to its services. That said, there’s a notable difference between managed and normal web APIs/services. Managed APIs are often enriched with additional features on top of a standard API or service. These are referred to quality of services or QoS. Common QoSs include security, access control, throttling, and usage monitoring. Security forms the foundation any API infrastructure across the entire digital value chain. Malicious users can access your systems the same as legitimate users would, therefore it’s important to enable security at all points of engagement. Usage monitoring helps enterprises to improve their APIs, attract the right app developers, troubleshoot problems and, ultimately, translate these to better business decision.

Boosting efficiency to become more competitive

Enterprises too are seeing the potential benefits of APIs to propel business growth, irrespective of the size and nature of the business and the industry they operate in. The key is to get started now to be able to maintain a competitive edge. A typical example is the extensive use of APIs in the hospitality industry; for instance, the owner of a restaurant or a small hotel would operate a simple website and some internal services. But at some point, when the business grows, they cannot maintain the same internal system and work with external parties. At this stage, business owners would need to think about consuming external services and exposing their services to the external world. And that’s when APIs and API management solutions come into play.

Large, global companies in the financial, transportation, logistics, and consumer sectors have already started to expose their systems and services to the outside world as APIs. The real benefit lies with being able to seamlessly integrate internal systems with those external ones to leverage benefits like creating properly structured services that are synced within the company, e.g. human resources department exposing non-sensitive employee data to other departments that need this information. A typical example is an online retail business that would need a payment solution to integrate with its system. Such a solution would not need to be implemented from scratch, rather the business can expose APIs via already available payment solution providers like Stripe, Zuora, or PayPal.

To explain this further, let’s consider a restaurant owner who can expose menus and ordering services via APIs. This will enable external developers to consume these APIs with their apps and incorporate the restaurant’s menus and services into the travel applications they’re building. When exposing APIs, the restaurant owner would need to consider throttling, a process responsible for regulating the rate at which the application is processing, as well as the security aspect of exposing these APIs. On top of these, a service provider may need some insights into the usage of these APIs – for instance, details about service consumers (like which apps have been invoked more), usage patterns (most popular food types), traffic patterns (peak order times), etc in order to make certain business decisions and make the service more efficient. For this, you might need sort of analytics and usage monitoring capabilities as part of your overall API management solution.

How Internal Services Can Expose Services to External World Via APIs

how internal services can expose services via APIs

Ultimately what you achieve in terms of business benefits is brand awareness by becoming a smart business. Moreover, in addition to profits gained from direct API consumption, users can earn additional revenue by charging users for API/service usage. This concept is known as API monetization and most API management solutions already have this feature in-built as an extension, enabling creative users to turn cool ideas into revenue generating APIs within minutes. And open source products have proved to be most useful to meet all your API management requirements as its cost effective and easy to deploy.

WSO2 and MedVision360: Delivering Healthcare across Europe

Jan-Marc Verlinden is the founder and CEO of MedVision360. MedRecord, their flagship project, is an eHR (electronic Health Record) system: everything from patient data to digital health apps, devices, wearables, companies and hospital systems are wrapped together, providing a single platform on which healthcare providers can build medical applications and expose data and services via APIs. Currently, the MedVision platform is used in over 8 large EU projects, including hospitals from Hannover to Rome to Southampton.

At WSO2Con EU 2015, Jan-Marc took the stage to explain how MedVision360 achieved all this: using WSO2 products at the heart of their platform, with expertise from our partner, Yenlo.

Inside the medicine cabinet

MedRecord was born of a desire to do better. Europe, says Jan-Marc, is aging; by 2020, there will be 3 working people to every old person. In China, this problem is bound to be even more serious. This is a huge challenge for healthcare.

Given the severity of this situation, one would imagine this problem would have been tackled ages ago. Not so.

According to Jan-Marc, there are a few major problems in the way of change coming in with effective use of ICT; cost, concerns – or technical ignorance- about privacy and data security, a lack of communication between ICT systems, and the human capital it costs for data entry.

There’s also the lack of financial incentives to do better. There’s no real incentive for doctors to change the way they work and to reduce those long queues to something as simple as a mobile app, especially given the costs faced.

MedVision360 built two stacks: the first, which they subsequently open sourced, uses XML for storing data – and a second, enterprise version, with better performance using PostgreSQL. Both are based on the CEN/ISO EN 13606 standard, which requires the platform to use a dual-model architecture that maintains a clear separation between information and knowledge.

To convey the depth of modelling involved in this, Jan-Marc used the example of blood pressure, one of the many measurements involved in the process of treating a patient.

image01
This is the type of semantic model template developed by the NHS (the National Health Services, UK).  The idea is that this delivers both the data needed and the context that a medical specialist would need to frame the data in. As the system consumes these archetypes, it becomes instantly proficient.

image00
However, due to different workflows and standards, a doctor in a country other than the UK might require a different version of things, as seen above; not just a 1-1 translation of terms, either.

Working with Yenlo, MedVision360 utilized the open source WSO2 API Manager, WSO2 App Manager, and WSO2 Identity Server to solve this issue. WSO2 API Manager is a complete solution for designing and managing the API lifecycle after publishing. MedRecord’s architecture uses API manager to expose the data in the MedRecord platform from the PaaS layer, while managing access rights. WSO2 Identity Server enables login through third party identity providers (like Google and Netherland’s UZI-pass), handling role based access control and providing an audit trail.

image003
Everything else – applications, websites – is hosted on this layer. Swagger and JSON make it easier to build validated apps. Paired with a drag-and-drop HTML5 tooling interface, developers can easily build applications by accessing functionality from APIs with a few clicks. Hooks to portals like Drupal and Liferay allow better, device-independent presentation of content.

This opens up possibilities even for integration with Google Fit or Apple Health Kit. Google Fit, for example, collects data on the patient walking and so on; while that’s not relevant for a doctor, who’s more concerned with the patient not walking, parsing and analyzing the data would allow medical professionals to keep an eye on their customers’ health.

Healthcare is a very serious business, and at WSO2, we’re glad that providers like MedVision360 – and their clients- have chosen to trust our platform with the lives of others. To examine the full video of Jan-Marc Verlinden’s talk, click here.

At WSO2, we’re committed to making our platform better. To check out the components that MedVision used so successfully, visit the WSO2 API Manager, Identity Server and App Manager pages.

Zeomega: Building on WSO2 for a Comprehensive Healthcare Solution

The typical health management platform is a complex mechanism. This is, after all, an industry with zero tolerance for faults: even the slightest mistake could mean a life in danger.

Building healthcare solutions is what Zeomega specializes in. The Texas-based firm delivers integrated informatics and business process management solutions. Zeomega’s clients collectively service more than 30 million individuals across the United States.

image00

WSO2 is a part of their success: key to Zeomega is Jiva, Zeomega’s population health management platform. Delivering analytics, workflow, content and patient engagement capabilities, Jiva uses key WSO2 products and provides a deployable PHM infrastructure that both healthcare providers and clients can use. A strong track record of integration and acquisitions keep both Zeomega and Jiva on top of what they do.

Attending WSO2Con Asia 2016 to explain all of this were Praveen Doddamani and Harshavardhan Gadham Mohanraj, Technical Leads at Zeomega. Their speech, titled Building on WSO2 for a Comprehensive Healthcare Solution, detailed how Jiva works and why. Let’s dig in.

The State of the Art

Jiva has the capability to integrate with various data repositories and management systems. During the initial days of integration, they built an ETL tool and a framework – using Python – to integrate data into Jiva, generally in the form of a CSV. It could also export data.

As their customer base expanded, this integration challenge became even more integral; their requirements changed to needing to load millions of records. To pull this off, Zeomega used the pyramid framework to build a RESTful web service that would do the job. They ended up building a SOAP system as well to better interface with their clients, and using these three tools, they could address batch integrations effectively.

When it comes to a deployment, however, with multiple servers, having these multiple systems turned out to be a burden, especially when clients needed a single API to be able to manipulate data; multiple systems with different tech stacks became roadblocks to both support and development.

The Fix

“We don’t want to rewrite our existing logic; we want to leverage the existing business logic and provide a healthcare solution to external applications and well as third-party vendors,” said Harshavardhan Mohanraj, who was co-presenting with Doddamani.

At this point, they started evaluating WSO2 for a solution to this problem. WSO2 Enterprise Service Bus and WSO2 API Manager are built for this purpose. The WSO2 ESB would allow them to retain their legacy business platform and still connect whatever they needed to. WSO2 API Manager would handle the complete API management lifecycle, allowing them to push out secure APIs for their real-time web services.

To do this, said Mohanraj, they created a Jiva API framework. The core Jiva platform is exposed through RabbitMQ. Data is sent and received to this core platform through a module with the WSO2 ESB; this handles the integration, data transformation, turning flat files (CSV/XML)  or anything else into the JSON actually processed by Jiva.

image01This functionality is exposed via WSO2 API Manager, which enables Zeomega to publish, deploy and manage the necessary SOAP and REST APIs.

In the future, said Mohanraj, they intend to shift Jiva from a monolithic structure to a less tightly coupled SOA model, with reusable components and better standards support. And to do this, they intend to use WSO2 – not just WSO2 ESB and WSO2 API Manager, but also WSO2 Identity Server and WSO2 Governance Registry.

“WSO2 products provide us with high performance, high availability, and better configurability,” said Mohanraj. “We want SOA governance, DevOps and flexibility. As a whole, we’re able to achieve a robust solution by integrating WSO2 products. We’re now moving away from spending more of our efforts on business infrastructure and we’re able to speed up agility by creating healthcare solutions.”

To learn more about Jiva and the WSO2 collaboration, watch the Zeomega talk at WSO2Con Asia 2016 here.

 

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