ESB HOWTO: TSSJS Barcelona BOF Session

Home

News: ESB HOWTO: TSSJS Barcelona BOF Session

  1. ESB HOWTO: TSSJS Barcelona BOF Session (14 messages)

    Thanks to all who attended the ESB HOWTO BOF and Enterprise Application Mashup sessions at TheServerSide Java Symposium last week. Here are the slide decks as well as the ESB functional evaluation spreadsheet covering commercial and open-source products, as promised during the conference. You can get the full presentation decks in Keynote format, and the ESB functional evaluation spreadsheet in Excel from: www.ciurana.eu/TSSJSBarcelona System-independent downloads: * ESB HOWTO slides - PDF * ESB functional evaluation - PDF * Enterprise Application Mashup - PDF Thanks to those who attended the sessions, and welcome to those who'll see the stack now. Please share your comments in this forum. Eugene Ciurana is TheServerSide contributing editor based in Silicon Valley and the Director of Systems Infrastructure at LeapFrog Enterprises. He can be reached on IRC under the /nick pr3d4t0r in the #esb, ##java, #awk, #security, and #olpc channels at irc.freenode.net.
  2. Unfortunately I was not able to attend TSSJS Barcelona this year. Had I been there, I would have pointed out that the functional evaluation document is just about 100% incorrect in its ratings of Apache ServiceMix. How is it that some of the core functionality inside of ServiceMix receive such low ratings or even zeros? If you would like someone with knowledge of ServiceMix to help correct the mistakes, there are many people in the ServiceMix community who are more than willing to help, including myself.
  3. How is it that some of the core functionality inside of ServiceMix receive such low ratings or even zeros?

    If you would like someone with knowledge of ServiceMix to help correct the mistakes, there are many people in the ServiceMix community who are more than willing to help, including myself.
    Hej, that'd be great. Can you please point out where you think that the document is inaccurate? Thanks! E
  4. I guess I can give a few facts here. As a disclaimer, I am part of ServiceMix team, but I'm trying to stay objective. I really think both Mule and ServiceMix are great products, each one with its own strengths and weaknesses. Deployment Topology: Mule instances do not really communicate together directly: they use an existing communication mean for that. So all the topologies supported by Mule that are nicely shown at [1] can also be supported by ServiceMix using the same kind of protocols. Streaming ServiceMix has been carefully designed to allow streams to be passed inside the JBI bus, when dealing with stream based protocols such HTTP, files or ftp. Remote deployment and management Remote deployment and management are supported per the JBI specification. On the monitoring side, ServiceMix has a plugin for Hyperic. Operating Systems Deployment Options I just want to say that OS X and Windows are the two OS used for developing ServiceMix. Deployment Complexity ServiceMix main distribution is a standalone (no appserver) installation. In addition, ServiceMix comes in a web application distribution that can be deployed on any App Server or Web Container. Lastly, ServiceMix can be easily embedded in any application (web or J2SE) by removing the deployment option using a spring based configuration. Support Options IONA, who acquired LogicBlaze a few months ago, provides support consulting and training on ServiceMix. JDK versions ServiceMix 3.1 branch uses Java 1.4. Some of the components requires Java 5, such as support for WS-Notification, JAXB2 and JAX-WS. There are some small bugs that prevents using the distribution on 1.4 out of the box (see [2]) but this should be fixed in 3.1.2. However, ServiceMix 3.2 will require Java 5, but there are some very robust tools that can be used to bring back Java 1.4 compatibility for specific needs such as Retrotranslator (see [3]). As for JDK 6, ServiceMix is fully compatible since several months (see [4]). Application Server Support I'm not sure what these numbers means. ServiceMix web application can be deployed on any app server. It has special support for Geronimo and JBoss too through native integration. Transport Synchronous, asynchronous and request/response are supported per the JBI spec. Integration/Framework EJB: you can call EJB by using Java proxies from jsr181 component if you need JBI: I just want to state that Mule JBI support has not been really updated since I left the project 2 years ago to join ServiceMix (see [5]). JNDI: I guess you are refering to the Mule JNDI container (see [6]). ServiceMix leverages spring well known features for that Jotm: You can use whatever transaction manager you want, provided that you can configure it in Spring, which is the case for Jotm (see [7]). Spring: ServiceMix is using spring as its own configuration mechanism and lots of components use Spring internally too .... Security ServiceMix uses mainly SAAJ for security, relying on HTTP authentication and WS-Security. However Acegi can be used with ServiceMix on top of SAAJ to secure your spring based services if needed. BPEL: Looking at [8] and [9], it seems Mule only supports a BPEL engine deployed in a separate box. Of course, any framework supporting HTTP/SOAP will usually be able to integrate with a BPEL engine. However, Apache Ode (fully BPEL 2.0 compliant engine) has a JBI component that can be deployed in ServiceMix. I also want to add that, given that ServiceMix is based on a standard technology (JBI), you can avoid vendor lock-in and you can reuse third party components like Corba ([10]), CICS ([11]) and many other components ([12]). [1] http://www.muleumo.org/display/MULE/Topologies [2] http://issues.apache.org/activemq/browse/SM-848 [3] http://retrotranslator.sourceforge.net/ [4] http://issues.apache.org/activemq/browse/SM-783 [5] http://svn.mule.codehaus.org/changelog/mule/trunk/mule-jbi [6] http://mule.codehaus.org/display/MULE/Jndi+Container [7] http://www.springframework.org/docs/api/org/springframework/transaction/jta/JotmFactoryBean.html [8] http://mule.mulesource.org/jira/browse/MULE-1455 [9] http://mule.mulesource.org/display/MULE/MULE+and+Oracle+SOA+BPEL+Integration [10] http://jbi4corba.sourceforge.net/ [11] http://jbi4cics.sourceforge.net/ [12] https://open-jbi-components.dev.java.net/
  5. @Guillaume, Thanks for the detailed response. My turn to offer a disclaimer: I've been using Mule for very high-volume, production-ready environments since last year, at two different large, publicly traded companies. I also authored a Mule case study published by TSS, and was invited to the MuleSource technical advisory board because of those experiences. Mule was able to push through 200 million transactions/day during our scalability testing; none of the other ESBs we evaluated, commercial or open-source, could do that on the same hardware. The short answer is that the presentations and spreadsheet posted with the note reflect the main reason why we're using Mule: It Just Works. While the spreadsheet that I posted with the article isn't mine, I did an evaluation of ServiceMix along with other ESBs around August-September 2007 as well. I agree with many of the things that you pointed out, except for this statement, which seems to indirectly imply that Mule (also open-source software) promotes lock-in:
    I also want to add that, given that ServiceMix is based on a standard technology (JBI), you can avoid vendor lock-in and you can reuse third party components like Corba (sic), CICS and many other components
    A main reason why we chose Mule for two mission-critical, high volume sites that I've been involved with was because of how well it helps in preventing vendor lock-in. It interoperates well with TIBCO, IBM, Oracle, ATG, Siebel, Day, and a cartload of other software in real world environments where we tested (protocols [JMS, SOAP, REST, BPEL, etc.] and applications). That, plus the number of adapters that it comes with made it another powerful reason for adoption. While JBI compliance is a nice thing to have, my business requirements are such that playing nice with others rates above JBI compliance. That's where Mule did better than ServiceMix during evaluation and proof of concept integration. Unlike ServiceMix and OpenESB, which seem to be largely written to meet the JBI spec, Mule was developed first to solve real-world problems and second to comply with standards bodies. Since Mule supports JBI endpoints, there is no issue having Mule talk back and forth to ServiceMix, OpenESB, or any other JBI-compliant software. Given the vagueness of JBI 1.0, compliance with it is hardly a meaningful feature. Let's hope that JBI 2.0 does better (I had a chance to interview the JBI 2.0 JSR team during JavaOne... maybe that interview will make it to a TSS video tech brief one of these days). Spring integration... there are several examples from the project's pages.
    IONA, who acquired LogicBlaze a few months ago, provides support consulting and training on ServiceMix.
    It's a question of maturity of the software as much as one of support. Neither ServiceMix, nor Celtix are ready for prime time, being still in the Apache incubator. That will translate into more support calls, and more headaches. Mule has been production-ready for a while, having been produced for solving real-life problems first, then released as open-source, and finally having a company around it.
    ServiceMix main distribution is a standalone (no appserver) installation. In addition, ServiceMix comes in a web application distribution that can be deployed on any App Server or Web Container. Lastly, ServiceMix can be easily embedded in any application (web or J2SE) by removing the deployment option using a spring based configuration.
    Mule does exactly that as well. Except for the security features in your posting, everything you mentioned is available in Mule; check out the org.mule.impl.security.MuleSecurityManager and related classes as well; HTTPS and WS-Security can be easily implemented through service managers. What I said at TheServerSide Java Symposia in Las Vegas and Barcelona, the Open Source Business Conference (The Art of Picking Your Poison), and the MuleCon is that all ESBs provide equivalent feature sets. If we compare data sheets, all ESBs look fantastic, just like the marketing or evangelist teams want us to believe. The difference occurs when using the ESBs in the real world: so far, in the projects where we're using it, Mule performs better than all the others. It Just Works. Cheers, pr3d4t0r
  6. Hi Eugene, I was at TSSJS Europe and I attended your presentation. I was struck by the way you are biased toward mule. I mean I agree with your architectural picture about ESB and I'm sure you had good experience with mule but why talking so badly about other ESB. For example at the BOF you said that OpenESB is closed when you try to make it talk with other ESB. This statement itself (double check with the engeneer that provide you informatios) doesn't make sense: there isn't a standard for ESB interoperability, so the only way of making ESB talk is by using a connector. And if OpenESB wasn't reachable by it's connector it would mean that it is useless as an ESB not just regarding the interoperability feature. This is not true of course, OpenESB connectors (http/soap for example) just follow the standard and they works. You said that ServiceMix is better under the interoperability issue, how can it be since there isn't a standard?, are you thinking about mule servicemix connector? that connector is there because mule people feel that not being JBI compliant is a lack so they found a way of being compliant by making run ServiceMix inside mule... I remember the early time of ejb, many said that the standard could be better, some said that existing non standard container (like enhydra do you remeber it?) were better and proven. after 5-7 years what is the situation like? I think that the importance of a standard can't be underestimated, of course the first release of a spec can always be improved, but this is normal. bye Raffaele
  7. @raffaele,
    I was at TSSJS Europe and I attended your presentation.
    I was struck by the way you are biased toward mule.
    I mean I agree with your architectural picture about ESB and I'm sure you had good experience with mule but why talking so badly about other ESB.
    Thanks for attending the presentation! I'm not biased against Mule per se; rather I'm biased toward things that made my work easier, from a technology, community, and support points of view. In my experience, and in my evaluation, Mule came ahead of the others. The point was not to plug Mule. If I hadn't been using Mule, I'd probably be plugging TIBCO's ESB, which came second in our evaluation. TIBCO had some slightly nicer features than Mule, but the price tag was too high in comparison and that's what disqualified it. The objective of the BOF was to discuss our common needs, and how we'd address them, from requirements to deployment. I can only speak for the things we tried, and the things that worked for us. Your mileage will vary depending on your business and technology requirements, and your SLAs.
    For example at the BOF you said that OpenESB is closed when you try to make it talk with other ESB. This statement itself (double check with the engeneer that provide you informatios) doesn't make sense: there isn't a standard for ESB interoperability, so the only way of making ESB talk is by using a connector. And if OpenESB wasn't reachable by it's connector it would mean that it is useless as an ESB not just regarding the interoperability feature. This is not true of course, OpenESB connectors (http/soap for example) just follow the standard and they works.
    No, what I said was that OpenESB was closed when it came to talking to non-Java systems. In order for me to get OpenESB to an EDI feed (common scenario for a large retailer with many systems designed and built in the 1980s), I had a lot more work to do with OpenESB than with Mule connectors and transformers. During the presentation I mentioned that a good ESB lets you talk to any other ESB with a minimum of fuss, and that you're allowed to daisy-chain them. If that's easy, cool! If not, you may be facing vendor lock-in. In this scenario, Websphere ESB is more conducive to lock-in than TIBCO's. TIBCO played nice with everything we threw at it. Websphere ESB likes to chat with IBM's other gear better than with other ESBs, and many of the adapters and transformers that it supports are supplied by third-parties, at an additional cost.
    You said that ServiceMix is better under the interoperability issue, how can it be since there isn't a standard?, are you thinking about mule servicemix connector? that connector is there because mule people feel that not being JBI compliant is a lack so they found a way of being compliant by making run ServiceMix inside mule...
    I'm not talking about standards; in many cases, my team and I ignore standard stuff in favour of things that work. It's a lot easier to get ServiceMix and Mule to talk to one another than others... cool! Then we get them to talk. The other bus in my architecture, as you can see from the BOF slide, is the single sign-on system. We could have gone with a product (open-source or commercial) that was standards compliant... say something that's a pain in the arse like SAML. We recently kicked the tires of some commercial products (i.e. Bull's Evidian, Atlassian Crowd) and open-source projects (i.e. OpenSSO). The winner for us? Atlassian Crowd. Because, again, It Just Works. I have no relation at all with Atlassian or Crowd; they aren't standards compatible in general (well, they just introduced OpenID...) but they work great, can talk to my DB and AD repositories, it's easy to define ACLs, etc. That's what my team and I care about.
    I remember the early time of ejb, many said that the standard could be better, some said that existing non standard container (like enhydra do you remeber it?) were better and proven. after 5-7 years what is the situation like? I think that the importance of a standard can't be underestimated, of course the first release of a spec can always be improved, but this is normal.
    At the risk of sounding like a jerk... we don't have much time to wait for a standard that *may* be ironed out in the next few years. The product cycles faced by my teams are such that we value what does the job well, scales to large volumes easily, and interoperates with other systems (standard or proprietary) with ease over a purist view of standards compliance. The current project I'm working on, a software download store with DRM features and some very strange business rules and interoperability requirements, meets what Java purists would consider standards for many things (i.e. JCR-170 for the content management) and not for others (i.e. Wicket front-end instead of JSF). We had roughly 85 calendar days (middle-April to middle-July) to pull this whole thing off, from scratch. I can't wait for the standard stuff if it isn't ready for the kinds of projects that we get to work on. We value time to develop/time to market over compliance, especially if the technology selection looks like it will "have legs". To address your EJB comment directly: Hibernate was not a standard... but it became one by solving the issues where EJB failed. Spring isn't a standard (but it's on its way to becoming one) because it addresses issues that JEE didn't in some fashion, and people prefer it. It Just Works some times trumps the elegant standard body... and becomes a more robust standard. Cheers, E
  8. This is a good analysis on ESB. I agree that when we are developing mission critical projects, we have to look at which product can deliver to my requiements within the time period. It doesnt matter how much standard compatble it has. Moreover the standads are evolving rapidly and we can not wait for the standad to mature and then develop applications. The best solution will be look at things available to us around that time and see which one is best suited.
  9. Well, we kind of begin understanding Eugene's evaluation criteria of the ESB products here. His scenario is very particular: integration of disparate products / technologies in a very reduced time frame. Now, if our scenario is different, for example we are designing a SOA adoption plan, with a long-term vision, i think the standards route (JBI, SCA, etc.) is more appropriate. Eugene, it's a pitty i missed your Barcelona presentations!! I promise next year i'll go :) Anyway, thanks for posting your presentations and data sheet. Andres Gonzalez http://coyotevil.blogspot.com/
  10. It's a question of maturity of the software as much as one of support. Neither ServiceMix, nor Celtix are ready for prime time, being still in the Apache incubator. That will translate into more support calls, and more headaches. Mule has been production-ready for a while, having been produced for solving real-life problems first, then released as open-source, and finally having a company around it.
    Whether ServiceMix itself is of high quality or not, I can't say, but you misunderstand the point of the Apache Incubator. When a project goes through incubating, we are educating an existing team and its processes to fit with how Apache operates. Therefore, incubation has absolutely nothing to do with the quality, or lack thereof, of the code - it is all about the project's people and processes. In fact, most incubated projects have had production releases for years before they decided to join Apache - Wicket, Tapestry, Spam Assassin, and iBATIS are a few that come to mind immediately. (disclaimer, Apache Incubator PMC member)
  11. Do you have any plans to integrate JBossESB into the ESB dashboard ?
  12. I think that the ESB Comparison is not really helpful to become an overview of the real differences and pro's or con's of ESBs. Above all, I'm missing detailled descriptions with the reason for each grading. Roland
  13. I feel I have to come to Eugene's defense here: I was at the presentation and although Eugene was most definitely showing Mule in a good light that was not really the point! For me the main lesson was to be pragmatic in the selection of your tools (ESBs in this case). I experimented with Mule in the past and have ServiceMix currently implemented in a project just about to go into production (although not sure whether it will stay there). If Java is your environment JBI is fine. If you want however a very simple and straightforward integration of several disparate protocols and have to transform the messages - Mule does rock! If you do Web services only - don't do an ESB, use a simple tool like XFire. Once again thanks for a great presentation (both entertainment as well as content wise) and thanks for the spreadsheet!
  14. Hi Ingo! Thanks for attending the presentation! And thanks for reminding me to put the spreadsheet and other materials up; with so much work back at the office, it could've easily slipped my mind. Take care, and have a great day, E
  15. Comparing ESB performance[ Go to top ]

    The 200 million trans a day quoted above isn't necessarily so amazing. We (I work for WSO2) have published some ESB performance comparisons: http://wso2.org/library/2259 http://wso2.org/library/1721 Mule didn't come out very well, though that is mainly because we had trouble getting it to work properly. We found that WSO2's ESB could handle 250 million tranasactions a day with XML messages on a single 4-way server.