Discussions

News: Learning More About ESBs and SOA Development at Mulecon

  1. Held at the Hilton Hotel in San Francisco over 2 days, Mulecon attracted approximately 400 delegates, including Mule staff. I was very glad to go as the conference let me talk to several Mule ESB users. I had to do a fair amount of begging to get an invitation since PushToTest is the author of the SOA Knowledge Kit, a TIBCO commissioned comparison of commercial SOA/ESB development platforms. (PushToTest will be an exhibitor at TUCON later this month, and I might be in their keynote session.) Maybe someday I will be appointed an ambassador to something. :-) The presentations varied between Mule staff talking about Mule and the product roadmap and customers talking about their use of Mule. The Mule staff seemed to be singing from the same songbook: Mule claims 13,000 deployments of Mule ESB, Mule 2.0 is not compatible with 1.4 but the migration should not be too difficult as the concepts are the same, Mule Enterprise Edition, Saturn and Mule HQ releases coming late this year. A Room Full of Architects It did not take long for me to realize that Mulecon delegates are mostly software architects. Typical questions I heard goes like this:
    • "Your company inherits a big bank and needs to decide between JMS and Advanced Message Queue Protocol (AMQP) for a universal protocol for your bank. Which would you pick?"
    • "How do you empirically come to a model that will let you uncover the performance characteristics and measurements?"
    These are the kinds of discussions that make my wife immediately yawn and roll her eyes! Geeks, there's a lot of 'em in this room. ESB, Grid, AMQP Approaches Conversations about hub-and-spoke, virtual circuits, and bus architecture seem to be over. Just about everyone I met expects a heterogeneous architecture where parts of a system are hub-and-spoke and others are bus-based. Easy service interfaces now exist between each type of architecture using daemons and local brokers. Jahan Moreh, VP of Engineering at U1, had a very basic message: "Provided the underlying products are good you won't have a problem." Jahan was more sanguine about guaranteed delivery and performance. In essence, "performance and guaranteed delivery are in conflict." Choose one but don't expect both. I very much want to do primary research to determine a standards way to profile performance in a guaranteed delivery setting. Hopefully one of our customers will commission a PushToTest study. (hint, hint.) I learn about AMQP at Mulecon. AMQP is a protocol-level standards initiative to provide a messaging infrastructure. Jahan told me, "AMQP tries to do something very important but may not be attainable. Because they are at the protocol level they may wind up being extensions on the side. I would bet on the JMS side." POJOs Rule, But Where Is BPM? Eugene Ciurana of LeapFrog gave a talk about LeapFrog's use of Mule. I just saw Eugene at TheServerSide.com Java Symposium in Las Vegas last week. Boy does Eugene get around! LeapFrog is marketing a child's toy that features downloadable content – not bad for products that must cost less than a few dollars to manufacture! The backend system to support this effort uses ESB technology to provide flexibility to LeapFrog's software developers and reliability in operating the service and applications. Many of the question-and-answer sessions at Mulecon include a question on Business Process Management (BPM) such as: "What are you doing for BPM in your architecture?" Eugene took one of these. This question echoes what I had learned in Las Vegas: Java architects and developers are frustrated looking for Business Process Management (BPM) standards and tools. Brian Sletten's talk at TSSJS was titled "Avoiding ESBs" but could have been better described as "I'm sick and tired of waiting for vendors to give me a decent Business Process Management (BPM) platform!" At Mulecon, Rory dela Pax of Biogen Idec, told me that "Mule is good at doing some workflow. But, all of us are struggling with BPM. We do a separation of skills strategy rather than overloading the ESB with these tasks." Over the years I have seen most of the platform vendors try to provide the Java development community with set of products, best practices, framework, and code to implement applications that deliver business flows. I am specifically remembering the failures of JBI, JEMs, BPEL, SCA, and WS-*. None have come together to offer a standard. I sense a lot of anger and disappointment at all the failed attempts. Mostly disappointment from me. [Editor's note: and me.] Eugene answered the BPM question by telling the delegates that LeapFrog pushes all of its development to Plain Old Java Objects (POJOs.) They actively separate every application from each other. LeapFrog then uses Mule routers to define the inputs and outputs. Eugene said, "We are not doing any transactional data at Leapfrog. Our support is for the toy devices." He added that Leapfrog has a separate side of the IT house for Oracle tools and BPEL. Mule and Clustering Rory dela Pax of Biogen Idec gave a brief talk on their migration from BEA WebLogic Integration (WLI) to Mule. The migration came about like many companies adopting an open-source project: A developer mentioned it during a water break conversation. The environment was ripe: Biogen Idec found WLI to be "a bit on the heavy side, unstable, and has not scaled well." They were also leery of the rumors of the Oracle buy-out since late 2006. They found that Mule has a one-for-one match in capabilities, plus they see Mule as lightweight, stable, and scalable. I can understand lightweight and stable, but the scalability claim seemed to need some proof. Rory tells me they achieve scalability by using WebLogic Server (WLS) 8.1 SP6's clustering. They deploy their Mule application as a WAR file in a cluster of JVMs in WLS. There are no separate JVMs in their environment. I imagine the gall the WLI product manager must feel at being swapped out. :-) Still, there is a lot that Biogen Idec needs to learn about clustering. They still need to define the best way to cluster. Rory told the delegates, "We don't know how to do that." They would like to define clustering methods in environments where message sizes grow larger. Right now their application uses simple verb+link combinations. The incoming request is to approve an invoice and the response contains a link to bring the user's browser into the application. Rory told me some of the downsides to using this WLS clustering approach. For example, they use Quartz as a scheduler. In this WLS clustering set-up changing the Quartz schedules means redeploying the application to the cluster. Moving Up To Mule 2.0 Mule 1.4 uses DTDs to define pretty much everything – settings, configuration, deployments. Mule 2.0 delivers XML Schema-based configuration that leverages Spring's "Extensible XML Authoring." The result is less cumbersome class names because of namespace support. They are updating their Eclipse support to provide auto-completion and context-specific help. Mule 2.0 features transport-specific endpoints and connectors and now everything is done through typed properties. There is a lot of extensibility because each module/transport comes with its own schema. Mule 2.0 lets you implement your own schema too. Some additional changes in Mule 2.0: CXF supercedes XFire (XFire is still available,) there is a new expression evaluator framework, streaming improvements, auto-transformation, and lots of bug fixes. Plus, Mule 2.0 has 30% more unit tests over 1.4. Mule uses Spring to implement Beans. Mule uses session and entity (data) beans inside the Mule container or through proxies to external data services. Mulecon left me a few questions:
    1. How important was the Spring-based approach to building services to Mule's popularity and success?
    2. Is anyone, I mean anyone on Earth, using OpenESB from Sun? None of the Mule users had any experience with it. [Perhaps the better question is: is anyone willing to admit it? At MuleCon, of course, you've a largely self-selecting group that doesn't use OpenESB...]
    3. How are Mule and Mule users testing Mule for scalability and performance? Mule 2 provides hundreds of unit tests but apparently no performance tests, at least none that I could find.
    4. What are the tradeoffs of an ESB versus Gigaspaces, Tangosol and other grid environments?
    Mulecon impressed me with its quality presentations and delegates. I will keep it in mind when PushToTest does its first user conference, PTTCon, or PushCon, or TestCon, or who knows!? [Editor's note: I suggest 'PTTui!'] -Frank Cohen http://www.pushtotest.com

    Threaded Messages (19)

  2. forgot: proprietary[ Go to top ]

    Frank, excellent re-cap, and good marketing for the Mule guys...cheap shot on openESB, when the better question, and maybe what you meant, is anyone implementing using JBI... the question i have for Mule and all ESB vendors is how is it different than EAI, how does it offer non-lock-in value to customers without JBI?... all this blah-blah SOA banter means absolutely zero to everyone, that much has been established, what is needed as has been established with JEE vendors, is a standard to track, follow, and implement, so that customers know they can rip-and-replace without massive pain... am i the only 1 who sees it this way?
  3. maybe what you meant, is anyone implementing using JBI... the question i have for Mule and all ESB vendors is how is it different than EAI, how does it offer non-lock-in value to customers without JBI?... I shouldn't have worded my question about OpenESB so strongly and specifically as I have nothing against it as an open-source project. But I don't see OpenESB simply as a JBI implementation either. It would be great if the ESB vendors would work together on a standard to track, a blueprint to an ESB application to which we could all compare our designs, and a standard that enables us to switch platforms with ease. But get real! We have had the opportunity for that kind of vendor collaboration for years and it is not happening. It may be that vendor-lock-in is not such a big deal. The ESB using delegates I met leave me with an impression that adopting multiple ESB platforms is ok. Most PushToTest customers have multiple application servers running in their datacenters. So why not have multiple ESBs? -Frank
  4. comprehensively disagree[ Go to top ]

    I must admit I have never been on the buying end of an enterprise software decision, but vendor lock-in will continue to dog Mule and others' attempts to gain traction, and because of that my money is on JBI-implementations to end up as the most heavily adopted ESB platforms... Again, i will repeat, am i the only 1 thinking that this proprietary approach is a recipe for customer avoidance? i heard your perspective, frank... IMO, the center of the ESB universe: http://jcp.org/en/jsr/detail?id=312
  5. Re: comprehensively disagree[ Go to top ]

    Hi Douglas,
    I must admit I have never been on the buying end of an enterprise software decision, but vendor lock-in will continue to dog Mule and others' attempts to gain traction
    Unfortunately, the only runners dogged in this race are those that embraced JBI. I have expressed my views on JBI to you before, though I admire your tenacity to keep gnawing on this old bone. But even the JSR-312 expert group will tell you that JBI got it wrong; too-focused on the vendor, nothing for the user to work with, Xml-centric, typical JCP API heaviness, etc. Tell the guys that spent a year building a JBI implementation that it was a good idea. They will have to migrate to JBI 2.0 to compete. They may tell you that not all “standards” should be embraced with careful consideration. I had some good conversations with Peter Walker (co-lead) about joining the expert group for JSR-312. I appreciated the community spirit of Peter reaching out but I felt the direction wasn’t compelling enough. It seemed to be going in a similar direction. We talked about OSGi and SCA support and that these may be weaved into the specification. While I think this is a good idea I don’t think it’s up to a standards committee to define how to build a server. The important pieces are those that interact with external systems and users; that are the connector architecture and configuration. I think SCA is a much better approach to the SOA/Integration problem because it unifies the configuration of SOA systems. Why is that good?
    • A standardized configuration means that developers don’t need to re-learn how read/write configurations.
    • It becomes possible to build tooling that can be used by all products that support the standard.
    • we start working towards a common vocabulary of terms in this space, which is much needed.
    I blogged about this need from an API perspective recently. Just to be clear, we are seeing exponential adoption of Mule (both users and customers). What really matters to organisations is that the software works, is battle tested and the feel confident that they can run their business on the software. Our users and customers get that with the Mule. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  6. re: tired[ Go to top ]

    Unfortunately, your view, Ross, is that a standard is an old-bone that you have to deal with, and I acknowledge the possibility that the world addresses the standards-issue with SCA, but I honestly have no idea what your p.o.v. is on not supporting JBI... "typical JCP API heaviness" is easily translated by discerning customers as meaning that you don't think that what has been done with Java is effective, even in the face of uncountable evidence to the contrary: who exactly are u selling Mule to? i can only assume that u r running from JBI because of openESB, even as Frank throws u an inflammatory bone in his initial post, about its supposed irrelevance...the conclusion i come to is that Glassfish/JBI/(MySQL) are beginning to consolidate the leadership of implementations for a standards-based integration platform... I am so tired of listening to Matt Asay, Dave Rosenberg, and the rest of the purported OSS cabal declare victory based on thousands of downloads...call me when u reach an inflection point of penetration that suggests customers are supporting products even when it is proprietary, because unless I am completely off, that will never happen, unless u r acquired by MSFT.... "exponential" is actually a mathematically derived statement that u should understand, and does not mean mere growth, what is it about what the application server market achieved so insidious to you non-JCP zealots, just sign-up, implement, and compete, if i am a customer, that is question #1 on the RFP... hiding behind religion, Spring, F.U.D., and back-slapping among cohorts is no replacement for running a business that actually scales, sustains, and provides customer value...
  7. Re: re: tired[ Go to top ]

    Douglas, You're sounding bitter and a little desperate. We honestly never see OpenESB in engagements, I don't know what else to say, except there is nothing to run from. Do you have some visibility into customers that use OpenESB? Who do they get support from? I haven't been able to find any information except that Sun do NOT support OpenESB http://www.pymma.com/eng/People/Blog-Paul-Perez-Chief-Architect/JBI,-Open-ESB-and-JCAPS. In fact they choose to support JCAPS, which is not based on JBI.
    Unfortunately, your view, Ross, is that a standard is an old-bone that you have to deal with, and I acknowledge the possibility that the world addresses the standards-issue with SCA, but I honestly have no idea what your p.o.v. is on not supporting JBI...
    Apart from the issues that I've already posted on previous threads with you, the fact that JBI 2 is planning to be a re-write of JBI is a telling sign that I made the right decision not to pollute Mule with JBI (besides that fact that JBI only addresses a sub-set of problems that Mule provides solutions for). I certainly have nothing against the JCP, but it does sometimes feel like a free-for-all where standardisation, innovation, vendors and developer egos mix uncomfortably.
    hiding behind religion, Spring, F.U.D., and back-slapping among cohorts is no replacement for running a business that actually scales, sustains, and provides customer value...
    Right now it seems OpenESB doesn't have any customers, there is nothing to buy. There is no customer relationship to nurture and sustain or provide value to. I am missing what your stake is in all this. Is there nothing good on telly? Cheers, Ross Mason MuleSource http://blog.rossmason.com
  8. re: rewrites[ Go to top ]

    I re-read my post, and admit that i may have come across as frustrated, apologies, if that is what u need...i would assume that openESB is currently second-tier in the integration offerings from Sun following SeeBeyond, but unless I am missing something, SB platform will continue to have to be revised to track customer requirements, just like Mule... Your sole and vaunted reason for not joining the JCP, for not supporting the JBI spec., and for de-riding openESB is the re-write issue, which i, as a non-spec. lead/non-implementer will take u at your word, whatever re-write means in your world, but I will say that there are 2 problems with your argument: 1. Adoption of standards requires work, implementations don't just go from v. 2 to v. 3 (lets just think of EJB, for example) without some amount of new learnings...that does not mean the latter is not backward-compatible with the former... 2. Did Frank not write above that v. 2 of Mule is fundamentally a re-write from v. 1.4? I support Mule as a business, and wish u well, so i did not get accusatory on this point, i would like to think that i understand that this happens in enterprise software... what i am failing to track, and where upon reading our previous convo. on TSS, I think i understand more, is that there is some antipathy toward JBI that just doesn't make business sense, thats all, thats my only point here... I don't get paid by Sun, I am not a community member of openESB, and have no financial stake in the outcome of the purported 'ESB-wars', I just thought i would challenge u guys to explain yourself, as it will most certainly come up on RFPs, and saying "re-write", "JCP = bad", "openESB is not a competitor" will not cut-it... I still plan to where my Mule t-shirt around this summer, if that is o.k. with u...
  9. Re: re: rewrites[ Go to top ]

    Your sole and vaunted reason for not joining the JCP, for not supporting the JBI spec., and for de-riding openESB is the re-write issue, which i, as a non-spec. lead/non-implementer will take u at your word
    Douglas, I really am not de-riding OpenESB, just sharing my experience. I do have issues with JBI, which is why Mule never went that route. I have just posted about what I see as the limitations of JBI on my blog
    2. Did Frank not write above that v. 2 of Mule is fundamentally a re-write from v. 1.4?
    Mule 2.0 isn't a re-write, to the user not much has changed at all except the configuration mechanism. Internally, we made some API changes and removed some bits that we were not happy with. All in all Mule's core has remain very similar.
    what i am failing to track, and where upon reading our previous convo. on TSS, I think i understand more, is that there is some antipathy toward JBI that just doesn't make business sense, thats all, thats my only point here...
    Making business sense is quite a big deal when writing software. I hope my blog sheds further light on how I came to the decision not to go to JBI.
    I don't get paid by Sun, I am not a community member of openESB, and have no financial stake in the outcome of the purported 'ESB-wars', I just thought i would challenge u guys to explain yourself, as it will most certainly come up on RFPs, and saying "re-write", "JCP = bad", "openESB is not a competitor" will not cut-it...
    Fair enough, I hope now I have addressed this for you.
    I still plan to where my Mule t-shirt around this summer, if that is o.k. with u...
    Absolutly! Since MuleCon we have some cool new swag including a MuleSource fleece jacket. I can have one sent to you if you want it. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  10. Re: comprehensively disagree[ Go to top ]

    Hmmm... it's seems I posted a broken link about my previous comments on JBI: http://www.theserverside.com/news/thread.tss?thread_id=46764#239389 Cheers, Ross Mason MuleSource http://blog.rossmason.com
  11. AMQP comments[ Go to top ]

    "AMQP tries to do something very important but may not be attainable."
    Well, it has been attained, in multiple production environments. So I wouldn't consider this person's other comments about AMQP to be useful. Besides, there really isn't any kind of fight between AMQP and JMS. The former is a protocol and the latter is an API for one particular programming language. There exists a binding to allow AMQP to be used from JMS clients, so they are in fact complementary technologies.
  12. I agree with Neil in that AMQP does work and has technically achieved most of what it set out to... and the rest is within grasp. There are AMQP products out there like Apache Qpid and Rabbit MQ that let you do things like publish a message using Python on Linux and subscribe to it using Java JMS on Solaris in one program and simultaneously subscribe using C# WCF in another. That works today, across products from different suppliers. Being an open protocol means that a client implementation can be 100% written in a modern scripting language. You can take your Python AMQP program and run it on Linux, Solaris, Windows or Z/OS unchanged. No nasty platform specific native-C library needs to be linked to your scripting engine. Yes, there are a couple of kinks in the interop being ironed out -- but everyone with an implementation is on the AMQP Working Group and are keen to make it work. There's also a little bit of finishing up to do - the exciting ones happening this year being Standardised Federation, Global Addressing (including for subscriptions) and Standardised Broker Management. AMQP is a neat solution cross-platform, inter-organisation business messaging. It's also no fad - look who's behind it at www.amqp.org AMQP is also a transport option for an SOA; no JMS bridging required, no "forever" commitment to Java, and no "HTTP 404" workarounds in your services code. Declared interest: I'm on the AMQP Working Group, and I'm responsible for systems which send about 1 billion AMQP messages per day across 5 continents. I'm happy :-)
  13. JMS and AMQP[ Go to top ]

    Deciding between 'JMS and AMQP' is a bit like deciding between EJBs and [choose your web server]. The latter is more general and platform neutral. The former is good for a whole class of well documented use cases. * Both work with each other! They solve different problems. JMS is a model for one kind of messaging and AMQP does many kinds of messaging. * Both work fine with Mule and POJO-based models and API-lite platforms such as Spring. * Both can connect Java applications to .NET applications, and both are both a complement to and sometimes a competitor for WS-* standards in large integration projects. * Good open source implementations exist with commercial support for wide scale enterprise use. It may also be worth noting that: * Interoperability across platforms works like HTTP, FTP or TCP. KISS. It just works. See e.g. http://saladwithsteve.com/2007/08/future-is-messaging.html * If you are programming in Python, Ruby, Perl, C#, .NET WCF, C, C++, ..., or Flex, as3, Javascript etc when creating an AJAX or Comet style application doing messaging over the wide area (eg using HTTP), then you may find AMQP works well for you. For example: http://www.infoq.com/news/2008/03/flex-rabbitmq-stomp and http://www.jaikoo.com/2008/3/14/oh-hai-rabbitmq * If you want wire level performance, eg to work with higher level protocols such as FIX/FAST or web services, then you may prefer AMQP, for example: http://www.intelfasterfs.com/trading/articles/071128-intellowlatency.aspx * If you want it in the cloud ... then because AMQP is a protocol, that works too: http://es.cohesiveft.com/site/rabbitmq Obviously I am bigging up good cases for RabbitMQ (http://www.rabbitmq.com/) but AMQP is an open protocol with several implementations. All are in heavy use in production. Finally - two tools may be similar in a few respects, but this does not mean they need to always solve all the same problems! Cheers alexis
  14. JMS and AMQP[ Go to top ]

    The JMS vs AMQP question is a bit of a false dichotomy. JMS isn't a protocol, it's an API. This makes it a bit odd to consider it when choosing a "universal protocol." This also means you don't need to choose between AMQP and JMS, you can have both! Java apps can use JMS with AMQP as the underlying message transport, and seamlessly interact with non Java apps through their native AMQP APIs.
  15. Re: JMS and AMQP[ Go to top ]

    Yes, JMS isn't a protocol and AMQP is, per se. But if you had heard the presentation that fomented the question you would have heard a direct contrasting of JMS and AMQP in the real world. For the most part, it would not be useful to implement the JMS "standard" over the AMQP "standard" except in the case of getting some legacy stuff to work. See, for example, http://www.rabbitmq.com/api-guide.html . For anything new, I certainly would not use JMS over AMQP if AMQP was the "approved" standard.
  16. Hi Frank, Thanks for the write up. I am a little embarrassed that I didn’t even get to meet you. I’m in San Francisco are you based here? Regarding the numbers you quoted, we actually had 250 attendees, we’ll have 400+ next year ☺. I’ll take a stab at your questions -
    1. How important was the Spring-based approach to building services to Mule's popularity and success?
    Well, Spring is popular with Mule users since we have always played well with Spring. Those users will be very happy to know that they can now combine Mule and Spring configuration seamlessly. So developers gets a common Xml language for configuring service and endpoints in Mule but can easily drop into spring configuration for doing non-Mule stuff such as JDBC DataSource or JMS Connection Strategies. Plus you get all the other Spring goodies such as AOP, DAO and JDBC abstractions. One of the main drivers for switching to a schema-based approach was to remove class names from configuration and make the configuration more succinct and much easier write. With schemas we now have attributes defined for properties and these are typed and validated. What’s more you get auto-completion inside your IDE and documentation for each attribute can pops up when you need it.
    2. Is anyone, I mean anyone on Earth, using OpenESB from Sun? None of the Mule users had any experience with it. [Perhaps the better question is: is anyone willing to admit it? At MuleCon, of course, you've a largely self-selecting group that doesn't use OpenESB...]
    We never see it, but it doesn’t mean it’s not in use somewhere. Projects usually die (or get reborn) if there is no uptake.
    3. How are Mule and Mule users testing Mule for scalability and performance? Mule 2 provides hundreds of unit tests but apparently no performance tests, at least none that I could find.
    We’re currently building out a JapEx test suit as part of our QA infrastructure, these will provide a good deal of performance metrics that we’ll be expanding for many configuration scenarios.
    4. What are the trade-offs of an ESB versus Gigaspaces, Tangosol and other grid environments?
    These technologies are completely complimentary. In fact GigaSpaces gave an excellent talk about the synergies between our products. ESB’s are typically used for moving information around between disparate systems, Orasol and Gigaspaces solve the problem of scaling out this data. Gigaspaces also provide scale out by being able to distribute work as well as data across a grid.
  17. Very nice and interesting article - many thanks for this detailled informations. Roland SOA Competence Network
  18. Frank, very nice summary. I'd like to address two comments you raised in your text. Clustering and the role of GigaSpaces with Mule. We at GigaSpaces have been working for while with Ross and the team on GigaSpaces/Mule integration. Integration which supports the following: 1. Space transport for Mule. Mule applications can take advantage of GigaSpaces XAP capabilities. 2. Clustering - ability to deploy mule applications across grid of physical machines. Clustering supports - deployment, scaling and high availability. 3. High Availability - ability to store the SEDA queues in memory and at the same time support fail-over semantics. Applications exploit the speed of memory storage and at the same time, in cases of failures (process/machine/network) , a backup node automatically takes over of the processing. More information of GigaSpaces/Mule integration can be found at: http://www.gigaspaces.com/wiki/x/ZAEXAg Guy Nirpaz, GigaSpaces Technologies
  19. Using OpenESB[ Go to top ]

    Awkwardly enough for some reason after reading this article+comments I feel ashamed of using OpenESB. Yes you read that right. We might actually be the only ones on Earth using OpenESB. Ironically my group is using it in JBoss and another group is using it in Glassfish. Unfortunately I don't know enough about Mule, but I have only read good things about it. I know from experience JBI and OpenESB are not perfect but they fulfill our needs quite well. Specifically we are mainly using the Binding Components we open sourced: RSS-BC and the XMPP-BC. Using these together with the HTTP/SOAP BC and BPEL allows one to do some pretty neat stuff.
  20. Re: Using OpenESB[ Go to top ]

    Awkwardly enough for some reason after reading this article+comments I feel ashamed of using OpenESB. Yes you read that right. We might actually be the only ones on Earth using OpenESB. Ironically my group is using it in JBoss and another group is using it in Glassfish. Unfortunately I don't know enough about Mule, but I have only read good things about it. I know from experience JBI and OpenESB are not perfect but they fulfill our needs quite well.

    Specifically we are mainly using the Binding Components we open sourced: RSS-BC and the XMPP-BC. Using these together with the HTTP/SOAP BC and BPEL allows one to do some pretty neat stuff.
    I'm very pleased to hear also some opinions which comes from the real practice :) In my opinion is Mule a very good solution - but by far not the unique in the "SOA Universum". We are actually preparing a long-term based report, matrix and intense information-pool over populare SOA-Suites and their components, characteristics, competencies, ... which isn't oriented exclusively on pure technical aspects of the suites. We have planned to include also a virtual SOA-Suite which is based exclusively on Open Source Components, the base of the ESB in this virtual Suite is JBI. Roland SOA Competence Network