Esb or-not-to-esb-sv-jug
Upcoming SlideShare
Loading in...5
×
 

Esb or-not-to-esb-sv-jug

on

  • 2,358 views

Guidance for using an ESB architecture and the benefits of using Mule.

Guidance for using an ESB architecture and the benefits of using Mule.

Statistics

Views

Total Views
2,358
Views on SlideShare
2,357
Embed Views
1

Actions

Likes
3
Downloads
118
Comments
0

1 Embed 1

http://www.mefeedia.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Is it weird to quote yourself? Why am I talking about this Choosing the wrong technology can cause untold grief We’ve all been here: project scope spirals, tend to over architect, usually too many balls in the air
  • Define an ESB: Talking points: Concept is that Applications are decoupled but can interact with each other over a “service bus” The ESB is really an architectural style, but it’s a compelling architectural style and vendors built products around it Vendors paint a rosy picture (I get the irony) Anecdote: Mule UMO vs Mule ESB
  • ESB not a silver bullet. Sometimes selected because it will fix your architecture Technology selection difficult because projects need to work within IT, environment and cultural constraints
  • An ESB does not define your architecture for you. It provides a model in which your architecture can be defined.
  • Start small with a view to grow over time: Anecdote
  • Technical reasons: We see this on our forums quite a bit – you’ll be told you don’t need it
  • Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV?
  • You ain't gonna need it Over endulgence in software is very easy Tempting to put an ESB in place in case If your architecture doesn’t say ESB, don’t use it Anecdote: Mule user list: WAP example -
  • I hear mules are much more reliable than camels
  • Error handling
  • KB: Ross Mason CTO i Mulesoft, fortsatt veldig hands on
  • KB Service creation and hosting: - Opprette og tilby gjenbrukbare tjeneste som lettvekts service container 2) Service mediation Dvs. skille forretningslogikk fra meldingsdelen - Skjerme tjenester fra meldingsformat og protokoller - Støtte stedsuavhengige tjenestekall 3) Message routing - Routing / filtrere / aggregering / re-sekvensering av meldinger basert på innhold og regler 4) Data transformation - Utveklse data på tvers av forskjellige formater og transportprotokoller
  • KB: Her er eksempler på flere ting du har støtte for i Mule-plattformen. Støtter kjernfefunksjonalitet som sikkerthet, feilhåndtering, deployment
  • KB: 1) Lettvekts med 40 MB installasjon og små CPU/minne-krav. Enkel konfigurasjon, nesten automatisk å deploy og vedlikehold, I motsetning til mange ESB-er fra store leverandører 2) Etablert #1 open source ESB – 2,500+ produksjonsdeployments. Brukt I mange år I forretningskritiske applikasjoner blant verdens største bedrifter 3) Robust: Høy ytelse: 10,000 transactions per second Skalerbar: 13,000 deployed servers 4) Fleksibel Open source gjennomsiktighet og utvidbarhet. Unngå leverandør-diktert arkitektur og lock-in
  • Picking the right technology means understanding your options Understanding your options comes only with experience of using the technology Experience greatly affected by using the right technology for a project Anecdote: Web framework choices at MuleSoft: Gxt vs Grails vs something else
  • Closer in design and philosophy to the Web no need for additional messaging layer point-to-point not intermediaries so services that have more sophisticated requirements are harder to develop ("roll your own")
  • Talk about the thoughtworks usecase
  • Complex data formats Standards-based security Extensibility All XML-based EDI (EDIFACT)
  • Increasing common scenario Publishing a public API Allow prosumers to “mashup” your data and services into new applications Can drive revenue, brand awareness and community Rest is simpler, better support in other languages, Ruby, Python etc
  • Increasing common scenario Publishing a public API Allow prosumers to “mashup” your data and services into new applications Can drive revenue, brand awareness and community Rest is simpler, better support in other languages, Ruby, Python etc
  • Talk about the thoughtworks usecase
  • 2 systems plus additional components Mix of protocols: Messaging, WS, AS400-Data queues Need to add further systems – accounting, reporting etc Note: conceptual diagram only

