Discussions

News: CodeHaus releases Mule 1.0, an open-source ESB

  1. The Mule team is very pleased to announce that version 1.0 has been released!

    From Mule's project page:
    Mule is an Enterprise Service Bus (ESB) messaging framework. It is a scalable, highly distributable object broker that can seamlessly handle interactions with services and applications using disparate transport and messaging technologies.

    Core features include:
    • Pluggable connectivity, including JMS, embedded transport, JDBC, TCP, UDP, multicast, HTTP, servlet, SMTP, POP3, file, and XMPP
    • Web Services via Axis or GLUE
    • Flexible topologies
    • Declarative and programmatic transaction support, including XA
    • REST API for web-based access to Mule events

    Notable in this release:
    • JCA 1.5 Resource Adapter - for easy deployment in J2EE 1.4 compliant Application Servers
    • IBM AS400 Data Queue support - for easy integration with IBM AS400
    • PGP Security - PGP message signing and encryption
    • Improved exception management - consistent exception hierarchy, better reporting and internationalisation.

    Threaded Messages (35)

  2. Interesting...[ Go to top ]

    Looks pretty exciting.It seems UMO is inline with eGate's e*Way(collaboration)concept. First glance at the documentation says that an UMO can be a POJO which is initialized by the Mule Engine.

    Does it have an inbuilt JMS server? Can this be plugged with other JMS Servers/Products? Is the load balancing of Mule Servers supported??

    Thanks,
    Rabi
  3. Maven[ Go to top ]

    Does it rely on Maven? Anytime I see Maven my eyes glaze over, it killed Geronimo for me :-)
  4. Maven[ Go to top ]

    It does use maven <glaze/> but our build is stable. I've had problems with maven in the past, but when we moved to Codehaus one of the guys there pretty much rewrote the build for us and now its solid.

    Cheers,

    Ross
  5. OpenAdapter[ Go to top ]

    It would be nice if mule had an interface to OpenAdapter http://www.openadapter.org/, or vice-versa.
  6. if only...[ Go to top ]

    it was an open-source Extra Special Bitter.
  7. if only...[ Go to top ]

    Its Extra Special, but it ain't bitter!
  8. what is it exactly?[ Go to top ]

    actually i cannot figure out what it is exactly? is it a message system like jms?, does it provide something like JGroups...... or what
    can we use it for reliable multicast to implement clustering or node replication easily
    thanks
  9. what is it exactly?[ Go to top ]

    actually i cannot figure out what it is exactly? is it a message system like jms?, does it provide something like JGroups...... or whatcan we use it for reliable multicast to implement clustering or node replication easilythanks
    As far as I can tell, it provides an abstraction to make it easy to use various messaging technologies (JMS, e-mail, web services, etc) in a consistant and integrated manner. For the most part you provide the message handlers and use configuration files to specify which services are used as input and output.<br>It tries not to provide the actual messaging services themselves. Although it does provide a few simple ones like in-memory and the console. It integrates with JMS, Axis, GLUE and other messaging technologies that don't need to be reinvented. It doesn't appear to support JGroups, but I think JGroups would be a perfect candidate to integrate into the system.
  10. what is it exactly?[ Go to top ]

    but I think JGroups would be a perfect candidate to integrate into the system.

    I agree, I would liked to have JGroups support for v1.0. Mule Transport providers a pretty easy to implement and the Mule community have already started to sumbit new transports to the project, so I think it will only be time before we support JGroups. Of course you could always have a go ;-)

    Cheers,

    Ross
  11. Here's an article[ Go to top ]

    Here's an article explaining mule. It seems to be a project that integrates several frameworks together that you would need to use in an enterprise application, and provides a way to integrate them cleanly and consistently.

    Also, provides a consistent way to source events from Servlets, WebServices, JMS, XMPP protocols etc.

    Seems really useful...

    http://www.devx.com/enterprise/Article/26680/0/page/1
  12. what is it exactly?[ Go to top ]

    Have a look at the Introduction page.
    http://mule.codehaus.org/Introduction

    It should explain the core concepts for you

    Cheers,

    Ross
  13. re: what is is exactly?[ Go to top ]

    Ross:
    I have some servers made in Java that do small request/do something/response protocols over a plain socket. Can I do the same with mule? What would be the advantages? I suppose that I can replace 10 server process with one mule server administrable with JMX. Please correct me if I'm wrong. I looked at the introduction and still not sure. I would like to know more about the posibilities of mule because it seems very interesting.
  14. re: what is is exactly?[ Go to top ]

    Mule supports a variety of topologies including client/server. Essentally, you drop your service object into Mule, configure an inbound endpoint on the service and Mule will handle servicing the request and passing the response back. The client doesn't have to be Mule though the MuleClient makes light work of sending data over any protocol (see http://mule.codehaus.org/Mule+Client).

    Ping user at mule dot codehaus dot org if you have any problems.

    Cheers,

    Ross
  15. JBI[ Go to top ]

    Ross,
    Does Mule have any plan to support JBI(JSR 208)?

    Alireza
  16. JBI[ Go to top ]

    Ross,Does Mule have any plan to support JBI(JSR 208)?Alireza

    It is certaining something high on our agenda to investigate.
  17. JBI[ Go to top ]

    Ross,Does Mule have any plan to support JBI(JSR 208)?Alireza
    It is certaining something high on our agenda to investigate.

    FWIW there is already an open source JBI container with Mule support, called ServiceMix

    James
  18. Interesting. I have been working on something similar over the last 2 months or so ( http://sourceforge.net/projects/infonatural-esb/ ), and wasn't aware of this effort.
    Seems however that the design decisions have differed slightly:
    I have gone for a more compact but pluggable design to be embedded either in EAR's or other applications (around 2000 LOC's in 50 implementation classes/interfaces in total so far), whereas Mule has gone for (Note! on first 2 minute browse.) a full server mode and lots of bells and whistles from the get-go (but still highly pluggable).

    Probably down to usage-scenario and taste what you need and prefer..

    I will definitely have a more in-depth look to understand the thinking behind it and see what I can learn, or even contribute.
    Hey, isn't cross-breeding of ideas, both ways one of the primary benefits of open source? I'm into learning and growing, not "bashing" of thinking other than my own..
  19. I've been playing around with Mule now for a couple of months, and I have to say it beats the ##@! out of IBM's integration/ESB solution that I am implementing at work. To really get a feel for the power of Mule you have to download the examples and look at the Loan Broker example. The Mule team has done an incredible job of giving us a real life bsiness example (not just the useless Hello World). The beauty of this example is the various configurations that show how to use the full capability of the different Mule transports. You can do the same example using web services (Axis), or jms, or tcp, udp, jdbc, VM, HTTP, servlet, Synchronous, asynchronous, or a combination of any. Whew! Great job. And the Mule Client makes using the underlying routers a snap. This is a developer's dream.
  20. Cheers John. This is one for the testimonials page ;-)

    Ross
  21. I've been playing around with Mule now for a couple of months, and I have to say it beats the ##@! out of IBM's integration/ESB solution that I am implementing at work.

    John,
    are you talking about the SIBus embedded into WebSphere V6. (since there are so many ESBs under the WebSphere umbrella ;-)
    If yes, the concepts seem similar from 30,000 feet: multiprotocol access, MOM-style transport, mediations/transformers ...
    Where is the fundamental difference?
    Jacques
  22. Congratulations to the Mule Team!

    Thanks for your great product, I know mule from a couple of months ago,
    I've studied its architecture and source codes, Personally I believe that its the best
    open source product for integration issues,
    You can see the real Flexiblity, Pluggability, Transparency,...

    Good Luck
    Alirez Taherkordi
    Http://www.taherkordi.com
  23. this has just saved me a job, great work, excellent documentation too
  24. Question[ Go to top ]

    I red documentation for a moment however I'm little bit confused. I understand flexibility behind, however from what I red I have got feeling that my UMO objects have to be ONE METHOD services. Is this correct?
    In my services I HAVE TO use MULE classes and interfaces, don't I?
    Is it possible to have my services little bit more decoupled from MULE interfaces?

    TNX
  25. I think that every class that is exposed as an endpoint using a transport on the bus, can have multiple methods published.

    If you look at the Spring events example:
    glue:http://localhost:44444/mule/OrderManager/processOrder

    publishes the processOrder method as an endpoint.

    Thus, you could have other methods also published as endpoints. I think its just that you have to configure every method separarately.

    Glue or Axis on the other hand, allows you to publish the entire interface/class as a WebService.
  26. Question[ Go to top ]

    I understand flexibility behind, however from what I red I have got feeling that my UMO objects have to be ONE METHOD services. Is this correct?

    No, a service can have multiple service methods. The service container has an EntryPointResolver that is used to determine what method is called on a service on an event-by-event basis. The default behaviour works out the method to call based on the payload type of the current event. Like everything else in Mule, this EntryPointResolver is pluggable, so other implementations could be used. An obvious option would be one that used Annotations to detemine the method to invoke.
    In my services I HAVE TO use MULE classes and interfaces, don't I?Is it possible to have my services little bit more decoupled from MULE interfaces?

    You don't need to use any Mule interfaces to send and receive events. for inbound message the method to call on your service is worked out by the EntryPointResolver, outbound message flow is controlled by the outbound router configured for the service. The examples often use a Mule interface as it makes it easier to understand where the event data comes from for newcomers.

    One of the major goals of Mule was to create a service environment that-
    a) didn't impose itself on the object it manages (zero code intrusion)
    b) removes any repetitive 'glue-code' and isolate any non-business related code, such as transformers, into reusable objects.

    Cheers,

    Ross
  27. Mule vs. OpenAdapter[ Go to top ]

    This does look very promising. I've looked at OpenAdapter before as a possible integration solution. Would someone in the know explain the differences between Mule and OpenAdapter?

    Thanks,

    Rong
    http://rongou.blogspot.com
  28. Mule vs. OpenAdapter[ Go to top ]

    Would someone in the know explain the differences between Mule and OpenAdapter?Thanks,Ronghttp://rongou.blogspot.com

    I'm no expert on OA but I think that a big difference is Mule is also a container. In Mule, all container-managed objects communicate via endpoints, whereas Open Adapter just provides the endpoints. The Mule container is SEDA-based so it is robust and scalable, and manages all component services such as pooling, threading, management, security, etc.

    In future, I see Mule being able to utilise OA adapters rather than the two projects competing.

    Cheers,

    Ross
  29. very interesting[ Go to top ]

    This project looks *extremely* interesting to me. There a couple of questions I couldnt find the answer to on the website.

    How long has the project been going? How did it start?

    And who is using it at the moment, on what kind of projects?

    These are definitely the kind of question people ask when evaluating a new technology.

    cheers
  30. very interesting[ Go to top ]

    good question, been trying to integrate into a project using programmatic configuration, but the documentation on the site is invalid. has anyone else managed to get it working?
  31. very interesting[ Go to top ]

    like all good projects it started in the my basement a couple of years ago ;-)

    For more information about who is using Mule and how try the mailing list (mailto:user at mule dot codehaus dot org). We are setting up a services and support company for Mule in the next couple of months; this should surface some user case studies soon.

    Cheers,

    Ross
  32. very interesting[ Go to top ]

    like all good projects it started in the my basement a couple of years ago ;-)

    Your basement could be worth a lot of money .. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  33. Why ESB?[ Go to top ]

    Hi Ross,

    Nice framework. But I why do you think it should be termed as an ESB?? Does the services are self describing and can be discovered by any one? How different is it from a Message Bus?? Architecture document talks about asyncronous inetgration which are done in two different threads (Receiver and Dispatcher) where the messages from the receiver are queued in the SEDA queues?? Could you please elaborate on this?? Are the messages stored in memory?? What is the revovery mechanism of the messages when the server fails.

    Thanks,
    Rabi
  34. Why ESB?[ Go to top ]

    Nice framework. But I why do you think it should be termed as an ESB?? Does the services are self describing and can be discovered by any one? How different is it from a Message Bus??

    Actually, ESB in my opinion is a service topology in that it is a well-trodden architecture for integrating disparate applications using a common interchange format (almost always Xml). To that end Mule is not an ESB as it can provide more flexible architecture, but I use the ESB term for marketing Mule as people know or at least have heard of it.

    Mule is actually an Enterprise Service Network (ESN) platform where services can participate in applications that use a variety of topologies such as client/server, peer-to-peer, ESB, hub and spoke or a mixture of all these - ESN. We currently don't say this from the outset because most people don't know what an ESN is yet :)
    Architecture document talks about asyncronous inetgration which are done in two different threads (Receiver and Dispatcher) where the messages from the receiver are queued in the SEDA queues?? Could you please elaborate on this?? Are the messages stored in memory?? What is the revovery mechanism of the messages when the server fails.
     
    The SEDA Model used by Mule uses event queues between components (when running asynchronously) to improve throughput. These queues are persistable so that the server can recover after a crash.

    However, The model used by Mule s pluggable so it's possible to switch out the SEDA stuff so not to use event queues at all (The Mule JCA Resource Adapter exactly this). The point of having pluggable Models is that other execution models can be used to fire interactions between components. In future, we may have BPEL model where interactions between components (through endpoints) is managed by Mule but the components and processing logic is handled by a BPEL engine.

    Cheers,

    Ross
  35. Why not use a BPM Engine?[ Go to top ]

    I have been examining several different ESBs(Sonic, Mule, ECT) and reading Chappelle’s book on ESB.

    However I still have few questions regarding ESBs(specifically Mule) and how it would compare functionally to a BPM(BPEL) Engine.

    1.) What are the differences between the Mule concept of a "Model" and a Business Process defined in BPEL.

    2.) With the traction that BPEL standard is getting wouldn't it make more sense to define Business processes in a standardize language?

    On last question?
    3.) What are the pros and cons for using Mule(or any ESB) within an app server?

    Regards,
    TGibson
  36. Why not use a BPM Engine?[ Go to top ]

    1.) What are the differences between the Mule concept of a "Model" and a Business Process defined in BPEL.

    Potentially, not very much. As mentioned im my previous post, there will most likely be a BPEL model for Mule that defers all service management to BPEL an Mule would handle data interactions between the services.
    2.) With the traction that BPEL standard is getting wouldn't it make more sense to define Business processes in a standardize language?
    It definitely makes sense to support the BPEL standard but not everyone wants or even can expose all their services using web services to be managed by BPEL. Mule can help here by providing an easy way of automatically exposing existing business object/services using soap endpoints. I think Mule and BPEL are complimentary in that Mule is concerned with the transport, routing and transformation of data where as BPEL defines the a way of working with services to build coherent business processes. The two would make a powerful combination.

    An additional question:
    3.) What are the pros and cons for using Mule(or any ESB) within an app server?

    Well above and beyond ESB capabilities for interfacing, delivering, transforming and routing data, Mule can be managed inside an AppServer. This means that -
    a) Mule resources can be managed by the AppServer
    b) Mule can adopt the lifecycle of the app server
    c) EJBs can send a receive events by subscribing of publishing to Mule endpoint URIs. This means the Mule ResourceAdapter acts as a TCP, SMTP, SSL, XMPP Resource Adapter inside the App Server. Really it's a Universal Resource Adapter.

    Cheers,

    Ross