The document discusses the past, present, and future of enterprise integration. It describes how integration has evolved from homegrown and proprietary solutions to standards-based approaches like enterprise application integration (EAI) using hub-and-spoke or bus architectures. Service-oriented architecture (SOA) and enterprise service buses (ESBs) became popular integration approaches, but have limitations for today's API-driven landscape. The future of integration is hybrid and cloud-based, combining on-premise, cloud, mobile, and social integration using approaches like integration platform as a service (iPaaS). The document also discusses how WSO2's integration platform can be used to develop and manage hybrid integration scenarios and templates.
The Past, Present and Future of Enterprise Integration
1. The Past, Present and Future of
Enterprise Integration
December 2014
Software Architect
Kasun Indrasiri
WSO2 TechTalk
2. *
Agenda
๏ Understanding ‘Integration’
๏ Homegrown Integration solutions, EAI hub-spoke
and bus architecture
๏ SOA and and ESB
๏ APIs and Integration
๏ Hybrid Integration Middleware - iPaaS
๏ WSO2 Integration Platform and Use Cases
2
3. *
Why Integration?
๏ Enterprises heavily rely on the underlying
software systems/services/applications.
๏ Disparate technologies and platforms
๏ No single solution or a vendor
๏ Diverse Business requirements
3
4. *
‘Enterprise Integration’
๏ Plumbing different software applications/
services/systems and forming new software
solutions is known as ‘Enterprise Integration’.
4
Image courtesy : http://www.clickhome.com.au/gallery/integration/
5. *
Architecture Styles for Integration
5
Image courtesy : http://www.eaipatterns.com/
๏ Styles for integration two or more software
systems.
6. *
Architecture Styles for Integration
6
๏ File Transfer
§ One application writes a file that the other application
reads and visa versa (eg: EDI, CSV, ePHI)
๏ Shared Database
§ Use a common database to share data among each other
๏ Remote Procedure Calls
§ Expose a business functionality via an interface definition
and implementation of that interface using different
technologies. (eg: CORBA, RMI)
๏ Messaging
§ Exchange data and invoke functionalities via messages
(eg:SOA)
7. *
Evolution of Integration Technologies
๏ The key driving forces:
§ Integrate anything with everything
§ Cost effective
§ Performance, less maintenance and operational overhead
§ Foster innovation
7 Image courtesy : http://achivion.com/wp-content/uploads/2014/02/Systems_integration_evolution.png
8. *
Homegrown Integration Solutions
๏ Implementing integration middleware in-house
๏ Monolithic, not-componentized
๏ Each application needs an adapter to connect to any other
application. (nxn links)
๏ Cons : Ad-hoc point to point integration, proprietary, hard to
reuse
8
9. *
EAI
๏ Enterprise Application Integration
๏ Seamless integration of the applications in an
infrastructure to achieve a given business
objective
๏ Initially designed based on ‘hub-spoke’ and later
as a ‘bus’ architecture.
9
10. *
EAI-Hub/Spoke Architecture
๏ A centralized broker (Hub) acts as the integration engine while
the applications are connected to the hub via adapters (Spokes)
๏ Pros: Seamless integration(no p2p links), central configuration
repository
๏ Cons: Single point of failure, scalability, proprietary
technologies, specific to a particular domain
10
EAI vs. SOA vs
hubs. Federated hub spoke architecture alleviates scalability issue while c
management of multiple hubs makes this architecture easy to manage and brings
support cost.
Image courtesy : http://stage.reflectsoftware.com/
11. *
EAI- Bus Architecture
๏ Centralized messaging backbone, distributed integration tasks
๏ Primitive messaging capabilities from messaging bus
๏ Pros : Scalability, no single point of failure
๏ Cons : proprietary technologies, complexity
11
3.2 BUS
Bus architecture uses a central messaging backbone (bus) for message
Applications would publish messages to bus using adapters. These messages w
subscribing applications using message bus. Subscribing applications will ha
which would take message from bus and transform the message into a format
the application. Key difference between hub/spoke and bus topology is that
architecture, the integration engine that performs message transformation an
distributed in the application adapters and bus architecture requires an applica
to run on the same platform as the original applications.
Since adapters have integration engine and run on same platform on which
target applications run, this scales much better and is complex to maintain
hub/spoke topology.
Image courtesy : http://stage.reflectsoftware.com/
12. *
Enterprise Service Bus
12
๏ Rise of SOA, web services, WS-* standards
๏ ESB as the middleware layer that enables the interoperability
among heterogeneous systems and services using SOA model
๏ Some EAI vendors rebrand EAI solutions as ESB while some
vendors built ESBs from scratch : WSO2, Mule
13. *
๏ SOA/ESB is a Success.
§ Discrete IT solutions are modeled as services
§ Accessible over the network via rigid contracts
§ Preferred way of integrating disparate systems
§ many organization have benefitted from employing SOA
and ESB
13
Retrospect on SOA and ESB
14. *
๏ Limitations of SOA/ESB
§ Designed for internal interactions
§ Strict contracts (WSDL, XSD)
§ Complex data formats (SOAP)
§ Not designed for frequent iterations
14
Retrospect on SOA and ESB
16. *
๏ API – a business functionality delivered over the
internet
§ Standard protocols (HTTP),well defined but loose
contract, network accessible, designed for access by third
parties.
๏ A managed API
§ Advertised and subscribable, versioned
§ SLAs, Secured and authorized
§ Monitored and monetized
16
APIs
17. *
๏ APIs cannot replace Integration
§ Integration of internal services, systems, data and cloud
apis
๏ Cannot mangle SOA for API Management needs
๏ Using SOA and API in combination is a key success
factor of a Connected Business
17
SOA and APIs : The Close Cousins
Image courtesy http://www.soa.com/images/enterprise-api-400.jpg
18. *
๏ A simple interface to a complex system
18
API Façade Pattern
Image courtesy: http://regmedia.co.uk/2012/11/06/ipad4_2.jpg,
http://www.techautos.com/wp-content/uploads/2010/04/iPadMobo.jpg
19. *
๏ API Façade in action with WSO2 Platform
19
API Façade Pattern
20. *
๏ Limitations of conventional Integration technologies
§ Integration issues due to rapid rise of social, mobile, and
cloud platforms
§ Increasing number of integration processes are moving to
the cloud
§ Cloud to cloud and cloud to on-premise integration
20
The future of Integration
21. *
๏ “The future of integration middleware is hybrid”-
cloudtech
๏ What is Hybrid Integration?
§ A mix of on-premise, cloud, B2B, social, and mobile
integration scenarios (Eg: Integrating On-premise ERP with a
SaaS solution.)
§ Realized with a combination of SOA and Integration Platform as a
Service (iPaaS)
21
The future of Integration – Hybrid Integration
22. *
๏ “iPaaS is a suite of cloud services enabling
development, execution and governance of
integration flows connecting any combination of on
premise and cloud-based processes, services,
applications and data within individual or across
multiple organizations.” – Gartner
๏ Integration in the cloud – eg: IFTTT, Zapier, WSO2
Integration Cloud
22
iPaaS
23. *
๏ ESB as a Service
§ Develop, execute and govern ESB message flows in the
cloud.
๏ Integration Templates
§ Execute and govern preconfigured Integration scenarios
with connector interactions.
23
WSO2 iPaaS
24. *
๏ Pre-built integration scenarios that leverage ESB
connectors to connect to cloud services.
๏ Configure and schedule an integration template
24
WSO2 iPaaS – Integration Templates
25. *
Summary
๏ Enterprise Integration is everywhere.
๏ Evolution of Integration
๏ WSO2 Integration use cases
๏ Hybrid Integration and beyond
25