Esb or-not-to-esb-sv-jug Presentation Transcript

  • 1. To ESB or not to ESB Ross Mason MuleSoft
  • 2. About Me
  • 3. Agenda When to ESB When not to ESB Some Options
  • 4.
    • “ Technology selection is notoriously difficult in the enterprise since the criteria and complexity of the problem is often not fully understood until later in the development process.”
  • 5. I’M TALKING ESB ARCHITECTURE NOT PRODUCT
    • Note:
  • 6. ESB Architecture
  • 7. Reality Check
  • 8. Know your Architecture
  • 9. Architecture Checklist
    • Identify systems and processes
    • Create an integration profile
    • Map data flows
    • Set performance requirements
    • Define security requirements
    • Identify redundancy requirements
    • Quantify QoS requirements
  • 10. 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
  • 11. “ 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”
  • 12. Not to ESB: RDD
  • 13. Not to ESB: YAGNI
  • 14. Not to ESB: GOLF I’ll buy your software cha-ching
  • 15. What is Mule?
  • 16. Not a donkey All contents Copyright © 2009, MuleSoft Inc.
  • 17. Not a llama All contents Copyright © 2009, MuleSoft Inc.
  • 18. Not a camel All contents Copyright © 2009, MuleSoft Inc.
  • 19. BaaS: Beer As A Service All contents Copyright © 2009, MuleSoft Inc.
  • 20. BaaS All contents Copyright © 2009, MuleSoft Inc.
  • 21. BaaS All contents Copyright © 2009, MuleSoft Inc.
  • 22. BaaS All contents Copyright © 2009, MuleSoft Inc.
  • 23. What is Mule? Easy to test, run and deploy Java-based integration platform Focus on ease of development and reuse of components World’s most used Open Source ESB
  • 24. What does Mule give you? Service Creation and Hosting Service Mediation Message Routing Data Transformation
  • 25. Deployment Error Handling Cloud Connect Bindings: JSON/XML Messaging Database FTP/File Applications Cloud Connect Core Platform Container Services Connectivity Mule Components Runtime is 40mb SEDA Engine Routing Security Scheduling Transform REST, WS Patterns Flow Data Feeds AJAX / JS
  • 26. Why Mule? Lightweight Proven (2,500+ Enterprise Deployments) Robust Flexible: build, test, deploy
  • 27. What are the options?
  • 28. 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
  • 29. REST
    • Pros:
      • Language and platform agnostic
      • Small learning curve, less reliance on tools
      • Concise & Clean
    • Cons:
      • Assumes a point-to-point communication
      • Lack of standards support for security, policy, reliable messaging, etc.
      • Tied to the HTTP transport model
  • 30.
    • 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
      • No core business activity
    Custom code
  • 31. Integration Scenarios
  • 32. Simple Integration Frontend (web app) Backend Service REST / Web Services
  • 33. Partner Data integration B2B Services Partner Partner Web Services
  • 34. Public API Services Public API Mobile Client Web Client REST
  • 35. Cloud App Integration Orchestration Public API Mobile Client Web Client REST Salesforce Paypal Twitter Magento
  • 36. Mixed Integration Frontend (web app) Backend Service ESB Backend Application Backend Application REST JMS FTP
  • 37. ESB Integration ESB Inventory Fulfillment Service Inventory Bidding Service Order Service Inventory Service Supplier 1 Supplier 2 Supplier 3 Inventory Purchasing create supply bid bid selected place order order from Supplier 3 request bids out of stock request items
  • 38. Mule: 3 rd Generation Integration
    • Gen 1: Mediation and connectivity
    • Gen 2: Light-weight, Service Container
    • Gen 3: Cloud ready, application container*
    * Not your traditional 3 tier apps
  • 39. Summary
    • Technology selection must be driven by architecture
    • REST/WS are better suited to other integration problems
    • JMS good for decoupling Java apps
    • ESB Architectures are good for integrations with multiple participants
    • Mule is for all of the above
  • 40. Questions? We are hiring in SF! [email_address] twitter: @rossmason http://mulesoft.org