Discussions

News: Podcast: Why ESB Matters in SOA

  1. Podcast: Why ESB Matters in SOA (19 messages)

    MuleSource CEO Dave Rosenberg talks about how Enterprise Service Bus technology is central for service-oriented architecture (SOA) implementations and how ESB enables easy integration and greater reusability of service components. Rosenberg touches upon:
  2. Why he believes the ESB is the foundation for an SOA
  3. Integration vs. service mediation
  4. What an ESB shouldn't do
  5. Why an ESB should have a small footprint
  6. Why SOA needs to concern itself with applications outside the Web services sphere
  7. Whether users are deploying ESBs tactically or strategically
  8. The scale and scope of SOA projects he's encountering
  9. Why he thinks services assembly capabilities need to precede BPM and governance iniatives
  10. Open source SOA vs. the traditional commercial software approach

Threaded Messages (19)

  • re: re-usability[ Go to top ]

    I am trying to figure out the balance between easy integration and re-usability, which seem like they are duplicative. If you have easy integration, why would you need re-usability? And how does an ESB promote re-usability of service components? I heard "lightweight", "non-fluff", and "more than services" as a calling card of an ESB, but still not sure what it does that an app server cannot manage... I feel like I have heard Mule and Dave talk about how JBI is non-necessary or even counter-productive to the ESB model, and I can't seem to figure out what, in the absence of JBI, an ESB does or why it would be considered anything but proprietary... I know this is a shared sentiment even among SOA proponents, but if the goal was to go to many-many, standardized integration, how is this accomplished in a non-JBI/non-JAX world?...
  • Re: re: re-usability[ Go to top ]

    Easy integration and re-use are not the same. Re-use is related to being able to consume a service or integration point in more than one scenario. Easy integration is, well, easy integration with other apps. Re: JBI--It's Ross who doesn't love it. My short answer is that JBI is a Java specification and has nothing to do with open source vs. proprietary software.
  • Java is not the only open option - and many companies have integration/ESB requirements and have zero Java in their organization. Apache Synapse is an open source ESB router that doesn't implement JBI but is completely open-standard and non-proprietary. Instead it relies on standards such as XSLT, XPath, E4X, Scripts and simple POJOs to create routing and mediation in an open fashion. JBI is just being updated to 2.0, but 1.0 does not implement enough portability that you can take one ESB config and move it seamlessly to another ESB. Synapse is available as a WAR file that is completely portable across application servers, and is simple and lightweight to install. Java standards are great for Java coding, but again and again open source projects have proved that portability can often be achieved more simply and easily using an open license.
  • re: say something[ Go to top ]

    I really hate to do this, but Dave, I am thinking you need to do something about your messaging because I am getting nothing out of your responses, including that merciless podcast I sat through, where when given an opportunity to present a comprehensive depiction of SOA, you gave one-word answers, that I quoted, and never really explained much of anything... I am sure I know less about what an ESB is than I did before, as all I got out of the podcast was anti-app server banter...you may take this offensively, but I would suggest the Mule executive team have a retreat soon and figure out what your messaging is, so you can explain: when to use an ESB, how to integrate in to existing architecture, and what standards to utilize... None of that came through in the podcast, and your terse answers elucidate no conversation on TSS...my point on easy integration is that why would you need it if you already have re-use, other than a simple interface for 'tying' the components together; and my point on JBI is that Ross must be speaking for the org., or else you have no idea what you're doing as CEO, allowing a company employee speak out against one of the true standards of SOA without, perhaps, agreeing with him? thats purely insane... 1. please explain to me why Mule does not support JBI... 2. please explain to me what is easy integration... 3. please give me an idea of how Mule gets customers.... with this, we can rally behind you more, without it, i am lost as to what your company is doing...
  • Give little respect to a NICE Idea dude[ Go to top ]

    1. Please explain to me why Mule does not support JBI... SUN and their standard enforcement business is not always the best in this world. 2. Please explain to me what easy integration...is EASY integration is where I do not have to call 100 different departments to complete a purchase order in my supply chain and pay millions to IBM or BEA. Learn from Amazon, some of the amazon.com web page is coming from the content of 100s of servers 3. Please give me an idea of how Mule gets customers.... Mule get customer where CTOs understand technologies or where a company cares about IT expenses. I think ideas like Mule, Spring, Hibernate is in this world for a reason and people behind it keep the spirit of nice software professionals.
  • Re: re: say something[ Go to top ]

    No offense taken. I have no idea who you are and am sorry that you feel even dumber than you were before. You could have just stopped listening to the podcast, which you'll note was not on this site, but one that is less technical than TSS. Your comments are merely flame-bait which I think TSS has too much of already. Should you want to discuss more about Mule/JBI etc. I am happy to do so with you via email or telephone 415-229-2009. We can also send Dan Diephouse to meet you for coffee since you are in the same town. Shaji explained your 3 question points in another comment. Perhaps you can come and educate the executive team as you seem to know everything.
  • Mr Dooley, "entrepreneur"[ Go to top ]

    Douglas, As a self-proclaimed entrepreneur you should know by now what it take to make a company successful. Dave is the CEO, not the technical spokes person for MuleSource. The CTO leads the technical direction of the company and the CEO looks after the business, my CEO's catch phrase was every time I came up with an idea was "show me the money". So, don't knock Dave for having a difference of opinion to Ross, Ross has a technical reason for not liking JBI (quite right too) and Dave has a business reason for thinking otherwise, I see nothing wrong or unusual with that. Personally my view of JBI is that it's just another TLA for stating the bleeding obvious but that's a whole new conversation. Why doesn't Mule support JBI? It does in many ways, it's just not been one of the sheep to follow the "I support all the latest acronym" crazes. -John-
  • re: flame-bait[ Go to top ]

    Dave, "Merely flamebait" is another way of saying you don't want to deal with it, have no way to respond it, and/or think I am right but don't want to admit it...it is a shame you choose not to discuss with me your positioning when given an opportunity, i find TSS to be an ideal forum to do that, but in lieu of that, I have thrown an e-mail to Dan D....perhaps, that is the best route for both of us to accomplish what we want to accomplish... John, Dave is a technical spokesperson considering the business they are in, otherwise Ross should be CEO, sorry that may appear to be flamebait, as well, but the CEO of a middleware company should know standards and the reasons why to support them, even if for some reason the CTO and CEO are not on the same page...I would like to hear you say something more about why JBI is not right, other than an argument that supporting acronyms is not necessary, thats a lame argument, I bet you can do better... douglas dooley
  • Re: re: flame-bait[ Go to top ]

    I hate to get in the middle of a fight but perhaps if you explain the benefits of JBI that are lost by not supporting it there might be a more meaningful conversation. I would like to know why it is important to support JBI. I'm not saying it isn't, I just don't know why I should care about it.
  • Re: re: flame-bait[ Go to top ]

    John,
    Dave is a technical spokesperson considering the business they are in, otherwise Ross should be CEO, sorry that may appear to be flamebait, as well, but the CEO of a middleware company should know standards and the reasons why to support them, even if for some reason the CTO and CEO are not on the same page...I would like to hear you say something more about why JBI is not right, other than an argument that supporting acronyms is not necessary, thats a lame argument, I bet you can do better...
    I'm going to jump in the middle of this one because I have experience with several ESBs, with and without JBI support. Having architected a few large, mission-critical applications around ESBs, I found that JBI wasn't buying me anything other than a checkmark in the Java JSRs checklist. The JBI-based implementations may be great for hooking up Java-to-Java systems developed by the same organization, but they don't work well if you have a mishmash of legacy, multi-vendor, and home-grown applications. When it came to putting my money and my job where my mouth is, Mule and TIBCO met all the integration requirements (with Mule having more interoperability options out of the box), including external interoperability with JBI. None of the other options/vendors did that. I met the team who developed the JBI 2.0 during JavaOne, and may still have a video I shot of them on the first day of the conference; they were the first ones to admit that JBI 1.0 was incomplete, so arguing that an ESB must meet that spec is asinine if your business depends on it. JBI 2.0 looks all right, but there are no hardened implementations for it out there yet. So far I've rolled out two large scale deployments centered on Mule because:
    1. I have all the interoperability options I need for legacy, new tech, standards- and nonstandards-compliant components.
    2. If I had to deploy a JBI-centric product tomorrow, I can integrate it into my Mule infrastructure with little fuss. We tested that and it works.
    3. Mule is a mature product, in production for at least 3 years in some pretty large installations; by the very nature of the JSR and when it was released, any JBI-centric product out there right now will be in beta at best.
    I'll be happy to discuss real-life scenarios using Mule if you'd like to explore this further. For me, real life is about balancing standards with things that work. Some things are pushed to be standards and suck (i.e. EJBs), where a rogue implementation comes out of the blue and becomes the standard (i.e. Hibernate) because they get the job done. Getting religious about standards is as dumb as buying everything from a single vendor without evaluating other options first. I said often here on TSS and other places that the key is to find the best-of-breed product or offering to meet your service level agreements. If you find something that can work well with proprietary and standardized products, and it meets your SLAs, why not use it? Cheers, Eugene Ciurana Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade: The Tesla Testament ISBN: 1-4116-7317-4 - BISAC: FIC031000
  • re: JBI[ Go to top ]

    James, I find the open marketplace of inter-operable JBI integration components to be the single most compelling selling point of a potential standards-based ESB project, such as the CICS and JMS components found here: http://wiki.open-esb.java.net/Wiki.jsp?page=Jbicomps I can't for the life of me think of a single reason not to support JBI, other than if you have TOO much religion on specs, and don't want to get behind Sun on this endeavor... Eugene, Java-Java integration is one major compelling argument for going with a JBI solution, and considering the penetration of proprietary app server-based JCA implementations out there (i'm thinking WebLogic, WebSphere, iWay, etc...), this seems like potentially as the single biggest ESB opportunity...i will have to concede that the sum total of all legacy integration projects exceeds JCA projects, but not CICS, nor any other legacy on its own... I think its asinine for Mule not to support JBI for the explicit reason that they are going to be rolling out JBI 2.0, and 1.0 is certainly better than a vacuum...otherwise, its just EAI, am I wrong?...I am certainly not against Mule as a platform, I wear my "Dumb Azz" t-shirt around every once in awhile, and like what their mission is...i would just like to figure out what they plan to do to be non-proprietary if I were to get excited about their business model, which has to be more than just being OSS... Standards are important in the ESB market, and no one should know this better than Mule, being the only pure-play giving it a go, locking customers in to your own flavor of integration is a non-scaling model, sure you can get some big-ticket accounts, but the majority will need to be sure that their investment is long-lasting: do i need to re-sell the entire value proposition of the Enterprise Java platform to you guys? douglas dooley
  • Re: re: JBI[ Go to top ]

    James,

    I find the open marketplace of inter-operable JBI integration components to be the single most compelling selling point of a potential standards-based ESB project, such as the CICS and JMS components found here:

    http://wiki.open-esb.java.net/Wiki.jsp?page=Jbicomps
    That helps. So what does the "JBI, we don't need no stinking JBI" crew say to that?
  • Re: re: JBI[ Go to top ]

    Standards are important in the ESB market, and no one should know this better than Mule, being the only pure-play giving it a go, locking customers in to your own flavor of integration is a non-scaling model, sure you can get some big-ticket accounts, but the majority will need to be sure that their investment is long-lasting: do i need to re-sell the entire value proposition of the Enterprise Java platform to you guys?
    Mule has interoperated with all the standard stuff that I've thrown at it, whether Java or otherwise. As a customer, I don't feel locked to Mule since I have the option to connect to it from a variety of systems, ranging from 1970s EDI technology to state-of-the-art messaging systems. JBI plays let me talk to... other JBI plays. Not good enough. Mule can interoperate as easily with non-Java systems as well as with Java systems. The Enterprise Java value proposition is good marketing but reality has a bad habit of intruding. While I'd love to interoperate only with other Java systems, in reality I may have to integrate applications from all kinds of platforms, data formats, protocols, etc. I don't care about the religiosity of Java, or .Net, or any other vendor's value proposition if it doesn't enable me to keep my customers happy. The systems I've built in the last few years have obeyed a simple guideline: Use the best of breed to meet the SLA. That's why I don't deal in absolutes. The best of breed may be open-source, or commercial, or JEE, or .Net, or $PRODUCT_NAME_HERE. In the case of ESBs, I rather have something like Mule that can talk to every protocol and messaging system I can think of, including JBI, than have a pure JBI play that will be hard or impossible to integrate with other technologies. The Enterprise Java value proposition is awesome. When it works. Cheers, E Eugene Ciurana Non-stop action. A vulnerable hero. A quest to save the world. It's the most exciting novel of the decade: The Tesla Testament ISBN: 1-4116-7317-4 - BISAC: FIC031000
  • Re: JBI[ Go to top ]

    As a customer, I don't feel locked to Mule since I have the option to connect to it from a variety of systems, ranging from 1970s EDI technology to state-of-the-art messaging systems.
    Yes Eugene - but you are still locked into Mule. If you want to avoid being tied to one vendor - and all that entails - you have to look towards using a standard component model - like JBI - and the choice of open JBI components to 3rd party systems, is already substantial and continuing to grow rapidly.
    JBI plays let me talk to... other JBI plays.
    JBI is a component model that allows components and integration assemblies to be deployed and managed by JBI compliant containers. The whole point of JBI is to to give people choice. And whilst Mule might try and play lip service to JBI, it isn't really compatible - you couldn't drop a JBI service assembly into Mule and expect it to run. BTW - the open source ESB with the most actively growing community is ServiceMix which is Apache licensed and JBI compatible too.
  • Re: JBI[ Go to top ]

    Service-oriented Architectures decouples the consumer from the service provider - in the same manner a customer would be decoupled by their used ESB Stacks and Manufacturers. The customer needs facilities to deploy their investment of „business services“ at different environments and without great changes by the code base or associated administration tasks. The Standard JBI (Java Business Integration) provides facilities to assemble and deploy Business-Components in distinct JBI-Environments: Will really come the day, when we can deploy the same „Business Services“ easily in different Integration-Environments from SAP, SUN, IBM, BEA, ORACLE, IONA, JBoss, Sonic, TIBCO, Apache, Mule, ... ? Roland SOA Competence Network
  • Re: re: say something[ Go to top ]

    where when given an opportunity to present a comprehensive depiction of SOA, you gave one-word answers, that I quoted, and never really explained much of anything...
    To be honest, I've never heard anyone present a comprehensive depiction of SOA. It's become an umbrella term used to encompass everything "middleware". its amazing that some many vendors have pumped so many millions of marketing dollars into it yet this is still one of the first questions asked. In my mind SOA is right up there with 'multimedia' on my list of hazy terminology.
    I am sure I know less about what an ESB is than I did before, as all I got out of the podcast was anti-app server banter
    I don't think there was anything anti-App Server in the cast. In fact we can be embedded in all the popular commercial and open source App Servers at various levels. But we have found that a large percentage of our users do choose to run Mule stand alone.
    ...you may take this offensively, but I would suggest the Mule executive team have a retreat soon and figure out what your messaging is, so you can explain: when to use an ESB, how to integrate in to existing architecture, and what standards to utilize...
    Dave's pod cast was aimed at a less technical audience, but has surfaced here. As for describing how to integrate to an existing architecture on a technical level is difficult without visual aids or a whiteboard. We support a whole host of standards from the JCP and W3C, to name some: JMS, JNDI, JCA, JMX, JDBC, EJB, JTA, JBI, JAAS, XML, XSLT, WS-Security, WSDL, blah. We also support proprietary and legacy integration to things like SAP, AS400 Data queues, SIP, Salesforce, etc. no need to wave the standards flag here.
    ...my point on easy integration is that why would you need it if you already have re-use, other than a simple interface for 'tying' the components together;
    Have you ever written integration code? If so, you must have experienced "integration deja vu" (or idejavu.org :) ) where you're writing the same plumbing code again and again but each time it's slightly different because some detail about the way the system was implemented or some infrastructure restriction, security policy etc. The problem with the "standards" to date in the Java world for 're-usable' components is that they are very API heavy and don't bend well when you need change the behaviour slightly due to some nuance in the system you're integrating with. The standards I'm talking about here are JCA and JBI. JCA is a heavily over-engineered standard in my opinion, but its heart was in the right place. JBI seems to be a spec written for framework vendors to get excited about, it really wasn't targeted to the people actually using the technology. Integration problems are prickly at best and people doing integration become encumbered quickly by APIs were not designed with their particular use case in mind. Generally, I think its naive to try standardising integration. I should mention that have spoken to Peter Walker, the spec lead for JBI 2 and it definitely seem to be moving in a better direction and one that I will follow to its conclusion.
    and my point on JBI is that Ross must be speaking for the org., or else you have no idea what you're doing as CEO, allowing a company employee speak out against one of the true standards of SOA without, perhaps, agreeing with him? thats purely insane...
    Me being the founder of the Mule project and co-founder of MuleSource surely gives me some leeway to speak out :) Besides he didn't say he liked it, he just said that I didn't. As a company, we haven't found JBI to be advantageous to our customer or user needs. I don't think anyone would categorise JBI as one of the true standards of SOA - did you read that somewhere? If Mule had blindly adapted JBI we'd be getting ready to re-write the whole thing once JBI 2 came out. Note that JBI 2 is looking to incorporate many features that Mule has, so I think we're doing something right. What I think would be far more useful is to define a good connector architecture standard and leave all the internals to the vendors. This would definitely promote interop without encumbering the server implementation. Note that all vendors like to differentiate, so even if a standard is used you can't easily swap one vendors component/connector/service with another, so you really need to ask: what is the point of some of these standards?. As a case in point the Jms connector in Mule has to make certain allowances for different interpretations of the JMS spec by different vendors. The good thing is that Mule was designed to handle these sorts of realities in an extensible way, but the user never needs to know. Since you are a JBI fan, have you counted how many Jms binding components have been Implemented? so much for reuse.
    1. please explain to me why Mule does not support JBI...
    We support integration to JBI containers but didn't adopt the container itself since it only allowed a sub-set of Mule features to be possible due to API/Design decisions, plus it is very XML-centric, which is a big show-stopper for many integration projects since you are talking to legacy systems.
    2. please explain to me what is easy integration...
    To use a tooth extraction example: The extraction is going ahead whether you like it or not, Mule provides the local anesthetic to make the whole process much more pleasant by abstracting the pain away from you.
    3. please give me an idea of how Mule gets customers....
    Mule is the leading open source ESB we have nearly 800,000 downloads at present and Mule has been running in production systems for over 4 years now. There is a commercial company behind Mule called MuleSource who offers subscription-based support (including 24x7), other services such as training, consulting, etc and Management and other tools for the Mule platform. Since mule is used for business critical applications (ESBs are usually a business strategy choice) our users like to have piece of mind that they can get support when they need it. They also get buy in to our roadmap because they help funding the future development of Mule and related products. Cheers, Ross Mason MuleSource
  • Re: re: say something[ Go to top ]


    Mule is the leading open source ESB we have nearly 800,000 downloads at present and Mule has been running in production systems for over 4 years now. There is a commercial company behind Mule called MuleSource who offers subscription-based support (including 24x7), other services such as training, consulting, etc and Management and other tools for the Mule platform. Since mule is used for business critical applications (ESBs are usually a business strategy choice) our users like to have piece of mind that they can get support when they need it. They also get buy in to our roadmap because they help funding the future development of Mule and related products.

    Cheers,

    Ross Mason
    MuleSource
    Ross: Very impressive informations over an important solution! Perhaps it's possible to become some more detailled impressions: If are public statistics over the amount of installations in Enterprises, their destinated business areas and additional informations over your most important customers available (maybe accompanied with some input from customer-side over their experiences with Mule in the Business-Projects) ? Very nice to hear some associated comments. Roland SOA Competence Network
  • EAI matters more than ESB in SOA[ Go to top ]

    The Bus (the "B" in ESB) is pretty vital in most cases but it is not possible to expose a service for reuse without solving the application integration problem. Enterprise SOA (ESOA?) needs a bus for sure but it also needs enterprise application integration (EAI). EAI is the core to E-SOA not the bus, the bus could be as simple as HTTP or MQ-Series, the real work is in the integration. Dave, I like the bit about baseball being delivered on Mule but can it scale to cover cricket? -John-
  • Re: EAI matters more than ESB in SOA[ Go to top ]

    JD--Cricket should be your new OSS project name--as far as I can tell the Pitch would be the Bus and the N systems would be the stumps.