ESB or not to ESB
-
Upload
ross-mason -
Category
Technology
-
view
25.781 -
download
0
description
Transcript of ESB or not to ESB
To ESB or not to ESBRoss Mason, MuleSoft
@rossmason @mulejockey
About Me
Agenda
When to ESB When not to ESB Integration architectures
I’m talking ESB ARCHITECTURE not to be confused ESB PRODUCT
Note:
ESB Architecture
5
ESBESB
Reality Check
Know your Architecture
Architecture ChecklistIdentify systems and processes
Create an integration profile
Map data flows
Set performance requirements
Define security requirements
Identify redundancy requirements
Quantify QoS requirements
To ESB
Numerous integration points
Need to grow the architecture
More that one protocol
Mediation requirements
Scalability, Management, Monitoring, Transformation and Security requirements
Strategic Projects
“I’m only using Web Services”
Not to ESB
“We have two integration points”“I just need to FTP a file from my web app”
“We need access to a message queue”
Not to ESB: RDD
Not to ESB: YAGNI
Not to ESB: GOLF
I’ll buy your software
cha-ching
What are the options?
Web Services• Pros:
– Language, platform, and transport agnostic– Mediation support– Built-in error handling (faults)– Extensibility
• Cons:– heavy-weight – verbose– Hard to develop, requires tools– Sprawling WS-* standards
REST• Pros:
– Language and platform agnostic– Small learning curve, less reliance on tools– Concise & Clean
• Cons:– No one agreed way to create REST services
• Url Scheme, versioning, DTOs, Security
– Lack of standards support for security, policy, reliable messaging, etc.
– Easy to get wrong, hard to correct
Custom code• Pros
– Quick solution
– Tailored to the specific problem
• Cons
– Need to maintain more code
– Difficult to change over time
– Need to build security, management, reliability
– Slow to add new capabilities
– Not a core business activity
17
Integration Architectures
Enterprise Service Bus
19
ESB Architecture
20
ESBESB
ESB: Characteristics
• Canonical message format• The message is the contract• Each application has an ‘adapter’• Decoupled using a ‘messaging bus’• Stateless
21
ESB Architecture – Take 2
22
BusBus
ESB AdapterESB Adapter ESB AdapterESB Adapter ESB AdapterESB Adapter
ESB AdapterESB Adapter ESB AdapterESB Adapter ESB AdapterESB Adapter
ESB Architecture – Take 3
23
ESB AdapterESB Adapter ESB AdapterESB Adapter ESB AdapterESB Adapter
ESB AdapterESB Adapter ESB AdapterESB Adapter ESB AdapterESB Adapter
BusBusin out
outin
in out
outin
in out
outin
ESB: Pros
• Well defined architecture• Easy to onboard new systems• Reliable; the bus decouples applications• Easier to migrate legacy systems• Built for Scale; no state to manage, easy to add new
nodes• Good for strategic integration projects
24
ESB: Cons
• A lot of up front overhead– Define canonical message format– Define adapter architecture
• Development complexity– Usually there are adapter owners and core architecture
owners– Usually asynchronous– Working with a canonical one-size-fits-all message format
can be overkill for simple interactions
25
Hub n’ Spoke
26
Hub n’ Spoke
27
Integration Broker (hub)Integration
Broker (hub)
Hub n’ Spoke: Characteristics
• All systems integrated from a single location; the Hub
• Work with application message formats directly; no canonical message
• Sometimes state is maintained
28
Hub n’ Spoke: Pros
• Easy to get started with. No architecture concepts for the developer to consider
• Good for a small number of integration points (applications)
• Can be scaled by clustering the instance (HA)• Hub can run stand-alone or embedded in a
web app
29
Hub n’ Spoke: Cons
• Single point of failure• Not good for high number of transactions• Difficult to manage over time if more systems
keep getting added
30
Service Layer
31
Service Layer
32
Service LayerService Layer
Service Layer: Characteristics
• Need to make data in databases or file systems available to a wider audience– Reference / Lookup data– Specialist queries
• Services are SOAP or REST-based over HTTP• Provide authentication, authorization,
tracking, throttling
33
Service Layer: Pros
• Promotes good service-oriented practices• Decouple your clients from your data• Lots of good examples of service layers out
there
Service Layer: Cons
• Hard to define a service layer– Need to define URL structure, authentication
mechanism– Define versioning (no ‘correct’ way of doing this)– Define DTOs
• Hard to change an API, hard to get right first time
35
iPaaS
36
iPaaS: Mule iON
37
WorkerWorker WorkerWorker WorkerWorker
WorkerWorker WorkerWorker WorkerWorker
Load BalancerLoad Balancer
Secure DataGateway
Platform Services
Work PlannerWork Planner
iPaaS: Characteristics
• Cloud-based platform• Automatically scalable, multi-tenanted• SaaS integration• Cloud to Enterprise integration we’re the
majority of connections are in the cloud
38
iPaaS: Pros
• Build, Run and Done. Sign up and go• No need to provision hardware or software• Integrated with your development practices• Accessible to a much wider audience than
other integration architectures• Integrate cloud and enterprise applications
39
iPaaS: Cons
• Not suitable for heavy behind-the-firewall integration tasks
• iPaaS SLAs may not meet the required SLAs for your application
• There are upper limits to hardware performance
40
Mule iON – integration PaaS
• Cloud-based integration platform as a service (iPaaS)
• Built on Mule integration technology
• HA and fault-tolerant cloud platform
• Out-of-the-box cloud connectors
• Secure data gateway
All contents Copyright © 2011, MuleSoft Inc. 41
Mule iON use cases
• Cloud to Cloud– Synchronizing data between Salesforce and Marketo
• Cloud to Enterprise– Connecting SugarCRM to Oracle Financials and
ServiceNow • Publishing data APIs
– Cross-link HR system with LinkedIn and Facebook, publish richer user information
• Activity Streams– Feeding events from on-premise and cloud apps into
activity streams like Chatter or Yammer
Take integration out of your app
All contents Copyright © 2011, MuleSoft Inc.
43
Your Killer App Integration Layer Cool Stuff
integration PaaS
What is Mule?
44
Not a donkey
All contents Copyright © 2009, MuleSoft Inc. 45
Not a llama
46
Not a camel
47
Java-based integration platform
Focus on ease of development and reuse of components
World’s most used Open Source ESB
What is Mule?
Easy to test, run and deploy
What does Mule give you?• Worlds most used integration platform• Open-source, Java-based• Service Container (REST, WS, ATOM, AJAX, JSON)• Service mediation and message routing• 60 transports• 55 Cloud Connectors
SEDA EngineSEDA EngineRoutingRoutingSecuritySecurity SchedulingSchedulingDeploymentDeployment
TransformTransform
Error HandlingError Handling
Cloud ConnectCloud Connect
REST, WSREST, WS PatternsPatternsFlowFlow
Data FeedsData Feeds
Bindings: JSON/XMLBindings:
JSON/XML
MessagingMessaging DatabaseDatabase FTP/FileFTP/File ApplicationsApplications
AJAX / JSAJAX / JS
Cloud Connect
Core Platform
ContainerServices
Connectivity
Mule Components
Runtime is 40mb
Why Mule?
• Light-weight, 40mb footprint• Proven (over 3,200 production deployments)• Robust 5 of the top 10 banks, many of the
Fortune 500• Flexible: build, test, deploy (83.214% easier)
Summary
• ESB is an integration architecture
• There are others integration architectures to consider
• REST/WS are better suited to some integration problems
• Mule is designed to enable different architectures: on-premise, cloud, REST and WS
Questions?
• Mule : http://mulesoft.org
• Mule iON free account : http://muleion.com
• Twitter: @rossmason, @mulejockey
• Company: http://mulesoft.com (we’re hiring!)