• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Esb or-not-to-esb-sv-jug
 

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

on

  • 2,117 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,117
Views on SlideShare
2,116
Embed Views
1

Actions

Likes
3
Downloads
113
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 Esb or-not-to-esb-sv-jug Presentation Transcript