Red Hat releases updated SOA platform, developer studio

Discussions

News: Red Hat releases updated SOA platform, developer studio

  1. Red Hat recently updated two of its JBoss open source offerings.The company announced JBoss Enterprise SOA Platform 5.0. The 5.0 version includes an updated enterprise service bus (ESB), and a new rules engine. The ESB includes updated protocol listeners and management consoles. Red Hat also announced JBoss Developer Studio 3.0. The toolset is built on Eclipse 3.5 and includes new tools for data transformation. The 3.0 version also supports RichFaces, Spring, and Struts.
  2. Having been working with the SOA Platform 4.x, I would strongly encourage anyone looking into selecting an ESB to consider other choices and not waste their time here.

    I've spent nearly 9 months working with the SOA Platform and the additional coding it introduced was painful. Especially when compared to Mule and ServiceMix + Camel. The Spring integration is such a load of shit honestly. The inherited design problems of Rossetta plagued the JBoss ESB and those problems leak out into the developers code.

    Don't be sucked into the pretty diagrams or crappy features e.g., Spring Integration. Take a moment and seriously evaluate the alternatives before you piss away hours into using JBoss ESB.

    Selecting an ESB is a very important thing for any company looking leverage a bus for their SOA underpinnings, so choose wisely.

    Richard L. Burton III
  3. I totally agree with you Richard Burton, i experienced the same previously as a JBoss partner. Prefer ServiceMix and Camel.

    /Daniel
  4. In my prior posting, I made note to how there are some serious design flaws. I wanted to touch a *little* more on what these flaws are and how they effect the developer.

    1. The JBoss ESB is by no means lightweight, it must be ran from within the JBoss Application Server. This tight coupling introduces some interesting concerns about supporting this internally, unless you have the staff with the JBoss know-how. So if you're looking into vesting time and money into this product, be aware of this tight coupling.

    2. Design issues:

    Diving deeper into the ESB design itself, you'll come across some instances in where little thought was given to design. Take for instance how the ActionPipelineProcessors are configured. When an ActionPipelineProcessor is created, the constructor must accept a ConfigTree class. ConfigTree with all due respect is a glorified map with some internal design leaking out to the developer in the form of public methods. When you think about it, the ActionPipelineProcessor is really a bean managed by a container. so why not call the setter methods directly on the class? At least this way the IDE (JBoss Developer Studio) can intelligently tell the developer what properties are available.

    Maybe you're thinking, "Okay, big deal I need to pull values out of a ConfigTree. So what?". Try reading the JavaDoc for JMSRouter and read up on 'message-prop-'. You'll start to see how this impacts the application design, readability and usability. 

    I touched on the Spring integration before and I wanted to add some additional feedback. When using the Spring integration that is provided by JBoss ESB, you're going to find some interesting versioning issues. I discovered this when I tried to use @Transactional with Spring 2.5.6. The Spring integration basically is an ESB service with a custom ActionPipelineProcessor called AbstractSpringAction. This class creates the ClassPathXmlApplicationContext directly using an embedded version of Spring. The version of Spring being used was 2.0.x. So if the Spring support gives you the warm and fuzzes, just be forewarned!

    There are many issues in the API itself that causes your code to be verbose. Let's take a look at a helper class (MessagePayloadProxy) that's designed to abstract the location of the message payload and "help make accessing the message payload a little more deterministic". The methods getPayload and setPayload thrown a checked exception called.. wait for it.. MessageDeliverException. Now you maybe asking yourself, why? I don't know either. I've read the source code and the reason doesn't match the checked exception either. Check out the reasoning http://bit.ly/bgfnWJ 

    I will admit this posting has a lot of frustration interwoven into it, but it's justified. I stand by my statement of encouraging people to evaluate Mule or ServiceMix vs. investing any time or money into this product.

    If you have any questions, comments, or etc. about this posting drop me your contact information and I'll be more than happy to speak with you.

    Best Regards,
    Richard L. Burton III

  5. Richard and Daniel

    We are sorry to hear that you are having so much trouble with SOA platform as we try to have a good working relationship with all our customers, partners and community members.

    Every case raised through our support channels is actively worked on by people who have intimate knowledge of our codebase, and we take all feedback seriously.  Many of the new features in SOA 5 are as a direct consequence of working closely with customers, partners and direct feedback from the community.  Our forums are active and we try very to listen to any and all positive criticism and suggestions.

    In answer to your criticism, it is true that the ESB is still based on the Rosetta architecture and some API decisions from that codebase do not suit all (even us).  We have publicly acknowledged this in the past and have never been shy when airing these issues, even when describing how we wish to address them.  We have a long history of open collaboration on the ESB dating back to when it first began in 2006 and are open to giving commit rights to contributors. Since this is open source, the benefits of open source are best served when the community helps itself by contributing ideas, code or use cases. We've seen JBossESB evolve a lot since the original Rosetta codebase and quite often that has been as a direct and indirect consequence of our community. If you have ideas you should raise them. If you have issues then you should create JIRAs. If you believe you can contribute code to resolving your problems then you should speak up and gain commit rights to helping yourselves as well as the larger JBossESB community.

    As part of any evaluation we would always encourage people to look at alternatives, there are numerous possibilities out there and not all of them suit every situation.  We are often brought in to these types of engagements and have a very good track record when it comes to comparisons with others.

    Every piece of software has its issues and we would encourage you to work with us, through the forums, committing code and the support portal which SOA entitles you to, in order to have them addressed.

    If you have any specific issues you wish to raise then you can always email me directly or move this across to our forums, where others can also participate.

    Kev
  6. I will say that JBoss does have good customer support based upon my experience. You won't here any complaints from me in that area.

    I do agree that no software is prefect. With that being said, there are two sort of problems that software can suffer from, buggy code and design/architectural problems.

    Out of these two, the latter is the most difficult to correct. It comes at cost finical to the client which makes upgrades slow, if at all finically possible.

    I know hindsight if 20/20, but I think Rosetta was a bad choice for the underpinnings of the ESB. I hope it's not powering the next release of the ESB.

    Although the project is OpenSource, I'm sure such a patch to architecture wouldn't be accepted since it has an impact to paying customers.

    The documentation is honestly fragmented in the sense that information pertaining to the bus may be found in the JBoss AS docs or in one of the guides written for the ESB. Which goes back to my initial issue about the tight coupling with the JBoss AS.

    To your last point, you may want to check your e-mail for one sent by me on Sat, Oct 24, 2009 at 11:07 PM. :)

    I've done a great deal of research on Mule, ServiceMix and JBoss ESB to obtain a clear understand of the key differences in each solution. The one thing that wasn't clear was, when does it make sense to select JBoss ESB over the other two mentioned.

    I don't intend to turn this thread in to some sort of hateful rant, that's why I followed up on my post with examples. 

    Richard L. Burton III
  7. Glad to hear that you like our support :)

    You will find no disagreement from us about the types of issues that can affect software, architectural problems are definitely the worst.  With that said we have made numerous changes to Rosetta over the years, always trying hard to minimise the effect on that codebase.  One thing I can say is that the ESB 5 codebase will not be based on Rosetta, this was discussed publicly at JBoss World last year, but that codebase will not be productised until SOA 6 is released.

    ESB does not have a tight coupling with the application server, although we do ship the SOA platform within that context.  As such the SOA documentation (and ours to an extent) will include aspects from AS.  I'm not sure which parts of the documentation you are specifically referring to, but if this is against soa then raise a support case, create a SOA issue and have it addressed.

    I have also looked through my email and can find no direct email from you, and many people will tell you how anal I am about keeping those ;), so am unsure what happened there.  Can you resend it?  What I did find was a comment you made on JBESB-2270 (29th October 2009).  If you are serious about those suggestions then please sign the contributor agreement and join in, http://www.jboss.org/contribute.  Take those suggestions to the developer forums and get them in for ESB 4.9.

    Kev
  8. Sorry, didn't handle that link properly.  The agreement can be found at http://www.jboss.org/contribute.

    Kev