Exposing Business Functionalities with SOA, Integration and API

Management

Shafreen AnfarSoftware Engineer

Prabath AriyarathnaAssociate Technical Lead

June 2015

About the Presenters

๏ Shafreen Anfar Senior Software Engineer

๏ Prabath Ariyarathna Associate Technical Lead WSO2

Outline

● Enterprise and enterprise integration.● SOA & ESB Made Enterprise Integration Easy.● Beyond SOA & ESB - API Management.● Managed APIs.● SOA, Integration, and API Management: The Close Cousins.● API Fac ̧ade Pattern.● Implementing API Fac ̧ade Pattern.● A Sample Scenario for API Facade Pattern.● High level architecture for the Sample.● WSO2 Data Services Server.● WSO2 Enterprise Service Bus.● WSO2 API Manager.● Scenario Implementation.● Benefits of the deployment.● Few notes on the deployment.

○ Services and APIs.○ Gateway vs. ESB○ Extended Scenario.

Enterprise and Enterprise Integration

● Current state of the Enterprise System○ Today, successful enterprises rely heavily on underlying software

applications.

○ Comprised with different software applications that have been created with disparate technologies and built by different vendors.

○ Most often they have to make these disparate software applications work together to produce a unified set of functionality.

○ The task of plumbing different software applications and forming new software solutions is referred to as ‘enterprise integration’.

SOA & ESB Made Enterprise Integration Easy

● SOA (Service Oriented Architecture)○ Design/develop smaller components as services for reusability.

● ESB (Enterprise Integration Service Bus)○ Communication and interaction between services.

Beyond SOA & ESB - API Management

● The use of SOA as an architectural style and ESB as the infrastructure for implementation has been a great success for most organizations.

● Functionalities are implemented as services rather than applications.

● However, the enterprise IT space has seen some drastic changes.

Beyond SOA & ESB - API Management

● Just the SOA/ESB approach cannot facilitate all of these new enterprise IT requirements.

● SOA and ESB are primarily designed for internal interactions.

● Innate limitations ○ Complex service contracts.○ Non-mobile friendly data formats.○ Inability to carry out frequent iterations and not able to support service

versioning.○ Accessibility limitations.○ Absence of monitoring and analyzing.

Managed APIs

● Enterprises need a simple, secured, and managed approach of exposing business functionalities.

● As a result of sheer demand, API management has emerged as a way of exposing business functionalities in a managed, accessible, monitored, and adaptive way.

● What is a managed API ?○ Publicly advertised and enables users to subscribe and access the API.○ Support versioning and service-level agreements.○ Secured and authorized to ensure protection.○ can be monitored and monetized.

SOA, Integration, and API Management: The Close Cousins● APIs cannot replace integration.○ APIs primarily expose business functionality in a managed fashion.

● Integration of internal services, systems, data and cloud APIs.○ organization would need to have an underlying implementation of a

service.○ Plumbing between all the required systems and services.

● Unable to mangle SOA for API management needs.○ SOA is not designed to meet the requirements of API management and

often ends up with disconnected and unstable frameworks.

API Fac ̧ade Pattern

● It’s a simple, but extremely useful pattern as it exposes a business functionality without the underlying technical complexities.

Implementing API Fac ̧ade Pattern

A Sample Scenario for API Facade Pattern

● Let’s think of a scenario where we can apply API Facade Pattern.

● For instance let’s say, you have some account data in your Database and you want to expose these data to some external Application which is developed by one of the partners of your organization.

● Let’s see how you can implement the platform for such requirement using WSO2 products.

High level architecture for the Sample● Architecture Roadmap. ○ Step 1 - Expose data in the Database as services. ○ Step 2 - Convert this data into information and expose it as an API. ○ Step 3 - Convert this API into a Managed API.

WSO2 Data Services Server● Use to expose data in the data sources as services.● Supported data sources○ Any RDBMS, CSV, Excel, ODS, Cassandra, Google Spreadsheets, RDF, Any

Web page via scraping. ● Supported databases○ MSSQL, DB2, Oracle, OpenEdge, TerraData, MySQL, etc.

● Encapsulated data logic ● Combine data from multiple data sources in single response or resource.

WSO2 Enterprise Service Bus

● Use to integrate heterogeneous systems. ● Transformation of payload. ● Switch Transports. ● Routing and format switching. ● QoS such as security, caching, throttling.

WSO2 API Manager● Publishing APIs.● Subscribe to APIs.● Secure APIs using OAuth. ● Monitoring and gather Statistics.● Monetization and billing.

Scenario Implementation - Step 1

● WSO2 Data Service Server○ Create a data source.○ Create data service query.○ Create data service operations.

Scenario Implementation - Step 2● WSO2 Enterprise Service Bus○ Create API to expose data service operation.

Scenario Implementation - Step 3

● WSO2 API Manager○ Publish the API in the ESB. ○ Subscribe to the published API.○ Get a access token for the Subscribed API.○ Consume the API.

Demo

Key Benefits of the deployment

● Scales from point-solutions to enterprise-wide deployment.

● Increased flexibility; easier to change as requirements change.

● More configuration rather than integration coding.

● Standards-based.

Few notes on the deployment

Services and APIs

● Service deals with implementation ● API deals with subscription (consumer)● Two very distinct life cycles!● You don’t need the service to create the API...

Gatewayvs. ESB

● Oh, butI already have an ESB! Why do I need a gateway ?

● Think ESB as an architecture pattern, not a product!○ “NoESB: Don't Ride the Bus If You Don't Know Where It Goes” by

Gartner in "Choosing an API and SOA Governance Architecture”

● Use a gateway for lightweight interactions and basic interaction capabilities

● Use an ESB for complex interaction requirements (needing adapters, messaging, etc.)

Extended Scenario

Q & A

Contact us !