Tag Archives: API Management

Travis Perkins: Disrupting the Retail Industry with WSO2 Integration Technology

Travis Perkins, UK’s largest supplier of building materials, embarked on their digital transformation journey last year in the hopes of enhancing customer experiences, growing their business and improving the usability of their systems. At WSO2Con EU 2017, Christopher Stone, the head of integration at Travis Perkins, talked about the steps they took to go digital with the help of WSO2 technology and key partners.

To help understand Travis Perkins’ current situation, Christopher used an analogy coined by their previous CIO Neil Pearce – the house of IT.

By looking at all the areas of the house that need improvement, Travis Perkins realized that they needed to adopt integration technologies that would allow their systems to be flexible, future-proof, innovative, and reactive. “Integration is the plumbing, electrical wiring, and foundation — basically the rooms of the house,” said Christopher. “Effective integration and quality data are the key enablers for our digital agenda that is built on a solid foundation such as reliable cloud infrastructure and networking.”

Once Christopher explained this analogy, he explored how they previously worked on integration projects. He would most likely be a part of a program delivery team who is pressured to deliver fast and within a strict budget. This hinders their vision of the overall enterprise benefits and results in a point-to-point spaghetti architecture that leads to high maintenance costs, difficult to support, inconsistent standards, reliability issues, and limited reusability.

Today, Travis Perkins has a central integration layer powered by WSO2 integration and API management products. Services are developed according to project requirements, but built with the entire enterprise in mind using a set of policies, patterns, and standards governed by the project diagnostic team. This results in maximum reusability, easier support and maintenance, and continuous improvement in delivery, quality, and speed. The replacement of their core ERP system from a legacy system to an ERP vendor named M3, for sales order entry, sales order management, pricing, tool hire, finance, and supply chain is the largest program Christopher’s team is currently delivering on. But they have been involved in various other integration projects too. “The right tools combined with the correct mindset, architecture, and governance allows you to meet your goals in achieving good enterprise integration which benefits your company as a whole,” he says.

Many external parties helped Travis Perkins along their journey. In their early days, Wheeve, integration technology experts partnered with WSO2, gave them a theoretical and conceptual mindset on how an integration department should run. They helped set up the department and build up the team and aided them with their architecture and processes. During the delivery phase, Travis Perkins’ engineers and analysts were supplemented by ICT solutions providers partnered with WSO2 — Chakray and Mitra Innovation. They offered integration specialists well-versed in the WSO2 platform who helped analyze the requirements and worked in an Agile Scrum fashion to deliver the projects. “They have helped us come leaps and bounds, not only in delivering projects but also in terms of learning from their experience and knowledge of the WSO2 platform,” said Christopher.

“WSO2 is a great platform. It enables us to deliver quickly and compliments our strategy to utilize open source technology wherever possible,” Christopher concluded. “When any of our engineers come across difficulties in development, the WSO2 Subscription gives us great SLA’s. We don’t need to use production maintenance support very often, but when it does happen we have a very good relationship with WSO2 for them to support us in getting back to business as usual.”

To learn more about how Travis Perkins is successfully traversing its digital transformation path, watch Christopher’s video at WSO2Con EU 2017 below.

Bringing an Efficient Home Care Solution to Life with WSO2 Technology

Senior citizens and disabled people—many in fragile health and requiring assistance—often have limited resources for managing their health and ensuring their security. Effective home care solutions allow such people to safely go about their day-to-day lives and enhances their quality of life. To aide home caregivers and patients, Raffaello Leschiera, a solution architect at Engineering Ingegneria Informatica, proposed a reference architecture for efficient home care using WSO2 technology at WSO2Con EU 2017.

Raffaello began by exploring the proposed reference architecture that connected and interfaced with all stakeholders, like the patient, his/her family and medical staff. Firstly, they need to collect data from medical devices in the patient’s home. Protocols like IEEE VU specifications are used and medical devices are mediated using Arduino and Raspberry Pi boards. Once collected, the data needs to be normalized and stored so it’s represented in the same way no matter which device it was collected from.

This data needs to run through analytics to monitor the patient’s health, process events and if needed, send notifications through various communication channels. Data integration channels using the HL7 standard protocol for health care is used to send this data to medical staff. The medical staff can then access it through web and mobile interfaces and an API gateway decouples all features from these user interfaces. And finally, the entire system needs to be synchronized and controlled by identity and access management to ensure security and privacy.

Reference architecture for a home care solution

Raffaello noted that WSO2’s comprehensive technology platform, particularly its integration and analytics capabilities, were the main reasons for picking WSO2 as their technology partner. The open source nature of the products was also a key deciding factor since Raffaello and his team work with many public administrators who prefer to adopt solutions that are completely open source. “WSO2 has a wide technology platform so you can find the right answer to every part of your problem,” said Rafaello. “And because all the products seamlessly integrate with each other it’s easy to focus on the domain problem rather than the technology problem,” he added.

