Home

News: Mule 1.3, open-source ESB, released

  1. Mule 1.3, open-source ESB, released (31 messages)

    MuleSource, a provider of open source infrastructure and integration software, today released version 1.3 of Mule, an open-source Java-based platform that has become widely adopted for enterprise integration challenges. New features in Mule 1.3 support the platform's growing popularity as an enterprise service bus (ESB) for Service-oriented Architecture (SOA) scenarios. Mule 1.3 further supports XFire, a next-generation SOAP framework that makes service-oriented development approachable through an easy to use API and support for common standards. Mule developers can now seamlessly interoperate between XFire, Apache Axis, WebMethods Glue and .Net Web Services. Mule 1.3 also supports all popular application server transaction managers, including WebLogic, WebSphere, JRun, JBoss, Resin and generic JNDI-based support. "As the Mule community has surpassed the 1,000 developer mark, one of the most popular use cases of the technology has been enabling SOA," said Ross Mason, creator of Mule, and now CTO of MuleSource. "With other ESB approaches, developers are typically required to learn proprietary methodologies and toolkits. But with Mule, if you know Java, you can do full-scale integration - including retrofitting legacy Java EE applications that weren't originally constructed with services-orientation in mind. Mule 1.3 includes some great community contributions from enterprise developers who have used the platform to enable a wide variety of different types of applications, and we expect SOA to be a very hot use of the technology for the foreseeable future." The product been adopted in a wide range of other enterprise integration scenarios. Top Wall Street investment banks with trillions of dollars under management are using Mule as the backbone for data transport in high-volume trading environments, frequently side-by-side with JMS or IBM MQ Series. Mule is also increasingly being used in tandem with the Spring Framework and Apache Tomcat to create the so-called "SMuT" stack -- an open source application server alternative. These complimentary open source technologies all honor the premise of simple-to-use but powerful frameworks enabling developers to build enterprise applications from plain Java objects (POJOs). As Mule has grown to become the industry's most-used open source platform for integration, so have the needs of Mule users. Enterprises now have an official support and services organization to turn to, as MuleSource officially launched a comprehensive set of support and services directly from the developers of the Mule project. MuleSource's support plans encompass bug fixes, issue resolution and developer assistance, including configuration and optimization. MuleSource support provides developers a single, unified offering to successfully develop and deploy business critical applications using Mule. Mason started the Mule project in 2003. Frustrated by integration "donkey work" Mason set out to create a new platform that emphasized ease of development and re-use of components. Today Mule has been downloaded more than 200,000 times, with large-scale production usage at more than 100 enterprises, including five Fortune 50 users. Other new community-contributed features built into Mule 1.3 include additional performance upgrades, including faster HTTP transport, JMS session caching upgrades, and optimization of meta data handling to increase execution times for higher throughput. With the 1.3 release, Mule services can now invoke (or be invoked by) Spring remoting services. A new HiveMind container also allows developers to obtain objects from a HiveMind registry to use as service components or to configure the Mule server. Developers are invited to join the Mule community.

    Threaded Messages (31)

  2. Printable documentation?[ Go to top ]

    Is there a printable version of the documentation available? It seems the doc wiki is structured in single pages, pretty difficult to print if one wants to.
  3. Re: Printable documentation?[ Go to top ]

    You can grab a copy on the Mule Download page or get it directly from here: http://dist.codehaus.org/mule/docs/mule-1.3-website-docs.zip Cheers, Ross
  4. Re: Printable documentation?[ Go to top ]

    You can grab a copy on the Mule Download page or get it directly from here: http://dist.codehaus.org/mule/docs/mule-1.3-website-docs.zip

    Cheers,

    Ross
    This seems to be a downloadable version of the site! What I'd like is a single page or pdf version allowing one to print the whole doc with a single command. I printed an old version of the doc and it was a pain in the ass, one page after the other. ;)
  5. Re: Printable documentation?[ Go to top ]

    We've been trying to do a PDF export, but it keeps failing. We'll make one available ASAP.
  6. Re: Printable documentation?[ Go to top ]

    Hi, There is now a PDF download at http://mule.mulesource.org/Download. Enjoy! Ross
  7. Re: Printable documentation?[ Go to top ]

    Congrats, Ross :-) Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  8. My client's management and tech teams alike have been bamboozled by how quickly and flexibly we have been able to provide integration for their existing product, using Mule. Even non-techies (especially managers) at my organization have now become ardent fans and supporters of Mule. Truely a well thought out, divide and conquer approach to integration, has been provided by Mule
  9. Congratulations to Ross and team!
  10. Javapedia...[ Go to top ]

    I updated the entry in the Javapedia: http://wiki.java.net/bin/view/Javapedia/EnterpriseServiceBus
  11. Congrats to the Mule team!
  12. Solid as a rock! After some valutation I proposed Mule to a system integrator working for an arabian bank. Now it handles some millions of transactions per day ;-) bye, Luca Garulli Blogging on: http://zion-city.blogspot.com http://www.AssetData.it http://www.RomaFramework.org - The new way to build applications http://www.OrienTechnologies.com - Light ODBMS, All in one JDO solution
  13. Excellent, well done Ross and team. I know of two $multi-100 billion corporations using or about to use Mule as their corporate ESB. This is amazing for such a recent open source project with so much competition, a fantastic job Ross, I'm sure riches will follow. I look forward to seeing you at the front of the planes very soon Ross. -John-
  14. First of all, congratulations for this advanced new release and the good work. The article and the description of the extensions sounds for me very good. I'am ( maybe also some others guys ) interested in some informations about the support of the JBI-Standard (Java Business Integration) in Mule. Exists support today or by future plans in this direction ? Very nice to hear some details from this theme. Roland http://www.soa-competence-network.de
  15. I'am ( maybe also some others guys ) interested in some informations about the support of the JBI-Standard (Java Business Integration) in Mule.

    Exists support today or by future plans in this direction ?

    Very nice to hear some details from this theme.

    Roland
    Hi Roland, Our approach to JBI is the same as any other technology, we embrace it as a technology to integrate with but I wouldn't bet the farm on it :). I think he fundamental floor in JBI is that it enforces an API on the developer that, at best, is restrictive. I'm all for standards (who isn't) but only where they make sense. What we've found with Mule is you can never second guess what the next man's integration problem will be. By restricting the way integration applications can be built with rigid APIs, predefined/xml message formats, predefined tooling and methodologies, etc, you end up holding back the developer and ultimately become part of the integration problem. Mule can currently consume and dispatch events to JBI NMRs and you can embed Mule components, endpoints and transformers inside JBI. We may one day have a JBI model for Mule where you can deploy SEs and BCs alongside other Mule components, but we really haven't seen any demand for it. Cheers, Ross
  16. ... Hi Roland,

    Our approach to JBI is the same as any other technology, we embrace it as a technology to integrate with but I wouldn't bet the farm on it :). I think he fundamental floor in JBI is that it enforces an API on the developer that, at best, is restrictive. I'm all for standards (who isn't) but only where they make sense. What we've found with Mule is you can never second guess what the next man's integration problem will be. By restricting the way integration applications can be built with rigid APIs, predefined/xml message formats, predefined tooling and methodologies, etc, you end up holding back the developer and ultimately become part of the integration problem.

    Mule can currently consume and dispatch events to JBI NMRs and you can embed Mule components, endpoints and transformers inside JBI. We may one day have a JBI model for Mule where you can deploy SEs and BCs alongside other Mule components, but we really haven't seen any demand for it.

    Cheers,

    Ross
    Hi Ross, many thanks for your answer. A generic problem of the IT-Standards is - many Solution-Provider has the compulsion to provide their own abstraction of the Standard ;-) One of the great goals of the Service-oriented Architectures (SOA) are the Independeny from Manufacturers, Solutions and more then all, the re-use of services or components. In my personally opinion (we are working with many different Integration-Solutions in different areas) is the Standard JBI an excellent solution in this direction, which permits a good level of abstraction by the development of generic Business- and Technology-Components for different Integration-Areas. For this reason we prefer to integrate in our projects some of the Open Source Solutions which supports the Standard JBI – as far as the structure and preferences of the customer make this really possible. Roland
  17. Hi Roland,
    A generic problem of the IT-Standards is - many Solution-Provider has the compulsion to provide their own abstraction of the Standard ;-)
    Ironically, this is often because the Standard didn't recognise all the usages of the technology it was standardizing. The reason why HTTP is a good protocol standard or Jms is a good messaging standard is because their problem domain is clearly defined and the applicability of the technology is well-understood. On the flip-side, defining standards of how services should integrate together is extremely difficult because the problem domain is difficult to define (no two enterprises have the same integration problem) and the applicability of the technology is so varied its impossible to second-guess they kind of integration people need to do. So JBI addresses as sub-set of problems and JBI vendors wanting to achieve more will have to work around the JBI API in order to provide more functionality -- and there is the 'compulsion to provide their own abstraction of the Standard'.
    One of the great goals of the Service-oriented Architectures (SOA) are the Independeny from Manufacturers, Solutions and more then all, the re-use of services or components.
    I think the reuse story is similar to the EJB reuse story, lets not go there :) Also, It looks like every JBI vendor have written their own JMS, HTTP, SOAP, (insert more here), Binding components...
    For this reason we prefer to integrate in our projects some of the Open Source Solutions which supports the Standard JBI – as far as the structure and preferences of the customer make this really possible.
    Mule does support JBI it just doesn't force you down that route. You can host Mule components in JBI and Mule applications can communicate directly with JBI containers. The forecast for Mule is to remain agnostic to JBI but strive to provide the easiest, robust, secure and intuitive integration with JBI and SCA as well as the raft of 30+ other transports and technologies we already support. Cheers, Ross
  18. Hi Ross,
    A generic problem of the IT-Standards is - many Solution-Provider has the compulsion to provide their own abstraction of the Standard ;-)

    Ironically, this is often because the Standard didn't recognise all the usages of the technology it was standardizing.

    Ok, I agree - but maybe sometimes the causes are also situated in some comercial reaons ... --

    One of the great goals of the Service-oriented Architectures (SOA) are the Independeny from Manufacturers, Solutions and more then all, the re-use of services or components.

    I think the reuse story is similar to the EJB reuse story, lets not go there :)
    Maybe in this theme our opinions distinct a bit. That's a case, which depends deeply by the architecture design and their real abstraction level - independly of SOA, EJB or other Architectures/Standards. But first of all, the theme Service-oriented Architectures (SOA) must primary be started by a level, which is situated on the real Business Logic and secondary by their technology parts. Service-oriented Architectures are existing in some excellent and abstract architecture designs, which was created time before the term „SOA“ has become their today relevance. The Service Infrastructure of this Designs permits a functionally re-use of the well defined external and internal Services and Components (maybe realized also with EJB ...). Unfortunately are in many cases not the architects or the other involved professionals the decider of the terms and forms, how must be implemented a Service-oriented Architecture in a global Enterprise ... -- Good ..., now return to Mule ... I think, for the moment provides Mule, with their support to multiple Protocols and Standards, also an excellent base to be a stable and mature integration solution and tool. We will take a more intense, personally look to the potentialities of Mule in the real integration facts, by the next time. For the moment, good Luck and great success for Mule and their hardworking Team. Cheers, Roland
  19. I think, for the moment provides Mule, with their support to multiple Protocols and Standards, also an excellent base to be a stable and mature integration solution and tool.

    We will take a more intense, personally look to the potentialities of Mule in the real integration facts, by the next time.

    For the moment, good Luck and great success for Mule and their hardworking Team.

    Cheers,
    Roland
    Thanks Roland, I hope I'll be seeing more of you in future :) Cheers, Ross
  20. ..., I hope I'll be seeing more of you in future :)

    Cheers,

    Ross
    At the moment we are in the final technical stages, to provide our Information & Collaboration-Portal with their new Look and extended Information Strategy - which will start in some weeks ago ... With this Portal, we will provide an extended Information & Discussion Platform, which is concentrated exclusively to the Areas of Service-oriented Architectures (SOA) and Integration, from an independently, professional Technology- and Business-View. By the first time, concentrated to the German speaking Community (Germany, Switzerland, Austria,...) - Extensions to support also the English and Spanish Languages (Hola amigos en España, Latino America y el resto del mundo) are planned for the near future. I think, that's a appropriate site, to describe also our future practical expierences with Mule and naturally all the other associated, important Technology- and Business-Themes. Naturally I will insert also some of this experiences in the interesting discussions here by TheServereside.com and some other sides. Cheers, Roland http://www.soa-competence-network.de
  21. Another victory for heavyweight lightweights! Even at such an early stage of development we have found Mule to be a very capable and intuitive system and luck forward to it's continuing success. Well done to all the team and Ross especially. It's nice to see all the honest kudos for this product. Neil Ellis (Currently at Rabobank International (UK) :-) )
  22. Re: Mule 1.3, open-source ESB, released[ Go to top ]

    Thanks for the kind words. I must say that I am blown away by the user responses! A big thanks has to go the Mule team and the active community, they have really helped evolve Mule in the right direction with tireless coding, suggestions, bug fixes and module submissions. Keep it coming!
  23. Re: Mule 1.3, open-source ESB, released[ Go to top ]

    Greeting Ross, This is indeed a major milestone. I was inspired by the Mule approach to handle very complex messaging scenarios in yet a simple and intuitive way, leveraging declarative and POJO based approach. The variety of integrated transports and the flexibility of the model was one of the major things that attracted me to look into this framework. I found it to be a classic solution for those who want to build SOA based applications for high performance environment without being limited to WebServices. During the work on the JavaSpaces support we also discovered that the potential of using the two together can be extremely beneficial for SOA enablement of highly scalable, mission critical applications. Those who are interested can find references for that work under the following links: Mule/JavaSpaces support Or GigaSpaces Mule Plug-in Good luck Nati S.
  24. Hi first congratz on the release! Now here's come the newbie question since I haven't had the chance to give a try to Mule or ESB in general : How does Mule (or ESB in general) relate to OSGi? I mean I am not a specialist of SOA but there seem to be some overlapp between those 2 technologies and I am hearing more and more of those buzzwords. So if anyone could give me some pointers, I would appreciate!
  25. Hi Alexandre, OSGi features heavily in the Mule 2.0 roadmap (which we're looking to make more public now 1.3 is out the door). Also the work that the Spring guys are doing in this area will be very complimentary to the way Mule will use OSGi. Cheers, Ross
  26. Congrats !! to Mule Team and Ross[ Go to top ]

    Congrats to the Mule Team!! Excellent work. I am recommending mule as the ESB for our organization. I had only one stumbler, the name Mule. The marketing and management were not convinced of a product called Mule could provide quality product. May be you should re consider changing the name to eMule or something.
  27. Congrats to the Mule Team!! Excellent work. I am recommending mule as the ESB for our organization.
    ...
    I think, a lot of the today available ESB-Solutions providing important features destinated to Service-oriented Architectures and Business Integrations. For me personally its always very important, to hear from the different opinions of the professionals in distinct areas or organisations. May I ask, what are the concrete advances of Mule which are the cause of your personally consideration ? Nice to hear also some other associated opinions from interested peoples. Roland http://www.soa-competence-network.de
  28. Hi Roland Some of the advantages I have seen are: 1. Lightweight POJOs - The vast majority of the work you do is with POJO transfer objects and POJO services. No framework wiring etc. This leads of course to potentially low coupling, excellent reuse opportunities and easy to understand/maintain code. 2. Intuitiveness/Simplicity, okay I think there are a few steps needed to complete this in Mule, but it is still a winner. There is a an attitude of simplicity in the configuration of Mule and to me that's it's killer feature, it's so simple to rewrite an in memory queue into a JMS Queue, to send an additional copy of a mesage as an email, add a web service endpoint; often by just changing a URL. This simplicity of course translates into maintainability. The only weakness I have seen is the support for message object properties is quite weak and inconsistent in 1.3. But basically if you dig Ant you'll dig Mule for much the same reason - so little does so much. 3. Extensibility, Mule is _fantastically_ extensible, in the same way Spring enables more than it restricts, Mule allows you to provide implementations of just about anything. The weakpoint here is that the configuration of transports seems a little verbose, but everything else is a doddle. 4. Zen. Mule has tuned into the Spring/Ant Zen, the way of Mule is the way of Spring and the way of Ant. If you are in the Zen of Mule, anything is possible ;-) So from my limited experience of Mule so far, these are the things that have sold me. Kind regards Neil
  29. Hi Neil, many thanks for your extensive and very interested description. I agree, that all points are very good reasons for a decision to a solution - above all, when this solution is coming from the Open Source Areas. But I think, some of the points - maybe all - are also provided in some other Open Source Solutions, how e.g. Apache ServiceMix - whose Development Team is also providing an excellent work. Roland
  30. Hi Roland, There are a wealth commercial and proprietry solutions out there, that claim to solve out integration problems in a variety of different ways. I would always put the emphasis on choosing the technology that has a strong production-use track record and fits the needs of your organisation. Mule is a mature (it's been around for 3.5 years now) integration platform that's being used by a number Fortune 50 companies and many more Fortune 2000 companies. I welcome the alternatives as is drives innovation but when building core integration or SOA applications you need to back the right horse :) Cheers, Ross
  31. Re: Congrats !! to Mule Team and Ross[ Go to top ]

    Ha! love or hate the name you never forget it. Probably best you don't include your marketing department in your technology adoption process :) Cheers, Ross
  32. Re: Congrats !! to Mule Team and Ross[ Go to top ]

    Ha! love or hate the name you never forget it.
    Probably best you don't include your marketing department in your technology adoption process :)

    Cheers,

    Ross
    Management is good candidate for exclusion too.