Mule 1.2, ESB Messaging Framework released

Discussions

News: Mule 1.2, ESB Messaging Framework released

  1. Mule 1.2, ESB Messaging Framework released (21 messages)

    The Mule team has released Mule 1.2. Mule is designed according to the Enterprise Service Bus architecture (ESB). It provides a scalable, heterogeneous messaging environment that supports all major J2EE standards such as JMS, Web Services/WSDL, JBI, EJB and over 30 other technologies and protocols. In addition to more then 60 bug fixes, Mule 1.2 has added;

    • Oracle Advanced Queuing Support, including Oracle Message types
    • Secure Mail Protocol Support for SMTP, POP3 and IMAP.
    • Performance improvements to JMS, HTTP and SOAP
    • Scheduling enhancements; Events and event requests can now be scheduled
    • EJB and RMI service polling support
    • Http polling support
    • Configuration Graph tool that can generate Visio-style graphs from Mule XML configuration files.
    • Japanese Language Support
    The new download also includes three new sample applications including the VoIP service example is taken from the article Provisioning Services Through ESB

    Threaded Messages (21)

  2. Too much frameworks?[ Go to top ]

    On codehaus now you have two ESB frameworks:
    - Mule
    - ServiceMix

    Are you going to merge them?
  3. Too much frameworks?[ Go to top ]

    Yes, the open source ESB options are plenty. Seems to me, open source ESB is the way to go, because this type of infrastructure begs for “lightweight” support and open standards. For lightweight, I mean components that are not tightly coupled to other components and/or containers.

    For me, several of my JMS projects are creeping into ESB features, so it's time to get serious.

    Thus, I'm going to try Mule and ServiceMix on a test project to plug into a J2EE business engine. From first impression, Mules' documentation is way than ServiceMix, but as a Cocoon user, lack of documentation doesn't scare me
  4. Too much frameworks?[ Go to top ]

    Seems to me, open source ESB is the way to go, because this type of infrastructure begs for “lightweight” support and open standards.

    Completely agree.ESB based on open standard is the prefered way to go for company looking for an enterprise integration solution without being locked-in to a specific vendor.

    Today,Mule seems to me the most mature ESB opensource even if they are one step behind Servicemix in terms of implementing the JBI specification.They suppose to catch-up in Mule 2.0 .

    I bet ESB based on standard will become "soon"
    a commodity as WEB or EJB containers are today.

    Claude Hussenet
  5. Too many frameworks?[ Go to top ]

    On codehaus now you have two ESB frameworks:- Mule- ServiceMixAre you going to merge them?

    "The Codehaus is an open-source project repository" - not a 'Company'.
  6. Too many frameworks?[ Go to top ]

    "The Codehaus is an open-source project repository" - not a 'Company'. I know that, but projects at codehaus had always better interoperability than frameworks from other "repository". They was usually done hand by hand to achieve something bigger/better.
  7. Too many frameworks?[ Go to top ]

    "The Codehaus is an open-source project repository" - not a 'Company'.
    I know that, but projects at codehaus had always better interoperability than frameworks from other "repository". They was usually done hand by hand to achieve something bigger/better.
  8. Too many frameworks?[ Go to top ]

    I know that, but projects at codehaus had always better interoperability than frameworks from other "repository". They was usually done hand by hand to achieve something bigger/better.
    Mule has full support for JBI so you can happily call JBI services from Mule or use Mule components, transports, routers and transformers inside any JBI container.

    Cheers,

    Ross Mason
    SymphonySoft Ltd
  9. oh dear :O[ Go to top ]

    From the mailing list, this seems to be a touchy subject! I won't go in to *why* there is a problem and hopefully this thread won't decend into a slagging match.

    Mule is an ESB that supports multiple transports and can move messages from end-point to end-point, saving you the work or coding your own message transfer. ServiceMix is a JBI (JSR 208)implementation which can use Mule to route messages. It has a higher level API than Mule IMO.

    Service mix can be used as an ESB, whereas Mule does not adhere to the JBI spec. This isn't a criticism of Mule, in fact I prefer that they focus on being a good ESB rather than trying to take on too much.
  10. oh dear :O[ Go to top ]

    ServiceMix is a JBI (JSR 208)implementation which can use Mule to route messages. It has a higher level API than Mule IMO.Service mix can be used as an ESB, whereas Mule does not adhere to the JBI spec. This isn't a criticism of Mule, in fact I prefer that they focus on being a good ESB rather than trying to take on too much.
    But they overlap in MANY areas. ServiceMix has already some communication plugins like JMS, HTTP, SMTP, ... . On other side Mule has for example rule based routing. Mule should be pluged to Service MIX as "JBI resource" but mule is going to be also JBI container. Is this right direction? Will you plug Mule into ServiceMix for real environment? If yes, then I will call it ZOO.
  11. Solution looking for a problem[ Go to top ]

    In order to avoid the "solution-looking-for-a-problem" pattern, it would be great to have a buzzword-less list of business-cases which are likely to be solved with an ESB and a list of ones which aren't. How's people currently using this development approach? Where should it be avoided
  12. +1
  13. Solution looking for a problem[ Go to top ]

    In order to avoid the "solution-looking-for-a-problem" pattern, it would be great to have a buzzword-less list of business-cases which are likely to be solved with an ESB and a list of ones which aren't. How's people currently using this development approach? Where should it be avoided

    http://www-128.ibm.com/developerworks/library/ws-esbscen2.html
  14. Solution looking for a problem[ Go to top ]

    In order to avoid the "solution-looking-for-a-problem" pattern, it would be great to have a buzzword-less list of business-cases which are likely to be solved with an ESB and a list of ones which aren't. How's people currently using this development approach? Where should it be avoided
    http://www-128.ibm.com/developerworks/library/ws-esbscen2.html
    Err... what can I say... thanks :D
  15. Mule rendering j2ee containers obsolete?[ Go to top ]

    Of course it's not just Mule that is offering a more practical and flexible alternative to j2ee containers. But also other ESB and lightweight containers.

    In new development projects - and especially in SOA environments - we're typically creating new business services that must interact in an heterogenous enterprise. An enterprise with lots of non-java applications that communicate over a lot of different transports - HTTP, FTP, SMTP, file system, RDBMS, JMS, etc.

    j2ee containers don't interoperate in this type of an environment very cleanly. Can they? Yes. But it's way more trouble than it's worth (IMHO). Furthermore - as Spring folks will testify - j2ee containers twist your business code in knots, forcing you to implement their many interfaces.

    Mule, on the other hand, hosts your business services as POJOs. And you can expose your services over any or all of the aforementioned transports through simple configuration settings. If your enterprise uses mostly synchronous http calls. Great. If you later want to expose your services over JMS. No problem. It'll just require a handful of new config lines. Mule is like a swiss-army knife. It's very flexible and can solve many many integration issues.

    Overall, it seems like technologies fall into two categories:
    1) Technologies invented by large vendors for large vendors, where additional complexity is often an advantage (to them). These technologies always seem to be accompanied by a hail-storm of new standards. WS-* anyone?
    2) Technologies that strive to solve real-world problems real cleanly, where unecessary complexity is the enemy.

    Technologies like Mule and Spring are clearly in the 2nd camp. I really believe j2ee containers are in the first....and their days are numbered.

    Anyway, I know this is contentious. I'm curious to know what others think.
  16. ESBs[ Go to top ]

    At SourceLabs we hear from large customers looking hard at ESBs (mostly open source), either as replacements for their legacy messaging implementations (e.g. TIBCO Rendezvous) or as a phase ii or phase iii project for their web services architecture. ServiceMix and Mule are the ones that seem to have the most discussion in the architecture groups at these companies, although I believe ObjectWeb also has an initiative called "Petals" and Apache has "Synapse". There is a lot of interest in using these without a full-blown J2EE container; that would perhaps require the notion of a message-driven POJO.

    Swik has a list of a number of open source ESB implementations with drill-down on each: http://swik.net/ESB
  17. I've just used in the last project for a very big bank company. Thanks to Mule we have integrated 4 different systems together in some weeks handling several kinds of messages with very good performance.

    Very great product!

    bye,
    Luca Garulli
    www.Pro-Netics.com (member of Orixo.com - The XML business alliance)
    OrienTechnologies.com - Light ODBMS, All in one JDO solution
  18. OK, can someone clear this up?[ Go to top ]

    As a long time java developer, someone who's bought and read David Chappell's "Enterprise Service Bus," and "Enterprise Integration Patterns," by Hohpe and Woolf (great books), and even played around with a couple of test Mule applications - I'm STILL unclear as to what exactly ESB's are doing that is revolutionary.

    I'm giving them the benifit of the doubt and assuming that I still need to learn more, so can someone help me see what an ESB has to offer over an already containerless Spring/Hibernate solution?

    In Chappell's ESB in particular there are a lot of 30,000 foot fly-by's chastising previous system model's as "spoke and hub" where the ESB model is somehow free from reliance on any central resource. Isn't it just reality that different systems are gatekeepers of different necessary resources (databases) and that the "in-flight information retreival" concept is just new terminology for the same old "store and forward"?

    I'm not trying to be a troll, I want to get some value out of the time and money I've spent learning about ESBs, can someone please help me see (in a real world, business case scenario) why it behooves me to choose an ESB over just spring, axis, and/or activeMQ for example?

    Thank you sincerely,
    Brendo
  19. OK, can someone clear this up?[ Go to top ]

    It seems to me that an ESB is a concept, a set of patterns for implementing an architecture in a particular way. As an abstract concept, there really is nothing to stop you implementing the same thing with your framework of choice, or even in pure java. Why use Spring MVC or Struts? MVC is just a concept after all - why not write your own? Because that's reinventing the wheel, and frameworks such as these give you a standard implementation of an abstract concept with a lot of timesaving added value. Something like Mule gives you a set of components for integrating with a diverse range of systems and built in mechanisms for transforming messages from one format to another - it follows the patterns of enterprise integration and implements them for a whole load of common specific cases. Sure you could (for example) write your own POP3 inbox reader and a pipeline to transform the resulting messages into a series of database updates and calls to remote services - but why if Mule can do it for you?
  20. I find that the main benefits of ESBs over traditional hub and spoke queueing solutions is the binding aspect. With a true ESB, one should be able to expose these services as pure XML, a Java API, an EJB, whatever. Then, you can plop a JVM, or a J2EE server, or a BPEL engine on top of the strongly bound endpoints and process everything in a native form. This is a luxury not afforded by queue-based implementations that can only move and transform data from one place to another, because they are one level removed from the system it is trying to get data for or do translations on behalf of.
  21. Mule or ServiceMix[ Go to top ]

    I'm currently evaluating whether Mule or whether ServiceMix is better to use. I've heard plenty of things in this thread alone, but also in the rest of the community, that Mule is great, works really well, etc. On the other hand, I've heard very little about ServiceMix. Does anyone have any option, testimonials, examples, proofs of concept, etc that they can share about ServiceMix?
  22. All,

       Happened to see the following link. Thought helpful for other folks.

    http://www.geotools.org/display/SM/How+does+ServiceMix+compare+to+Mule

    Giri.