To describe how WSO2 products were used for different tasks, Raffaello compared the home care solution to a football game:

  • Goalkeeper: WSO2 Microservices Framework for Java (WSO2 MSF4J) serves as the goalkeeper. This is the entire back-end of the system, which is based on lightweight microservices that are developed, deployed and monitored through MSF4J in a highly scalable and reliable manner with integrated security.
  • Defenders: WSO2 Data Analytics Server serves as one defender that receives data, analyzes it in real-time, and sends notifications. WSO2 Enterprise Integrator is the next defender who transforms disparate types of data into a normalized format and sends it to the hospital IT systems.
  • Forwards: WSO2 API Manager is one of the forwards, which faces the medical staff and is used to design, prototype and publish APIs and govern API usage. WSO2 IoT Server is another forward, which faces the medical devices for data collection, device management and protocol support.
  • Wings of the pitch: Here the WSO2 Identity Server takes care of all the strict security and privacy requirements.
  • Center of the pitch: Finally, WSO2 Governance Registry serves as the ‘Lionel Messi’ at the center of the pitch; in other words it governs the solution through surveillance just like how Messi would guide and lead his team to victory.
  • For this solution to work, Engineering Ingegneria Informatica needed a remote device that can track a patient’s movements within his/her home. Enter Joe Care (or the Joker pictured above). Joe Care is a remote presence device that is flexible and agile enough to move around the patient’s home. They used various technologies like Arduino boards, software that deals with movement and the sense of space as well handling (touch). It served as the medical eyes, ears, voice and fingers within the patient’s home.

    In the future Rafaello and his team aim to engage with users more, further analyze threat paths and include more technology like wearables that monitor movement and exercise. They would also like to create more intelligent early warning score models and move their entire solution to the cloud so more patients and operators can access it.

    Watch Rafaello’s presentation at WSO2Con EU 2017 below to learn more about their home care solution powered by WSO2.

A Smarter Transport Management System for London with the Help of WSO2

Transport for London (TfL) has a daily challenge – to keep a city of over 8 million people moving around the metropolis. Its magnitude can neither guarantee the transport system will always absorb commuters nor give them a congestion-free experience. It is a place where the smallest of changes would have a massive impact on your journey. Citing an example, Roland Major, a former enterprise architect at TfL, says that a London Underground strike once saw a 3% increase in traffic and a staggering 90 minute increase in journey time. Estimates project a 60% increase in congestion around central London by 2031.

Given all these complications, TfL decided to become more intelligent with technology to reduce commuter times, make the roads safer for pedestrians, cyclists and drivers, and to slow the pace of traffic. Intelligence and data with a purpose are the buzzwords here. “We need better understanding of real-time demand. What insight can we get from our data, and how can we get innovative with all this information?” says Roland. He was actively involved with TfL’s Surface Intelligent Transport System (or SITS), a project that aims to better manage the city’s entire road space of pavements, cycle lanes, and motorways.

SITS’ business proposition is that it can offer billion pounds’ worth benefit to London by identifying delays in the road networks sooner than it is done at present: “We weren’t detecting incidents, and by the time we have detected them, they were already over. With technology, we can see these incidents early. We recognized that the market can do sensible things with our data,” says Roland. For example, within the traffic light system in London, TfL manages an estimated 7,000 junctions around the city and 14,000 magnetometers detect millions of daily events. This data is discarded after analysis; however, if used, TfL realized that the response time to delays improved by 15 minutes.

TfL has a 10 year plan in place, with all the of different required components mapped out. Data analytics form the core of this operational model. Data is obtained from GPS systems and bus routes. The road incidents are logged and used to determine what additional information is needed to understand and manage each leg of commuter journeys. All the data is hosted on the cloud and currently TfL is in the process of adding these components to the framework.

TfL’s transport management system

London’s new road management system relies on WSO2’s API management, integration, identity and access management, and analytics products for the intelligent work needed. These products are deployed on a private cloud managed by WSO2. The starting point – LondonWorks, a registry of all road works and street related events, both planned and current, in the Greater London area. LondonWorks is used to assess road networks, coordinate the various road works to minimize congestion and for inspection, compliance, and monitoring. Maps and forms of type data have been integrated to allow entry of incidents into the system and their identification on the map.

As their model progresses, TfL has ambitious plans for all the data they have streaming in – big data analytics to give them more insights to road movements, which will enable them to give the necessary alerts and empower them with smarter ways to deliver better, safer commuter experiences for London.

Watch Roland’s presentation for more details on TfL’s plans for London.

Explore the WSO2 middleware platform with its offerings in API management, integration, identity and access management, analytics, and IoT.

Did you know that WSO2 won TfL’s data analytics Hackathon contest? Learn all about it.

Building a Cloud Native Platform for CitySprint’s On the Dot Delivery Service

Picture a scenario where you are analyzing the results of a marketing survey which shows that a high percentage of consumers prefer same day shipping, online tracking of their orders, choice of shipping options, and deliveries within a specific time slot. Then you find out that retailers already fulfill around 65% of these needs, but there is a gap in the market, a gap that you can fill by offering a novel service. This is precisely what UK-based logistics and delivery service provider, CitySprint did when they developed the On the dot delivery service, which allows shoppers to receive their orders during a one hour time slot of their choice without extra costs.

