Discussions

News: New Article: The Road to JBI: Paved with Good Intentions

  1. According to Ross Mason, JSR-208, Java Business Integration, has languished in favor of open source integration tools. Here he gives his thoughts on why this happened, and how integration and ESB technologies can move forward from here. Read the article

    Threaded Messages (116)

  2. According to Ross Mason, JSR-208, Java Business Integration, has languished in favor of open source integration tools. Here he gives his thoughts on why this happened, and how integration and ESB technologies can move forward from here.

    Read the article
    I don't believe it is ok that people working on stuff that competes with JBI comment on public places, which should be neutral, about JBI. While you did not state explicitly that JBI is bad, it can be easily read between the lines that you are trying to influence the reader how we do not need JBI at all and how there are some significant flaws in it. Mule does not have native support for JBI, so it can be considered JBI container. I do not see James Strachan posting articles on main TSS page about non-standardized ESBs such as Mule, with critical hat on. You are entitled to your own opinion, but I do not believe you are entitled to post on main TSS page about things which compete with yours, especially in critical ways.
  3. Whats the next part of this series? ODF is bad?
  4. So lets go and analyze SOME parts of the article that trouble me the most. There are of course many more for which I am not willing to invest time now.
    Why hasn’t there been a more definitive move in the industry towards adopting the JBI standard? What are some of the areas where JBI falls short?
    You will have to ask BEA and IBM about that since if we take a look at ballot results, it seems all major tech players other than 2 mentioned above, have voted for JBI. http://jcp.org/en/jsr/results?id=3226 So claiming that there is some flaw in JBI specification is hard to digest if we consider Google, Apple, Oracle etc voted for. I'll try to give a hint why BEA and IBM abstained, maybe, perhaps, and by some chance SCA and SDO had something to do with that. And if we consider the market share IBM and BEA have in java enterprise market, I would dare to say they are guilty why JBI hasnt hit mainstream.
    It meets vendor needs at the expense of developers.
    I would have to disagree here. I strongly believe JBI is good spec, and if developer is not able to understand how JBI container should work, then he is at the wrong place, meaning he should probably go and do some HTML editing.
    While there is scope for standardization in integration, JBI misses the mark - JBI is no TCP/IP.
    Dont quite get what you are saying here, but if you are implying integration is not quite understood problem domain, you are wrong I believe, or perhaps your claim implies SOA is something new and not variation of process that has been done even before CORBA? Educated general public will hardly swallow 'SOA is new' cake.
    Savvy developers understand that standards mandating rigid approaches to problems with infinite variables
    Which would imply if someone disagrees with you then he is no savvy, because sky is red cause someone says so.
    Addressing the XML configuration piece, Service Component Architecture (SCA) seems to be a step in the right direction. However, the standard may still not be ready for prime-time, as some people deem it to be a bit too Web Services-centric, and the configuration is overly verbose. Moreover, SCA has not yet received the adoption required for it to be a front-runner.
    This pretty much summs it up. You dont believe any standard is good enough at the moment, except of course Mule 'standards'. Absolutely nothing personal here, just I generally do not appreciate bashing of open standards.
  5. You dont believe any standard is good enough at the moment, except of course Mule 'standards'.


    Absolutely nothing personal here, just I generally do not appreciate bashing of open standards.
    You need to calm down. He never said that no standards are good enough. He pointed to some open standards that he thinks work well. Furthermore, he was not "bashing" open standards. He doesn't like one particular open standard which is his right. He thinks another, SCA is still immature - it is, I've worked with it. If he did bash all open standards that would be his right too. What I'm still waiting to see is some coherent and cogent argument on either side of JBI. So far neither of you is doing very well. He states an opinion and so do you. Neither of you are giving any specific facts to support your opinions.
  6. You dont believe any standard is good enough at the moment, except of course Mule 'standards'.


    Absolutely nothing personal here, just I generally do not appreciate bashing of open standards.


    You need to calm down. He never said that no standards are good enough. He pointed to some open standards that he thinks work well. Furthermore, he was not "bashing" open standards. He doesn't like one particular open standard which is his right. He thinks another, SCA is still immature - it is, I've worked with it. If he did bash all open standards that would be his right too. What I'm still waiting to see is some coherent and cogent argument on either side of JBI. So far neither of you is doing very well. He states an opinion and so do you. Neither of you are giving any specific facts to support your opinions.
    Like I said, read between lines. Of course he is not going to say JBI is bad, but he will say stuff like "Savvy developers understand that standards mandating rigid approaches to problems with infinite variables" which would imply on subconscious level if you are smart you gotta be on our side since other side is excluded. Also, I don't have to prove JBI is good specification, companies which voted for it showed it. Its not the best specification, but good enough. On the other hand, if he is criticizing something, he should provide facts/metrics.
  7. So lets go and analyze SOME parts of the article that trouble me the most. There are of course many more for which I am not willing to invest time now.
    Why hasn’t there been a more definitive move in the industry towards adopting the JBI standard? What are some of the areas where JBI falls short?
    You will have to ask BEA and IBM about that since if we take a look at ballot results, it seems all major tech players other than 2 mentioned above, have voted for JBI.
    http://jcp.org/en/jsr/results?id=3226

    So claiming that there is some flaw in JBI specification is hard to digest if we consider Google, Apple, Oracle etc voted for.

    I'll try to give a hint why BEA and IBM abstained, maybe, perhaps, and by some chance SCA and SDO had something to do with that. And if we consider the market share IBM and BEA have in java enterprise market, I would dare to say they are guilty why JBI hasnt hit mainstream.
    These vendors voted on a promise of a common standard for integration. However, if you look at their actions after this ballot you'll see that JBI did not get their support: * Redhat and JBoss did not adopt JBI once the spec was released * Oracle bought BEA and are going with AquaLogic, which is not JBI compliant * Progress inherited ServiceMix when they bought IONA, but the direction of the open source arm of that deal is still unclear * Tibco did adopt JBI, but then (I'm told) ripped it out in their most recent version of ActiveMatrix (hence there is no longer a mention of JBI) * IBM and BEA abstained from the vote for JBI * Not sure if SAP NetWeaver uses JBI or not, but if it does it's had no impact. * Software AG, Microsoft and other EAI vendors didn't participate * Apple and Google may build their own, but the community will never see any benefits from it. AFAIK neither have adopted JBI So that just leaves 2 known implementations: OpenESB from SUN and ServiceMix hosted at apache. This hardly demonstrates an endorsement for JBI, in fact it looks more like a rejection.
    It meets vendor needs at the expense of developers.

    I would have to disagree here. I strongly believe JBI is good spec, and if developer is not able to understand how JBI container should work, then he is at the wrong place, meaning he should probably go and do some HTML editing.
    Wow, that's a little unfair. The spec introduced lots of new concepts, jargon and is generally fairly complicated. I think you are saying that only those that have time to digest all this and also agree with the way the spec is defined should use it? Well, that's what has happened thus folks haven't embraced JBI.

    While there is scope for standardization in integration, JBI misses the mark - JBI is no TCP/IP.

    Dont quite get what you are saying here, but if you are implying integration is not quite understood problem domain, you are wrong I believe, or perhaps your claim implies SOA is something new and not variation of process that has been done even before CORBA? Educated general public will hardly swallow 'SOA is new' cake.
    The point here is to call a standard a standard doesn't make it so. Standards have traditionally been about defining the characteristics of a focused problem domain then defining a set of rules that could be used to the solve the problem in a specified way. In the case of TCP/IP it was sending data between two networked devices. The spec defines all the various conditions that need to be catered for. The scope is small, the problem is well understood. The same is true for JMS (though the API could have been much cleaner if it wasn't influenced by vendors). Trying to standardize the whole integration platform just doesn't make sense. It shouldn't matter whether JBI uses OSGi or not, It shouldn't matter how transformations are performed. These sorts of things should be left to the implementor of the spec. I strongly believe that if we want successful standards in the EAI/SOA space they should focus purely on the _edge_ e.g., the points were interaction with people or other systems occur. This is why I would favour a well thought out connector architecture spec and efforts like SCA that focus on the wiring together of services rather than the runtime. Note that SCA and JBI don't compete, but if you have a common configuration JBI is less useful. If you have a common connector architecture (that might even look like BCs) then JBI is totally redundant.

    Savvy developers understand that standards mandating rigid approaches to problems with infinite variables

    Which would imply if someone disagrees with you then he is no savvy, because sky is red cause someone says so.
    Not at all. However, some developers do invest more than others into their career choice. Others don't have the time or inclination to follow every new technology that appears on the market and will go with what ever they are given in their organisation. Some don't have a choice. Would you say if someone doesn't like/understand the JBI spec he should be a HTML developer? (see above :) )

    Addressing the XML configuration piece, Service Component Architecture (SCA) seems to be a step in the right direction. However, the standard may still not be ready for prime-time, as some people deem it to be a bit too Web Services-centric, and the configuration is overly verbose. Moreover, SCA has not yet received the adoption required for it to be a front-runner.

    This pretty much summs it up. You dont believe any standard is good enough at the moment, except of course Mule 'standards'.
    I believe JBI isn't the right approach and SCA has promise but is not quite there yet. In the mean time I'm not touting Mule as a standard either. I am just expressing from some of my experiences in this space that the best way to standardize would be at the configuration level and the connector level. I've always taken the approach with Mule that we would embrace and support all standards that make sense (JEE standards, WS-*, W3C standards and loads of protocol support), but we haven't settled any one standard for the core container to give our users the most choice and flexibility when building SOA/EAI.
    Absolutely nothing personal here, just I generally do not appreciate bashing of open standards.
    No problem at all. It's always useful to hear other POVs. If you don't mind me asking, what is your stake in JBI? Cheers, Ross Mason MuleSource http://blog.rossmason.com
  8. This hardly demonstrates an endorsement for JBI, in fact it looks more like a rejection.
    Of course it is rejection but the question is why it was rejected? I strongly believe it was because of political and business reasons not because JBI has big technical flaws. Like I said, IBM and BEA marketing and sales divisions are very powerful and influential, and it was in IBMs and BEAs interests to claim invention of SOA ESB thing, SCA. Do you agree with me that political and business reasons influenced more to JBI rejection, than technical spec?
    Wow, that's a little unfair. The spec introduced lots of new concepts, jargon and is generally fairly complicated. I think you are saying that only those that have time to digest all this and also agree with the way the spec is defined should use it? Well, that's what has happened thus folks haven't embraced JBI.
    Integration is very hard and complicated domain and is very very different than common application development like EJB/Spring etc. If one is rejecting JBI just because it is expressed in a little too much formal way, he is obviously in wrong domain. Imagine how someone not understanding JBI would handle Sagas (long compensating biz tx).
    If you don't mind me asking, what is your stake in JBI?
    Have worked commercially with open source and proprietary ESBs, and one of the worst development experiences I had ever had is when I had to work with BEA ESB. It was really really annoying. And it was all due to not being based on standards. If AquaLogic was based on JBI, it would be piece of cake both for me personally and for business as well since time already invested in JBI research would have been reused (cheaper, faster to prototype etc). Have worked with ServiceMix and it was really cool. We (team) read JBI spec, discussed a bit, and when started working with ServiceMix it was really fast and productive. We knew what is the API contract between components etc. That is why standards are good: it is faster, cheaper and more productive. Would like to use Mule as well, however it will not happen until license is somehow fixed, since from my perspective it is broken now, and it is definitely not business friendly for small and medium sized companies which do not have legal departments to do research of license implications.
  9. Lets also see how 'hard' development with JBI is, taken from ServiceMix pojo tutorial: public class PojoReceiver implements MessageExchangeListener { private MessageList messageList = new MessageList(); public void onMessageExchange(MessageExchange exchange) throws MessagingException { NormalizedMessage message = exchange.getMessage("in"); getMessageList().addMessage(message); } public MessageList getMessageList() { return messageList; } } Stunningly complex stuff right there.
  10. Do you agree with me that political and business reasons influenced more to JBI rejection, than technical spec?
    I don't agree with that. IBM and BEA abstained because they felt they had a better approach, very different from the JBI approach, there were big technical differences here. It's not like the Microsoft/rest of world web services debacle. I think the vendors that did vote yes in the ballot decided not to adopt purely on technical reasons once they started to implement the spec.
    Integration is very hard and complicated domain and is very very different than common application development like EJB/Spring etc. If one is rejecting JBI just because it is expressed in a little too much formal way, he is obviously in wrong domain. Imagine how someone not understanding JBI would handle Sagas (long compensating biz tx).
    The fact is more and more development these days _is_ integration. Enterprises don't throw anything away. So integration has to be made easier or we're going to end up in a (bigger) mess.
    Would like to use Mule as well, however it will not happen until license is somehow fixed, since from my perspective it is broken now, and it is definitely not business friendly for small and medium sized companies which do not have legal departments to do research of license implications.
    Our license is the CPAL v1.0 license which is OSI Approved. You should have no issue adopting it if you want to, none of our ever growing community have an issue with it. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  11. The fact is more and more development these days _is_ integration. Enterprises don't throw anything away. So integration has to be made easier or we're going to end up in a (bigger) mess.
    If some developer is not able to comprehend the JBI, then I seriously doubt he will understand what long running compensating bizz tx are and what are the implications it brings to table. It could happen if sagas become common knowledge like JDBC today, which I doubt.
    I don't agree with that. IBM and BEA abstained because they felt they had a better approach, very different from the JBI approach, there were big technical differences here. It's not like the Microsoft/rest of world web services debacle. I think the vendors that did vote yes in the ballot decided not to adopt purely on technical reasons once they started to implement the spec.
    Well that's one interpretation that's for sure, with which I disagree. However could you explain again why Mule is not based on JBI in the context of one of my previous responses regarding the timeline when Mule 1.0 and when JBI have been released to general public?
    Our license is the CPAL v1.0 license which is OSI Approved. You should have no issue adopting it if you want to, none of our ever growing community have an issue with it.
    I don't believe it is open source since attribution clause is not in the open source spirit. However, licensing should be discussed maybe in different thread.
  12. Our license is the CPAL v1.0 license which is OSI Approved. You should have no issue adopting it if you want to, none of our ever growing community have an issue with it.
    I don't believe it is open source since attribution clause is not in the open source spirit. However, licensing should be discussed maybe in different thread.
    Well the license is OSI approved. It doesn't get more open source than that. But agreed, this is a separate point of discussion, maybe you should write a paper for TSS. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  13. Well the license is OSI approved. It doesn't get more open source than that. But agreed, this is a separate point of discussion, maybe you should write a paper for TSS.
    I dont have much experience with licensing but I'll try to summarize why CPAL is not open source in GPL-like sense. When I am using some GPL software and distributing it (as modified for example), I can not revoke rights given to me from previous entity in chain to the next receiver in the distribution chain. Lets say we have A, B and C. A is original creator, B is user of A's library and B distributes modified version to C. A -> B -> C. In GPL, B has no obligations to A except he must give same rights when distributing software to next person in chain that A has given to him. In CPAL, B has obligation to A with regard to attribution, which implies A is always at the top of food chain, people are always obliged to comply to the A. Which is not what open source is all about.
  14. Re: run-time standards[ Go to top ]

    Ross, I understand we have discussed, but i would like you to explain why exactly a standard is not appropriate for a run-time, as you state: "Trying to standardize the whole integration platform just doesn't make sense. It shouldn't matter whether JBI uses OSGi or not, It shouldn't matter how transformations are performed. These sorts of things should be left to the implementor of the spec." I already asked about your (Mule) best practices that evidently should come from experiences in the field, and with JAX-WS, et al, there is already the infrastructure for connecting disparate applications, or would u say that is 2 web services-based? I presume Mule supports this, so along with legacy, border-line proprietary, 1-to-1 JCA connections, the parameters for "edge" of 'SOA' are pretty much solved in the Java integration space... what is not convincingly accounted for is the clarity for customers to know they will not be locked-in to a given solution, i mean this is whole downfall of EAI, is it not? what is so special or even different about ESBs that EAI did not address as late as '99, or even ongoing? i think everyone on here generally wants Mule to succeed, at least in its potential to dramatically reduce end-point connections, and integrating legacy data and apps, but in the absence of a way-forward, your arguments on JBI boil down to: the vendors that have a stake in conceiving and propagating a non-standard integration environment, such as WebSphere, Microsoft, and to a certain extent WebLogic Integration (along with some lesser players that have long-lists of proprietary-based implementations) agree that we did not want to: a. re-write our software b. give the JCP the influence on the burgeoning ESB market c. argue that standards are appropriate In every case, universally, the arguments fall-down, and fall to the side as standardized implementations take-over a market...i understand u have some technical issues with run-time standardization, as bullet-pointed in your article, but do these overcome the inherent cost to customers of not having a standard to understand, develop to, and ultimately is not the cost borne by those vendors who do not support a standard... i mean, unless u own the platform, such as Windows, though not app servers since there is a portability argument, will not customers move to standardized platforms... i would guess u will gather adoption rates to support your thesis, but isnt it just a matter of time before customers demand some clarity on how they can avoid the long-discarded practice of vendor lock-in, or better yet, why doesn't Mule have an alternative to JBI as an argument, rather than the thoroughly historically discarded argument that: standards are great, they just dont apply well here...
  15. I don't have a problem with Ross Mason posting a critcism of JBI on this or any other forum. His employer and interest is clearly identified so there is no deceit here. I would wish for an article that gave a more substantive crtique of JBI. This one was so light that I can see why its perceived by some as self-serving instead of informative. I'd also like to hear more about what is gained or lost by non-adherence or adherence to JBI. Nevertheless, Mr. Mason has raised some good points that a JBI proponent should respond to. A point - counter point on JBI would be interesting.
  16. I don't have a problem with Ross Mason posting a critcism of JBI on this or any other forum. His employer and interest is clearly identified so there is no deceit here.

    I would wish for an article that gave a more substantive crtique of JBI. This one was so light that I can see why its perceived by some as self-serving instead of informative. I'd also like to hear more about what is gained or lost by non-adherence or adherence to JBI. Nevertheless, Mr. Mason has raised some good points that a JBI proponent should respond to. A point - counter point on JBI would be interesting.
    Have you worked with JBI? Have you read the spec and worked with JBI container implementation? Have you worked with Mule?
  17. Have you worked with JBI? Have you read the spec and worked with JBI container implementation? Have you worked with Mule?
    What is your point? First you don't think the Mason post should be allowed because he's with Mule and now you are questioning my right to be interested in what he and those who disagree with him have to say. This is a public forum that exists to encourage debate and discussion of topics of interest to this professional community. You seem to not understand how that works.
  18. The more pertinent criticism of Mason's piece ought to be that he didn't address the elephant in the room, namely that JBI has mostly failed gain a foothold because it's object orientation dress up in service oriented clothes. Here's a quick summation of what's wrong with JBI from an interview with ZapThink's Jason Bloomberg:
    JBI is more of a plug-in architecture where you can take Java-based components and plug them into a Java-based integration framework. Sure you can expose them as services, but it's really a single platform story.
    JCA on steroids is the dismissal I've heard from a few JBI detractors. It doesn't really matter who raised their hand in the JCP meeting back in 2005. The industry has voted with its feet. Outside of Sun's Open ESB and Apache ServiceMix, it's been non-existent, though it did recently pop up in the Eclipse Swordfish SOA runtime project. Swordfish likely is where JBI either makes a future for itself or it stays on the periphery. Having talked to all of the major vendors in this space about JBI, it's not getting supported unless there is massive grassroots adoption of it. They make faces like they just sniffed a dead cat when they hear the mention of JBI.
  19. The more pertinent criticism of Mason's piece ought to be that he didn't address the elephant in the room, namely that JBI has mostly failed gain a foothold because it's object orientation dress up in service oriented clothes.

    Here's a quick summation of what's wrong with JBI from an interview with ZapThink's Jason Bloomberg:

    JBI is more of a plug-in architecture where you can take Java-based components and plug them into a Java-based integration framework. Sure you can expose them as services, but it's really a single platform story.


    JCA on steroids is the dismissal I've heard from a few JBI detractors.

    It doesn't really matter who raised their hand in the JCP meeting back in 2005. The industry has voted with its feet. Outside of Sun's Open ESB and Apache ServiceMix, it's been non-existent, though it did recently pop up in the Eclipse Swordfish SOA runtime project. Swordfish likely is where JBI either makes a future for itself or it stays on the periphery.

    Having talked to all of the major vendors in this space about JBI, it's not getting supported unless there is massive grassroots adoption of it. They make faces like they just sniffed a dead cat when they hear the mention of JBI.
    Could it be, just a blind guess, that two biggest vendors in EE market, IBM and BEA, who didnt vote for JBI since they had their own vision, influenced the customer market? What do you think would have happened with JBI isf IBM and BEA fully adopted, supported and promoted JBI? We gotta make clear distinction between marketing and business strategies and technical details. If we are going to discuss second hand information (I heard what some guy said somewhere) that the quality of discussion will not be high. If you have used JBI and have seen some flaws please share so we can discuss techie stuff. Just dont give us here some second hand, business talks.
  20. @ William Childers "Mr. Mason has raised some good points that a JBI proponent should respond to" Since you haven't said you have used JBI and Mule I will assume you haven't. So the question is, how can you qualify his claims as good points based on only superficial stuff you have rad in this article and perhaps some other blogs? Please enlighten me. Thanks
  21. Could it be, just a blind guess, that two biggest vendors in EE market, IBM and BEA, who didnt vote for JBI since they had their own vision, influenced the customer market?

    What do you think would have happened with JBI isf IBM and BEA fully adopted, supported and promoted JBI?

    We gotta make clear distinction between marketing and business strategies and technical details. If we are going to discuss second hand information (I heard what some guy said somewhere) that the quality of discussion will not be high.

    If you have used JBI and have seen some flaws please share so we can discuss techie stuff. Just dont give us here some second hand, business talks.
    Nah. SAP, Oracle, JBoss, Progress, Software AG, Tibco and Microsoft don't want any part of it either. And it's got nothing to do with IBM and BEA, they just don't think it's a good way to implement services. Nobody adopted, supported or promoted JBI. In three years I haven't met anybody outside of Sun who has a good thing to say about it. Not one other vendor, not a single analyst, not a single consultant, not a single user. I agree business talks ... and JBI's doing next to no business. You can glom that into the "marketing" sphere if you want, but it's a technology in search of someone to care. Perhaps the greatest sin in Mason's piece is that he's taken time to kick a dead horse (or at least a quadriplegic one). I've already shared the fundamental criticism of JBI with you - that it's an OO hammer trying to pound square services into round Java platform holes. You can address that if you like, or not. Frankly, if you're working on a standard Java-centric integration project, why not just use JCA? It's got widespread support and chances are it's capable of performing the task at hand (unless you're building multi-platform services, in which case JBI probably isn't the tool you'll want to use).
  22. Quick correction, Tibco does support JBI (though Tibco doesn't seem to think it important enough to mention on ActiveMatrix Service Bus data sheet).
  23. Quick correction, Tibco does support JBI (though Tibco doesn't seem to think it important enough to mention on ActiveMatrix Service Bus data sheet).
    I believe that JBoss also has a JBI product .. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java and .NET
  24. I use JBI for what it's good for. One point here : JBI is for service integration not for service implementation, there SCA might be a better solution (but I still think that POJO + REST engine such as netkernel is even better). So to all the people criticizing JBI for not being good at making services and being too object oriented, they miss the target which is INTEGRATION. Nothing prevents JBI components to expose a service facade. I personnally use a REST on message approach. As for integration, I find JBI an excellent solution and with the integration of OSGI an even better one. Integration of messaging concept at its core is the right choice. Mule is also very good at it but of course Mr Mason is selling his product. I agree that JBI component packaging could be simpler but OSGI will simplify all of that. The JBI api are quite consistent and good. Jos.
  25. I use JBI for what it's good for.
    One point here : JBI is for service integration not for service implementation, there SCA might be a better solution (but I still think that POJO + REST engine such as netkernel is even better).
    So to all the people criticizing JBI for not being good at making services and being too object oriented, they miss the target which is INTEGRATION.
    Nothing prevents JBI components to expose a service facade. I personnally use a REST on message approach.
    As for integration, I find JBI an excellent solution and with the integration of OSGI an even better one. Integration of messaging concept at its core is the right choice.
    Mule is also very good at it but of course Mr Mason is selling his product.
    I agree that JBI component packaging could be simpler but OSGI will simplify all of that. The JBI api are quite consistent and good.

    Jos.
    Excellent post and I couldn't agree more about skirting around the integration spaghetti (where possible) with a resource-oriented approach.
  26. with a resource-oriented approach.
    I would dare to say resource oriented approach is not good. Please, read OASIS SOA Reference Model and Reference Architecture papers. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
  27. Quick correction, Tibco does support JBI (though Tibco doesn't seem to think it important enough to mention on ActiveMatrix Service Bus data sheet).
    Hi Michael, I believe TIBCO have abandoned JBI in their most recent release of ActiveMatrix. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  28. JBI Lame or Not?[ Go to top ]


    Nah. SAP, Oracle, JBoss, Progress, Software AG, Tibco and Microsoft don't want any part of it either.
    Ahh, not quite right. Tibco ActiveMatrix does support it. I'm guessing its being 'de-emphasised' as we type... :-)
  29. Nah. SAP, Oracle, JBoss, Progress, Software AG, Tibco and Microsoft don't want any part of it either. And it's got nothing to do with IBM and BEA, they just don't think it's a good way to implement services. Nobody adopted, supported or promoted JBI.

    In three years I haven't met anybody outside of Sun who has a good thing to say about it. Not one other vendor, not a single analyst, not a single consultant, not a single user. I agree business talks ... and JBI's doing next to no business. You can glom that into the "marketing" sphere if you want, but it's a technology in search of someone to care.


    Well, Progress Software AG have just brought into JBI in a big way with their purchase of IONA Technologies - and their is a very good reason for it - lots of users want a standards based ESB to avoid vendor lock-in - and have deployed Apache ServiceMix in very large enterprises. Maybe you're not talking to the right people ? ;)

    Rob Davies
    IONA FUSE: Enterprise Open Source Integration
  30. Well, Progress Software AG have just brought into JBI in a big way with their purchase of IONA Technologies - and their is a very good reason for it - lots of users want a standards based ESB to avoid vendor lock-in - and have deployed Apache ServiceMix in very large enterprises. Maybe you're not talking to the right people ? ;)
    Fair point Rob, though why ServiceMix instead of Synapse? I know I'm touching upon religious matters here, but I figured I'd toss that one out there for you. The argument for Synapse has been that it works far better across disparate platforms. And beyond that, if I'm an enterprise looking to avoid service lock-in (e.g. tying everything to the implementation) wouldn't I be better off using Artix than ServiceMix? Seems to me the larger question here is what ESB can do the best job in terms of loosely coupled, logic abstracted, stateless, composable, reusable, contract-based, autonomous and discoverable. If I'm adhering to those principles isn't Artix going to be the better, more solid state choice?
  31. And beyond that, if I'm an enterprise looking to avoid service lock-in (e.g. tying everything to the implementation) wouldn't I be better off using Artix than ServiceMix? Seems to me the larger question here is what ESB can do the best job in terms of loosely coupled, logic abstracted, stateless, composable, reusable, contract-based, autonomous and discoverable. If I'm adhering to those principles isn't Artix going to be the better, more solid state choice?
    We are not talking here about ServiceMix or Artix, we are talking about standards and JBI. What are the benefits and what are the drawbacks. You can achieve all non-functional requirements with JBI, just people haven't given JBI a chance.
  32. What anger[ Go to top ]

    Just my 5 cents on this topic. I'm the author of Open Source ESBs in Action book. We discuss both the Mule architecture as well as the ServiceMix / JBI architecture in the book and we show a lot of examples that show the differences and similarities for both Mule and ServiceMix. Having worked with both ESBs a lot I find this debate has a lot of anger, and I really don't see why. It's clear that JBI hasn't taken off as expected back in 2005, but we can see a number of great implementations including ServiceMix, PEtALS, Open ESB and JBoss ESB. The clear advantage of using JBI is that you can use JBI components from different implementations. In the book we show how to use a PEtALS and an Open ESB component within ServiceMix. So it really works! I think the choice for Mule to not implement JBI is a viable one, it's great that we now have several approaches to implement an open source ESB. I can't see why the opinion of Ross about JBI sets such a lot of anger. It's just his opinion and provides insight in his choice to not go for JBI with Mule. But this doesn't mean that JBI is not a viable approach. I think ServiceMix shows that a JBI implementation can work really well. In the posts I also see the debate of JBI vs SCA. I recently presented a talk at JavaOne about this debate, see slides. We showed that you can easily integrate a SCA implementation (like Apache Tuscany) and a JBI implementation (like ServiceMix). And think SCA is foremost a component model that standardizes the configuration of service components. This works nicely with a JBI container, which lacks such a component model. So maybe we can cut the angry remarks and really look at how we can use JBI, SCA and for example the Mule architecture to solve our integration challenges. Best regards, Tijs Rademakers
  33. Re: What anger[ Go to top ]

    I can't see why the opinion of Ross about JBI sets such a lot of anger. It's just his opinion and provides insight in his choice to not go for JBI with Mule.
    There is no anger from my side really, its just the way I communicate. If you, as an independent author, have written the original article it is highly likely I would not participate this eagerly in this thread. Now, if you do not see that there is business agenda being pushed behind the original article, bad for you. The only problem is when agenda is being pushed in public forums which should exist for the sake of community and not for the sake of companies, and especially when I think agenda is not correct in objective sense from my subjective view.
  34. Re: What anger[ Go to top ]

    Okay, my comment was a bit cynical. I understand your point about the business agenda and public forums and I agree on that. But having this said, I really think that this is Ross's opinion about JBI and not the business agenda of MuleSource. He actually explains pretty much the reasons we he decided to not go for JBI with the Mule project. And the article brings up the JBI debate again, and I think that can help in demystifying the misconceptions about JBI.
  35. Re: What anger[ Go to top ]

    He actually explains pretty much the reasons we he decided to not go for JBI with the Mule project.
    I believe JBI was not given a chance both in global and Mule contexts. People generally against it bailed out of it too early and never really tried to make it the best it can possibly be. If people really wanted to make integration/ESB space better, we would have by now imaginary: 1) EDI JBI Profile - send any type non-XML data over JBI infrastructure 2) Streaming JBI Profile - stream any kind of content over JBI infrastructure Profiles in context similar to the OASIS XACML Profiles, extensions over core standard.
  36. Re: What anger[ Go to top ]

    He actually explains pretty much the reasons we he decided to not go for JBI with the Mule project.


    I believe JBI was not given a chance both in global and Mule contexts. People generally against it bailed out of it too early and never really tried to make it the best it can possibly be.

    If people really wanted to make integration/ESB space better, we would have by now imaginary:

    1) EDI JBI Profile - send any type non-XML data over JBI infrastructure

    2) Streaming JBI Profile - stream any kind of content over JBI infrastructure

    Profiles in context similar to the OASIS XACML Profiles, extensions over core standard.
    This 'easier-to-bail-our' observation, or to rename it 'personal(company)-interests-first' has occurred with Spring as well. Just when JCP started adopting Spring concepts into formal standards, bang!, SpringSource announces release of their proprietary app server. I ain't saying it is so, I could be wrong afterall, but when looking at those events with following thought in mind 'Is there business benefit behind that move', if the answer is yes...reasonable doubt...
  37. Re: What anger[ Go to top ]

    The problem with the adoption of the JBI specification is that most companies chose another path. IBM went the SCA road (interestingly, WebSphere Process Server and WebSphere ESB - including the latest releases - still haven't adopted the SCA version hosted at OSOA) and vendors like Sonic, Tibco and Oracle pretty much went their own way. So we never saw a marketplace of JBI components where components from different vendors can be plugged-in to JBI containers from vendor X. Although in the open source space, we have quite a few JBI implementations with PEtALS, ServiceMix and Open ESB. So yes I think there is a business reason behind the choice to not go for JBI for all companies who didn't adopt JBI, including Mule. For handling non-XML data over JBI infrastructure, I think ServiceMix already provides a decent way to handle this. For example when you consume an text or objectmessage from a JMS queue with the servicemix-jms binding component, you can use a marshaler to add this content, for example as an attachment, to the JBI message before its sent on to the NMR. But yes, the industry (at least most integration vendors) lost its interest in JBI and therefore we didn't see any enhancements. But how about JBI v2, is there still any work being done there?
  38. I've already shared the fundamental criticism of JBI with you - that it's an OO hammer trying to pound square services into round Java platform holes. You can address that if you like, or not. Frankly, if you're working on a standard Java-centric integration project, why not just use JCA? It's got widespread support and chances are it's capable of performing the task at hand (unless you're building multi-platform services, in which case JBI probably isn't the tool you'll want to use).
    Come on now, saying JCA and JBI are the same is just plain silly. Please re-read the specs so you can get the facts straight. You haven't pointed out single technical JBI problem. All we saw here was: -JBI is bad cause original author says so -JBI is bad because some unknown guy says so -JBI is bad because people(IBM marketing/sales departments) say SCA is better If you are willing to take someone else's word instead of your own experience, its your choice. But at least say explicitly so, so we know you are not informed. Additionally, Mule is not truly open source, so its additional reason to doubt intent of the article. If they really wanted to be OS, they would go GPL/LGPL, not that mess of the license. http://mule.mulesource.org/display/MULE/License I mean, could it be more confusing than to add this clause to license "must occur on the graphic user interface employed by the end user to access such Covered Code ". The bottom line here from my point of view is that this license is in gray area, it is not in true open source spirit. So it is hard to not understand the original article as pushing personal agenda thru public media.
  39. Come on now, saying JCA and JBI are the same is just plain silly. Please re-read the specs so you can get the facts straight.

    You haven't pointed out single technical JBI problem. All we saw here was:
    -JBI is bad cause original author says so
    -JBI is bad because some unknown guy says so
    -JBI is bad because people(IBM marketing/sales departments) say SCA is better

    If you are willing to take someone else's word instead of your own experience, its your choice. But at least say
    explicitly so, so we know you are not informed.

    Additionally, Mule is not truly open source, so its additional reason to doubt intent of the article. If they really wanted to be OS, they would go GPL/LGPL, not that mess of the license.
    http://mule.mulesource.org/display/MULE/License

    I mean, could it be more confusing than to add this clause to license "must occur on the graphic user interface employed by the end user to access such Covered Code ".

    The bottom line here from my point of view is that this license is in gray area, it is not in true open source spirit. So it is hard to not understand the original article as pushing personal agenda thru public media.
    Nice job of evasion. Of course JBI and JCA aren't the same, but that's not the question. What is it that you think you need to do with JBI that you couldn't more or less achieve with JCA? I suspect if we took it down to real world cases (e.g. trying to integrate things inside the Java platform), the answer would precious little. Seems to me all you're doing here is embracing Sun's marketing and insisting JBI's got relevance without addressing any of the multiple criticisms lodged against it. Two simple questions for you: do you consider JBI to be, fundamentally, OO programming, and, if so, will that give you the level of abstraction required to build distributed (e.g. multi-platform) services? I've got no skin in whether Mule is a better ESB, so if you think that, or anything else you've typed, is somehow going to offend me, guess again.
  40. Nice job of evasion. Of course JBI and JCA aren't the same, but that's not the question. What is it that you think you need to do with JBI that you couldn't more or less achieve with JCA? I suspect if we took it down to real world cases (e.g. trying to integrate things inside the Java platform), the answer would precious little.
    First, I do not understand what evasion you are talking about, please elaborate. Now regarding the second part, come on, you could use almost any stack to develop ESB, I could take Axis or Cxf and build ESB on top of it, or ActiveMq, or Camel or even Spring. You can solve any problem in multiple ways, we are talking about choosing the right one for problem at hand. So please no more "I'll enlighten you speeches".
    Seems to me all you're doing here is embracing Sun's marketing and insisting JBI's got relevance without addressing any of the multiple criticisms lodged against it.
    Wrong!!!! If you have read carefully, I have agreed JBI has issues (all XML stuff), but I did not skip "addressing" part, people like Mule developers have bailed on addressing. Instead of 'fixing' the standard and making it better they developed their proprietary solutions and totally skipped JBI. So whom should I trust, vendor who delivered standard (Sun) or vendor who bailed on standard and developer proprietary solution?
    Two simple questions for you: do you consider JBI to be, fundamentally, OO programming, and, if so, will that give you the level of abstraction required to build distributed (e.g. multi-platform) services?
    Ofc it is OO when you implement intra-ESB SE or BC since you do it in Java, however dependency between components (service contract definition) is WSDL based. But please, go download ServiceMix and try it. You can configure distributed ESB (multiple ESB instances on different machines with partitioned services able to detect one another without custom programming required) in minutes. Bottom line: yes you can build distributed, modular and multi-platform services in JBI/ServiceMix. Been there, done that. Next please.
    Or am I only non-biased when I selectively apply the complaint that vendors abuse open standards committees and try to generate false hype?
    Yes Sun has abused (a little, community has made significant benefit from overall JCP performance) JCP we all know that. However, you dont mention BEA and IBM abusing their influence in order to prevent JBI hitting main stream. Double standards much?
    but I still think that POJO + REST engine such as netkernel is even better)
    How can you support statement when contract between components is not defined in standard way (WSDL)? Good luck defining global IT strategy for any serious company with services defined in REST/Pojo. I really dont have energy now to try to fight the fight WHY STANDARS ARE IMPORTANT. If you (not you personally, general public) do now see and understand that then I guess no senior IT positions for you. With my business hat on, it is all about money and risk. If I save X money now by using Mule opposed to JBI container, and in 5 years Mule company is out of business (I would not like this to happen, imaginary scenario for illustrative purposes), and mission critical bug is discovered in company with no IT support (all IT operations are outsourced to external vendors), I'll have to pay Y to get it fixed. Since it is non-standard solution, workforce market is smaller than in standard tools, so i will have to pay more since demand is larger than supply. Since it is mission critical and requires expertise it will have to be bought for even more money. Plus, add costs for future support. If Y > X, guess who wins. And it terms of development costs associated with Mule and ServiceMix, I dont think there is any significant difference. Same thing with daily maintenance. In terms of pure runtime performance, is it actually reasonable to compare wrappers-around-wrappers a.k.a. ESBs?
  41. First, I do not understand what evasion you are talking about, please elaborate. Now regarding the second part, come on, you could use almost any stack to develop ESB, I could take Axis or Cxf and build ESB on top of it, or ActiveMq, or Camel or even Spring. You can solve any problem in multiple ways, we are talking about choosing the right one for problem at hand. So please no more "I'll enlighten you speeches".
    And the question was how many real world "problems" are you realistically going to encounter that you can't solve with JCA instead of JBI?
    Wrong!!!! If you have read carefully, I have agreed JBI has issues (all XML stuff), but I did not skip "addressing" part, people like Mule developers have bailed on addressing. Instead of 'fixing' the standard and making it better they developed their proprietary solutions and totally skipped JBI. So whom should I trust, vendor who delivered standard (Sun) or vendor who bailed on standard and developer proprietary solution?
    Why is it up to them to fix a "standard" they and pretty much everyone else doesn't care about? You've said it yourself. Anyone can download ServiceMix or OpenESB. There's nothing stopping them. My advice would be not to "trust" any vendor, but that's just me.
    Ofc it is OO when you implement intra-ESB SE or BC since you do it in Java, however dependency between components (service contract definition) is WSDL based.

    But please, go download ServiceMix and try it. You can configure distributed ESB (multiple ESB instances on different machines with partitioned services able to detect one another without custom programming required) in minutes.

    Bottom line: yes you can build distributed, modular and multi-platform services in JBI/ServiceMix. Been there, done that. Next please.
    I'm fully aware that it doesn't require custom work as long as you stay within the strict parameters of the JBI universe, the problem is most of the world exists outside those parameters and likely won't submit to being reduced to them (and I'm not talking about vendors here).
    Yes Sun has abused (a little, community has made significant benefit from overall JCP performance) JCP we all know that. However, you dont mention BEA and IBM abusing their influence in order to prevent JBI hitting mainstream. Double standards much?
    All they did was not vote to ratify it and then not support it. They didn't make anyone else not support it. SAP and Oracle didn't ask IBM and BEA before they chose to ignore JBI. You keep acting like two companies that others should have been happy to undercut somehow poisoned the well, when the rather obvious truth is that what we've got here is Murder on the Orient Express. Everybody did it, including users, who greeted JBI with a collective yawn.

    How can you support statement when contract between components is not defined in standard way (WSDL)? Good luck defining global IT strategy for any serious company with services defined in REST/Pojo.

    I really dont have energy now to try to fight the fight WHY STANDARS ARE IMPORTANT. If you (not you personally, general public) do now see and understand that then I guess no senior IT positions for you.

    With my business hat on, it is all about money and risk. If I save X money now by using Mule opposed to JBI container, and in 5 years Mule company is out of business (I would not like this to happen, imaginary scenario for illustrative purposes), and mission critical bug is discovered in company with no IT support (all IT operations are outsourced to external vendors), I'll have to pay Y to get it fixed. Since it is non-standard solution, workforce market is smaller than in standard tools, so i will have to pay more since demand is larger than supply. Since it is mission critical and requires expertise it will have to be bought for even more money. Plus, add costs for future support.

    If Y > X, guess who wins. And it terms of development costs associated with Mule and ServiceMix, I dont think there is any significant difference. Same thing with daily maintenance.

    In terms of pure runtime performance, is it actually reasonable to compare wrappers-around-wrappers a.k.a. ESBs?
    Outside of Iona (which recently got bought), who's supporting anything I build with ServiceMix? If the litmus test is going to be what if I've got a bug in five years, then you're making a de facto argument to go with a monster-sized vendor (an argument with which I'd heartily disagree). Like I said way up at the top, Swordfish may be the thing that breathes new life into JBI by actually giving it something to plug into. It wouldn't surprise me to see Swordfish get used as a (less limiting) runtime, allowing developers to leverage the JBI super container model where appropriate. As for standards, WSDL's fine, but not everything is going to have a WSDL contract in front of it, nor should it.
    I would dare to say resource oriented approach is not good. Please, read OASIS SOA Reference Model and Reference Architecture papers. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
    HTTP is a standard too. As for the value of taking a resource-oriented approach, I'll defer to Dan Diephouse, who built the XFire Web services stack. For the record, I'm not an either/or guy on this point. My stance is if you can't deliver "and" then I'm not terribly interested in that sort of limitation. I want consistent semantics (something you can't buy) and I want configuration management. And I think you're failing to recognize how far beyond JBI the world has moved. Check out the OASIS SOA Reference Architecture. In particular pay attention to the visibility model on page 55. Here's the money quote - "Visibility and interoperability in a SOA ecosystem requires more than location and interface information, or the traditional Application Programming Interface (API)." In other words, JBI seeks to standardize all the wrong stuff.
    We are not talking here about ServiceMix or Artix, we are talking about standards and JBI. What are the benefits and what are the drawbacks. You can achieve all non-functional requirements with JBI, just people haven't given JBI a chance.
    Rob was talking about Iona and I responded to his post. And the question was, for the big things that I happen to care about (and I listed them) wouldn't I be better off with Artix? Artix has a stellar technical architecture, one that was years ahead of what OASIS is trying to formalize at this very moment. I agree that JBI ostensibly might seem like the right tool for some projects, but the larger realization taking hold with service-oriented architecture is that such project-centric thinking is literally choking the businesses these applications were meant to serve. JBI is a Java platform tool, which can actually get in the way of achieving the goals set forth in the OASIS SOA-RM and SOA-RA if you allow the tool to dictate your semantics and overly limit your ability to incorporate new efficiencies. If you made JBI your enterprise platform for tasks such as assembly, reuse, modification and integration, I submit you'd find yourself unable to achieve the agility SOA is supposed to deliver.
  42. And the question was how many real world "problems" are you realistically going to encounter that you can't solve with JCA instead of JBI?
    Probably none from tech perspective. Probably a lot from business perspective. The point is JCA has different scope and purpose than JBI. There is no reference in JCA spec of abstract contract definition not bound to any concrete implementation, such as WSDL. JBI is based on WSDL not just as format of representing service contracts, but also as SOA-ish model of abstraction. If you do not see the difference between JCA and JBI now I do not believe you would 'see' it even if I wrote line by line comparison between JCA and JBI.
    Why is it up to them to fix a "standard" they and pretty much everyone else doesn't care about?...
    Like I said, and you seem to confirm my doubts, it is easiest to bail and do not care. Mule did provide only ESB implementation, they did not provide standard which would drive the implementation of ESB and components hosted on ESB. And JBI and its implementations have done that. Mule did not provide alternative, but rather only their proprietary implementation.
    the problem is most of the world exists outside those parameters and likely won't submit to being reduced to them (and I'm not talking about vendors here)
    Please, go use any JBI implementation, find concrete technical problem that is caused by flaws in JBI specs and I'll concede. You speak on really really abstract terms here.
    who greeted JBI with a collective yawn.
    Typical FUD. It is so because you say so. And please ignore all comments and links to blogs which support my claim that IBM and BEA had something against JBI in business context, and not in technical context.
    As for standards, WSDL's fine, but not everything is going to have a WSDL contract in front of it, nor should it.
    Yes man, I know you can find exception for every rule. I know you can find domain which you can not model effectively in WSDL. You are forgetting WSDL is THE STANDARD when defining service contract in platform neutral way. I am not pushing WSDL, nor is Sun. Entire industry is pushing WSDL. Maybe you would be kind to invent your of service specification standard and share with us. Finding exception to the rule aint too hard.
    HTTP is a standard too.
    Yes it is and it has nothing to do with ESB/JBI discussion since it is a transport/wiring protocol, at lower level of abstraction which has nothing to do with ESB concepts we are talking about. FYI, you can do resource-orineted approach over JMS as well, so point is?
    In other words, JBI seeks to standardize all the wrong stuff.
    What wrong things? JBI's default format/standard for specifying service definition is WSDL. I really do not understand to what wrong stuff are you referring here to? Development, deployment and/or runtime model? You suggesting WSDL is bad?
    JBI is a Java platform tool, which can actually get in the way of achieving the goals set forth in the OASIS SOA-RM and SOA-RA if you allow the tool to dictate your semantics and overly limit your ability to incorporate new efficiencies. If you made JBI your enterprise platform for tasks such as assembly, reuse, modification and integration, I submit you'd find yourself unable to achieve the agility SOA is supposed to deliver.
    Have you ever written any SE/BC in JBI? Please do if you havent. I am really not flaming you or trying to discredit you, but you talking in the same sentence in 3/4 different levels of abstraction. You mention SOA RM, WSDL, JBI and Java. I mean come on. Also, if you havent written not a single SE/BC and you say this "you'd find yourself unable to achieve" I am really doubting your credibility. So I will try to conclude: if you haven't written any JBI SE/BC, my above sentence stands correct IMHO, if you have written please provide concrete problems you have encountered so we can discuss.
  43. Probably none from tech perspective. Probably a lot from business perspective.
    The point is JCA has different scope and purpose than JBI. There is no reference in JCA spec of abstract contract definition not bound to any concrete implementation, such as WSDL. JBI is based on WSDL not just as format of representing service contracts, but also as SOA-ish model of abstraction.
    If you do not see the difference between JCA and JBI now I do not believe you would 'see' it even if I wrote line by line comparison between JCA and JBI.
    Seems to me that from a business perspective, all you're talking about is a new way to do EAI and no one needs that. You're basically using SOA to do what you could already do. There's really no point to that. I spend my entire working life talking to and working with people either deploying, analyzing or selling SOA. I've been doing it for eight years. I know companies that are beside themselves over the fact that all SOA has accomplished for them is a few integration projects.

    Like I said, and you seem to confirm my doubts, it is easiest to bail and do not care. Mule did provide only ESB implementation, they did not provide standard which would drive the implementation of ESB and components hosted on ESB. And JBI and its implementations have done that. Mule did not provide alternative, but rather only their proprietary implementation.
    I agree it was easy to bail on JBI once everyone realized it was trying to standardize the wrong stuff. SOA isn't about ESBs. They're tools that can perhaps be used in an SOA, or not, and standardizing them on the Java platform was never a user concern.
    Please, go use any JBI implementation, find concrete technical problem that is caused by flaws in JBI specs and I'll concede. You speak on really really abstract terms here.
    Well, it's hard to go out and find a problem people were smart enough to avoid.
    Typical FUD. It is so because you say so.
    And please ignore all comments and links to blogs which support my claim that IBM and BEA had something against JBI in business context, and not in technical context.
    One of us follows these matters far more closely than the other, and it's not you. Yes, IBM and BEA didn't like JBI. That's common knowledge. They didn't force almost everyone else not to like it too. And, having spoken directly to all of the major non-supporting vendors about why they don't like JBI, I can tell you firsthand that the first thing out of their mouths is that it's technology in search of business problem that doesn't exist.
    Yes man, I know you can find exception for every rule. I know you can find domain which you can not model effectively in WSDL. You are forgetting WSDL is THE STANDARD when defining service contract in platform neutral way. I am not pushing WSDL, nor is Sun. Entire industry is pushing WSDL. Maybe you would be kind to invent your of service specification standard and share with us. Finding exception to the rule aint too hard.
    You are really out of date. Yes, WSDL is an established and widely used standard that's going to survive well into the future. However, there are A LOT of people who could tell you that WS-* integration has got its limitations and, if you're going to bring SOA into the mix (and you did), then that's only one way to skin the integration cat. In fact, I know some companies that are applying the old 80-20 rule to REST and WS-*, with WS-* being the 20.
    Yes it is and it has nothing to do with ESB/JBI discussion since it is a transport/wiring protocol, at lower level of abstraction which has nothing to do with ESB concepts we are talking about. FYI, you can do resource-orineted approach over JMS as well, so point is?
    Point is you're using a bazooka to light your cigarette.
    What wrong things? JBI's default format/standard for specifying service definition is WSDL. I really do not understand to what wrong stuff are you referring here to? Development, deployment and/or runtime model? You suggesting WSDL is bad?
    WSDL is fine. It does what it does and it does it well in that context. Yet you brought up the SOA-RM and, if you actually dig through the SOA-RA and digest what it's saying, you might just start to realize that the API-centric approach to SOA taken by JBI is a side alley to the whole process.
    Have you ever written any SE/BC in JBI? Please do if you havent.
    I am really not flaming you or trying to discredit you, but you talking in the same sentence in 3/4 different levels of abstraction. You mention SOA RM, WSDL, JBI and Java. I mean come on.

    Also, if you havent written not a single SE/BC and you say this "you'd find yourself unable to achieve" I am really doubting your credibility.

    So I will try to conclude: if you haven't written any JBI SE/BC, my above sentence stands correct IMHO, if you have written please provide concrete problems you have encountered so we can discuss.
    Credibility? Hey, I know where folks like Diephouse, Fremantle, Manes, Bloomberg, Boubez, Matsumura and dozens of others stand on these issues and it's not with the parochial concerns over writing a JBI SE/BC (from someone using pseudonym). You introduce SOA into the topic, but it's clear that all you're talking about are glorified EAI projects. I fully recognize you can do a successful integration project using JBI given the right parameters. Yet if you tried to make that central to your enterprise architecture, like State Street Corp. or dozens of others like them, the constraints of JBI would croak you. And that's the level of abstraction that really counts. I'm not arguing that JBI is a failure as a Java platform tool, but the problem with it, the problem I mentioned way back in my first post in this thread, is that JBI pretty much stops at being a Java platform tool. If you're a Java platform developer that may be all you care about, but even then it's just a different way of doing EAI and it's not really delivering the larger benefits this standardization and architectural upheaval was supposed to deliver.
  44. Just ran across this article by Steve Vinoski about how RPC systems represent a dead end when it comes to distributed computing. It does a superior job of laying out the reasons why something like JBI often gets panned for not being the right method to realize the distributed computing nirvana envisioned by SOA. Even if you're not inclined to agree with him, the article is worth a read as Vinoski's got enough brain for three heads when it comes to matters like this.
  45. If you read Steve's article carefully you'll see he is not overly fond of any of the standard RPC distributed computing infrastructures and that includes the standard SOAP, WSDL, WS-* based stacks that lot of other ESBs push regardless of whether they implement JBI or not. So, that's a bit off topic, IMHO... However, I think the positioning of JBI as a Java-only framework is a little misplaced. Maybe it's due to poor exposition of JBI but JBI was never intended to be a service development framework - in other words, you'd never expect to write JBI based APIs to implement your services. As another poster has pointed out it's an integration framework, not a service development or composition framework like SCA. A JBI container can *host* a service in an SE and you can use appropriate BCs to communicate with non-Java systems. e.g., a CICS BC can allow you to expose a CICS component as a service endpoint in a JBI container. What I hope JBI would address in its next release is non XML data in NMR (without resorting to XOP based packaging which Keith has demonstrated), ability to short-circuit NMR (why does everything have to pass through NMR?), interceptor chains and RESTful endpoints (which would mean no WSDL) - from a presentation I saw from Peter Walker lot of these features are on the cards for JBI 2.
  46. It does a superior job of laying out the reasons why something like JBI often gets panned for not being the right method to realize the distributed computing nirvana envisioned by SOA.
    OMG. JBI and its implementations do not depend on any kind of distributed communication method/type nor on any kind of transport and wiring protocol. You can do any kind of distributed computation model from any level of abstraction you can think of: sync, async, req-respo [add your favorite here]. JBI is not constraining you to any distributed computing model in any way.
  47. Just ran across this article by Steve Vinoski about how RPC systems represent a dead end when it comes to distributed computing.

    It does a superior job of laying out the reasons why something like JBI often gets panned for not being the right method to realize the distributed computing nirvana envisioned by SOA. Even if you're not inclined to agree with him, the article is worth a read as Vinoski's got enough brain for three heads when it comes to matters like this.
    Please take a look at this diagram.http://servicemix.apache.org/5-jbi.data/jbi-architecture.png JBI does not impose any kind of restrictions on communication type/model between Binding Component and External Service Provider. You can implement this communication any way you like, COBOL, plain TCP/IP etc etc. Only thing Binding Component has to do is to know how to translate between request from NMR to itself over formalized WSDL contract into some back end operation over some transport. So, NMR and BC contract is WSDL, most likely over java method call since it is usually in same JVM. BC and External Service Provider is anything you like communicated over any medium you like. It is up to BC to translate between abstract operation names defined in WSDL into TCP/IP packet for example.
  48. Please take a look at this diagram.http://servicemix.apache.org/5-jbi.data/jbi-architecture.png

    JBI does not impose any kind of restrictions on communication type/model between Binding Component and External Service Provider. You can implement this communication any way you like, COBOL, plain TCP/IP etc etc.

    Only thing Binding Component has to do is to know how to translate between request from NMR to itself over formalized WSDL contract into some back end operation over some transport.

    So, NMR and BC contract is WSDL, most likely over java method call since it is usually in same JVM.

    BC and External Service Provider is anything you like communicated over any medium you like. It is up to BC to translate between abstract operation names defined in WSDL into TCP/IP packet for example.
    Yes, all I have to do is code the SEs and BCs, then put WSDLs in front of them, then run them through the NMR. There's certainly no inefficiency in THAT process. That's so much easier than typing GET. And that with no component library, no streaming and no policy/configuration management (something I can add fairly easily to WCF - which offers some rather elegant serialization flexibility, and where the Service, Operation and Messaging abstractions aren't linked WS-*). I really don't mean to come off as fundamentally disliking JBI. If we're talking about the sort of constrained problem set you're seemingly focused on (integrating components into a Java runtime), then it's one of many viable tools you could use (and it is a problem set many Java developers need to solve). It understands its universe. Yet when we bring scale and extensibility into the discussion, when we expand the problem set and seek to handle complexities beyond raw integration, then JBI does not necessarily profile as the right tool for the job (unless, like SOPERA, you've put a lot of work into adding policy and resource management capabilities).
  49. Seems to me that from a business perspective, all you're talking about is a new way to do EAI and no one needs that.
    From the business perspective that if you use wrong tool for the problem at hand you will lose money down the road. Thats why smart people will not use JCA for real integration projects.
    You're basically using SOA to do what you could already do. There's really no point to that. I spend my entire working life talking to and working with people either deploying, analyzing or selling SOA. I've been doing it for eight years. I know companies that are beside themselves over the fact that all SOA has accomplished for them is a few integration projects.
    WTH man?? Please choose level of abstraction you want us to discuss things at. You start talking about JCA vs JBI and then you switch to SOA SOA SOA. I gave you one difference between JCA and JBI: WSDL - formalized service contract definition. You reply with SOA SOA SOA.
    Point is you're using a bazooka to light your cigarette.
    I have no idea what are you talking about. It was not me who mentioned WIRING and TRANSPORT protocol in the MIDDLE of thread about ABSTRACT concepts.
    Yet you brought up the SOA-RM and, if you actually dig through the SOA-RA and digest what it's saying, you might just start to realize that the API-centric approach to SOA taken by JBI is a side alley to the whole process.
    You mentioned resource oriented approach, so I provided the SOA RM link so you can see the industry trend is quite the opposite.
    Well, it's hard to go out and find a problem people were smart enough to avoid.
    Credibility?
    Yes, in my opinion you have zero credibility to discuss JBI. First of all, you haven't written not a single BC/SE. And you come here to 'teach' us how JBI is bad? How can you have courage to claim you know something if you haven't event tried it? So far you have not managed to provide not a single technical flaw in JBI spec. All you did was business marketing talk, backed up with 0 experience in JBI, based on superficial information you have found on internet. So I'll give you 2 out of 10. Nice try, good marketing sales moves and talk, zero techie background. No actually I'll give you 3/10 because of your cocky 'were smart enough to avoid' attitude.
  50. From the business perspective that if you use wrong tool for the problem at hand you will lose money down the road. Thats why smart people will not use JCA for real integration projects.
    That's not a business perspective, that's a developer preference perspective (and your preferences will change). I've already said that JBI has it's place. It's not bad technology. If I'm building components in GlassFish and looking to integrate them with a bunch of other components with Java APIs, then JBI might be the tool to use. As for JCA, I suspect it's still being used at orders of magnitude beyond JBI, and likely for bigger ticket projects to boot. It's a stable integration framework and it connects to everything (SWIFT, Ingres, Informix, Tuxedo, UNIX, .NET, COM, CORBA, EJB, 3GL, 4 GL, any MQ you care to name, any enterprise app you care to name, etc.). The CCI works.
    WTH man?? Please choose level of abstraction you want us to discuss things at. You start talking about JCA vs JBI and then you switch to SOA SOA SOA. I gave you one difference between JCA and JBI: WSDL - formalized service contract definition. You reply with SOA SOA SOA.
    I'm sorry, I didn't realize you were the only one allowed to jump between levels of abstraction as it suited you. Of course, why are you using a WSDL? I mean, is it because of the performance advantages it gives you? Of course not. It's verbose and inefficient, yet it's supposed to allow you to embrace a laundry list of service-oriented principles (mentioned way up high in this thread). So you're sitting here telling me how wonderful WSDLs are (and I've got nothing against them) and how it will allow people to embrace those SO principles, yet when it gets pointed out (explicitly) that the major knock on JBI is that it runs roughshod over those SO principles, you hide behind a flimsy abstraction defense. You're doing things in the name of a big picture you don't even see.
    I have no idea what are you talking about. It was not me who mentioned WIRING and TRANSPORT protocol in the MIDDLE of thread about ABSTRACT concepts.
    God forbid anyone point out that there might be better ways of moving data around than embracing the level of abstraction you personally care about at this moment. Why mess with the middle man that is a JBI binding component? Why take the perhaps unnecessary step of turning a BPEL workflow into a service engine component? The answer had better not be so that you can use JBI. That's just busywork coding. You're abstracting to use a framework. Did it ever occur to you how backwards that is? Serious question here, are you reusing any of you SE components or BCs in any place other than a JBI runtime?
    You mentioned resource oriented approach, so I provided the SOA RM link so you can see the industry trend is quite the opposite.
    Oh, I know what the industry trend is. I know where Rails2, Mule, WSO2, SpringSource, IBM, Microsoft (and soon Oracle, SAP and JBoss/Red Hat) are headed - toward resource-orientation. If you read the SOA-RA (not that I have any hope you will) you should notice, unmistakably, where it's kicking open the door for REST and moving well beyond the plumbing concerns of writing a BC/SE.
  51. That's not a business perspective, that's a developer preference perspective
    If you agree with me that you and I will not come to understanding here even in million years, I would suggest we stop quoting each other so our e-peen contest does not hijack the thread. It is not worth the time.
  52. That's not a business perspective, that's a developer preference perspective

    If you agree with me that you and I will not come to understanding here even in million years, I would suggest we stop quoting each other so our e-peen contest does not hijack the thread. It is not worth the time.
    Fair enough, though I am honestly curious about whether you've reused any SEs or BCs outside a JBI runtime (or even in it).

  53. If you agree with me that you and I will not come to understanding here even in million years, I would suggest we stop quoting each other so our e-peen contest does not hijack the thread. It is not worth the time.


    Fair enough, though I am honestly curious about whether you've reused any SEs or BCs outside a JBI runtime (or even in it).
    JBI SE/BC is wrapper around other components/applications/libraries. Noone needs to used JBI components outside of JBI because it is just a Adapter pattern. (http://en.wikipedia.org/wiki/Adapter_pattern) JBI is adapting WSDL logical operation names into the API provided by component it is adapting. Lets say I have J2SE business application which does payment processing. Application was initially developed in J2SE with no integration in mind. If I wanted to expose this application in JBI ESB environment, all I have to do in SE for example is to map logical WSDL name to concrete method on some Java object in library being adapted. Entire business logic is still contained in original application. Your comments show you have lack of basic understanding what JBI is and what it does. JBI BC/SE does not have to and it should not contain any kind of business logic or business rules (in local context, it could for example contain ESB global wide rules), because it is just delegating processing to component which is being adapted. That is 100% reuse.
  54. In before
    overly limit your ability to incorporate new efficiencies.
    business FUD type of response.
  55. http://svn.apache.org/repos/asf/servicemix/smx3/trunk/common/servicemix-components/src/main/java/org/apache/servicemix/components/ Drools: 3 classes File: 2 classes RSS: 2 classes Quartz: 4 classes Should I count LoC? Really 'complex' stuff right there.
  56. I believe those are not JBI Binding Connectors & Service Engines. You are counting the classes of ServiceMix lightweight components. I believe that these can only be accessed via the NMR by deploying them using the servicemix-bean or servicemix-lwcontainer SE.
  57. I believe those are not JBI Binding Connectors & Service Engines. You are counting the classes of ServiceMix lightweight components. I believe that these can only be accessed via the NMR by deploying them using the servicemix-bean or servicemix-lwcontainer SE.
    You stand correct, I looked at the wrong package. On my local PC I have SEs and BCs in 'deployables' directory but couldnt find it on public SVN. Correct numbers are (counted from SM on my PC): Drools: 7 Quartz: 8 File: 4 Done have RSS on my local SM repo. Someone knows why SEs and BCs are not available via browsing? I provided the link to illustrate how easy it is to enable some library/protocol/system so it can participate in JBI/ESB environment. Especially it is interesting to see Drools/ODE component since there is no business logic/rules in JBI part, JBI is just acting as delegate.
  58. Take a look at http://svn.apache.org/repos/asf/servicemix/components/. It looks like the JBI Components have been moved to this location.
  59. I suspect that this has probably been done to isolate the JBI components from the SMX3 and SMX4 trees, since they are used in both versions.
  60. Take a look at
    http://svn.apache.org/repos/asf/servicemix/components/.
    There you are! Thanks for the link.
  61. JBI SE/BC is wrapper around other components/applications/libraries. Noone needs to used JBI components outside of JBI because it is just a Adapter pattern. (http://en.wikipedia.org/wiki/Adapter_pattern)

    JBI is adapting WSDL logical operation names into the API provided by component it is adapting. Lets say I have J2SE business application which does payment processing. Application was initially developed in J2SE with no integration in mind. If I wanted to expose this application in JBI ESB environment, all I have to do in SE for example is to map logical WSDL name to concrete method on some Java object in library being adapted. Entire business logic is still contained in original application.

    Your comments show you have lack of basic understanding what JBI is and what it does.

    JBI BC/SE does not have to and it should not contain any kind of business logic or business rules (in local context, it could for example contain ESB global wide rules), because it is just delegating processing to component which is being adapted. That is 100% reuse.
    Oh, I totally understand all of that. You're talking about EAI, essentially using JBI (with the NMR as the hub) to integrate things. That's the problem, and Ross hit it on the head with his article. You're writing a WSDL for a single job. It doesn't even sound like you're registering the WSDL anywhere so that others might reuse that same J2SE component for another service -- something I ought to be able to do across multiple ESBs if I've got a good WSDL. And this is really the crux of it - "Noone needs to used JBI components outside of JBI because it is just a Adapter pattern." I feel fairly comfortable in stating there isn't a business of any significant size on this planet that is doing all of its integration projects inside a JBI-compliant ESB. So you're just using this tool to perform adapter integration (and I fully allow that for what you're integrating it may be an easier to use adapter pattern - never once argued that it wouldn't be) and it's go no relevance to the ecosystem outside of JBI. You're writing one-off WSDLs and you're not even reusing those inside of JBI. Right there is why few people give a rat's hindquarters about JBI. Thanks for finally admitting this is just an adapter pattern (and I've got nothing against it in that context). Now kindly explain to me why a business needs to care about yet another adapter pattern? I suggest you actually sit down and digest what the SOA-RM says and consider the relative unimportance of yet another adapter pattern in that context.
  62. JBI SE/BC is wrapper around other components/applications/libraries. Noone needs to used JBI components outside of JBI because it is just a Adapter pattern. (http://en.wikipedia.org/wiki/Adapter_pattern)

    JBI is adapting WSDL logical operation names into the API provided by component it is adapting. Lets say I have J2SE business application which does payment processing. Application was initially developed in J2SE with no integration in mind. If I wanted to expose this application in JBI ESB environment, all I have to do in SE for example is to map logical WSDL name to concrete method on some Java object in library being adapted. Entire business logic is still contained in original application.

    Your comments show you have lack of basic understanding what JBI is and what it does.

    JBI BC/SE does not have to and it should not contain any kind of business logic or business rules (in local context, it could for example contain ESB global wide rules), because it is just delegating processing to component which is being adapted. That is 100% reuse.


    Oh, I totally understand all of that. You're talking about EAI, essentially using JBI (with the NMR as the hub) to integrate things.

    That's the problem, and Ross hit it on the head with his article. You're writing a WSDL for a single job. It doesn't even sound like you're registering the WSDL anywhere so that others might reuse that same J2SE component for another service -- something I ought to be able to do across multiple ESBs if I've got a good WSDL.

    And this is really the crux of it - "Noone needs to used JBI components outside of JBI because it is just a Adapter pattern."

    I feel fairly comfortable in stating there isn't a business of any significant size on this planet that is doing all of its integration projects inside a JBI-compliant ESB. So you're just using this tool to perform adapter integration (and I fully allow that for what you're integrating it may be an easier to use adapter pattern - never once argued that it wouldn't be) and it's go no relevance to the ecosystem outside of JBI. You're writing one-off WSDLs and you're not even reusing those inside of JBI. Right there is why few people give a rat's hindquarters about JBI.

    Thanks for finally admitting this is just an adapter pattern (and I've got nothing against it in that context). Now kindly explain to me why a business needs to care about yet another adapter pattern? I suggest you actually sit down and digest what the SOA-RM says and consider the relative unimportance of yet another adapter pattern in that context.
    I see what you are targeting but you are wrong. Let me elaborate. The type of projects I was referring here to and I had experience with are for public (government) sector with global influence. We are talking here about integration between 40 and 70 government systems plus integration with private (usually banking) sector. All these efforts had to not only satisfy functional and non-funtional requirements, but also had to be aligned with strategic vision of government in question. Global effort, lots of money at stake. Few important things we had in mine are, listed in random order: -standardzied development model -standardized deployment model -container/standard with good support to easily deploy artifacts cross-cutting in nature (security, transactions, profiling, SLAs, non-repudiation etc) -container/standard capable to support Long Running Business Transactions with Compensating Actions -conatiner capable to support (versionable) Canonical Data Model -container capable to support Ownership and Centralized Authorization management of domains (systems) While I can not share who/when/where etc due to NDA, we found JBI standard provides support for all above mentioned requirements. It provides centralized management framework and distributed processing platform. "You're writing one-off WSDL" You are wrong. If system to be integrated into ESB already provides WSDL based API, one can reuse WSDL with for example Cxf BC. If system does not provide WSDL based API, one is created and every other system wanting to communicate with it needs to conform to only WSDL. It is obvious that in this complexity one has to make formalized contract between systems in form of WSDL since it would be maintenance nightmare. Add ownership and authorization issue into the context, and you see that architects board overseeing the entire solution must have formalized service definitions. Also, I hope you have heard about BPEL specification, which is based on WSDL, and which isformalized model for LRB Tx support. By being WSDL based, all entities in JBI have native support for BPEL. And we solved 2 problems by only being CONFORMANT to the standard. If you are talking about integration projects where you need to integrate up to 3-4 small to mid-sized systems, you probably stand correct. In context of projects I have mentioned above you are 100%.
  63. You are wrong. If system to be integrated into ESB already provides WSDL based API, one can reuse WSDL with for example Cxf BC. If system does not provide WSDL based API, one is created and every other system wanting to communicate with it needs to conform to only WSDL. It is obvious that in this complexity one has to make formalized contract between systems in form of WSDL since it would be maintenance nightmare. Add ownership and authorization issue into the context, and you see that architects board overseeing the entire solution must have formalized service definitions.

    Also, I hope you have heard about BPEL specification, which is based on WSDL, and which isformalized model for LRB Tx support. By being WSDL based, all entities in JBI have native support for BPEL. And we solved 2 problems by only being CONFORMANT to the standard.

    If you are talking about integration projects where you need to integrate up to 3-4 small to mid-sized systems, you probably stand correct. In context of projects I have mentioned above you are 100%.
    The problem I see people having, and I see it a lot (and not just inside of JBI), is that when they write the WSDL, they don't log it and the component (e.g. the J2SE payment processor) winds up getting used by three other developers who then write separate WSDLs for their projects. What ultimately happens is that it breaks all the associated SLAs. Like I said, this happens so frequently it can boggle your mind. I am literally agog at how often I've bumped into over the past 18 months. It's an epidemic. As for BPEL, I'm a big proponent of it and would argue you'll get a lot farther in most cases using BPEL to orchestrate a process with the components not getting integrated into a hub. As a rule, I'd prefer my container to be part of the process (compositions) rather than my process to be part of my container (integration). I understand why you'd consider JBI for the types of e-commerce projects you've listed (though I still don't see JBI as being essential in those cases). Certainly the banks and government need to show a single face to each other in most cases. Yet internally those banks and government agencies might be acting like three or four small businesses in order to create that single face and I'd still worry that JBI's central messaging structure can endanger the downstream components (by not natively being able to respond to events and policy changes - and that's an ESB concern that extends far beyond JBI). Obviously the entities involved try to make sure that doesn't occur from an architectural standpoint, but JBI's focus on the runtime and integration/adapter pattern (for me) puts the project focus in the wrong place. For instance, with the requirements you listed I'd argue against starting with "container" in the discussion. You might determine that it's going to have to require a container methodology to do all of that (and you might determine it quickly), but you might decide against containers in some instances and, thus, against a strictly proscribed container of containers for the implementation. You also might sit down and determine that, inevitably these single integrations may grow to become multiple integrations and that JBI isn't going to be the best tool to handle that sort of multidirectionality.
  64. winds up getting used by three other developers who then write separate WSDLs for their projects.
    Well I have seen misuses myself, however that does not show JBI has flaws but rather developer laziness/incompetence etc.
    though I still don't see JBI as being essential in those cases
    Nope, I haven't said it is essential, but it is better than non-standardized approach such as Mule. If SCA finally hits the mainstream (it has been trying to hit the mainstream for couple of years now), it will be looked at and compared/evaluated in greater detail. I am not proposing blind following of one stack, just at this point in time it seems there are no big competitive advantages in using SCA over JBI and there are definitely no competitive advantages of Mule over JBI. Seems, choosing between JBI and SCA now seems more like a preference of team conducting ESB job.
    Certainly the banks and government need to show a single face to each other in most cases
    As you know, systems being integrated into ESB are not aware there is JBI implementation running between them. Only dependency between components is abstract WSDL service definition, so JBI is transparent in that regard.
    you listed I'd argue against starting with "container" in the discussion
    Well, as I said, in order to satisfy listed business and technical requirements, one has to define technical infrastructure on top of which business model will be executed. So one has to define which type of execution container will be used. All I can say is: JBI gets things done, in standard and formal way.
  65. Also, I hope you have heard about BPEL specification, which is based on WSDL, and which isformalized model for LRB Tx support. By being WSDL based, all entities in JBI have native support for BPEL. And we solved 2 problems by only being CONFORMANT to the standard. If you are talking about integration projects where you need to integrate up to 3-4 small to mid-sized systems, you probably stand correct. In context of projects I have mentioned above you are 100%.
    It has been pointed out to me about logical flaw in my statement quoted above. I somehow missed the most important part, to append big WRONG at the end of the last sentence. My apologies for confusion caused.
  66. And it's got nothing to do with IBM and BEA, they just don't think it's a good way to implement services.
    Yeah right. And big players don't (ab)use standard committees to push their own agendas. If you could put non-biased business hat on you could perhaps see what is going on. In the era of SOA hype, what do tech companies need more to increase their sales than ultra sparkling, shiny, nice looking diagrams and images. http://www.osoa.org/download/attachments/4028/Example_SCA_Assembly.jpg http://www.ibm.com/developerworks/library/ws-soa-scamashups/scadiagram.gif Because if it looks new and shiny it gotta be good and revolutionary. Not to mention that it would be really really hard to explain non-technical executive, who is deciding which ESB is to be bought, what is JBI, since JBI does not sparkle. There you have it, I have found one major non-technical flow in JBI, no sparkling photos and diagrams.
  67. Yeah right. And big players don't (ab)use standard committees to push their own agendas.

    If you could put non-biased business hat on you could perhaps see what is going on. In the era of SOA hype, what do tech companies need more to increase their sales than ultra sparkling, shiny, nice looking diagrams and images.
    You mean big players like Sun? Or am I only non-biased when I selectively apply the complaint that vendors abuse open standards committees and try to generate false hype? I've lost count of all the sparkling, shiny, nice looking diagrams and images I've seen of JBI. It got hyped to the extreme, but it fizzled. Heaven forfend that we blame JBI's inability to gain traction on JBI. Maybe we should make a betamax video about how great it is.
  68. Have you worked with JBI? Have you read the spec and worked with JBI container implementation? Have you worked with Mule?


    What is your point? First you don't think the Mason post should be allowed because he's with Mule and now you are questioning my right to be interested in what he and those who disagree with him have to say.

    This is a public forum that exists to encourage debate and discussion of topics of interest to this professional community. You seem to not understand how that works.
    If you haven't worked with JBI and Mule you are in wrong thread I reckon. How can you justify/accept/support one's opinion if you don't know matter at hand?
  69. If you haven't worked with JBI and Mule you are in wrong thread I reckon. How can you justify/accept/support one's opinion if you don't know matter at hand?
    First of all I haven't accepted or supported anyone's opinion. The problem is that opinion is all you have offered. You've not supported your opinion with facts organized in a cogent argument. Secondly, all threads are open to everyone. You're not the thread NAZI around here. Thirdly, I've worked with - developed & architected - with multiple ESB's since 2004 and with similar middleware for much longer. I've been doing services for 18 years, XML for 10 and SOA for about 13. I have plenty of the background necessary to evaluate competeing arguments on this and other matters.
  70. Nevertheless, Mr. Mason has raised some good points that a JBI proponent should respond to
    That is what you have said so I am asking how can you qualify point as 'good' if you haven't worked with JBI and Mule. (I am still assuming you haven't since you haven't said explicitly that you have)
    Secondly, all threads are open to everyone. You're not the thread NAZI around here.
    My deepest apologies if the tone of my post was like that, it was really not my intention. I prefer to avoid corporate courteous style of talk in any scenario other then business-2-customer cases, simply because I do not mind people talking to me the way I have talked here, open and straight to the matter.
  71. Thirdly, I've worked with - developed & architected - with multiple ESB's since 2004 and with similar middleware for much longer. I've been doing services for 18 years, XML for 10 and SOA for about 13. I have plenty of the background necessary to evaluate competeing arguments on this and other matters.
    Would you mind to share what is the best ESB in your opinion in terms of development productivity and developer happiness (as a indirect source for future spendings and savings), and perhaps in terms of maintenance as well? Thanks
  72. Would you mind to share what is the best ESB in your opinion in terms of development productivity and developer happiness (as a indirect source for future spendings and savings), and perhaps in terms of maintenance as well?

    Thanks
    I favor SonicMQ as an integration style ESB and BEA's AquaLogic as an orchestration style ESB. In a bake off conducted a couple of years ago at my former employer's, TIBCO and IONA also did very well though more so with the system engineers than with the developers.
  73. I favor SonicMQ as an integration style ESB
    Oops, I meant SonicESB.
  74. Nevertheless, Mr. Mason has raised some good points that a JBI proponent should respond to


    That is what you have said so I am asking how can you qualify point as 'good' if you haven't worked with JBI and Mule. (I am still assuming you haven't since you haven't said explicitly that you have)

    His points can be considered "good" or "bad" from an architectural perspective whether or not you have used JBI or Mule. Consider what he claims are limitations on JBI. For example, he says that JBI is too tightly-bound to XML and WSDL. That would be a serious limitation for large enterprises if it is so. If a JBI advocate can refute that, I'd be interested in what they have to say. Similarly, the other alleged limitations of JBI could also be serious barriers to enterprise adoption. Not being a JBI expert, I would want to know if in fact these are limitations of JBI and how or if they would necessarily transfer to any product that supported JBI. I want to hear both sides. His point about cross-vendor component reuse being a myth is a valid one, at least to those of us who have to work with a certain major vendor’s products. This certain major vendor claims to support all sorts of open standards in their middleware and yet we keep finding that this certain major vendor’s components work only on this certain major vendor’s middleware and that they discourage the use of 3rd party components and frameworks on their “open” products. In the past few days we had a senior engineer from this vendor come by and tell us yet again not to use Spring stuff on their application server. So, in my experience, vendors talk about standards and standardization and portability, but in my experience vendors who sell their software continually subvert the spirit and intent of open standards. I also have my doubts about SCA since many of the same culprits who mucked up EJBs and Java EE are behind it. it.
  75. R: straw-man arguments[ Go to top ]

    William, O.k., I don't know enough, but i am failing to c what the big deal about XML and WSDL is, like enterprises just don't have enough in-house talent, or out-sourced contacts to learn the basics of web services, which is the whole point of SOA, is it not?...please feel free to educate me on what the hold-up is to being "too...XML and WSDL." As for the re-usability argument, its straight-up comedy hour when a totally non-portable connector architecture like Mule's or anything else u want to advocate for says things like: re-usability is fiction...like Mule's or anyone that does not use JBI has a better portability/re-usability story?... i mean, c'mon, we all know the Spring-originated claims that EJB and JEE are non-portable, in fact, as i said, that is Microsoft's claim for not using Java app servers, and it is the exact same claim that Ross is using against JBI, that it is not Always, Perfectly Portable by the constraints that the spec. intends for re-usability... the reality is that if you adhere to the spec., it is re-usable, contrary to the propaganda by Microsoft, SpringSource, and MuleSource, and the fact that WebLogic and WebSphere introduced proprietary extensions in the app server is not a damning offense for a standard such as JBI... talk about subverting standards, lets start with the vendors that are openly hostile to them, its like life, its a process, and not an end-game, u aren't so myopic as to think that this whole thing should be figured out in 1 release, the fact that Ross has come on here to deride JBI and not answer basic questions about viability in spite of standards probably has nothing to do with the impending release of JBI v.2, the success of openESB, or customer questions about the value of standards in the ESB space, now does it? i am sure it doesn't...
  76. William,

    O.k., I don't know enough, but i am failing to c what the big deal about XML and WSDL is, like enterprises just don't have enough in-house talent, or out-sourced contacts to learn the basics of web services, which is the whole point of SOA, is it not?...please feel free to educate me on what the hold-up is to being "too...XML and WSDL."
    In large enterprises there is a lot of legacy stuff, non-XML friendly stuff and some very demanding volume processing SLAs. XML and web services cannot always measure up in terms of performance and scalability and they don’t always fit very well with the legacy technology. Take COBOL/CICS for instance. Most of the world still runs on it. The XML and web services “wrapper” software works badly. COBOL has static memory definition (working storage) that doesn’t handle XML document of highly variable size very well. In order to get web services without a complete rewrite we’re basically forced to front end this stuff with a Java service component that slows everything down. Enterprises don’t want to be forced to do that.
    i mean, c'mon, we all know the Spring-originated claims that EJB and JEE are non-portable
    Those of us who’ve built systems on the major app servers know they are not completely portable. And, if you aren’t careful, your code could be more portable than your architecture. Now you can argue that it’s a conspiracy, but the fact is that even with 2 “certified” Java EE app servers, you have a certain amount of non-portability. The same guys who gave us this are now offering us SCA to “fix” the problem.

    the reality is that if you adhere to the spec., it is re-usable, contrary to the propaganda by Microsoft, SpringSource, and MuleSource, and the fact that WebLogic and WebSphere introduced proprietary extensions in the app server
    Not really. Many specs seem to be written loosely leaving ambiguities and gaps. Take a look at WS-I.org. That’s an entire organization that is supposed to be devoted to making vendors “adhering” to the same standards actually interoperate. It’s hard to do. It’s hard to write a spec that is fool-proof. And, as you said, the big vendors seem to intentionally subvert the standards they claim to support. I’m not going to question his motives. I’m just interested in hearing both sides of this. So tell us why the next version of JBI will improve things. Tell us about how it will fix the current versions shortcomings. I have an open mind on this.
  77. Re: XML and re-usability[ Go to top ]

    William, Understood. CICS and COBOL are barriers but i guess the industry will just have to make its own mind-up customer-by-customer on what is better: reduced application/data performance or proprietary extensions...to use an over-used metaphor in this environment, Java was once deemed unusable for performance reasons, and customers decided to bet on the standard until the performance caught up...so w/r/t XML, i am persuaded to feel that asychronicity allows for some performance hits that are not allowable in e-commerce situations such as when hitting Databases... If u r working on a supply chain integration project, and utilize an ESB, such as one that supports JBI with its XML-verboseness, the performance seems to be less important even considering some pre-existing SLA's, but i am just speaking hypothetically, so i understand your p.o.v. and experiences may dictate that XML and by extension WSDL just will never cut it: i just tend to doubt it, but i know u have more knowledge on this than i do...we shall c... as for re-usability and the ever-evasive portability proposition, i feel like i am more on solid ground on the argument that a customer and by extension a vendor supplying products to said customer-base should err on the side of assuming progression toward the goal of absolute portability, even if that is a pipe-dream in practice, as it should be supportable that 90% portability is better than rip-and-replace every day of the week... i like JBI v.2 as an effort to battle-test the value proposition that standards matter even in the nebulous space of application integration, i am still of the ilk that JAX is sufficient, but i am willing to throw-a-bone to the ESB crowd, and will admit that the above-mentioned XML argument probably requires a mechanism beyond just app server integration practices, so lets just say that an ESB is going to live-on: what would it mean for JBI v.2 to never actually launch? it would mean EAI, pure and simple...i assume that most people in the ESB space have to have had experience in the EAI markets of the 90's in order to achieve something better and more marketable in the form of ESBs, but outside of a standard, whether that be JBI v.2 or not, what do customers invest in: development skills for SCA? integration skills on a particular vendor's best practices? legacy app performance SLAs? i dont know what they would do, BEA and IBM, and presumably MuleSource, feel that SCA is the answer, but that is not going to solve vendor lock-in, it will just make life easier for the developers...not 4 the platform admin's where decisions are made...we need a standard, and i simply disregard any anti-JBI banter in the absence of a replacement, as it is all-EAI all-the-time...and that train left, it failed, and it cost hundreds of millions of dollars that could have been better spent on standard JEE... i have a bias, but i feel like i am on stable ground advocating for JBI v.2 in the face of a sea of proprietary implementations; i mean in that world why not just go with BizTalk Server?
  78. Re: XML and re-usability[ Go to top ]

    BEA's AquaLogic as an orchestration style ESB
    If my memory serves me right, correct me if I'm wrong, in AquaLogic versions prior to 3 you HAD to use their GUI for ALL operation, you could NOT do any kind of scripting/Ant/batch or whatever. Only API provided to developers was their mouse clicking API. Loooolzzzzz. Now that is what you get when no standards are involved. If we take a look at relevant JBI spec part we can see compliant implementation must provide JMX based API deployment, and also Ant based deployments as well. Any comments on this one?
  79. Re: XML and re-usability[ Go to top ]

    BEA's AquaLogic as an orchestration style ESB


    If my memory serves me right, correct me if I'm wrong, in AquaLogic versions prior to 3 you HAD to use their GUI for ALL operation, you could NOT do any kind of scripting/Ant/batch or whatever. Only API provided to developers was their mouse clicking API. Loooolzzzzz.

    Now that is what you get when no standards are involved.

    If we take a look at relevant JBI spec part we can see compliant implementation must provide JMX based API deployment, and also Ant based deployments as well.

    Any comments on this one?
    As you probably know, AquaLogic is built on top of BEA's WebLogic application server. What we liked from a developer perspective was its tooling, the fact that we could leverage WebLogic tools and features and their strong legacy integration support. For an ESB, it was easy to install, configure and use. Compared to ESBs with similar architectures, they did a better job. - This is Summer 2006. I still prefer integration style ESB's - the kind built on messaging based products like Sonic's and Tibco’s. That reflects my view of what an ESB should do. I see the ESB as a platform for integration and communications. I also see it as a way of off-loading responsibilities from application servers which allows you simplify the platforms your services deploy to (less if any Java EE) and to insure greater consistency in the implementation of infrastructure services such as transformations, security, itinerary management and routing, and run-time governance. The orchestration style ESB products want you to run all these things in their application server (which is what they tend to be built on) which restricts you choices/options for how these services are implemented. With an integration ESB I can more easily mix services implemented in Java, .NET and other technologies and still get a single, consistent implementation of each of my infrastructure services. The future as I see it is that Java EE application servers or at least their current architectures will fade away. The new Spring platform based on OSGi components that can be plugged into a standard JVM to provide only the capabilities you want and need is close to where we should be going. I see a lot of the workload balancing, failover and other application server type responsibilities being pushed down to the ESB, network devices and VM managers. This will allow us to integrate a greater variety of technologies past, present and future from more sources with fewer problems. Every application server won’t have to come with its own version of WS-Security or cloning or load balancing, etc. The truth is that the only thing I can think of that Java EE does that cannot be currently replaced with an ESB, network device or VM manager is global transaction management. Now I’m a realist enough to know that the big vendors will fight hard to keep this from happening, but I hope the open standards and open source communities force them into it.
  80. Re: XML and re-usability[ Go to top ]

    so i understand your p.o.v. and experiences may dictate that XML and by extension WSDL just will never cut it:
    I’m not sure it will never cut it for most things, but there are some applications that still run in assembler or C purely for performance reasons. Real-time fraud detection for credit card processing comes to mind. Understand that I started using Java and XML in 1998 after coming from a Tuxedo C/C++ environment. I’m the guy around here who is pushing this stuff forward, but I have to acknowledge and consider the points of view of the business and the legacy IT guys. The truth is that IBM tells us that COBOL/CICS is 7 times more efficient than Java EE on their z series mainframes. For high volumes, nothing beats COBOL/CICS on Z for price performance. My argument back to them is along the lines of productivity, maintainability and the trends in labor versus hardware costs. Nevertheless, there are some requirements the new stuff still cannot meet, it all costs money and skilled labor is hard to find. So, the big commercial vendors who cater to companies like mine have to make sure that they don’t push products that only address green field development. That seems to be one of Mason’s points about JBI. I don’t know if JBI necessarily precludes non Java and non XML support in an ESB, I don’t see why it should, but I’d want to hear that and why from someone with greater knowledge of JBI than I have.
    as for re-usability and the ever-evasive portability proposition, i feel like i am more on solid ground on the argument that a customer and by extension a vendor supplying products to said customer-base should err on the side of assuming progression toward the goal of absolute portability, even if that is a pipe-dream in practice, as it should be supportable that 90% portability is better than rip-and-replace every day of the week...
    My experience with the big commercial vendors is that they continue to do all they can to discourage portability. They talk open standards support, but actively try to lock you in to their tools, platforms and middleware and they do not hesitate to resort to FUD. I’m constantly fighting the portability battle.
    i like JBI v.2 as an effort to battle-test the value proposition that standards matter even in the nebulous space of application integration, i am still of the ilk that JAX is sufficient, but i am willing to throw-a-bone to the ESB crowd
    I posted a lengthier version elsewhere in this thread, but I see ESB and OSGi in combination with network devices and VM managers as a way of eliminating most uses of Java EE application servers. Can JBI v.2 help here?
  81. I've answered Ross points in my blog at http://gnodet.blogspot.com/2008/07/ross-mason-cto-of-mulesource-recently.html
  82. I agree completely and would appreciate more facts and hard references in place of biased generalizations and subjective opinions. Otherwise, author's agenda seems obvious, but hardly proven.
  83. I agree completely and would appreciate more facts and hard references in place of biased generalizations and subjective opinions. Otherwise, author's agenda seems obvious, but hardly proven.
    Hi Dennis, That is a fair enough comment, but I am just offering up my objective opinions on JBI from the viewpoint of a vendor who had the option to adopt it. I spent a lot of time looking a JBI in the early days and my comments summarize my findings. My reasons for publishing this was because I have been asked *a lot* in the past about my thoughts on JBI so I decided to record them in this blog post. Some folks at TSS thought these would make good discussion points, InfoQ thought the same. I do think the lack of adoption of JBI by vendors is telling. I am just providing one account. Cheers, Ross Mason MuleSource http://blog.rossmason.com


  84. I don't believe it is ok that people working on stuff that competes with JBI comment on public places, which should be neutral, about JBI. While you did not state explicitly that JBI is bad, it can be easily read between the lines that you are trying to influence the reader how we do not need JBI at all and how there are some significant flaws in it.

    Mule does not have native support for JBI, so it can be considered JBI container.

    I do not see James Strachan posting articles on main TSS page about non-standardized ESBs such as Mule, with critical hat on.

    You are entitled to your own opinion, but I do not believe you are entitled to post on main TSS page about things which compete with yours, especially in critical ways.
    Hi "Chief Thrall", The basis for this article was a blog entry I posted a few months back. The reason for posting was simple, lots of people were interested in why we didn't select JBI for Mule. I think its fair enough for anyone to post their views on TSS about any topic relating to enterprise development providing they are balanced and moderate. Given the amount of discussion around this posting I'd say i was worthwhile posting this article for the community to comment on. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  85. The reason for posting was simple, lots of people were interested in why we didn't select JBI for Mule
    Mule RC 1 released on Feb. 03, 2005 and JBI spec finalized at 25 Aug, 2005, public review was available at 04 Mar, 2005, according to these resources. http://today.java.net/pub/n/Mule1.0-rc2 http://jcp.org/en/jsr/detail?id=208 If above is true, how did you knew at that time JBI will not gain adoption and that it has some major flows? Could it be, just my blind guess, that you perhaps didnt want to rewrite your software from scratch to make it JBI compatible? Non-rewrite is much cheaper and faster. So how come Mule 1 was released before JBI was out and now, 3 years later, you claim Mule is not based on JBI because it has flows in it? Am I missing something here? Am I interpreting this information in the wrong way? Please correct me if I am saying something incorrect.
  86. The reason for posting was simple, lots of people were interested in why we didn't select JBI for Mule


    Mule RC 1 released on Feb. 03, 2005 and JBI spec finalized at 25 Aug, 2005, public review was available at 04 Mar, 2005, according to these resources.

    http://today.java.net/pub/n/Mule1.0-rc2
    http://jcp.org/en/jsr/detail?id=208

    If above is true, how did you knew at that time JBI will not gain adoption and that it has some major flows?
    Chief, I didn't 'know' that JBI was not going to work out. However, I did my diligence once the specification was released and my the decision over time based on my findings and of others in the team. We even did a JBI spike for Mule. We made the decision not to go with JBI based on technical reasons in that JBI would restrict some of the very useful features that were already available in Mule such as: - No prescribed message format. You aren't forced to use XML - Service contracts don't have to be WSDL - Transformations don't have to be XML-based - The event flow model performs better in Mule since we don't require a normalized message router.
    So how come Mule 1 was released before JBI was out and now, 3 years later, you claim Mule is not based on JBI because it has flows in it?
    Because Mule is a more mature product :) Seriously, I wasn't blogging 3 years ago, otherwise I probably would have blogged about it. If you did see any of my conference talks between 2005 and now, I've given the same answers to questions about JBI that I do today. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  87. 1) No prescribed message format. You aren't forced to use XML 2) Service contracts don't have to be WSDL 3) Transformations don't have to be XML-based 4) The event flow model performs better in Mule since we don't require a normalized message router.
    Agree with 1, it was a fault. However, 2, 3 and 4 are consequences of 1 so we can conclude we have 1 fault: 1) No prescribed message format. You aren't forced to use XML So, instead of fixing this issue, like writing proposal to JCP, reaching global consensus etc, people gave up after like 1 year after the release. And this is dangerous, because seems you (people against JBI) have bailed on smallest obstacle without trying to actually solve the issue and help the industry. And that's why I am not buying it. It is easiest ti quit and go on and do your own thing than to stay here and try to improve/fix which have been already developed.
  88. What I have the problem with the most is that on the one hand we have formalized, standardized approach in form of JBI, where it is clearly described what are the semantics and behaviors of ESB (JBI approach), and on the other hand we have for example Mule, which does not have formal document about semantics and behaviors. And personally I believe being standardized and formalized is very important both at technical and business level of operations for any company developing business applications and using technical solutions from big vendors.
  89. Censor criticism[ Go to top ]

    Chief, I find it interesting that you don't think the founder of an open source technology is a credible source for criticism of an existing standard. Haven't certain vendors (well poised to benefit economically from JBI adoption) been long beating the drum about its benefits? How is that any more credible? Call me naive, but I think the TSS.com readers are savvy enough to draw their own conclusions, even if - God forbid - some commentary about JBI has some critical / competing points of view.
  90. Re: Censor criticism[ Go to top ]

    Chief, I find it interesting that you don't think the founder of an open source technology is a credible source for criticism of an existing standard.
    Just because someone is the founder of open source project does not mean point of view he is presenting is correct.
    Call me naive, but I think the TSS.com readers are savvy enough to draw their own conclusions, even if - God forbid - some commentary about JBI has some critical / competing points of view.
    I am not worried about seasoned and experienced IT guys, my worry are new and inexperienced developers who can not form opinion on their own until they get more XP. I remember my old days when I was rookie, and discussion like these have helped me to not accept some claims as truth just because someone says so. You gotta search for truth by yourself. That is how you learn and become knowledgeable.
    How is that any more credible?
    JBI is good spec. Of course it needs some polishing, but in general it is very good concept. Smart people have worked on it. The failure of JBI, if we can actually call it a failure, is not because of technical faults, but rather bad marketing strategies and fighting between big IT vendors for integration market share. Just put yourself for a second in shoes of IBM Integration Division Manager, and think what you would do to protect interests of IBM company as a whole in regard to the JBI spec and integration market.
  91. A big part of why JBI failed is that they decided to define a completely new deployment model with a completely new classloader structure. Fortunately they've decided to go with OSGI next. Why oh why can't JSR's define a bunch of APIs and leave it up to others to manage the configuration and deployment of libraries that use those APIs.
  92. A big part of why JBI failed is that they decided to define a completely new deployment model with a completely new classloader structure. Fortunately they've decided to go with OSGI next. Why oh why can't JSR's define a bunch of APIs and leave it up to others to manage the configuration and deployment of libraries that use those APIs.
    Please note that JAR file with lifecycle, a.k.a. OSGi is very different from JBI. You can use OSGi model as an implementation of JBI. So they don't compete but work together.
  93. A big part of why JBI failed is that they decided to define a completely new deployment model with a completely new classloader structure. Fortunately they've decided to go with OSGI next. Why oh why can't JSR's define a bunch of APIs and leave it up to others to manage the configuration and deployment of libraries that use those APIs.


    Please note that JAR file with lifecycle, a.k.a. OSGi is very different from JBI. You can use OSGi model as an implementation of JBI. So they don't compete but work together.
    I think this may be referring to the defined classloading mechanism in the JBI spec. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  94. The key concept in JBI is the core messaging APIs, not the deployment or packaging parts. This is why, two open source JBI implementations (OpenESB with Fuji and ServiceMix with ServiceMix 4) are going the OSGi way. OSGi is a good standard and a really good fit for a container (be it a JBI container or not). Ross, I recall some time ago you Mule was planning to go OSGi (as you even stated in http://www.theserverside.com/news/thread.tss?thread_id=42458). Is OSGi another standard that does not fit well with Mule ? ;-)
  95. The key concept in JBI is the core messaging APIs, not the deployment or packaging parts. This is why, two open source JBI implementations (OpenESB with Fuji and ServiceMix with ServiceMix 4) are going the OSGi way. OSGi is a good standard and a really good fit for a container (be it a JBI container or not).

    Ross, I recall some time ago you Mule was planning to go OSGi (as you even stated in http://www.theserverside.com/news/thread.tss?thread_id=42458). Is OSGi another standard that does not fit well with Mule ? ;-)
    +1 Eclipse Swordfish will go all three ways: JBI, OSGi and SCA. Armin Wallrab, SOPERA GmbH BTW: There is a good online presentation of my former colleague and JBI-spec lead Ron Ten-Hove. Enjoy http://developers.sun.com/docs/javacaps/tutorials/demos/jbi-jca/launch.html
  96. A big part of why JBI failed is that they decided to define a completely new deployment model with a completely new classloader structure. Fortunately they've decided to go with OSGI next. Why oh why can't JSR's define a bunch of APIs and leave it up to others to manage the configuration and deployment of libraries that use those APIs.
    +1.
  97. Re: straight-up hilarious[ Go to top ]

    Ross, I fully appreciate the effort you have made to point out that JBI has not taken over the once-EAI world, now called-ESB world, i feel obliged as your boss would no doubt expect to respond with some fairly baseless claims of my own, just to keep this convo. going...i mean really, good job, this discussion was badly needed, and it couldn't have come from a better source, seeing that MuleSource is target #1 for pointless removal of JBI from their standard-support... I also feel like i can participate in this thread seeing that you make zero mention of why developers are dis-enfranchised from supporting JBI, though make a reference to it, the only thing i can come up with is your claims that: 1. Re-usability is Fiction. 2. SCA is better. As for #1, are you saying that the Sun-sponsored effort to standardize pre-built components here: https://open-esb.dev.java.net/Components.html is not viable for other vendors? Are you saying that these are non-standard JBI implementations? My understanding was that any JBI ESB could use these components with their own Bus...for someone who values the concept of portability and the implementation initiative to make portability a value proposition so as not to lock in customers to a new and improved EAI model, this is pretty much the best thing going in the entire middleware market... It would be akin to JBoss coming up with a site for EJB components that would be fully EJB 3 supported thus being portable to Glassfish, WebLogic, and Geronimo: nothing would be better for customers, kind of like the old Theory Center efforts...your argument that re-usability does not exist is akin to Microsoft's proposition that using JEE app servers is fiction in that there is no such thing as portability...is that what u r getting at? 2. The SCA v. JBI argument has been covered ad nauseum but apparently not enough for the die-hards to look for ways to make it a competitive standard v. standard battle to the death, kind of like Spring and EJB...while there are some issues to work out, they can be complimentary and your thesis that JBI falls down for developers apparently in favor of SCA is patently false, nothing says vendor-sponsored, developer-neutral like SCA...who is doing SCA as opposed to JBI? I will have another post to make since i adore this topic, and i am committed to public harassing MuleSource in to not being proprietary in their implementation of EAI, which is essentially what you guys do, under the marketing banner of ESB integration; there are standards and there is proprietary implementations, and Mule falls in to the latter today, even if you traipse out so-called minor spec.'s that make you look kinda standardish... i just wish religion wasnt so important to u guys, that u would choose to compete with Sun on this for the sake of argument, and not for the sake of customers: i mean r u really going to argue to me that customers prefer not to have a standard implementation of an ESB, and trust that Mule will live in infinitum, and will be supported by its start-up sponsor? r u?
  98. Re: IBM and BEA on SCA[ Go to top ]

    Can anyone reconcile the statements of the two largest, non-OSS app server vendors in their vote on JBI v.2 last year: http://jcp.org/en/jsr/results?id=4206 In one statement, IBM does not like that JBI allows for various development methodologies when working with JBI. In the same vote, BEA says that they do not like that JBI prefers a Java-based development approach, even considering the use of SCA... I might be dense, but it would seem that these border on contradictory responses from the coordinated effort to stall JBI...JBI v.2 allows for many ways to integrate, but offers a JCP-standardized way to build an ESB, and thus allow integration to be achieved according to the customer's best practices... IBM seems to be saying that they want SCA all-the-time, BEA seems to be saying that they do not want Java all-the-time...what do you think, Ross, what does it matter what you develop in, as long as it integrates, i mean i would think that the main beneficiaries of Java development would want a Java-centric integration approach, but maybe that is not a future direction, considering the advent of Glassfish and the march of JBoss on their business... I am still struggling after 2 years, many replies on various forums, this article from MuleSource, and the supposed irrelevance of JBI to understand why a vendor would be anti-JBI...is there a reason not to support it in the run-time, and then recommend SCA for development, considering the length which Sun has gone to demonstrate their support of the lifespan of SCA?... as 4 Mule, it is the purported leader in the independent ESB "market", so it must have some pretty good best practices on which customers can develop and integrate, what are these that make it so attractive, as to not go with a standard process? I have had some conversations on-line with you guys, but am still struggling to understand what makes your ESB different than Forte's EAI solution, other than product functionality enhancements: where EAI failed, where does ESB survive?...
  99. Re: straight-up hilarious[ Go to top ]

    Hello Douglas, This wouldn't be the same without you! It sounds like you rolled out of the wrong side of the bed again :) I try and sift through to your points and address them.
    Ross, I fully appreciate the effort you have made to point out that JBI has not taken over the once-EAI world, now called-ESB world, i feel obliged as your boss would no doubt expect to respond with some fairly baseless claims of my own, just to keep this convo. going...i mean really, good job, this discussion was badly needed, and it couldn't have come from a better source, seeing that MuleSource is target #1 for pointless removal of JBI from their standard-support...

    I also feel like i can participate in this thread seeing that you make zero mention of why developers are dis-enfranchised from supporting JBI,
    I'm not speaking about all developers, only the ones I have encountered. However, it is much easier to see that vendors have not adopted JBI. I think that is very telling. If the vendors do not adopt the standard there is little for the developer community to get behind.
    is not viable for other vendors? Are you saying that these are non-standard JBI implementations?
    I applaude SUN for their efforts, they have ported many of their jWay connectors to BCs. I'd like to hear from users about their real-world experience of using these in a different container. The point I was making is that each vendor that has built a JBI container also built a suite of binding components _exactly_ the same as the next vendor. Hardly re-use in action.
    nothing says vendor-sponsored, developer-neutral like SCA...
    All I'm saying is I prefer the approach of SCA not necessily SCA itself. I think focusing on the configuration is more valuable since you can share tools and generate a common glossary of terms for service composition.
    I will have another post to make since i adore this topic, and i am committed to public harassing MuleSource in to not being proprietary in their implementation of EAI
    I'm sure you will :) however, I need to get back to the rest of my day. I'll see your posts tomorrow.
    i just wish religion wasn't so important to u guys, that u would choose to compete with Sun on this for the sake of argument, and not for the sake of customers: i mean r u really going to argue to me that customers prefer not to have a standard implementation of an ESB, and trust that Mule will live in infinitum, and will be supported by its start-up sponsor? r u?
    Hmmm, you keep talking about religion, but it has nothing to do with it (though you seem to be on a crusade :) ). We have nothing against SUN and actually partner with them in other areas. We do believe in our approach and as a software company we keep assessing where are to ensure we don't miss out on opportunities in this space. JBI was something that was not appealing to us, nor many other vendors such as BEA, IBM, Software AG, RedHat or TIBCO. Are you trying to persuade these guys to go with JBI? Cheers, Ross Mason MuleSource http://blog.rossmason.com
  100. Counter argument[ Go to top ]

    BTW, for those looking for a more rational discussion to counter my blog post, James Lorenzen posted a very helpful reply from the viewpoint of a SC BC developer. Thanks James! Cheers, Ross Mason MuleSource http://blog.rossmason.com
  101. Re: Counter argument[ Go to top ]

    BTW, for those looking for a more rational discussion to counter my blog post, James Lorenzen posted a very helpful reply from the viewpoint of a SC BC developer. Thanks James!

    Cheers,

    Ross Mason
    MuleSource

    http://blog.rossmason.com
    In that blog as summary we see following: "IMHO I think a lot of assumptions where made about JBI, but you also addressed some of the issues with JBI. One reason I think JBI has not been adopted is the fact that it didn't have the backing early on of IBM and Bea. From what I recall they dropped out pretty early once they realized it was going to be a competing product. Another reason for a lack of adoption is I think again the lack of communicating what JBI really is." Though I doubt posters in this thread, me included, appreciate "for those looking for a more rational discussion" part.
  102. Re: Counter argument[ Go to top ]

    Though I doubt posters in this thread, me included, appreciate "for those looking for a more rational discussion" part.
    Oops, I posted this directly after replying to a Douglas Dooley post. didn't mean to tar everyone with the same brush. Cheers, Ross Mason MuleSource http://blog.rossmason.com
  103. Re: ouch[ Go to top ]

    don't hurt me, Ross... please accept my apologies for trying to get you guys to come up with an argument in response to questions that u will certainly hear from customers... mea culpa, i guess...
  104. Streaming in JBI: yes or no?[ Go to top ]

    Does ServiceMix actually support streaming or not? The JBI spec contemplates any kind of XML Source as the NormalizedMessage content, which virtually allows for the usage of Streaming XML (STaX source)... But what does actually happen in ServiceMix when a MessageExchange is sent? Is it sent DOM-style or SAX-style? From my point of view, streaming capability includes at least the following features: - Message is passed along as a reference, and when the message is consumed, it is consumed directly from the source, not from a memory region. - Message is being processed in a chain as it becomes available. For example, if a file endpoint received XML, applies an XSLT transformation, and does a wiretap through to another file endpoint while sending the resulting message to an HTTP endpoint, "streaming" means to me that all this is done on-the-fly. As the message is being read from the source (only ONCE), it is being transformed and the content is being written on both outbound endpoints. Am I right? I believe that Mule supports this kind Streaming (although I am not 100% sure), but does ServiceMix support it?
  105. Does ServiceMix actually support streaming or not? The JBI spec contemplates any kind of XML Source as the NormalizedMessage content, which virtually allows for the usage of Streaming XML (STaX source)... But what does actually happen in ServiceMix when a MessageExchange is sent? Is it sent DOM-style or SAX-style?

    From my point of view, streaming capability includes at least the following features:
    - Message is passed along as a reference, and when the message is consumed, it is consumed directly from the source, not from a memory region.
    - Message is being processed in a chain as it becomes available. For example, if a file endpoint received XML, applies an XSLT transformation, and does a wiretap through to another file endpoint while sending the resulting message to an HTTP endpoint, "streaming" means to me that all this is done on-the-fly. As the message is being read from the source (only ONCE), it is being transformed and the content is being written on both outbound endpoints.

    Am I right? I believe that Mule supports this kind Streaming (although I am not 100% sure), but does ServiceMix support it?
    Does this answer your question? http://markmail.org/message/s7hp4mmjiov6azzp
  106. Does ServiceMix actually support streaming or not? The JBI spec contemplates any kind of XML Source as the NormalizedMessage content, which virtually allows for the usage of Streaming XML (STaX source)... But what does actually happen in ServiceMix when a MessageExchange is sent? Is it sent DOM-style or SAX-style?

    From my point of view, streaming capability includes at least the following features:
    - Message is passed along as a reference, and when the message is consumed, it is consumed directly from the source, not from a memory region.
    - Message is being processed in a chain as it becomes available. For example, if a file endpoint received XML, applies an XSLT transformation, and does a wiretap through to another file endpoint while sending the resulting message to an HTTP endpoint, "streaming" means to me that all this is done on-the-fly. As the message is being read from the source (only ONCE), it is being transformed and the content is being written on both outbound endpoints.

    Am I right? I believe that Mule supports this kind Streaming (although I am not 100% sure), but does ServiceMix support it?


    Does this answer your question?
    http://markmail.org/message/s7hp4mmjiov6azzp
    Also, seems it is irrelevant whether ServiceMix or Mule support this. The question is is there technical flaw in JBI spec which would prevent implementation of such feature in compliant container?
  107. A few corrections[ Go to top ]

    Wow! What a spirited thread. As a member of the JSR 208 EG, my opinion on this subject is obviously a bit biased, but I did want to clarify a few points in Ross' original email. RM: It (JBI) meets vendor needs at the expense of developers. KB: The aim of JBI is the exact opposite: help developers by increasing choice and eliminating vendor lock-in. By defining a standard plug-in architecture for integration components along with an interoperable communication infrastructure, JBI gives integration developers the ability to choose components that match their needs. Call me crazy, but I doubt this serves the "needs" of vendors. RM: XML messages will be used for moving data around. KB: This is a common misconception related to JBI. The payload of a message in JBI (called a NormalizedMessage) can be any type of content. The confusion here arises from the fact that the term 'content' is unfortunately overloaded in the spec. It refers to both an abstract concept: all data that comprises the content of the message, as well as concrete API concept: setContent() and getContent() take a TrAX Source object. The thing is that the Source object itself can simply contain a pointer to any type of content: binary, NTV, object, etc. that is also carried in the normalized form of the message. RM: Data Transformation is always XML-based KB: The TrAX Source object is used simply because it provides a nice abstraction for message content. You don't have to use the TrAX framework to translate message content. RM: No need for message streaming KB: To the contrary, use message streams to your heart's content: * javax.xml.transform.stream.StreamSource * javax.activation.DataSource * javax.xml.transform.stax.StAXSource RM: Service contracts will be WSDL KB: Yes and no. There is really no requirement for integration developers to use WSDL at all. The WSDL support is there so that independent container implementations have a mechanism for declaring communication contracts in an interoperable fashion. I know that ServiceMix and Project Fuji do not require the user to touch WSDL when creating services, for example.
  108. Re: A few corrections[ Go to top ]

    As a member of the JSR 208 EG, my opinion on this subject is obviously a bit biased, but I did want to clarify a few points in Ross' original email.
    Hmmmm interesting points. Would be nice to see replies from anti-JBI folks to these comments coming from the 'source' directly.
  109. JBI 2.0 - When?[ Go to top ]

    KB - thanks for the clarifications. Btw, when is JBI 2.0 going to be released? I haven't seen any updates on the JSR 312 page for a long time. Is there a public draft available somewhere?
  110. Re: JBI 2.0 - When?[ Go to top ]

    Interestingly enough, Peter Walker (the spec lead) touched on this the last time Ross's views on JBI were on TSS. You can find that thread and Peter's comment here: http://www.infoq.com/news/2008/05/jbi-debate#view_22465 Re: updates on the JSR 312 page -- we had a F2F at JavaOne this year and one of the items that came up is increased transparency. I think we all want the same thing, which is increased community involvement in the process. A number of good ideas were tossed around about how to achieve this (e.g. public discussion list, recent activity page, etc.). Hopefully, some of these ideas will come to fruition in the near future. Re: schedule -- I'm the wrong person to ask. I thought the 208 spec would be done "next week" for three months. ;-)
  111. Re: JBI 2.0 - When?[ Go to top ]

    Keith - a few more questions: Regarding using XML in NMR are you saying NMR can actually handle non XML data? Peter seems to be saying otherwise. My impression was also the same, i.e., the transformation has to be handled at the edge through BCs. Doesn't the File BC support consuming non-XML payloads today? This wiki also seems to suggest BCs would handle transformation via Encoders... http://wiki.open-esb.java.net/Wiki.jsp?page=Introduction But then in the same page we see "JBI does not limit messages posted to NMR to be in XML format" - it's a bit confusing. As for WSDL, are you saying JBI allows describing services using other mechanisms, such as annotated POJOs or is it a proprietary extension in SM or Fuji? And do the service invocations always have to happen over SOAP? Can JBI support some native binding for service invocations, a la SCA which allows service calls over IIOP, JMS etc? I didn't quite follow Ross' objections about Java based XML transformation - many other ESBs use XSLT transformers or XQuery engines written in Java - doesn't Mule do the same or maybe I missed something.
  112. Re: JBI 2.0 - When?[ Go to top ]

    Regarding using XML in NMR are you saying NMR can actually handle non XML data?
    The NMR itself is payload agnostic. It takes a reference to a Source object along with (n) attachments and (n) message properties and passes these between components. So the answer to your question is yes, because the NMR doesn't actually process the content.
    Doesn't the File BC support consuming non-XML payloads today?
    The beautiful thing about JBI is now I get to ask you which vendor's File BC you are talking about. ;-) Based on something you say below, I'm guessing that it's the OJC File BC @ java.net. I would float an email to the users list (users@open-esb.dev.java.net) and I'm sure the engineer responsible for that component will answer your question.
    As for WSDL, are you saying JBI allows describing services using other mechanisms, such as annotated POJOs or is it a proprietary extension in SM or Fuji?
    I honestly can't remember how SM handles this, but I do recall seeing some examples some time back. I'm sure Guillaume will jump in here at any second. As for Fuji, we actually generate the WSDL behind the scenes (although the user does have an option to tinker with WSDL directly if they choose). The user gets to stick with artifacts that make sense in their problem domain and the components get a standard service description they expect - everyone is happy in Fuji land !
    And do the service invocations always have to happen over SOAP?
    A service hosted in JBI can be offered over any protocol that you have support for in binding components. Likewise, application logic hosted in JBI can access an external service using any protocol that is available through installed binding components.
    Can JBI support some native binding for service invocations, a la SCA which allows service calls over IIOP, JMS etc?
    The OJC project at java.net has a CORBA and JMS BC available today.
    I didn't quite follow Ross' objections about Java based XML transformation - many other ESBs use XSLT transformers or XQuery engines written in Java - doesn't Mule do the same or maybe I missed something.
    I don't want to put words in Ross's mouth, but I don't think he had a problem with XSLT itself. He was just concerned that XSLT was the only option. This is not the case, so hopefully everyone is happy now.
  113. Re: JBI 2.0 - When?[ Go to top ]

    Regarding using XML in NMR are you saying NMR can actually handle non XML data?

    The NMR itself is payload agnostic. It takes a reference to a Source object along with (n) attachments and (n) message properties and passes these between components. So the answer to your question is yes, because the NMR doesn't actually process the content.
    Keith, doesn't the JBI standard dictate javax.xml.transform.Source in the message payload/content? Doesn't this mean that the payload can only be a XML type? (Regardless of whether this is DOM, SAX, etc.) Please correct me if I am wrong.
  114. Re: JBI 2.0 - When?[ Go to top ]

    Yes, the spec requires an XML type for the Source that's used in NormalizedMessage.setContent(). Of course, that content could just be: The actual X-Ray image could be an attachment to the message with the name of 'cid:attach1'. Why require XML at all you may ask? Because it's the lowest common denominator for all components to have an interoperable view of the message content. In this case, all components are capable of inspecting this message and determining whether or not they are able to process it. Components that can consume X-Ray data will go to the attachment and yank out a binary stream. One other point here. Integration developers don't have to care about XOP, attachments, or even message normalization semantics. That is the domain of the component developer. The integration developer just has to know how to declare in a component's configuration the type of the payload is not XML. This can be done through WSDL or any other service configuration interface the component wishes to expose. hth, keith
  115. Re: A few corrections[ Go to top ]

    Thanks. This is exactly the kind of useful and informative rebuttal I was hoping to see.
  116. Ross, much has already been said in response to your criticism against JBI. I'm not sure if I'm really going to add anything new to the discussion, but I'd like to throw in my two cents from the point of view of a SOA vendor who builds upon JBI. I'm pretty much tempted to say that JBI is not a users' standard but rather a vendors' standard. I don't mean to say that it's bad or entirely irrelevant for users, it's just that I think that as a user you actually don't gain that much from "having JBI inside". How does the owner of a Volkswagen benefit from the fact that it shares the platform and more than 40% of the parts with an Audi? The huge cost savings on the manufacturer's side might result in a more attrative price tag and spare parts might be more readily available, but more often than not the decision to go with a particular brand is influenced by the things that happen on top of the platform such as exterior and interior design, convenience, brand image. I think the same is true for SOA and/or integration middleware: JBI is not a diffentiator, the value is in the features you build on top of it. For Swordfish and SOPERA ASF (Sopera's core product offering), we chose to build upon JBI for largely pragmatic reasons. There are excellent open source runtime implementations out there and there are loads of binding components and service engines that allow us to concentrate on adding value instead of re-inventing the wheel. That said, there actually ARE some things about JBI that still bother me, albeit not too much: The fact that the messaging model is based on XML is a two edged sword. On one hand, you lose some flexibility and performance when dealing with purely legacy message formats (although there are work arounds, as already stated elsewhere). But on the other hand, in most of the integration challenges that we see in real-world customer situations, one side of the integration often is XML-based anyway (consider hiding a legacy system that spits out fixed-length records behind a web service). When designing an integration framework you'll ultimately have to come up with SOME kind of messaging abstraction. If the one specified by JBI fits in, so much the better. Concerning the component and deployment model, I wholeheartedly agree that the JBI 1.0 working group could have done better. The component model is a tad too heavy-weight, being a burden for component developers, and deployment is just a pain. But now that everyone seems to agree that OSGi is the way to go, there's no need to stick to the JBI 1.0 legacy. The OSGi-based ServiceMix 4 (and probably Fuji also, although I'm not familiar with this) already demonstrates how you can leverage the good points about JBI while avoiding most of its shortcomings and I'm sure that these ideas will show up in JBI 2.0, should it be finished one day. :-) Apart from that, I'm outright with you on the things you said about standardization. Standards DO have their merits, but the target audience should be kept in perspective. If I'm looking at customer RFPs where they're asking for JBI support as a checkbox feature, I can't stop marveling. SCA, on the other hand, is -- in my view -- a very good approach in that it concentrates on the areas that are relevant for users (such as application composition and deployment) while leaving ample freedom for vendors to chose the best way to actually implement the runtime environment. For some, JBI is the best way -- for whatever reasons. Your mileage may vary. Cheers, Oliver Wolf SOPERA http://www.eclipse.org/swordfish


  117. For Swordfish and SOPERA ASF (Sopera's core product offering), we chose to build upon JBI for largely pragmatic reasons. There are excellent open source runtime implementations out there and there are loads of binding components and service engines that allow us to concentrate on adding value instead of re-inventing the wheel.
    What kind of Business Components ( SOA == Business Process Level ::: JBI == Java Business Integration ) are today available, which are concretely based on the standard JBI ? I'm very interested to get to know some of this existing solutions. Roland SOA Competence BTW: Very nice to hear on TSS also notices from another manufacturers - please continue and provide the interested people more practical informations over Swordfish and SOPERA.