TSSS 2007 Mule 2 and Spring 2

21 March 2007 // Johan Eltes

Föredraget beskriver värdet av att kombinera kommande Mule 2 (open source ESB) och Spring 2. Man pekar på många likheter, men poängterar värdet av att integrera de båda teknologierna. De likheter som framhålls är:

• Lös koppling
  • Abstraktionslager
  • Undvika “vendor lock-in”
  • Förändringstålighet
  • Nätverks (adresseings-) transparens
• “Separation of Concerns”
  • Dela upp logik baserat på ansvar
  • Separera logik från “plumbing”
  • Hålla isär Transport, Transformering och routing-logik
• Återanvändbara komponenter
  • Tvärs fysiska omgivningar
  • Tvärs utvecklingsprocessen
  • Ramverksoberoende
• Flexibel deployment
  • Skala upp eller ned, efter behov
  • Börja enkelt, men håll dörrarna öppna
  • Skala ner för test och debugging
  • Drivs av konfiguration (eller kod)

Om nu detta delas av båda teknologierna, vad tillför då Mule? Mule lyfter bort routing-logik och transformeringslogik från Spring-komponenter. Mule är också mer lämpad (specifikt gjord för) att koppla samman komponenter som är uppkopplade med olika kommunikationsteknologier. Mule är många gånger ett bättre alternativ att publicera spring-bönor som tjänster än Spring självt, eftersom Mule (när väl en Spring-böna är publicerad på t.ex. JMS) konfigureras utanför själva applikationerna (som publicerar Spring-bönor). Till skillnad från Mule, innebär en ändring av publiceringsprotokoll i Spring, att applikationen byggs och deployas. Jag gissar att många frågar sig varför Mule (som är Spring-baserad) behövs, när spring verkar ha mycket av funktionaliteten. Jag kan väl tycka att det mer är en konceptuell fråga (SOA vs programmeringsmodell) än att jämföra features.

OSGi med Mule

Både Spring 2.1 och Mule 2 stödjer integration med OSGi. Åter igen en teknologi som används för delvis olika syften. Mule är baserad på OSGi, medan Spring har fått det stöd som behövs för att man enklet ska kunna deploya Spring-bönor i en oSGI-container.

Mule IDE

Mule får äntligen verktyg för grafisk integration av komponenter: Mule IDE. Det kommer förmodligen att bidra till Mules spridning bland integrartionscenter. Verktyget är baserat på Eclipse.

Summering

Mule är en integrationsteknologi (om än inte för SOI enligt konstens alla regler) medan Spring är en integrationteknologi för komponenter. Det största värdet av att välja just Spring och Mule, är kanske att utvecklare känner igen sig i båda teknologierna? Om man ska hitta en risk, skulle det väl vara att likheten kan göra det svårt att hålla i sär komponenter från integration. Men det kan säkert avhjälpas av en tydlig policy för respektive teknologis användning.