“We wanted to positively disrupt the time slot delivery space. In doing so, we wanted to build an API ecosystem that sparks interaction, open new channels and reach new streams of revenue,” says Eduard Lazar, Senior Solutions Consultant at LastMileLink Technologies (a CitySprint Innovation Lab). At the heart of of this project was generating value for users and driving innovation, “On the dot is all about convenience for consumers, be it as a fulfillment method or in terms of collection and delivery time slots. We also wanted to simplify integration and create a developer community through our API ecosystem,” he adds.

Defining the key challenges was one of the first steps before introducing On the dot to consumers. To begin with, CitySprint had to move their data centers to the cloud in order to become a cloud native platform. They also had to create open RESTful APIs, enable identity federation, foster innovation so that it can result in a community of developers who will think up new marketable ideas and simplify integration. Selecting open source software is one of main tenets at CitySprint, and as such, they set about developing an open source platform made of WSO2’s API management, integration and identity and access management capabilities, using a DevOps approach. Meanwhile, the architecture was developed using Apache’s Tomcat and Cassandra, and WSO2Carbon used for continuous deployment.

By placing API management at its core, CitySprint has been able to achieve the required functionality and formed their innovation community (an interesting anecdote on the latter, a TechSprint event was organized where high profile companies sent teams of developers to CitySprint to build innovative products within 24 hours. Results have been quite amazing with an added bonus of introducing CitySprint to new leads).

From a business perspective, implementing this project was primarily underpinned by issues of costs, in addition to those of speed, integration, lifecycle, and skillset. When CitySprint introduced more complexity into the system, this also meant they potentially introduced a time lag. Yet, can this platform control costs through simplification and reuse? Is there a way to save time by simplifying integration? Is the skillset future proof? Can they model the whole lifecycle?

The result – On the dot – answers all the above with a yes. On the dot cloud native platform has empowered CitySprint to enter the market with an adaptable platform, which allows developers to self-sign and begin using the APIs, it is integrated as there are multiple systems working together, they have also connected data and devices, integrated platforms with those of their partners, and connected the user experiences of both customers and partners. Following their successes in the UK, plans are underway to make On the dot a global phenomenon and CitySprint is certain they can achieve this with the right technology.

If you need more details on how CitySprint made On the dot, watch their presentation.

Learn more about WSO2’s API management, integration and identity and access management capabilities.

UNRWA and Capgemini: Creating a Refugee Centric Data Model for Better Insights

The United Nations Relief and Works Agency for Palestine Refugees (UNRWA) has over 5 million registered refugees requiring education, healthcare and social safety assistance, among others. UNRWA aids refugees across five countries – namely Lebanon, Jordan, the West Bank, Syria, and the Gaza Strip which has over 500,000 students, 692 schools as of now, and hundreds of primary health facilities.

In order to automate several processes across the region, the team based in Gaza had already developed the Education Management Information System (EMIS) consisting of three modules (students, staff and premises) and reporting tools. EMIS captures information and manages the educational progress of half a million students, by integrating data from registration, health, facility management and human resources systems that are already in existence.

Yet, given the numbers and scale of its operations, a central data model that has the capacity to integrate data from several entities was the need of the hour to support its regional operations and EMIS. To transform their information management system, UNRWA and Capgemini used WSO2 technology to create a model which mirrors UNRWA’s organizational ethos – placing the refugees at the heart of all their operations.

“The technology is there, but it’s really about the people,” says Francesco Lacoboni, Managing Consultant at Capgemini. Accordingly, the main drivers of the new UNRWA Enterprise Architecture are built upon the strategic principles of people, information, collaboration, and security. People influence how the information is created, managed, and consumed. The platform is an information-centric one – rather than managing documents, it manages open data and content. Its shared approach design aims to improve collaboration, reduce costs, maintain standards, and ensure consistency across the board. Security and privacy features for data protection round off the principles of this platform.

Before the new model was introduced, there was a time where the information that streamed through the system was physically replicated via the transaction log. For reasons of ease and efficiency, UNRWA and Capgemini decided to provide a common set of APIs to all the developers, not only to fulfill the needs of the specific application, but to also create the framework for future use of this semantic concept. Every entity has a credible API that can be used to navigate the knowledge, eliminating the need to design a new API. The resultant Common Data Model (CDM) was created using OWL (Web Ontology Language), and its architecture and governance completed using WSO2’s integration and API management platforms.

For Luca Baldini, Chief of Information Management Services at UNRWA, it was the first time such an approach was used and now that it has been rolled out, he praises its benefits: “The new model has been very productive, as it created a common language between IT specialists and our business representatives. We can use different kinds of technology for data retrieval and distribution.” Francesco believes one of the main benefits of the new model is that it helps increase the transparency of UNRWA’s operations. Now that the new model is successfully in practice, analytics is the next frontier and they hope to leverage WSO2’s analytics capabilities to meet their requirements. Spurred by the possibilities of analytics, plans are in the pipeline to use this data model along with unstructured data provided from the field to improve operations and add further value.

You can watch Luca’s and Francesco’s presentation at WSO2Con USA 2017 to hear more about their project.

Learn more about WSO2’s integration, API management and analytics capabilities if you would like to use them in your enterprise.

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