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!)